dynamic source routing protocol

8/7/2019 Dynamic Source Routing Protocol

1/35

DYNAMIC SOURCE ROUTING PROTOCOL

Submitted in partial fulfillment of the requirement of University of MumbaiFor the Degree of

BachelorofEngineering(Computer Engineering )

By

PranavBhujle

Ashish Mathew

Aditya Prasad

Pankajkumar Thakur

under the guidance of

Prof. Payel Gupta

DEPARTMENT OF COMPUTER ENGINEERING

PILLAIS INSTITUTE OF INFORMATION TECHNOLOGY,

ENGINEERING, MEDIA STUDIES & RESEARCH

NEW PANVEL 410 206


2/35

1. INTRODUCTION

Mobile hosts such as notebook computers, featuring powerfulCPUs, large main memories,

hundreds of megabytesof disk space, multimedia sound capabilities, and colour displays,arenow easily affordable and are becoming quitecommon in everyday business and personal life.

At thesame time, network connectivity options for use with mobilehosts have increased

dramatically, including support fora growing number of wireless networking products

basedon radio and infrared.With this type of mobile computing equipment, there isa natural

desire and ability to share information betweenmobile users. Often, mobile users will meet

under circumstancesthat are not explicitly planned for and in whichno connection to a

standard wide-area network such as is available. For example, employees may

findthemselves together in a meeting room; friends or businessassociates may run into each

other in an airport terminal; ora collection of computer science researchers may gather ina

hotel ballroom for a workshop or conference. Requiringeach user to connect to a wide-area

network in such situations,only to communicate with each other, may not bepossible due to

lack of facilities, or may be inconvenientor impractical due to the time or expense required

for suchconnection.

These kinds of networks of mobile hosts have becomeknown as ad hoc networks. An ad

hoc network is a collectionof wireless mobile hosts forming a temporary networkwithout the

aid of any centralized administration or standardsupport services regularly available on the

wide-areanetwork to which the hosts may normally be connected.

Some form of routing protocol is in general necessaryin such an environment, since two

hosts that may wish toexchange packets might not be able to communicate directly.

For example, Figure 1 illustrates a simple ad hocnetwork of three mobile hosts using

wireless network interfaces.Host C is not within the range of host As wirelesstransmitter

(indicated by the circle around A) and hostA is not within the range of host Cs wireless

transmitter.IfA andC wish to exchange packets, they may inthis case enlist the services of

host B to forward packetsfor them, since B is within the overlap betweenAsrange and Cs

range. The maximum number of networkhops needed to reach another mobile host in any

practicalad hoc network is likely to be small, but may oftenbe greater than one as shown here.


3/35

Figure 1:An ad hoc network of threewireless mobile hosts

The routing problemin a real ad hoc network may be even more complicatedthan this

example suggests, due to the inherent nonuniformpropagation characteristics of wireless

transmissionsand since any or all of the hosts involved may move atany time.

The Dynamic Source Routing protocol (DSR) [3][1] is a simple and efficient routing

protocol designed specifically for use in multi-hop wireless ad hoc networks of mobile nodes.

Using DSR, the network is completely self-organizing and self-configuring, requiring no

existing network infrastructure or administration. Network nodes (computers) cooperate to

forward packets for each other to allow communication over multiple hops between nodes

not directly within wireless transmission range of one another. As nodes in the network move

about or join or leave the network, and as wireless transmission conditions such as sources of

interference change, all routing is automatically determined and maintained by the DSR

routing protocol. Since the number or sequence of intermediate hops needed to reach any

destination may change at any time, the resulting network topology may be quite rich and

rapidly changing.

The DSR protocol allows nodes to dynamically discover a source route across multiple

network hopsto any destination in the ad hoc network. Each data packet sent then carries in

its header the completeordered list of nodes through which the packet must pass, allowing

packet routing to be trivially loop-free and avoiding the need for up-to-date routing

information in the intermediate nodes through which the packet is forwarded. By including

this source route in the header of each data packet, other nodes forwarding or overhearing any

of these packets may also easily cache this routing information for future use. This DSR


4/35

protocol is a part of the Monarch Project at Carnegie Mellon University [3], a long-term

research project that is developing networking protocols and protocol interfaces to allow truly

seamless wireless and mobile networking. The Monarch Project is named in reference to the

migratory behaviour of the monarch butterfly, and can also be considered as an acronym for

Mobile Networking Architectures. The scope of the research includes protocol design,

implementation, performance evaluation, and usage-based validation, spanning areas ranging

roughly from portions of the ISO Data Link layer (layer 2) through the Presentation layer

(layer 6).

Comparing DSR protocol to other ad-hoc network protocols, it is a routing protocol that

had very low overhead yet was able to react quickly to changes in the network, providing

highly reactive service to help ensure successful delivery of data packets in spite of node

movement or other changes in network conditions. The protocol specification for DSR has

also been submitted to the Internet Engineering Task Force (IETF), the principal protocol

standards development body for the Internet, and is currently one of the protocols under

consideration in the IETF Mobile Ad Hoc Networks (MANET) Working Group for adoption

as an Internet Standard for IP routing in ad hoc networks.

This paper describes the design of the DSR protocol. Literature Survey and related work

on the DSR protocol is described in Section 2. Section 3 of this paper discusses our

assumptions in the design of DSR. In Section 4, we present the design of the DSR protocol

and describe the resulting important properties of this design. In particular, we describe here

the design of the two mechanisms that make up the operation of DSR, Route Discoveryand

Route Maintenance; we also discuss the use of DSR in supporting heterogeneous networks

and interconnecting to the Internet, and describe the current support present in DSR for

routing of multicast packets in ad hoc networks. We also discuss the header format of the

DSR protocol.


5/35

2. LITERATURE SURVEY AND RELATED WORK

Research in the area of routing in multi-hop wireless ad hoc networks dates back at least to

1973, whenthe U.S. Defence Advanced Research Projects Agency (DARPA) began the

Packet Radio Network (PRNET) project.PRNET and its successor, the Survivable Adaptive

Networks (SURAN)project, generated a substantial number of fundamental results in this

area. With the increasingcapabilities and decreasing costs of small, portable computers such

as laptops and PDAs (PersonalDigital Assistants), and with the increasing availability of

inexpensive wireless network interface devicessuch as wireless LAN interfaces packaged as

PCMCIA PC Cards, a growing number of other researchprojects in ad hoc networking have

developed.

In our literature survey here, we concentrate on research specifically related to the DSR

protocol.The initial design of the DSR protocol, including our basic Route Maintenance andRoute Discoverymechanisms, was first published in December 1994, with significant

additional design details and initialsimulation results published in early 1996 [3]. As noted in

Section 1, the designspecification for DSR has also been submitted to the MANET (Mobile

Ad Hoc Networks) Working Groupof the IETF (Internet Engineering Task Force) in their

efforts to standardize a protocol for routing of IPpackets in an ad hoc network [1].The

originalmotivation in the design of DSR came fromthe operation of theAddressResolution

Protocol (ARP) used in the TCP/IP suite of protocols in the Internet. ARP is used on

Ethernets andother types of networks to find the link-layer MAC address of a node on the

same subnet as the sender.

A node sending a packet to a local IP address for which it does not yet have the MAC

address cached,broadcasts an ARP REQUEST packet on the local subnet link, giving the IP

address of the node it is lookingfor; that node responds with an ARP REPLY packet, giving

its MAC address, and all other nodes ignore theREQUEST. If all nodes in an ad hoc network

are within wireless transmission range of each other, this is theonly routing protocol needed

for the ad hoc network. DSR extends this basic behaviour of ARP by allowingthe REQUEST

packet (the ROUTE REQUEST rather than an ARP REQUEST) to be propagated multiple

hopsaway by being forwarded by neighbour nodes, with the ultimate ROUTE REPLY being

returned over multiplehops back to the initiator of the REQUEST.


6/35

DSRs nonpropagating ROUTE REQUEST packets are indeed quite similar to the basic

ARP REQUESTbehaviour, except that a mobile node may answer the ROUTEREQUEST

fromits cache,whereasARP REQUESTSare normally only answered by the target node itself.

The original implementation of DSR in 1997 also was structured as an extension of

ARP,integrated into the existing ARP implementation in the FreeBSD Unix kernel

[FreeBSD], using an extensionof the ARP REQUEST and ARP REPLY packet formats; as

described in Sections 4.8, however, it wasultimately decided to operate DSR at the network

layer rather than at the link layer, to allow routing betweendifferent heterogeneous networks

all forming a single ad hoc network.

DSR is also similar in approach to the source routing discovery mechanism used in the

IEEE 802 SRTbridge standard, and related mechanisms have also been used in other systems

includingFLIP and SDRP. The amateur radio community has also worked extensively with

routing in wireless networks of (sometimes) mobile hosts, holding an annual packet radio

computer networking conference sponsoredby the American Radio Relay League (ARRL)

since 1981. Amateur packet radio networking originallyused only source routing, with

explicit source routes constructed by the user, although some had consideredthe possibility of

a more dynamic source routing scheme. A system known as NET/ROMwas also developed to

allow the routing decisions to be automated, using a form of distance vector routingprotocol

rather than source routing. NET/ROMalso allows updating of its routingtable based on the

source address information in the headers of packets that it receives [6].

Recently, a number of other protocols have been structured around mechanisms similar

to the RouteDiscovery and Route Maintenance mechanisms in DSR. For example, the Signal

Stability-Based Adaptiverouting protocol (SSA) and the Associativity Based Routing

protocol (ABR) eachdiscover routes on demand in a way similar to Route Discovery in DSR,

but each attempts to select onlylong-lived links between nodes where possible; favouring

long-lived links helps avoid routes breaking soonafter discovering them but may result in use

of routes over a greater number of hops than the shortest routesavailable. ABR also adds

overhead for periodic beacon packets required to monitor link stability. TheAd Hoc On-

Demand Distance Vector routing protocol (AODV) [4] uses mechanisms similar toDSRs

Route Discovery and Route Maintenance, but it uses them to create hop-by-hop routes rather

thansource routes as is done in DSR; this use of hop-by-hop routes avoids the source routing


7/35

header overheadof DSR but prevents or makes difficult many of the route caching and other

Route Discovery optimizationspresent in DSR and prevents AODV from supporting uni-

directional links between nodes. The ZoneRouting Protocol (ZRP) defines a routing zone

around each individual node,with a periodic (proactive) protocol such as distance vector or

link state for routing within a zone and anon-demand protocol such as DSR for routing

between zones; the use of routing zones reduces some aspectsof the overhead of the Route

Discovery procedure as in DSR but adds the overhead of maintaining zonemembership and

routing information within each zone. ZRP may also fail at times to successfully

deliverpackets with highly mobile nodes, since the routing protocol within a zone does not

utilize on-demandoperation.

Finally, DSR has recently been used as a basis for further work by other researchers,

including suggestedimprovements to the Route Discovery mechanism. For example, Ko and

Vaidya [6] have proposedan optimization to Route Discovery, known as Location-Aided

Routing (LAR), that uses knowledge of thephysical (geographical) location of the target node

of the Route Discovery (e.g., from GPS, the GlobalPositioning System) to narrow the area of

the network over which the ROUTE REQUEST packets must bepropagated. Castneda and

Das [2] have proposed a similar Route Discovery optimizationthat uses only logical

(topological) location information, not physical location information, and thus doesnot

require access to GPS. Above the routing layer, Holland and Vaidya [6] have recentlystudied

the behaviour of TCP in ad hoc networks, using DSR as a routing protocol; their work added

explicitinteraction between TCP and the Route Discovery and Route Maintenance

mechanisms to allow TCP tocorrectly react to a route failure rather than treating it as network

congestion, and to allow TCP to restartsending as soon as a new route to the destination is

discovered.


8/35

3. ASSUMPTIONS

We assume that all nodes wishing to communicate with other nodes within the ad hoc

network are willingto participate fully in the protocols of the network. In particular, each

node participating in the networkshould also be willing to forward packets for other nodes in

the network.

We refer to the minimum number of hops necessary for a packet to reach from any node

located at oneextreme edge of the ad hoc network to another node located at the opposite

extreme, as the diameterof thead hoc network. We assume that the diameter of an ad hoc

network will often be small (e.g., perhaps 5 or 10 hops), but may often be greater than 1.

Packets may be lost or corrupted in transmission on the wireless network. A node

receiving a corruptedpacket can detect the error and discard the packet.

Nodeswithin the ad hoc networkmay move at any time without notice, andmayevenmove continuously,but we assume that the speed with which nodes move is moderate

with respect to the packet transmissionlatency and wireless transmission range of the

particular underlying network hardware in use. In particular,DSR can support very rapid rates

of arbitrary node mobility, but we assume that nodes do not continuouslymove so rapidly as

to make the flooding of every individual data packet the only possible routing protocol.

We assume that nodes may be able to enablepromiscuous receive mode on their wireless

networkinterface hardware, causing the hardware to deliver every received packet to the

network driver softwarewithout filtering based on link-layer destination address. Although

we do not require this facility, it is,for example, common in current LAN hardware for

broadcast media including wireless, and some of our optimizations can take advantage of its

availability. Use of promiscuous mode does increase the softwareoverhead on the CPU, but

we believe that wireless network speeds are more the inherent limiting factorto performance

in current and future systems; we also believe that portions of the protocol are suitablefor

implementation directly within a programmable network interface unit to avoid this overhead

on theCPU [3]. Use of promiscuous mode may also increase the power consumption of the

networkinterface hardware, depending on the design of the receiver hardware, and in such

cases, DSR can easily beused without the optimizations that depend on promiscuous receive

mode, or can be programmed to onlyperiodically switch the interface into promiscuous mode.


9/35

Wireless communication ability between any pair of nodes may at times not work

equally well in bothdirections, due for example to differing antenna or propagation patterns

or sources of interference aroundthe two nodes. That is, wireless communications between

each pair of nodes willin many cases be able to operate bi-directionally, but at times the

wireless link between two nodes may beonly uni-directional, allowing one node to

successfully send packets to the other while no communicationis possible in the reverse

direction. Although many routing protocols operate correctly only over bidirectionallinks,

DSR can successfully discover and forward packets over paths that contain uni-

directionallinks. Some MAC protocols, however, such as MACA, MACAW, or IEEE802.11

[5], limit unicast data packet transmission to bi-directional links, due to the required

bidirectionalexchange of RTS and CTS packets in these protocols and due to the link-level

acknowledgementfeature in IEEE 802.11; when used on top of MAC protocols such as these,

DSR can take advantage ofadditional optimizations, such as the route reversal optimization

described below.

Each node selects asingle IP address by which it will be known in the ad hoc network.

Although asingle node may have many different physical network interfaces, which in a

typical IP network wouldeach have a different IP address, we require each node to select one

of these and to use only that addresswhen participating in the DSR protocol. This allows each

node to be recognized by all other nodes in thead hoc network as a single entity regardless of

which network interface they use to communicate with it. Inkeeping with the terminology

used by Mobile IP [3], we refer to the address bywhich each mobile node is known in the ad

hoc network as the nodes home address, as this address wouldtypically be the address that

the node uses while connected to its home network (rather than while away,being a member

of the ad hoc network). Each nodes home address may be assigned by any mechanism (e.g.,

static assignment or use of DHCP for dynamic assignment), although the method ofsuch

assignment is outside the scope of the DSR protocol.


10/35

4. DETAILED DESCRIPTIONOF THE DSR PROTOCOL

4.1 Overviewand Important Properties ofthe Protocol

TheDSR protocol is composed of twomechanisms thatwork together to allowthe discovery

and maintenanceof source routes in the ad hoc network:

Route Discovery is the mechanismby which a node S wishing to send a packet to a

destination node Dobtains a source route to D. Route Discovery is used only when S attempts

to send a packet to D anddoes not already know a route to D

Route Maintenance is the mechanism by which node S is able to detect, while using a

source routeto D, if the network topology has changed such that it can no longer use its route

to D because a linkalong the route no longer works. When Route Maintenance indicates a

source route is broken, S canattempt to use any other route it happens to know to D, or can

invoke Route Discovery again to find anew route. Route Maintenance is used only when S isactually sending packets to D.

Route Discovery and Route Maintenance each operate entirely on demand. In particular,

unlike otherprotocols, DSR requires no periodic packets ofany kindat any levelwithin the

network. For example, DSRdoes not use any periodic routing advertisement, link status

sensing, or neighbour detection packets, and doesnot rely on these functions from any

underlying protocols in the network. This entirely on-demand behaviourand lack of periodic

activity allows the number of overhead packets caused by DSR to scale all the way downto

zero, when all nodes are approximately stationary with respect to each other and all routes

needed forcurrent communication have already been discovered. As nodes begin to move

more or as communicationpatterns change, the routing packet overhead of DSRautomatically

scales to only that needed to track theroutes currently in use.

In response to a single Route Discovery (as well as through routing information from

other packetsoverheard), a node may learn and cache multiple routes to any destination. This

allows the reaction torouting changes to be much more rapid, since a node with multiple

routes to a destination can try anothercached route if the one it has been using should fail.

This caching ofmultiple routes also avoids the overheadof needing to perform a new Route

Discovery each time a route in use breaks.


11/35

The operation of Route Discovery and Route Maintenance in DSR are designed to allow

uni-directionallinks and asymmetric routes to be easily supported. In particular, as noted in

Section 3, in wireless networks,it is possible that a link between two nodes may not work

equally well in both directions, due to differingantenna or propagation patterns or sources of

interference. DSR allows such uni-directional links to be usedwhen necessary, improving

overall performance and network connectivity in the system.

DSR also supports internetworking between different types of wireless networks,

allowing a sourceroute to be composed of hops over a combination of any types of networks

available [1][6]. Forexample, some nodes in the ad hoc network may have only short-range

radios, while other nodes have bothshort-range and long-range radios; the combination of

these nodes together can be considered by DSR as asingle ad hoc network. In addition, the

routing of DSR has been integrated into standard Internet routing,where a gateway node

connected to the Internet also participates in the ad hoc network routing protocols;and has

been integrated intoMobile IP routing, where such a gateway node also serves the role of

aMobile IPforeign agent [3][6].

4.2 Basic DSR Route Discovery

When some node S originates a new packet destined to some other node D, it places in the

header of thepacket asource route giving the sequence of hops that the packet should follow

on its way to D. Normally,S will obtain a suitable source route by searching itsRoute Cache

of routes previously learned, but if noroute is found in its cache, it will initiate the Route

Discovery protocol to dynamically find a new route to D.

In this case, we call S the initiatorand D the targetof the Route Discovery.

For example, Figure 2 illustrates an example Route Discovery, in which a node A is

attempting todiscover a route to node E. To initiate the Route Discovery, A transmits a

ROUTE REQUEST message asa single local broadcast packet, which is received by

(approximately) all nodes currently within wirelesstransmission range ofA. Each ROUTE

REQUEST message identifies the initiator and target of the RouteDiscovery, and also

contains a unique request id, determined by the initiator of the REQUEST. Each

ROUTEREQUEST also contains a record listing the address of each intermediate node


12/35

Figure 2: Route Discovery example: Node A is the initiator, and node E is the target.

through which this particularcopy of the ROUTE REQUEST message has been forwarded.

This route record is initialized to an empty listby the initiator of the Route Discovery.

When another node receives a ROUTE REQUEST, if it is the target of the Route

Discovery, it returnsa ROUTE REPLY message to the initiator of the Route Discovery,

giving a copy of the accumulated routerecord from the ROUTE REQUEST; when the

initiator receives this ROUTE REPLY, it caches this route in itsRoute Cache for use in

sending subsequent packets to this destination. Otherwise, if this node receiving theROUTE

REQUEST has recently seen another ROUTE REQUEST message from this initiator bearing

this samerequest id, or if it finds that its own address is already listed in the route record in

the ROUTE REQUESTmessage, it discards the REQUEST. Otherwise, this node appends its

own address to the route record in theROUTE REQUEST message and propagates it by

transmitting it as a local broadcast packet (with the samerequest id).

In returning the ROUTE REPLY to the initiator of the Route Discovery, such as node E

replying back to Ain Figure 1, node E will typically examine its own Route Cache for a route

back to A, and if found, will useit for the source route for delivery of the packet containing

the ROUTE REPLY. Otherwise, Emay perform itsown Route Discovery for target node A,

but to avoid possible infinite recursion of Route Discoveries, it mustpiggyback this ROUTE

REPLY on its own ROUTE REQUEST message for A. It is also possible to piggybackother

small data packets, such as a TCP SYN packet, on a ROUTE REQUEST using this

samemechanism. Node E could also simply reverse the sequence of hops in the route record

that it trying tosend in the ROUTE REPLY, and use this as the source route on the packet

carrying the ROUTE REPLY itself.For MAC protocols such as IEEE 802.11 that require a

bi-directional frame exchange as part of the MACprotocol [5], this route reversal is preferred

as it avoids the overhead of a possible second RouteDiscovery, and it tests the discovered

route to ensure it is bi-directional before the Route Discovery initiatorbegins using the route.


13/35

However, this technique will prevent the discovery of routes using uni-directionallinks. In

wireless environments where the use of uni-directional links is permitted, such routes may in

somecases be more efficient than those with only bi-directional links, or they may be the only

way to achieveconnectivity to the target node.

When initiating a Route Discovery, the sending node saves a copy of the original packet

in a local buffercalled the SendBuffer. The Send Buffer contains a copy of each packet that

cannot be transmitted by thisnode because it does not yet have a source route to the packets

destination. Each packet in the Send Bufferis stamped with the time that it was placed into

the Buffer and is discarded after residing in the Send Bufferfor some timeout period; if

necessary for preventing the Send Buffer from overflowing, a FIFO or otherreplacement

strategy can also be used to evict packets before they expire.

While a packet remains in the Send Buffer, the node should occasionally initiate a new

Route Discoveryfor the packets destination address. However, the node must limit the rate at

which such new RouteDiscoveries for the same address are initiated, since it is possible that

the destination node is not currentlyreachable. In particular, due to the limited wireless

transmission range and the movement of the nodes inthe network, the network may at times

become partitioned, meaning that there is currently no sequence ofnodes through which a

packet could be forwarded to reach the destination. Depending on the movementpattern and

the density of nodes in the network, such network partitions may be rare or may be common.

If a new Route Discovery was initiated for each packet sent by a node in such a situation,

a large numberof unproductive ROUTE REQUEST packets would be propagated throughout

the subset of the adhoc networkreachable from this node. Inorder to reduce the overhead from

such Route Discoveries, we use exponential back-off to limit the rate at which new Route

Discoveries may be initiated by any node for the same target. If the node attempts to send

additional data packets to this same node more frequently than this limit, thesubsequent

packets should be buffered in the Send Buffer until a ROUTE REPLY is received, but the

node mustnot initiate a new Route Discovery until the minimum allowable interval between

new Route Discoveriesfor this target has been reached. This limitation on the maximum rate

of Route Discoveries for the sametarget is similar to the mechanism required by Internet

nodes to limit the rate at which ARP REQUESTs aresent for any single target IP address.


14/35

Figure 3: Route Maintenance example: Node C is unable to forward a packet from A to E

over its link to next hop D.

4.3Basic DSR Route Maintenance

When originating or forwarding a packet using a source route,each node transmitting the

packet is responsiblefor confirming that the packet has been received by the next hop along

the source route; the packet isretransmitted (up to a maximum number of attempts) until this

confirmation of receipt is received. Forexample, in the situation illustrated in Figure 2, node

A has originated a packet forE using a source routethrough intermediate nodes B, C, and D.

In this case, node A is responsible for receipt of the packet at B,node B is responsible forreceipt at C, node C is responsible for receipt at D, and node D is responsible forreceipt

finally at the destination E. This confirmation of receipt in many cases may be provided at no

cost toDSR, either as an existing standard part of theMAC protocol in use (such as the link-

level acknowledgementframe defined by IEEE 802.11 [5]), or by a passive acknowledgement

(in which, for example, B confirms receipt at C by overhearing C transmit the packet to

forward it on to D). If neither ofthese confirmation mechanisms are available, the node

transmitting the packet may set a bit in the packetsheader to request a DSR-specific software

acknowledgement be returned by the next hop; this softwareacknowledgement will normally

be transmitted directly to the sending node, but if the link between thesetwo nodes is uni-

directional, this software acknowledgement may travel over a different, multi-hop path.

If the packet is retransmitted by some hop the maximum number of times and no receipt

confirmationis received, this node returns a ROUTE ERROR message to the original sender

of the packet, identifying thelink over which the packet could not be forwarded. For example,

in Figure 3, ifC is unable to deliver thepacket to the next hop D, then C returns a ROUTE

ERROR to A, stating that the link from C to Dis currentlybroken. Node A then removes

this broken link from its cache; any retransmission of the original packetis a function for

upper layer protocols such as TCP. For sending such a retransmission or other packets tothis

same destination E, if A has in its Route Cache another route to E (for example, from

additional ROUTEREPLYs from its earlier Route Discovery, or from having overheard


15/35

sufficient routing information from otherpackets), it can send the packet using the new route

immediately. Otherwise, it may perform a new RouteDiscovery for this target (subject to the

exponential backoff described in Section 4.2).

4.4 Additional Route Discovery Features

4.4.1 Caching Overheard Routing Information

A node forwarding or otherwise overhearing any packet may add the routing information

from that packet to its own Route Cache. In particular, the source route used in a data packet,

the accumulated route record in overhears packets from X. a ROUTE REQUEST, or the route

being returned in a ROUTE REPLY may all be cached by any node. Routing information

from any of these packets received may be cached, whether the packet was addressed to this

node, sent to a broadcast (or multicast) MAC address, or received while the nodes network

interface is in promiscuous mode.

One limitation, however, on caching of such overheard routing information is the

possible presence ofuni-directional links in the ad hoc network (Section 2). For example,

Figure 4 illustrates a situation in which node A is using a source route to communicate with

node E. As node C forwards a data packet along the route from A to E, it can always add to

its cache the presence of the forward direction links that it learns from the headers of these

packets, from itself to D and from D to E. However, the reverse direction of the links

identified in the packet headers, from itself back to Band from Bto A, may not work for it

since these links might be uni-directional. IfC knows that the links are in fact bi-directional,

for example due to the MAC protocol in use, it could cache them but otherwise should not.

Likewise, node V in Figure 4 is using a different source route to communicate with node

Z. If node C overhears node X transmitting a data packet to forward it to Y (from V), node C

should consider whether the links involved can be known to be bi-directional or not before

caching them. If the link from X to C (over which this data packet was received) can be

known to be bi-directional, then C could cache the link from itself to X, the link from X to Y,

and the link from Y to Z. If all links can be assumed to be bi-directional, C could also cache

the links from X to W and from W to V. Similar considerations apply to the routing


16/35

Figure 4:Limitations on caching overheard routing information: Node C is forwarding

packets to E andoverhears packets from X.

information thatmight be learned from forwarded or otherwise overheard ROUTE REQUEST

or ROUTE REPLY packets.

4.4.2 Replying to ROUTE REQUESTs using Cached Routes

A node receiving a ROUTE REQUEST for which it is not the target, searches its own Route

Cache for a route to the target of the REQUEST. If found, the node generally returns a

ROUTE REPLY to the initiator itself rather than forwarding the ROUTE REQUEST. In the

ROUTE REPLY, it sets the route record to list the sequence of hops over which this copy of

the ROUTE REQUEST was forwarded to it, concatenated with its own idea of the route from

itself to the target from its Route Cache.

However, before transmitting a ROUTE REPLY packet that was generated using

information from its

Route Cache in this way, a node must verify that the resulting route being returned in the

ROUTE REPLY, after this concatenation, contains no duplicate nodes listed in the route

record. For example, Figure 5 illustrates a case in which a ROUTE REQUEST for target E

has been received by node F, and node F already has in its Route Cache a route from itself to

E. The concatenation of the accumulated route from the ROUTE REQUEST and the cached

route from Fs Route Cache would include a duplicate node in passing from C to F and back

to C.

Node F in this case couldattempt to edit the route to eliminate the duplication, resulting in a

route from A to Bto C to D and on to E, but in this case, node F would not be on the route

that it returned in its own ROUTE REPLY. DSR Route Discovery prohibits node F from

returning such a ROUTE REPLY from its cache for two reasons. First, this limitation


17/35

Figure 5: A possible duplication of route hops avoided by the Route Discovery limitation on

replying to ROUTE REQUESTs from the Route Cache.

increases the probability that the resulting route is valid, since F in this case should have

received a ROUTE ERROR if the route had previously stopped working. Second, this

limitation means that a ROUTE ERROR traversing the route is very likely to pass through

any node that sent the ROUTE REPLY for the route (including F), which helps to ensure that

stale data is removed from caches (such as at F) in a timely manner. Otherwise, the next

Route Discovery initiated by Amight also be contaminated by a ROUTE REPLY from F

containing the same stale route. If the ROUTE REQUEST does not meet these restrictions,

the node (node F in this example) discards the ROUTE REQUEST rather than replying to it

or propagating it.

4.4.3 Preventing ROUTE REPLY Storms

The ability for nodes to reply to a ROUTE REQUEST based on information in their Route

Caches, as described in Section 4.4.2, could result in a possible ROUTE REPLY storm in

some cases. In particular, if a nodebroadcasts a ROUTE REQUEST for a target node for

which the nodes neighbours have a route in their RouteCaches, each neighbour may attempt

to send a ROUTE REPLY, thereby wasting bandwidth and possiblyincreasing the number of

network collisions in the area.

For example, in the situation shown in Figure 6, nodes B, C, D, E, and F all receive

As ROUTE REQUESTfor target G, and each have the indicated route cached for this target.


18/35

Figure 6: A ROUTE REPLY storm could result if many nodes all reply to the same ROUTE

REQUEST fromtheir own Route Caches. The route listed next to each node shows the route

to destination G currently listedin that nodes Route Cache.

Normally, they would all attempt toreply from their own Route Caches, and would all send

their REPLYs at about the same time since they allreceived the broadcast ROUTE

REQUEST at about the same time. Such simultaneous replies from differentnodes all

receiving the ROUTE REQUEST may create packet collisions among some or all of these

REPLIESand may cause local congestion in the wireless network. In addition, it will often be

the case that thedifferent replies will indicate routes of different lengths, as shown in this

example.If a node can put its network interface into promiscuous receive mode, it should

delay sending its ownROUTE REPLY for a short period, while listening to see if the

initiating node begins using a shorter route first.That is, this node should delay sending itsown ROUTE REPLY for a random period d H _ _h _ 1 _ r_,where h is the length in

number of network hops for the route to be returned in this nodes ROUTE REPLY,r is a

random number between 0 and 1, andH is a small constant delay (at least twice the maximum

wirelesslink propagation delay) to be introduced per hop. This delay effectively randomizes

the time at which each node sends its ROUTE REPLY, with all nodes sending ROUTE

REPLYs giving routes of length less than h sending their REPLYs before this node, and all

nodes sending ROUTE REPLYs giving routes of length greaterthan h sending their REPLYs

after this node. Within the delay period, this node promiscuously receives allpackets, looking

for data packets from the initiator of this Route Discovery destined for the target of

theDiscovery. If such a data packet received by this node during the delay period uses a

source route of lengthless than or equal to h, this node may infer that the initiator of the Route


19/35

Discovery has already received aROUTE REPLY giving an equally good or better route. In

this case, this node cancels its delay timer and doesnot send its ROUTE REPLY for this

Route Discovery.

4.4.4 ROUTE REQUEST Hop Limits

Each ROUTE REQUEST message contains a hop limit that may be used to limit the

number of intermediatenodes allowed to forward that copy of the ROUTE REQUEST. As the

REQUEST is forwarded, this limit isdecremented, and the REQUEST packet is discarded if

the limit reaches zero before finding the target. Wecurrently use this mechanism to send a

nonpropagatingROUTE REQUEST (i.e., with hop limit 0) as aninexpensive method of

determining if the target is currently a neighbour of the initiator or if a neighbournodehas a

route to the target cached (effectively using the neighbours caches as anextension of the

initiatorsown cache). If no ROUTE REPLY is received after a short timeout, then a

propagatingROUTE REQUEST (i.e.,with no hop limit) is sent.

This mechanism can be used to implement an expanding ringsearch for the target [3].

For example, a node could send an initial nonpropagating ROUTE REQUEST asdescribed

above; if no ROUTE REPLY is received for it, the node could initiate another ROUTE

REQUESTwith a hop limit of 1. For each ROUTE REQUEST initiated, if no ROUTE

REPLY is received for it, thenode could double the hop limit used on the previous attempt, to

progressively explore for the target nodewithout allowing the ROUTE REQUEST to

propagate over the entire network. However, this expanding ringsearch approach could have

the effect of increasing the average latency of Route Discovery, since multipleDiscovery

attempts and timeouts may be needed before discovering a route to the target node.

4.5 Additional Route Maintenance Features

4.5.1 Packet Salvaging

After sending a ROUTE ERROR message as part of Route Maintenance as described in

Section 4.3, a nodemay attempt to salvage the data packet that caused the ROUTE ERROR

rather than discarding it. To attemptto salvage a packet, the node sending a ROUTE ERROR

searches its own Route Cache for a route from itselfto the destination of the packet causing

the ERROR. If such a route is found, the node may salvage the packetafter returning the


20/35

Figure 7: Node C notices that the source route to D can be shortened, since it overheard a

packet from Aintended first forB.

ROUTE ERROR by replacing the original source route on the packet with the route fromits

Route Cache. The node then forwards the packet to the next node indicated along this source

route. Forexample, in Figure 3, if node C has another route cached to node E, it can salvage

the packet by applyingthis route to the packet rather than discarding the packet.When

salvaging a packet in this way, the packet is also marked as having been salvaged, to prevent

asingle packet being salvagedmultiple times. Otherwise, it could be possible for the packet to

enter a routingloop, as different nodes repeatedly salvage the packet and replace the source

route on the packet with routesto each other. An alternative mechanism of salvaging that we

have considered would be to replace onlythe unused suffix of the original route (the portion

in advance of this node) with the new route from thisnodes Route Cache, forming a new

route whose prefix is the original route and whose suffix is the routefrom the Cache. In this

case, the normal rules for avoiding duplicated nodes being listed in a source routeare

sufficient to avoid routing loops. However, this mechanism of salvaging would prevent the

new routefrom backtracking from this node to an earlier node already traversed by this

packet, to then be forwardedalong a different remaining sequence of hops to the destination.

The current salvaging mechanism allowsbacktracking but prevents a packet from being

salvaged more than once.

4.5.2 Automatic Route Shortening

Source routes in use may be automatically shortened if one or more intermediate hops in theroute becomeno longer necessary. This mechanism of automatically shortening routes in use

is somewhat similar to theuse of passive acknowledgements. In particular, if a node is able to

overhear a packet carrying a sourceroute (e.g., by operating its network interface in


21/35

promiscuous receive mode), then this node examines theunused portion of that source route.

If this node is not the intended next hop for the packet but is namedin the later unused portion

of the packets source route, then it can infer that the intermediate nodes beforeitself in the

source route are no longer needed in the route. For example, Figure 7 illustrates an examplein

which node C has overheard a data packet being transmitted from A to B, for later

forwarding to C; thearrow pointing to one node in the source route in each packet indicates

the intended next receiver of thepacket along the route.

In this case, this node (node C) returns agratuitous ROUTE REPLY message to the

original sender of thepacket (nodeA). The ROUTE REPLY gives the shorter route as the

concatenation of the portion of the originalsource route up through the node that transmitted

the overheard packet, plus the suffix of the original sourceroute beginning with the node

returning the gratuitous ROUTE REPLY. In this example, the route returned inthe gratuitous

ROUTE REPLY message sent from C to A gives the new route as the sequence of hops from

Ato C to D.

4.5.3 Increased Spreading ofROUTE ERROR Messages

When a source node receives a ROUTE ERROR for a data packet that it originated, this

source node propagatesthis ROUTE ERROR to its neighbours by piggybacking it on its next

ROUTE REQUEST. In this way, stale information in the caches of nodes around this source

node will not generate ROUTE REPLYs that contain thesame invalid link for which this

source node received the ROUTE ERROR.

For example, in the situation shown in Figure 3, node A learns from the ROUTE

ERROR message fromC, that the link from C to Dis currently broken. It thus removes this

link from its own Route Cache andinitiates a new Route Discovery (if it doesnt have another

route to E in its Route Cache). On the ROUTEREQUEST packet initiating this Route

Discovery, node A piggybacks a copy of this ROUTE ERROR message,ensuring that the

ROUTE ERROR message spreads well to other nodes, and guaranteeing that any

ROUTEREPLY that it receives (including those from other nodes Route Caches) in response

to this ROUTE REQUESTdoes not contain a route that assumes the existence of this broken

link.


22/35

A further improvement to Route Maintenance can be considered, in which anode, such as

Ain Figure 5, that receives a ROUTE ERROR will forward the ERROR along the same

sourceroute that resulted in the ERROR. This will almost guarantee that the ROUTE ERROR

reaches the node thatgenerated the ROUTE REPLY containing the broken link, which will

prevent that node from contaminating afuture Route Discovery with the same broken link.

4.5.4 Caching Negative Information

In some cases, DSR could potentially benefit from nodes caching negative information in

their RouteCaches. For example, in Figure 3, if node A caches the fact that the link from C to

Dis currently broken(rather than simply removing this hop from its Route Cache), it can

guarantee that no ROUTE REPLY thatit receives in response to its new Route Discovery will

be accepted that utilizes this broken link. A shortexpiration period must be placed on this

negative cached information, since while this entry is in its RouteCache, A will otherwise

refuse to allow this link in its cache, even if this link begins working again.

Another case in which caching negative information in a nodes Route Cache might be

useful is the casein which a link is providing highly variable service, sometimes working

correctly but often not working.This situation could occur, for example, in the case in which

the link is near the limit of the sendingnodes wireless transmission range and there are

significant sources of interference (e.g., multipath) nearthe receiving node on this link. In this

case, by caching the negative information that this link is broken, anode could avoid adding

this problematic link back to its Route Cache during the brief periods in which itis working

correctly.

4.6. Supportfor Heterogeneous Networks and Mobile IP

In configuring and deploying an ad hoc network, in many cases, all nodes will be equipped

with the same typeof wireless network interfaces, allowing simple routing between nodes

over arbitrary sequences of networkhops. However, a more flexible configuration might be to

also equip a subset of the nodes with a secondnetwork interface consisting of a longer-range

(and thus generally lower speed) wireless network interface.For example, in a military


23/35

Figure 8: An ad hoc network consisting of nodes communicating via short-range radios, with

nodes A, B,andC also having long-range radios.

setting, a group of soldiers might all use short-range radios to communicateamong

themselves, while relaying through truck-mounted higher power radios to communicate with

othergroups.

This general type of network configuration is the ad hoc networking equivalent of

wireless overlaynetworks. Due to the high degree of locality likely to be present among

directly cooperatingnodes communicatingwith each other, such a network

configurationwould allowhigh speed communicationamong such cooperating nodes, while at

the same time allowing communication with other nodes furtheraway without requiring verylarge numbers of network hops. The longer-range radios might also allow gapsbetween

different groups of nodes to be spanned, reducing the probability of network partition. A

simpleexample of such an ad hoc network configuration is shown in Figure 8. Nodes A, B,

and C, here, each haveboth short-range and long-range radio interfaces, all other nodes in the

ad hoc network have only short-rangeradio network interfaces. Node X is using a source

route to node Y that uses a sequence of both short-rangeand long-range hops.

4.6.1 UseofInterface Indices in DSR

DSR supports automatic, seamless routing in these and other heterogeneous configurations,

through itslogical addressing model [1]. Using conventional IP addressing, each ad hoc


24/35

Figure 9: An ad hoc network consisting of nodes with heterogeneous network interfaces.

network nodewould configure a different IP address for each of its possibly many network

interfaces, but as noted inSection 3, each node using DSR chooses one of these as its home

addressto use for all communication whilein the ad hoc network. This use of a single IP

address per node gives DSR the ability to treat the overallnetwork as single routing domain.

To then distinguish between the different network interfaces on a node,each node

independently assigns a locally unique interface index to each of its own network

interfaces.The interface index for any network interface on a node is an opaque value

assigned by the node itself.

The particular value chosen must be unique among the network interfaces on that

individual node butneed have no other significance and need not be coordinated with any

other nodes in choosing their owninterface indices. On many operating systems, a unique

value to identify each network interface is alreadyavailable and can be used for this purpose;

for example, the if index field in the ifnet structure for anetwork interface in BSD Unix-based

networking stacks can be used directly by a node forthe interface index for that network

interface.

For example, Figure 9 illustrates a simple ad hoc network of four nodes, in which node Ais using onetype of network interface (represented by the triangles), node C and node D are

using an different type ofphysical network interface (represented by the circles), and node B

is configured with both types of networkinterfaces and can forward packets between the two

different types of radio technologies. The numberlabelling each network interface indicates

the interface index chosen by the corresponding node for thatinterface. Since the interface

indices are chosen independently by each node, it is possible, for example,that nodes Band D

each chose index 1 for their circle network interfaces, but node C chooses index 4.The

interface index is used as part of each hop in each source route discovered and used by

DSR.Specifically, a path through the ad hoc network from a source node N0 to a destination

node Nm is fullyrepresented as a series of hops N0/i0 _N1/i1 _N2/i2 __Nm, where


25/35


26/35

is also possible for a node to use a single network interface both for participationin the ad hoc

network and also for connection to the Internet through standard IP routing; in this case,the

reserved interface index identifies the logically separate functionality of this interface for its

Internetconnection, and the node uses another (locally assigned) interface index value to

identify this interface inits separate logical function of participation in the ad hoc network.

If the gateway node is acting as a Mobile IP home agent or foreign agent (termed a

mobility agent)on this network interface, it uses the reserved interface index value

IF_INDEX_MA. Otherwise, thegateway node uses the reserved value IF_INDEX_ROUTER.

The distinction between the reserved indexvalues for mobility agents and for routers allows

mobility agents to advertise their existence (as needed forMobile IP) at no cost. A node in the

ad hoc network that processes a routing header listing the interface indexIF_INDEX_MA can

then send a unicastMobile IPAGENT SOLICITATION to the correspondingaddress in the

routing header to obtain complete information about the Mobile IP services being provided.

In processing a received ROUTE REQUEST, a gateway node generates a ROUTE

REPLY, giving its reservedinterface index value, if it believes it may be able to reach the

target node through its Internet connection. Thus, the originator of the Route Discovery may

receive REPLYs both from the gateway and from the nodeitself, if the node is really present

in the ad hoc network. When later sending packets to this destination,the sender should prefer

cached routes that do not traverse a hop with an interface index of IF_INDEX_MAor

IF_INDEX_ROUTER, since this will prefer routes that lead directly to the destination node

within thead hoc network.

4.7 Multicast Routing with DSR

DSR does not currently support true multicast routing, but does support an approximation of

this thatis sufficient in many network contexts. Through an extension of the Route Discovery

mechanism, DSRsupports the controlled flooding of a data packet to all nodes in the ad hoc

network that are within somespecified number of hops of the originator; these nodes may

then apply destination address filtering (e.g., insoftware) to limit the packet to those nodes

subscribed to the packets indicated multicast destination address.

While this mechanism does not support pruning of the broadcast tree to conserve

network resources, it canbe used to distribute information to all nodes in the ad hoc network


27/35

subscribed to the destination multicastaddress. This mechanism may also be useful for

sending application level packets to all nodes in a limitedrange around the sender.

To utilize this form of multicasting, when an application on a DSR node sends a packet

to a multicastdestination address, DSR piggybacks the data from the packet inside a ROUTE

REQUEST targeted at themulticast address. The normal ROUTE REQUEST propagation

scheme described in Section 4.2 will resultin this packet being efficiently distributed to all

nodes in the network within the specified hop count (TTL)of the originator. After forwarding

the packet as defined for Route Discovery, each receiving node thenindividually examines

the destination address of the packet and discards the packet if it is destined to amulticast

address to which this node is not subscribed.

4.8 Location ofDSR Functions in the ISO Network Reference Model

When designing DSR, two different options were considered, regarding where should DSR

be placed in the ISO model: routing at the link layer(ISO layer 2) and routing atthenetwork

layer(ISO layer 3). Originally, it was opted to route at the link layer for several reasons:

Pragmatically, running the DSR protocol at the link layer maximizes the number of

mobile nodesthat can participate in ad hoc networks. For example, the protocol can route

equally well betweenIPv4,IPv6, and IPX nodes.

Historically [3], as mentioned in Section 2, DSR grew fromour contemplation of a multi-

hop propagating version of the Internets Address Resolution Protocol(ARP), as well as from

the routing mechanism used in IEEE 802 source routingbridges. These are layer 2 protocols.

Technically, DSR was designed to be simple enough that that it could be implemented

directly inthe firmware inside wireless network interface cards [3], well below thelayer 3

software within amobile node. There is great potential in this for DSR running inside a cloud

ofmobile nodes around a fixed base station, where DSR would act to transparently extend the

coveragerange to these nodes. Mobile nodes that would otherwise be unable to communicate

with the basestation due to factors such as distance, fading, or local interference sources

could then reach the basestation through their peers.

Ultimately, however, it was decided to specify [1] and to implement DSR as a layer

3protocol, since this is the only layer at which DSR could realistically support nodes with

multiple networkinterfaces of different types, as described in Section 4.6.


28/35

4.9 Optional DSR Flow State Extension

This section describes an optional, compatible extension to the DSR protocol, known as

"flow state", that allows the routing of most packets without an explicit source route header in

the packet. The DSR flow state extension further reduces the overhead of the protocol yet

still preserves the fundamental properties of DSR's operation.

Once a sending node has discovered a source route such as through DSR's Route Discovery

mechanism, the flow state mechanism allows the sending node to establish hop-by-hop

forwarding state within the network, based on this source route, to enable each node along the

route to forward the packet to the next hop based on the node's own local knowledge of the

flow along which this packet is being routed.

Flow state is dynamically initialized by the first packet using a source route and is then able

to route subsequent packets along thesame flow without use of a source route header in the

packet.The state established at each hop along a flow is "soft state" and thus automatically

expires when no longer needed and can be quickly recreated as necessary. Extending DSR's

basic operation based on an explicit source route in the header of each packet routed, the flow

state extension operates as a form of "implicit source routing" by preserving DSR's basic

operation but removing the explicit source route from packets.

4.9.1 Flow Establishment

A source node sending packets to some destination node MAY use the DSR flow stateextension described here to establish a route to that destination as a flow. A "flow" is a route

from the source to the destination represented by hop-by-hop forwarding state within the

nodes along the route. Each flow is uniquely identified by a combination of the source node

address, the destination node address, and a flow identifier (flow ID) chosen by the source

node.

4.9.2 Processing Route Errors

When a node receives a Route Error of type UNKNOWN_FLOW, it marks the flow to

indicate that it has not been established end-to-end. When a node receives a Route Error of

type DEFAULT_FLOW_UNKNOWN, it marks the default flow to indicate that it has not

been established end-to-end.


29/35

4.10 DSRon IPv4

The Dynamic Source Routing protocol makes use of special header carrying control

information that can be included in any existing IP packet. The reason that DSR on IPv4 is

specified here is that it requires much less bandwidth than DSR on IPv6.

DSR header is an IP-level protocol just as TCP or UDP are; it is inserted directly after IP

header. The protocol number in the IP header is changed to DSR header (to be assigned by

IANA), and next header field in the DSR header is updated to point to the original protocol

number of the terminal header.

This DSR Options header in a packet contains a small fixed-sized, 4-octet portion, followed

by a sequence of zero or more DSR options carrying optional information. The end of the

sequence ofDSR options in the DSR Options header is implied by the total length of the DSR

Options header.

4.10.1 Fixed Portion ofDSR Header

DSR header has a fixed portion of 4 bytes (Next header, reserved, Flow State Header,

payload length) and any number of options encoded in Type-Length-Value (TLV) notation.

The Next Header is a 8-bit selector and identifies the type of header that immediately

follows the DSR Header. The reserved bits are to be ignored, as they are reserved for further

use. The payload length is a 16-bit field which mentions the length of the DSR Options

Header excluding the 4-octet fixed portion. It defines the total length of all options included

in the DSR Options Header.

The most significant bit in the Option Type value (that is, Option Type & 0x80)

represents whether or not a node receiving this Option Type (when the node does not

implement processing for this


30/35

Fi : Format

Fi re 11:Fi ed Portion of DSROptions Header

Option Type) SHOULD respond to such a DSR option with a Route Error of type

OPTION_NOT_SUPPORTED, except that such a Route Error should never be sent in

response to a packet containing a Route Request option.

The two following bits in the Option Type value (thatis, Option Type & 0x60) are a two-

bit field indicating how such a node that does not support this Option Type MUST process

the packet:

00 = Ignore Option

01 = Remove Option

10 = Mark Option

11 = Drop Packet


31/35

When these 2 bits are 00 (that is, Option Type & 0x60 == 0), a node not implementing

processing for that Option Type MUST use the Opt Data Len field to skip over the option and

continue processing. When these 2 bits are 01 (that is, Option Type & 0x60== 0x20), a node

not implementing processing for that Option Type MUST use the Opt Data Len field to

remove the option from the packet and continue processing as if the option had not been

included in the received packet. When these 2 bits are 10 (that is, Option Type & 0x60 ==

0x40), a node not implementing processing for that Option Type MUST set the most

significant bit following the Opt Data Len field, MUST ignore the contents of the option

using the Opt Data Len field, and MUST continue processing the packet. Finally, when these

2 bits are 11 (that is, Option Type & 0x60 == 0x60), a node not implementing processing for

that Option Type MUST drop the packet.

4.10.2DSR Options

The following options have been defined: Route Request,Route Reply, Route Error,

Acknowledgment Request,Acknowledgment, DSR Source Route, Pad1, and PadN[7]. These

are only quickly introduced here; all thegory details are omitted.

Route Request contains Identification, TargetAddress and Address[1..n] fields.

Route requestswill be sent to the limited broadcast address255.255.255.255, and the

destination address wherethe source wants to find the route for is placed in Targetaddress

field. Identification is a sequence number,used to distinguish between already seen and old

messages.Address [1..n] are used to store the addressesalong the the path of Route

Discovery.

Route Reply contains L-bit, Reserved and Address[1..n] fields. Last Hop External

bit indicates thatthe last address represents the last node in the DSR network, and the actual

destination is outside of MANET.Address[1..n] contains the source route gathered within

the route request. Route Replies are usually sent backto the originator of Route Request by

either the nodethat was the Target of the original Route Request or by some intermediate

node, as a Reply from Cache or as agratuitous Reply.

Route Error contains Error Type, Reserved, Salvage,Error Source Address,

Error Destination Address,and error type -specific information. Currently,only one error

type, Node Unreachable, is specified.The contents of Salvage field are derived from


32/35

theDSR Source Route option triggering the error. ErrorSource Address is the address of the

node which encounteredan error; Error Destination Address is theoriginal source of the

failed packet. In the case of NodeUnreachable message, type-specific information containsthe

address of the unreachable node. Route Errorsare sent to inform the source (and intermediate

nodes)of failed source routes.

Acknowledgment Request contains Identificationfield. It is a unique value that will be

used in Acknowledgmentresponse to create a link between the two. Acknowledgmentsare

used for ensuring the reliable deliveryof Route Maintenance packets if no other form

(e.g.link-layer acknowledgments, passive acknowledgmentsby promiscuous mode) is

available.Acknowledgment contains Identification, ACKSource Address, and ACK

Destination Addressfields. Identification is copied from the Request, ACK

Source Address is the address of the node originatingthe acknowledgment, and ACK

Destination Address isthe address to which the acknowledgment will be deliveredto.

DSR Source Route contains F and L -bits,Reserved, Salvage, Segments Left,

and Address [1..n] fields. First and Last Hop External bitsindicate whether the route leads

to or from outside ofthe DSR network; such paths must not be returnedfrom the cache of

intermediate nodes. Salvage indicatesthe number of times the packet has been salvaged

(see section 4.5.1), that is, rewritten by an intermediatenode to ensure delivery. Segments

Left indicateshow many addresses in the option must still be traverseduntil reaching the

final destination. Address[1..n] liststhese intermediate nodes which the packet has been,

andwill be, through. DSR Source Route option is presentin almost every packet.

Pad1 and PadN options include requested amount ofpadding, to ensure that the total DSR

Header will beproperly aligned to a multiple of 4 bytes.


33/35

5. FUTURE WORK

The scope of applicability of DSR needs to be moreprecisely defined. Interactions with

IPSEC, and routingprotocol security in general should be studied. Interactionswith packet

filters should be explored. Thespecification text should be clarified on some points,

especiallyregarding retransmissions. Especially a mixednetwork of uni- and bidirectional

links should be simulated.How destructive a DSR node (or a set of nodes)can be with old

cache entries should be studied. Eventhough DSR is not meant for many hundreds of nodes,

comparisons with other MANET protocols with theseamounts of nodes might be interesting.


34/35

6. CONCLUSION

DSR applies rather well to a smallish, less than a hundred, network of nodes that trust each

other. In such networks, DSR may be especially useful if it is important to be able to deal

with both high and low node mobility with reasonably small overhead without any manual

changes; DSR is highly adaptive.

There are some areas that need clarifications or more study; some of these are applicable to

some otherMANET protocols too, though:

Study on the more generic problem of trusting routing updates in ad-hoc networking

Clarifications and tests on cache management, especially ensuring cache freshness and

how far wrong data could spread

Being able to use IPSEC to verify either the payload or DSR header data, so that link-

layer security would not be required

Clarifications on retransmission mechanisms and how that applies to unreliable IP

Clarifications on interactions with firewalls and packet filters

Clarifications and tests with bi- and uni-directionality of links

Some other clarifications on the specification text


35/35

7. REFERENCES

[1] Josh Broch, David B. Johnson, and David A. Maltz.The Dynamic Source RoutingProtocol for Mobile Ad Hoc Networks. Internet-Draft, draft-ietf-manet-dsr-03.txt,

October 1999. Work in progress. Earlier revisions published June 1999, December1998, and March 1998.

[2] Robert Castaneda and Samir R. Das. Query Localization Techniques for On-demand

Routing Protocols in Ad Hoc Networks. In Proceedings of the Fifth InternationalConference on Mobile Computing and Networking(MobiCom99).ACM,August 1999.

[3] David B. Johnson. Routing in Ad Hoc Networks of Mobile Hosts. In Proceedings of

the IEEE Workshop on Mobile Computing Systems andApplications, pages 158163.

IEEE Computer Society, December 1994.

[4] Carnegie Mellon University Monarch Project.CMU Monarch Project Home Page.

Available at http://www.monarch.cs.cmu.edu/.

[5] IEEE Computer Society LAN MAN Standards Committee.Wireless LAN Medium

Access Control (MAC) andPhysical Layer (PHY) Specifications, IEEE Std

802.11-1997. The Institute of Electrical and Electronics Engineers, New York,

New York, 1997.

[6] David B. Johnson, David A. Maltz, and Josh Broch.DSR: The Dynamic Source Routing

Protocol for Multi-Hop Wireless Ad Hoc Networks. in Ad Hoc Networking, edited byCharles E. Perkins, Chapter 5, pp. 139-172, Addison-Wesley, 2001

[7] PekkaSavola: DSR: Dynamic Source Routing, CSC/FUNET, Helsinki University of

Technology.

dynamic source routing protocol

Documents