Spanakis Manolis CS539 Computer Science Department 16/03/2005 Mobile Ad-hoc NETworks Routing Protocols

Spanakis ManolisCS539

Computer Science Department

16/03/2005

Mobile Ad-hoc NETworks Mobile Ad-hoc NETworks Routing ProtocolsRouting Protocols

Hmm, A MANETmakes sense.

Dad, you can useNelson if I am

too fast.Hi, Marge.I miss you.

I can hear u, Lisa.Can u hear me?

Yes. What areyou doing,

Nelson?

Be home early,Homer.

The Simpson'sThe Simpson's

IETF MANET Working Group

The Mobile Ad-hoc Networking (manet) Working Group is a chartered working group within the Internet Engineering Task Force (IETF) to investigate and develop candidate standard Internet routing support for mobile, wireless IP autonomous segments.

The charter and official IETF Home Page for manet are found at :http://www.ietf.org/html.charters/manet-charter.html

Description of Working Group Purpose of MANET working group

standardize IP routing protocol functionality suitable for wireless routing application withinboth static and dynamic topologies with increased dynamics due to nodemotion or other factors.

Approaches are intended to be: relatively lightweight in nature suitable for multiple hardware and wireless environments,

and address scenarios MANETs are deployed at the edges of an IP infrastructure hybrid mesh infrastructures (e.g., a mixture of fixed and

mobile routers) should also be supported by MANET specifications and management features.

Description of Working Group

Using mature components from previous work on experimental reactive and proactive protocols, the WG will develop two Standards track routing protocol specifications:

Reactive MANET Protocol (RMP) Proactive MANET Protocol (PMP)

Both IPv4 and IPv6 will be supported. Routing security requirements and issues will also be

addressed.

Goals and Milestones:Done Post as an informational Internet-Drafts a discussion of mobile ad-hoc networking and issues.

Done Agenda bashing, discussion of charter and of mobile ad hoc networking draft.

Done Discuss proposed protocols and issues. Redefine charter.

Done Publish Informational RFC on manet design considerations

Done Review the WG Charter and update

Done Submit AODV specification to IESG for publication as Experimental RFC

Done Develop I-D for potential common manet encapsulation protocol approach

Done Submit initial I-D(s) of candidate proposed routing protocols and design frameworks

Done Promote implementation, revision, and testing of initial proposed I-D(s)

Done Explore basic performance and implementation issues of initial approaches

Done Explore proposed proactive protocol design commonalities

Done Submit DSR specification to IESG for publication as Experimental RFC

Done Submit OLSR specification to IESG for publication as Experimental RFC

Done Submit TBRPF specification to IESG for publication as Experimental RFC

Done Develop a further focused problem statement and address an approach for a common engineering work effort

Done Reevaluate the WG's potential based on the problem statement consensus

Mar 05 Submit initial ID of RMP for WG review

Mar 05 Submit initial ID of PMP for WG review

Mar 05 Submit inital ID of generalized MANET flooding approach

Jun 05 Revise WG documents and review

Nov 05 Document initial implementation progress and experience Revise documents based upon implementation experience

Feb 06 Submit RMP specification and supporting documentation to IESG for publications as Proposed Standard

Feb 06 Submit PMP specification and supporting documentation to IESG for publications as Proposed Standard

Feb 06 Submit MANET flooding specification to IESG for publication as Experimental Standard

Mar 06 Review and update milestones

Current Status

Internet-Drafts:The Dynamic Source Routing Protocol for Mobile Ad

Hoc Networks (DSR) (264775 bytes)

Dynamic MANET On-demand Routing Protocol (DYMO) (48518 bytes)

Request For Comments:Mobile Ad hoc Networking (MANET): Routing Protoc

ol Performance Issues and Evaluation Considerations (RFC 2501) (28912 bytes)

Ad Hoc On Demand Distance Vector (AODV) Routing (RFC 3561) (90356 bytes)

Optimized Link State Routing Protocol (RFC 3626) (161265 bytes)

Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) (RFC 3684) (107963 bytes)

Mobile Ad Hoc Networks (MANET)

Networks formed by a collection of wireless mobile hosts

Without any pre-existing infrastructure or the aid of any centralized administration

Network characteristics change over timeRoutes between nodes may potentially contain

multiple hopsNumber of hosts in the network


May need to traverse multiple links to reach a destination


Mobility causes route changes

Why Ad Hoc Networks ?

Ease and Speed in deployment

Decreased dependence on infrastructure

Only possible solution to interconnect a group of nodes

Many Commercial Products available today

MANET Applications

Body Area Networkingbody sensors network,

Personal area Networkingcell phone, laptop, ear

phone, wrist watch Emergency operations

search-and-rescue (earthquakes, boats, airplanes…)

policing and fire fighting

Military environmentssoldiers, tanks, planes,

battlefield Civilian environments

taxi cab networkmeeting roomssports stadiumsboats, small aircraft

Variations

Traffic characteristics may differ in different ad hoc networks bit rate, reliability requirements, unicast, multicast, host-based

addressing, content-based addressing, capability-based addressing

Ad-hoc networks may co-exist and co-operate with infrastructure-based networks

Mobility characteristics may be different Speed, direction of movement, pattern of movement

Symmetric vs Asymmetric Nodes’ capabilities and responsibilities

Issues in Mobile Ad-hoc Networks

Limited wireless transmission range Broadcast nature of the wireless medium

Hidden terminal problem Packet losses due to transmission errors Mobility-induced route changes Mobility-induced packet losses Battery constraints Potentially frequent network partitions Ease of snooping on wireless transmissions

(security hazard)

What’s unique about a MANET ?

Moving nodes ever changing topology

Wireless links

various and volatile link quality

Pervasive (cheap) devices

Power constraints

Security Confidentiality, other attacks

MANET Protocol Zoo

Topology based routing Proactive approach, e.g., DSDV.

Reactive approach, e.g., DSR, AODV, TORA.

Hybrid approach, e.g., Cluster, ZRP.

Position based routing Location Services:

DREAM, Quorum-based, GLS, Home zone etc.

Forwarding Strategy:

Greedy, GPSR, RDF, Hierarchical, etc.

Recent Research TopicsRecent Research Topics

RoutingBetter metric, higher throughputA high-throughput path metric for multi-hop wireless routing. MobiCom 03.A high-throughput path metric for multi-hop wireless routing. MobiCom 03.

Transport Layer TCP performance: throughput, fairness, etc.Enhancing TCP fairness in ad-hoc networks using neighborhood RED. MobiCom 03.Enhancing TCP fairness in ad-hoc networks using neighborhood RED. MobiCom 03.Improving fairness among TCP flows crossing wireless ad-hoc and wired networks. Improving fairness among TCP flows crossing wireless ad-hoc and wired networks.

MobiHoc 03.MobiHoc 03.

MAC LayerMAC protocol for directional antennasA MAC protocol for full exploitation of directional antennas in ad-hoc wireless networks. A MAC protocol for full exploitation of directional antennas in ad-hoc wireless networks.

MobiHoc 03.MobiHoc 03.

Recent Research Topics (cont.)Recent Research Topics (cont.)

Security Reliable routing against malicious nodesAriadne: A secure on-demand routing protocol for ad-hoc networks. MobiCom 2002.Ariadne: A secure on-demand routing protocol for ad-hoc networks. MobiCom 2002.

Power ManagementPower saving and power controlAsynchronous wakeup for ad hoc networks. MobiHoc 2003. Asynchronous wakeup for ad hoc networks. MobiHoc 2003.

A power control MAC protocol for ad hoc network. MobiCom 2002.A power control MAC protocol for ad hoc network. MobiCom 2002.

Ad-hoc & p2p a Comparison

P2P is based on an IP network Ad-hoc is based on a mobile radio network Mobile Ad-hoc and Peer-to-Peer Networks hold

many similarities concerning their routing algorithms andnetwork management principles

Both have to provide networking functionalities in a completely unmanaged and decentralized environmentIe. To determine how queries (packets) are guided

through the network

Ad-hoc & p2p a Comparison

Ad-hoc & p2p - Differences

Ad-hoc & p2p - Similarities

Routing in Mobile Ad-Hoc Networks

Routing Overview

Mobile wireless hostsOnly subset within range at given timeWant to communicate with any other node

Routing Overview

Network with nodes, edges

Goal: transfer message from one node to anotherWhich is the “best” path?Who decides - source or

intermediate nodes?

msg

Which path?

Generally try to optimize one of the following:Shortest path (fewest hops)Shortest time (lowest latency)Shortest weighted path (utilize

available bandwidth, battery)

Who determines route?

Source (“path”) routing [Like airline travel]Source specifies entire route Intermediate nodes just forward to specified next hop

Destination (“hop-by-hop”) routing [Like postal service]Source specifies only destination in message header Intermediate nodes look at destination in header,

consult internal tables to determine appropriate next hop

MANET Routing

Standardization effort led by IETF Mobile Ad-hoc Networks (MANET) task grouphttp://www.ietf.org/html.charters/manet-cha

rter.html9 routing protocols in draft stage, 4 drafts

dealing with broadcast / multicast / flow issues

Other protocols being researchedutilize geographic / GPS info, ant-based

techniques, etc.

MANET Routing Properties

Qualitive PropertiesDistributed operation Loop FreedomDemand Based

OperationSecurity Sleep period operationUnidirectional link

support

Quantitative PropertiesEnd-to-End data

throughputDelaysRoute Acquisition timeOut of order delivery

(percentage)Efficiency

MANET Routing Properties

No distinction between “routers” and “end nodes”: all nodes participate in routing

No external network setup: “self-configuring” Efficient when network topology is dynamic

(frequent network changes – links break, nodes come and go)

Self Starting Adapt to network conditions

Why is Routing in MANET different ?

Host mobility link failure/repair due to mobility may have

different characteristics than those due to other causes

Rate of link failure/repair may be high when nodes move fast

New performance criteria are used route stability despite mobilityenergy consumptionhost position

Dynamic Solution much more difficult to be deployed

Routing Protocols

No Routing Plain Flooding (PF)

Proactive protocols: determine routes independent of traffic determine routes independent of traffic pattern, traditional link-state and distance-vector routing pattern, traditional link-state and distance-vector routing protocols are proactiveprotocols are proactive.. Destination Sequence Distance Vector (DSDV) Link State Routing

Reactive protocols: discover routes and maintain them only discover routes and maintain them only if needed.if needed. Dynamic Source Routing (DSR) Ad-hoc On-Demand Distance Vector Routing (AODV)

Hybrid protocols Zone Based Routing (ZBR)

Trade-Offs

Latency of route discovery Proactive protocols may have lower latency since routes

are maintained at all times Reactive protocols may have higher latency because a

route from X to Y will be found only when X attempts to send to Y

Overhead of route discovery/maintenance Reactive protocols may have lower overhead since

routes are determined only if needed Proactive protocols can (but not necessarily) result in

higher overhead due to continuous route updating Which approach achieves a better trade-off depends on the

traffic and mobility patterns

Routing ProtocolsRouting Protocols

Flooding for Data Delivery

B

A

S E

F

H

J

R

C

G

IK

Z

Y

M

N

L


B

A

S E

F

H

JC

G

IK

Z

YBroadcast transmission

M

N

L

R


B

A

S E

F

H

JC

G

IK

Z

Y

M

N

L

R


B

A

S E

F

H

JC

G

IK

Z

Y

M

N

L

R


B

A

S E

F

H

JC

G

IK

Z

Y

M

• Nodes J and K both broadcast packet P to node R• Since nodes J and K are hidden from each other, their transmissions may collide Packet P may not be delivered to node R at all, despite the use of flooding

N

L

R


B

A

S E

F

H

JC

G

IK

Z

Y

M

N

L

R


B

A

S E

F

H

JC

G

IK

• Flooding completed• Nodes unreachable from S do not receive packet• Flooding may deliver packets to too many nodes (in the worst case, all nodes reachable from sender may receive the packet)

Z

Y

M

N

L

R

Flooding for Data Delivery: Advantages

Simplicity Efficient than other protocols when rate of

information transmission is low enough overhead of explicit route

discovery/maintenance incurred is highersmall data packets infrequent transfersmany topology changes occur between

consecutive packet transmissions Potentially higher reliability of data delivery

Flooding for Data Delivery: Disadvantages

Very high overheadData packets may be delivered to too many

nodes who do not need to receive them

Lower reliability of data deliveryIf Broadcasting is unreliable (ie. 802.11 MAC)

Flooding of Control Packets

Many protocols perform (potentially limited) flooding of control packets, instead of data packets

The control packets are used to discover routes

Discovered routes are subsequently used to send data packet(s)

Dynamic Source Routing

Draft RFC at http://www.ietf.org/internet-drafts/draft-ietf-manet-dsr-07.txt

Source routing: entire path to destination supplied by source in packet headerUtilizes extension header following

standard IP header to carry protocol information (route to destination, etc.)

DSR Protocol Activities

Route discoveryUndertaken when source needs a route

to a destinationRoute maintenance

Detect network topology changesUsed when link breaks, rendering

specified path unusableRouting (easy!)

Details

Intermediate nodes cache overheard routes “Eavesdrop” on routes contained in headersReduces need for route discovery

Intermediate node may return Route Reply to source if it already has a path storedEncourages “expanding ring” search for route

Details (cont.)

Destination may need to discover route to source to deliver Route Replypiggyback Route Reply onto new Route Request

to prevent “infinite loop”

Route Request duplicate rejection:Source includes identification number in Route

RequestPartial path inspected for “loop”

Route Maintenance

Used when link breakage occurs Link breakage may be detected using link-layer ACKs,

“passive ACKs”, DSR ACK request 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 RequestPiggybacks Route Error on new Route Request to

clear intermediate nodes’ route caches, prevent return of invalid route

Issues

ScalabilityDiscovery messages broadcast throughout

network Broadcast / Multicast

Use Route Request packets with data includedDuplicate rejection mechanisms prevent “storms”

Multicast treated as broadcast; no multicast-tree operation definedScalability issues

Route Discovery in DSR

B

A

S E

F

H

J

D

C

G

IK

Z

Y

Represents a node that has received RREQ for D from S

M

N

L


B

A

S E

F

H

J

D

C

G

IK

Represents transmission of RREQ

Z


M

N

L

[S]

[X,Y] Represents list of identifiers appended to RREQ


B

A

S E

F

H

J

D

C

G

IK

• Node H receives packet RREQ from two neighbors: potential for collision

Z

Y

M

N

L

[S,E]

[S,C]


B

A

S E

F

H

J

D

C

G

IK

• 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

L

[S,C,G]

[S,E,F]


B

A

S E

F

H

J

D

C

G

IK

Z

Y

M

• Nodes J and K both broadcast RREQ to node D• Since nodes J and K are hidden from each other, their transmissions may collide

N

L

[S,C,G,K]

[S,E,F,J]


B

A

S E

F

H

J

D

C

G

IK

Z

Y

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

M

N

L

[S,E,F,J,M]

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)

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 headerhence the name source routing

Intermediate nodes use the source route included in a packet to determine to whom a packet should be forwarded

Route Reply in DSR

B

A

S E

F

H

J

D

C

G

IK

Z

Y

M

N

L

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

• Node D sends back a Reply (RREP) to S with the pathNOTE: If node D does not know a rout back to S it might be necessary to start it’s own rout discovery to S.

Data Delivery in DSR

B

A

S E

F

H

J

D

C

G

IK

Z

Y

M

N

L

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

Packet header size grows with route length

DSR: Advantages

Routes maintained only between nodes who need to communicatereduces overhead of route maintenance

Route caching can further reduce route discovery overhead

A single route discovery may yield many routes to the destination, due to intermediate nodes replying from local caches

Packet header size grows with route length due to source routing

Flood of route requests may potentially reach all nodes in the network

Care must be taken to avoid collisions between route requests propagated by neighboring nodes insertion of random delays before forwarding

RREQ

DSR: Disadvantages

DSR: Disadvantages

An intermediate node may send Route Reply using a stale cached route, thus polluting other caches

Increased contention if too many route replies come back due to nodes replying using their local cacheRoute Reply Storm problemReply storm may be eased by preventing a

node from sending RREP if it hears another RREP with a shorter route

Ad-hoc On-demand Distance Vector Routing

Draft RFC at http://www.ietf.org/internet-drafts/draft-ietf-manet-aodv-10.txt

“Hop-by-hop” protocol: intermediate nodes use lookup table to determine next hop based on destination

Utilizes only standard IP header

AODV Protocol Activities

Route discoveryUndertaken whenever a node needs a

“next hop” to forward a packet to a destination

Route maintenanceUsed when link breaks, rendering next

hop unusableRouting (easy!)

Route Discovery

Route Request:Source broadcasts Route Request (RREQ)

message for specified destinationIntermediate node Forward message toward

destination Route Reply

Destination unicasts Route Reply msg to sourceIntermediate node create next-hop entry for

destination and forward the replyIf source receives multiple replies, uses one

with lowest hop count

Route Maintenance

Used when link breakage occurs Detecting node may attempt “local repair” Route Error (RERR) message generated

Contains list of unreachable destinationsSent to “precursors”: neighbors who recently

sent packet which was forwarded over broken linkPropagated recursively

Route Requests in AODV

B

A

S E

F

H

J

D

C

G

IK

Z

Y

M

N

L


B

A

S E

F

H

J

D

C

G

IK

Z


M

N

L


B

A

S E

F

H

J

D

C

G

IK

Z

Y

M

N

L

Reverse Path Setup in AODV

B

A

S E

F

H

J

D

C

G

IK

• 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

L


B

A

S E

F

H

J

D

C

G

IK

Z

Y

M

N

L


B

A

S E

F

H

J

D

C

G

IK

Z

Y

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

M

N

L

Route Reply in AODV

B

A

S E

F

H

J

D

C

G

IK

Z

Y

Represents links on path taken by RREP

M

N

L

Route Reply in AODV

An intermediate node (not the destination) may also send a Route Reply (RREP) provided that it knows a more recent path than the one previously known to sender S

To determine whether the path known to an intermediate node is more recent, destination sequence numbers are used

The likelihood that an intermediate node will send a Route Reply when using AODV is not as high as DSR

Forward Path Setup in AODV

B

A

S E

F

H

J

D

C

G

IK

Z

Y

M

N

L

Forward links are setup when RREP travels alongthe reverse path

Represents a link on the forward path

Data Delivery in AODV

B

A

S E

F

H

J

D

C

G

IK

Z

Y

M

N

L

• Routing table entries used to forward data packet.

• Route is Route is notnot included in packet header. included in packet header.

DATA

Why Sequence Numbers in AODV

To avoid using old/broken routes To determine which route is newer

To prevent formation of loops

Assume that A does not know about failure of link C-D because RERR sent by C is lost

Now C performs a route discovery for D. Node A receives the RREQ (say, via path C-E-A)

Node A will reply since A knows a route to D via node B Results in a loop (for instance, C-E-A-B-C )

A B C D

E

Summary: AODV

Routes need not be included in packet headers Nodes maintain routing tables containing

entries only for routes that are in active use At most one next-hop per destination

maintained at each nodeDSR may maintain several routes for a single

destination Unused routes expire even if topology does not

change

Hybrid Protocols

Zone Routing Protocol (ZRP)

Zone routing protocol combines

Proactive protocol: which pro-actively updates network state and maintains route regardless of whether any data traffic exists or not

Reactive protocol: which only determines route to a destination if there is some data to be sent to the destination

ZRP: Example withZone Radius = d = 2

SCA

EF

B

D

S performs routediscovery for D

Denotes route request

ZRP: Example with d = 2

SCA

EF

B

D


Denotes route reply

E knows route from E to D, so route request need not beforwarded to D from E

ZRP: Example with d = 2

SCA

EF

B

D


Denotes route taken by Data

Implementation Issues

Implementation Issues:Where to Implement Ad Hoc Routing

Link layer

Network layer

Application layer

Issues inMobile Ad Hoc Networking

Issues other than routing have received much less attention so far Other interesting problems:

Address assignment problem MAC protocols Improving interaction between protocol layers Distributed algorithms for MANET QoS issues Applications for MANET

Algorithms for dynamic networks Security

Privacy, Authentication, Authorization, Data integrity Ad-Hoc Sensor networks

Addressing based on data (or function) instead of name, “send this packet to a temperature sensor”

Related Standards Activities

Internet Engineering Task Force (IETF) Activities

IETF manet (Mobile Ad-hoc Networks) working grouphttp://www.ietf.org/html.charters/manet-charter.html

IETF mobileip (IP Routing for Wireless/Mobile Hosts) working group http://www.ietf.org/html.charters/mobileip-charter.ht

ml IETF PILC (Performance Implications of Link

Characteristics) working grouphttp://www.ietf.org/html.charters/pilc-charter.htmlhttp://pilc.grc.nasa.gov

Related Standards Activities

BlueToothhttp://www.bluetooth.com

HomeRFhttp://www.homerf.org

IEEE 802.11http://grouper.ieee.org/groups/802/11/

Hiperlan/2http://www.etsi.org/technicalactiv/hiperlan2.htm

DYMO

Dynamic MANET On-demand Routing Protocol (DYMO) Ian Chakeres Elizabeth Belding-Royer Charlie Perkins

The Dynamic MANET On-demand (DYMO) routingprotocol is intended for use by mobile nodes in wireless multihop networks. It offers quick adaptation to dynamic conditions, low processing and memory overhead, low network utilization, and determines unicast routes between nodes within the network.

The Dynamic MANET On-demand (DYMO) routing protocol enables dynamic, reactive, multihop routing between participating nodes wishing to communicate. The basic operations of the protocol are route discovery and management. During route discovery the originating node causes dissemination of a Routing Element (RE) throughout the network to find the target node. During dissemination each intermediate node creates a route to the originating node. When the target node receives the RE it responds with RE unicast toward originating node. During propagation each node creates a route to the target node. When the originating node is reached routes have been established between the originating node and the target node in both directions. In order to react quickly to changes in the network topology nodes should maintain their routes and monitor their links. When a packet is received for a route that is no longer available the source of the packet should be notified. A Route Error (RERR) is sent to the packet source to indicate the current route is broken. Once the source receives the RERR, it will re-initiate route discovery if it still has packets to deliver. In order to enable extension of the base specification, DYMO defines the handling of unsupported extensions. By defining default handling, future extensions are handled in a predetermined understood fashion. DYMO uses sequence numbers to ensure loop freedom [3]. All DYMO packets are transmitted via UDP on port TBD. Chakeres, et al. Expires July 5, 2005

Goals

Create a unicast route Simple, small

Easy to implement Extendable

Enhancements & optimizations IPv4 and IPv6 Basic internet connectivity Use what we know

Route Discovery

Routing Element (RE)Simple, common processingREBlock

RREQ => RE A=1 MANETcast RREP => RE A=0 Unicast hop-by-hop Path accumulation

Optional accumulation, processing and transmission

Route Maintenance

Avoid expiring good routesUpdate reverse route lifetime on data

receptionUpdate forward route lifetime on data

transmission Inform sources of broken routes quickly

Active links must be monitoredSeveral mechanisms available

Route Error (RERR) Optional additional invalid routes

DYMO Short Term Goals

dymo-00 availablefeedback already received (more expected)dymo-01soon

MANET list discussion Simple, quick implementation

Looking for DYMO implementersSimulators and various OSPlease contact us

Documents

Spanakis Manolis CS539 Computer Science Department 16/03/2005 Mobile Ad-hoc NETworks Routing Protocols