“DYNAMIC SOURCE ROUTING PROTOCOL”

Submitted in partial fulfillment of the requirement of University of Mumbai

For the Degree of

Bachelor of Engineering
(Computer Engineering )

By
Pranav Bhujle
Ashish Mathew
Aditya Prasad
Pankajkumar Thakur

under the guidance of

Prof. Payel Gupta

DEPARTMENT OF COMPUTER ENGINEERING

PILLAI’S INSTITUTE OF INFORMATION TECHNOLOGY,
ENGINEERING, MEDIA STUDIES & RESEARCH
NEW PANVEL – 410 206
 1. INTRODUCTION
Mobile hosts such as notebook computers, featuring powerful CPUs, large main memories,
hundreds of mega bytes of disk space, multimedia sound capabilities, and colour displays, are
now easily affordable and are becoming quite common in everyday business and personal
life. At the same time, network connectivity options for use with mobile hosts have increased
dramatically, including support for a growing number of wireless networking products based
on radio and infrared. With this type of mobile computing equipment, there is a natural desire
and ability to share information between mobile users. Often, mobile users will meet under
circumstances that are not explicitly planned for and in which no connection to a standard
wide-area network such as is available. For example, employees may find themselves
together in a meeting room; friends or business associates may run into each other in an
airport terminal; or a collection of computer science researchers may gather in a hotel
ballroom for a workshop or conference. Requiring each user to connect to a wide-area
network in such situations, only to communicate with each other, may not be possible due to
lack of facilities, or may be in convenient or impractical due to the time or expense required
for such connection.
These kinds of networks of mobile hosts have become known as ad hoc networks. An ad
hoc network is a collection of wireless mobile hosts forming a temporary network without the
aid of any centralized administration or standard support services regularly available on the
wide-area network to which the hosts may normally be connected.
Some form of routing protocol is in general necessary in such an environment, since two
hosts that may wish to exchange packets might not be able to communicate directly.
For example, Figure 1 illustrates a simple ad hoc network of three mobile hosts using
wireless network interfaces. Host C is not within the range of host A’s wireless transmitter
(indicated by the circle around A) and host A is not within the range of host C’s wireless
transmitter. If A and C wish to exchange packets, they may in this case enlist the services of
host B to forward packets for them, since B is within the overlap between A’s range and C’s
range. The maximum number of network hops needed to reach another mobile host in any
practical ad hoc network is likely to be small, but may often be greater than one as shown
here.
 Figure 1: An ad hoc network of three wireless mobile hosts

The routing problem in a real ad hoc network may be even more complicated than this
example suggests, due to the inherent non uniform propagation characteristics of wireless
transmissions and since any or all of the hosts involved may move at any 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 hops to any destination in the ad hoc network. Each data packet sent then carries in
its header the complete ordered 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
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 Discovery and
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.
 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, when the 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 increasing capabilities and decreasing costs of small, portable computers such
as laptops and PDAs (Personal Digital Assistants), and with the increasing availability of
inexpensive wireless network interface devices such as wireless LAN interfaces packaged as
PCMCIA PC Cards, a growing number of other research projects 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 and
Route Discovery mechanisms, was first published in December 1994, with significant
additional design details and initial simulation results published in early 1996 [3]. As noted in
Section 1, the design specification for DSR has also been submitted to the MANET (Mobile
Ad Hoc Networks) Working Group of the IETF (Internet Engineering Task Force) in their
efforts to standardize a protocol for routing of IP packets in an ad hoc network [1].The
original motivation in the design of DSR came from the operation of the Address Resolution
Protocol (ARP) used in the TCP/IP suite of protocols in the Internet. ARP is used on
Ethernets and other 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 looking for; that node responds with an ARP REPLY packet, giving
its MAC address, and all other nodes ignore the REQUEST. If all nodes in an ad hoc network
are within wireless transmission range of each other, this is the only routing protocol needed
for the ad hoc network. DSR extends this basic behaviour of ARP by allowing the REQUEST
packet (the ROUTE REQUEST rather than an ARP REQUEST) to be propagated multiple
hops away by being forwarded by neighbour nodes, with the ultimate ROUTE REPLY being
returned over multiple hops back to the initiator of the REQUEST.
 DSR’s non propagating ROUTE REQUEST packets are indeed quite similar to the basic
ARP REQUEST behaviour, except that a mobile node may answer the ROUTEREQUEST
from its cache, whereas ARP REQUESTS are 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 extension of the ARP REQUEST and ARP REPLY packet formats; as
described in Sections 4.8, however, it was ultimately decided to operate DSR at the network
layer rather than at the link layer, to allow routing between different 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 SRT bridge standard, and related mechanisms have also been used in other systems
including FLIP 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 sponsored by the American Radio Relay League (ARRL)
since 1981. Amateur packet radio networking originally used only source routing, with
explicit source routes constructed by the user, although some had considered the possibility
of a more dynamic source routing scheme. A system known as NET/ROM was also
developed to allow the routing decisions to be automated, using a form of distance vector
routing protocol rather than source routing. NET/ROM also allows updating of its routing
table 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 Route Discovery and Route Maintenance mechanisms in DSR. For example, the Signal
Stability-Based Adaptive routing protocol (SSA) and the Associativity Based Routing
protocol (ABR) each discover routes on demand in a way similar to Route Discovery in DSR,
but each attempts to select only long-lived links between nodes where possible; favouring
long-lived links helps avoid routes breaking soon after discovering them but may result in use
of routes over a greater number of hops than the shortest routes available. ABR also adds
overhead for periodic beacon packets required to monitor link stability. The Ad Hoc On-
Demand Distance Vector routing protocol (AODV) [4] uses mechanisms similar to DSR’s
Route Discovery and Route Maintenance, but it uses them to create hop-by-hop routes rather
than source routes as is done in DSR; this use of hop-by-hop routes avoids the source routing
header overhead of DSR but prevents or makes difficult many of the route caching and other
Route Discovery optimizations present in DSR and prevents AODV from supporting uni-
directional links between nodes. The Zone Routing 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 a non-demand protocol such as DSR for routing
between zones; the use of routing zones reduces some aspects of the overhead of the Route
Discovery procedure as in DSR but adds the overhead of maintaining zone membership and
routing information within each zone. ZRP may also fail at times to successfully deliver
packets with highly mobile nodes, since the routing protocol within a zone does not utilize
on-demand operation.
Finally, DSR has recently been used as a basis for further work by other researchers,
including suggested improvements to the Route Discovery mechanism. For example, Ko and
Vaidya [6] have proposed an optimization to Route Discovery, known as Location-Aided
Routing (LAR), that uses knowledge of the physical (geographical) location of the target
node of the Route Discovery (e.g., from GPS, the Global Positioning System) to narrow the
area of the network over which the ROUTE REQUEST packets must be propagated.
Castãneda and Das [2] have proposed a similar Route Discovery optimization that uses only
logical (topological) location information, not physical location information, and thus does
not require access to GPS. Above the routing layer, Holland and Vaidya [6] have recently
studied the behaviour of TCP in ad hoc networks, using DSR as a routing protocol; their
work added explicit interaction between TCP and the Route Discovery and Route
Maintenance mechanisms to allow TCP to correctly react to a route failure rather than
treating it as network congestion, and to allow TCP to restart sending as soon as a new route
to the destination is discovered.
 3. ASSUMPTIONS

We assume that all nodes wishing to communicate with other nodes within the ad hoc
network are willing to participate fully in the protocols of the network. In particular, each
node participating in the network should 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 one extreme edge of the ad hoc network to another node located at the opposite
extreme, as the diameter of the ad 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 corrupted packet can detect the error and discard the packet.
Nodes within the ad hoc network may move at any time without notice, and may even
move continuously, but we assume that the speed with which nodes move is moderate with
respect to the packet transmission latency 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 continuously move 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 enable promiscuous receive mode on their wireless
network interface hardware, causing the hardware to deliver every received packet to the
network driver software without 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 software overhead on the CPU, but
we believe that wireless network speeds are more the inherent limiting factor to performance
in current and future systems; we also believe that portions of the protocol are suitable for
implementation directly within a programmable network interface unit to avoid this overhead
on the CPU [3]. Use of promiscuous mode may also increase the power consumption of the
network interface hardware, depending on the design of the receiver hardware, and in such
cases, DSR can easily be used without the optimizations that depend on promiscuous receive
mode, or can be programmed to only periodically switch the interface into promiscuous
mode.
 Wireless communication ability between any pair of nodes may at times not work
equally well in both directions, due for example to differing antenna or propagation patterns
or sources of interference around the two nodes. That is, wireless communications between
each pair of nodes will in many cases be able to operate bi-directionally, but at times the
wireless link between two nodes may be only uni-directional, allowing one node to
successfully send packets to the other while no communication is possible in the reverse
direction. Although many routing protocols operate correctly only over bidirectional links,
DSR can successfully discover and forward packets over paths that contain uni-directional
links. 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 bidirectional
exchange of RTS and CTS packets in these protocols and due to the link-level
acknowledgement feature in IEEE 802.11; when used on top of MAC protocols such as these,
DSR can take advantage of additional optimizations, such as the route reversal optimization
described below.
Each node selects a single IP address by which it will be known in the ad hoc network.
Although a single node may have many different physical network interfaces, which in a
typical IP network would each have a different IP address, we require each node to select one
of these and to use only that address when participating in the DSR protocol. This allows
each node to be recognized by all other nodes in the ad hoc network as a single entity
regardless of which network interface they use to communicate with it. In keeping with the
terminology used by Mobile IP [3], we refer to the address by which each mobile node is
known in the ad hoc network as the node’s home address, as this address would typically 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 node’s home address may be assigned by any
mechanism (e.g., static assignment or use of DHCP for dynamic assignment), although the
method of such assignment is outside the scope of the DSR protocol.
 4. DETAILED DESCRIPTION OF THE DSR PROTOCOL

4.1 Overview and Important Properties of the Protocol

The DSR protocol is composed of two mechanisms that work together to allow the discovery
and maintenance of source routes in the ad hoc network:
Route Discovery is the mechanism by which a node S wishing to send a packet to a
destination node D obtains 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 route to D, if the network topology has changed such that it can no longer use its route
to D because a link along the route no longer works. When Route Maintenance indicates a
source route is broken, S can attempt to use any other route it happens to know to D, or can
invoke Route Discovery again to find a new route. Route Maintenance is used only when S is
actually sending packets to D.
Route Discovery and Route Maintenance each operate entirely on demand. In particular,
unlike other protocols, DSR requires no periodic packets of any kind at any level within the
network. For example, DSR does not use any periodic routing advertisement, link status
sensing, or neighbour detection packets, and does not rely on these functions from any
underlying protocols in the network. This entirely on-demand behaviour and lack of periodic
activity allows the number of overhead packets caused by DSR to scale all the way down to
zero, when all nodes are approximately stationary with respect to each other and all routes
needed for current communication have already been discovered. As nodes begin to move
more or as communication patterns change, the routing packet overhead of DSR
automatically scales to only that needed to track the routes currently in use.
In response to a single Route Discovery (as well as through routing information from
other packets overheard), a node may learn and cache multiple routes to any destination. This
allows the reaction to routing changes to be much more rapid, since a node with multiple
routes to a destination can try another cached route if the one it has been using should fail.
This caching of multiple routes also avoids the overhead of needing to perform a new Route
Discovery each time a route in use breaks.
The operation of Route Discovery and Route Maintenance in DSR are designed to allow
uni-directional links 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 differing antenna or propagation patterns or sources of
interference. DSR allows such uni-directional links to be used when necessary, improving
overall performance and network connectivity in the system.
DSR also supports internetworking between different types of wireless networks,
allowing a source route to be composed of hops over a combination of any types of networks
available [1][6]. For example, some nodes in the ad hoc network may have only short-range
radios, while other nodes have both short-range and long-range radios; the combination of
these nodes together can be considered by DSR as a single 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 into Mobile IP routing, where such a gateway node also serves the role of a
Mobile IP foreign 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 the packet a source 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 its Route Cache
of routes previously learned, but if no route 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 initiator and D the target of the Route Discovery.
For example, Figure 2 illustrates an example Route Discovery, in which a node A is
attempting to discover a route to node E. To initiate the Route Discovery, A transmits a
ROUTE REQUEST message as a single local broadcast packet, which is received by
(approximately) all nodes currently within wireless transmission range of A. Each ROUTE
REQUEST message identifies the initiator and target of the Route Discovery, 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
 Figure 2: Route Discovery example: Node A is the initiator, and node E is the target.

through which this particular copy of the ROUTE REQUEST message has been forwarded.
This route record is initialized to an empty list by the initiator of the Route Discovery.
When another node receives a ROUTE REQUEST, if it is the target of the Route
Discovery, it returns a ROUTE REPLY message to the initiator of the Route Discovery,
giving a copy of the accumulated route record from the ROUTE REQUEST; when the
initiator receives this ROUTE REPLY, it caches this route in its Route Cache for use in
sending subsequent packets to this destination. Otherwise, if this node receiving the ROUTE
REQUEST has recently seen another ROUTE REQUEST message from this initiator bearing
this same request id, or if it finds that its own address is already listed in the route record in
the ROUTE REQUEST message, it discards the REQUEST. Otherwise, this node appends its
own address to the route record in the ROUTE REQUEST message and propagates it by
transmitting it as a local broadcast packet (with the same request 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 use it for the source route for delivery of the packet containing
the ROUTE REPLY. Otherwise, E may perform its own Route Discovery for target node A,
but to avoid possible infinite recursion of Route Discoveries, it must piggy back this ROUTE
REPLY on its own ROUTE REQUEST message for A. It is also possible to piggy back other
small data packets, such as a TCP SYN packet, on a ROUTE REQUEST using this same
mechanism. Node E could also simply reverse the sequence of hops in the route record that it
trying to send 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 MAC protocol [5], this route reversal is preferred as
it avoids the overhead of a possible second Route Discovery, and it tests the discovered route
to ensure it is bi-directional before the Route Discovery initiator begins using the route.
However, this technique will prevent the discovery of routes using uni-directional links. In
wireless environments where the use of uni-directional links is permitted, such routes may in
some cases be more efficient than those with only bi-directional links, or they may be the
only way to achieve connectivity to the target node.
When initiating a Route Discovery, the sending node saves a copy of the original packet
in a local buffer called the Send Buffer. The Send Buffer contains a copy of each packet that
cannot be transmitted by this node because it does not yet have a source route to the packet’s
destination. Each packet in the Send Buffer is stamped with the time that it was placed into
the Buffer and is discarded after residing in the Send Buffer for some timeout period; if
necessary for preventing the Send Buffer from overflowing, a FIFO or other replacement
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 Discovery for the packet’s destination address. However, the node must limit the rate
at which such new Route Discoveries for the same address are initiated, since it is possible
that the destination node is not currently reachable. In particular, due to the limited wireless
transmission range and the movement of the nodes in the network, the network may at times
become partitioned, meaning that there is currently no sequence of nodes through which a
packet could be forwarded to reach the destination. Depending on the movement pattern 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 number of unproductive ROUTE REQUEST packets would be propagated throughout
the subset of the ad hoc network reachable from this node. In order 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, the subsequent
packets should be buffered in the Send Buffer until a ROUTE REPLY is received, but the
node must not initiate a new Route Discovery until the minimum allowable interval between
new Route Discoveries for this target has been reached. This limitation on the maximum rate
of Route Discoveries for the same target is similar to the mechanism required by Internet
nodes to limit the rate at which ARP REQUESTs are sent for any single target IP address.
 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.3 Basic DSR Route Maintenance

When originating or forwarding a packet using a source route, each node transmitting the
packet is responsible for confirming that the packet has been received by the next hop along
the source route; the packet is retransmitted (up to a maximum number of attempts) until this
confirmation of receipt is received. For example, in the situation illustrated in Figure 2, node
A has originated a packet for E using a source route through intermediate nodes B, C, and D.
In this case, node A is responsible for receipt of the packet at B, node B is responsible for
receipt at C, node C is responsible for receipt at D, and node D is responsible for receipt
finally at the destination E. This confirmation of receipt in many cases may be provided at no
cost to DSR, either as an existing standard part of the MAC protocol in use (such as the link-
level acknowledgement frame 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 of these confirmation mechanisms are available,
the node transmitting the packet may set a bit in the packet’s header to request a DSR-
specific software acknowledgement be returned by the next hop; this software
acknowledgement will normally be transmitted directly to the sending node, but if the link
between these two 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
confirmation is received, this node returns a ROUTE ERROR message to the original sender
of the packet, identifying the link over which the packet could not be forwarded. For
example, in Figure 3, if C is unable to deliver the packet to the next hop D, then C returns a
ROUTE ERROR to A, stating that the link from C to D is currently “broken.” Node A then
removes this broken link from its cache; any retransmission of the original packet is a
function for upper layer protocols such as TCP. For sending such a retransmission or other
packets to this 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 sufficient routing information from other packets), it can send the packet using the
new route immediately. Otherwise, it may perform a new Route Discovery for this target
(subject to the exponential back off 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 node’s network
interface is in promiscuous mode.
One limitation, however, on caching of such overheard routing information is the
possible presence of uni-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 B and from B to A, may not work for it
since these links might be uni-directional. If C 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
 Figure 4: Limitations on caching overheard routing information: Node C is forwarding
packets to E and overhears packets from X.

information that might 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 F’s Route Cache would include a duplicate node in passing from C to F and back
to C.
Node F in this case could attempt to edit the route to eliminate the duplication, resulting in a
route from A to B to 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
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 A might 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 node broadcasts a ROUTE REQUEST for a target node for
which the node’s neighbours have a route in their Route Caches, each neighbour may attempt
to send a ROUTE REPLY, thereby wasting bandwidth and possibly increasing 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
A’s ROUTE REQUEST for target G, and each have the indicated route cached for this target.
Figure 6: A ROUTE REPLY storm could result if many nodes all reply to the same ROUTE
REQUEST from their own Route Caches. The route listed next to each node shows the route
to destination G currently listed in that node’s Route Cache.

Normally, they would all attempt to reply from their own Route Caches, and would all send
their REPLYs at about the same time since they all received the broadcast ROUTE
REQUEST at about the same time. Such simultaneous replies from different nodes all
receiving the ROUTE REQUEST may create packet collisions among some or all of these
REPLIES and may cause local congestion in the wireless network. In addition, it will often
be the case that the different 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 own ROUTE 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 its
own 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 node’s ROUTE REPLY, r is a
random number between 0 and 1, and H is a small constant delay (at least twice the
maximum wireless link 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 greater than h sending their
REPLYs after this node. Within the delay period, this node promiscuously receives all
packets, looking for data packets from the initiator of this Route Discovery destined for the
target of the Discovery. If such a data packet received by this node during the delay period
uses a source route of length less than or equal to h, this node may infer that the initiator of
the Route Discovery has already received a ROUTE REPLY giving an equally good or better
route. In this case, this node cancels its delay timer and does not 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 intermediate nodes allowed to forward that copy of the ROUTE REQUEST. As
the REQUEST is forwarded, this limit is decremented, and the REQUEST packet is
discarded if the limit reaches zero before finding the target. We currently use this mechanism
to send a non propagating ROUTE REQUEST (i.e., with hop limit 0) as an inexpensive
method of determining if the target is currently a neighbour of the initiator or if a neighbour
node has a route to the target cached (effectively using the neighbours’ caches as an
extension of the initiator’s own cache). If no ROUTE REPLY is received after a short
timeout, then a propagating ROUTE REQUEST (i.e., with no hop limit) is sent.
This mechanism can be used to implement an expanding ring search for the target [3].
For example, a node could send an initial non propagating ROUTE REQUEST as described
above; if no ROUTE REPLY is received for it, the node could initiate another ROUTE
REQUEST with a hop limit of 1. For each ROUTE REQUEST initiated, if no ROUTE
REPLY is received for it, the node could double the hop limit used on the previous attempt,
to progressively explore for the target node without allowing the ROUTE REQUEST to
propagate over the entire network. However, this expanding ring search approach could have
the effect of increasing the average latency of Route Discovery, since multiple Discovery
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 node may attempt to salvage the data packet that caused the ROUTE ERROR
rather than discarding it. To attempt to salvage a packet, the node sending a ROUTE ERROR
searches its own Route Cache for a route from itself to the destination of the packet causing
the ERROR. If such a route is found, the node may salvage the packet after returning the
 Figure 7: Node C notices that the source route to D can be shortened, since it overheard a
packet from A intended first for B.

ROUTE ERROR by replacing the original source route on the packet with the route from its
Route Cache. The node then forwards the packet to the next node indicated along this source
route. For example, in Figure 3, if node C has another route cached to node E, it can salvage
the packet by applying this 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
a single packet being salvaged multiple times. Otherwise, it could be possible for the packet
to enter a routing loop, as different nodes repeatedly salvage the packet and replace the
source route on the packet with routes to each other. An alternative mechanism of salvaging
that we have considered would be to replace only the unused suffix of the original route (the
portion in advance of this node) with the new route from this node’s Route Cache, forming a
new route whose prefix is the original route and whose suffix is the route from the Cache. In
this case, the normal rules for avoiding duplicated nodes being listed in a source route are
sufficient to avoid routing loops. However, this mechanism of salvaging would prevent the
new route from “backtracking” from this node to an earlier node already traversed by this
packet, to then be forwarded along a different remaining sequence of hops to the destination.
The current salvaging mechanism allows backtracking 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 the
route become no longer necessary. This mechanism of automatically shortening routes in use
is somewhat similar to the use of passive acknowledgements. In particular, if a node is able to
overhear a packet carrying a source route (e.g., by operating its network interface in
promiscuous receive mode), then this node examines the unused portion of that source route.
If this node is not the intended next hop for the packet but is named in the later unused
portion of the packet’s source route, then it can infer that the intermediate nodes before itself
in the source route are no longer needed in the route. For example, Figure 7 illustrates an
example in which node C has overheard a data packet being transmitted from A to B, for later
forwarding to C; the arrow pointing to one node in the source route in each packet indicates
the intended next receiver of the packet along the route.
In this case, this node (node C) returns a gratuitous ROUTE REPLY message to the
original sender of the packet (node A). The ROUTE REPLY gives the shorter route as the
concatenation of the portion of the original source route up through the node that transmitted
the overheard packet, plus the suffix of the original source route beginning with the node
returning the gratuitous ROUTE REPLY. In this example, the route returned in the gratuitous
ROUTE REPLY message sent from C to A gives the new route as the sequence of hops from
A to C to D.

4.5.3 Increased Spreading of ROUTE ERROR Messages

When a source node receives a ROUTE ERROR for a data packet that it originated, this
source node propagates this 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 the same 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 from C, that the link from C to D is currently broken. It thus removes this
link from its own Route Cache and initiates a new Route Discovery (if it doesn’t 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 node’s Route Caches) in response
to this ROUTE REQUEST does not contain a route that assumes the existence of this broken
link.
A further improvement to Route Maintenance can be considered, in which anode, such as
A in Figure 5, that receives a ROUTE ERROR will forward the ERROR along the same
source route that resulted in the ERROR. This will almost guarantee that the ROUTE
ERROR reaches the node that generated the ROUTE REPLY containing the broken link,
which will prevent that node from contaminating a future 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 Route Caches. For example, in Figure 3, if node A caches the fact that the link from C
to D is currently broken(rather than simply removing this hop from its Route Cache), it can
guarantee that no ROUTE REPLY that it receives in response to its new Route Discovery
will be accepted that utilizes this broken link. A short expiration period must be placed on
this negative cached information, since while this entry is in its Route Cache, 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 node’s 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 sending node’s wireless transmission range and there are
significant sources of interference (e.g., multipath) near the 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 it is
working correctly.

4.6. Support for Heterogeneous Networks and Mobile IP

In configuring and deploying an ad hoc network, in many cases, all nodes will be equipped
with the same type of wireless network interfaces, allowing simple routing between nodes
over arbitrary sequences of network hops. However, a more flexible configuration might be
to also equip a subset of the nodes with a second network interface consisting of a longer-
range (and thus generally lower speed) wireless network interface. For example, in a military
Figure 8: An ad hoc network consisting of nodes communicating via short-range radios, with
nodes A, B,and C also having long-range radios.

setting, a group of soldiers might all use short-range radios to communicate among
themselves, while relaying through truck-mounted higher power radios to communicate with
other groups.
This general type of network configuration is the ad hoc networking equivalent of
wireless overlay networks. Due to the high degree of locality likely to be present among
directly cooperating nodes communicating with each other, such a network configuration
would allow high speed communication among such cooperating nodes, while at the same
time allowing communication with other nodes further away without requiring very large
numbers of network hops. The longer-range radios might also allow gaps between different
groups of nodes to be spanned, reducing the probability of network partition. A simple
example of such an ad hoc network configuration is shown in Figure 8. Nodes A, B, and C,
here, each have both short-range and long-range radio interfaces, all other nodes in the ad hoc
network have only short-range radio network interfaces. Node X is using a source route to
node Y that uses a sequence of both short-range and long-range hops.

4.6.1 Use of Interface Indices in DSR

DSR supports automatic, seamless routing in these and other heterogeneous configurations,
through its logical addressing model [1]. Using conventional IP addressing, each ad hoc
 Figure 9: An ad hoc network consisting of nodes with heterogeneous network interfaces.

network node would configure a different IP address for each of its possibly many network
interfaces, but as noted in Section 3, each node using DSR chooses one of these as its home
address to use for all communication while in the ad hoc network. This use of a single IP
address per node gives DSR the ability to treat the overall network 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 but need have no other significance and need not be coordinated with any
other nodes in choosing their own interface indices. On many operating systems, a unique
value to identify each network interface is already available and can be used for this purpose;
for example, the if index field in the if net structure for a network interface in BSD Unix-
based networking stacks can be used directly by a node for the interface index for that
network interface.
For example, Figure 9 illustrates a simple ad hoc network of four nodes, in which node A
is using one type of network interface (represented by the triangles), node C and node D are
using an different type of physical network interface (represented by the circles), and node B
is configured with both types of network interfaces and can forward packets between the two
different types of radio technologies. The number labelling each network interface indicates
the interface index chosen by the corresponding node for that interface. Since the interface
indices are chosen independently by each node, it is possible, for example, that nodes B and
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 fully represented as a series of hops N0/i0 _ N1/i1 _ N2/i2 _ 􀀀􀀀􀀀_ Nm, where the
notation Nk/ik is used to indicate that node Nk must transmit the packet using its network
interface ik in order to deliver the packet over the next hop to node Nk􀀀1.
In forwarding a ROUTE REQUEST, a node adds to the route record in the REQUEST,
not only its own address (Section 4.2), but also the interface index of its own network
interface on which it forwards the packet. To allow the reversing of a sequence of hops for a
reverse route back to the originating node (when, for example, the existence of bi-directional
links can by assumed based on the underlying MAC protocol),the node forwarding the
ROUTE REQUEST may also add to the route record in the REQUEST, the interface index of
its own network interface on which it received the ROUTE REQUEST packet. For example,
the source route shown in Figure 8 is A/1_ B/1 _ C/4_ D. The corresponding reversed route is
D/1_ C/4 _ B/2_ A. The interface indices to represent a route are carried in the ROUTE
REQUEST, the ROUTE REPLY, and the source route in the header of data packets.

4.6.2 Internet Interconnection and Mobile IP

DSR supports the seamless interoperation between an ad hoc network and the Internet,
allowing packets to transparently be routed from the ad hoc network to nodes in the Internet
and from the Internet to nodes in the ad hoc network [1]. To enable this interoperation, one
(or more) nodes in the ad hoc network must be connected to the Internet, such that it
participates in the ad hoc network through DSR, and also participates in the Internet through
standard IP routing. We call such a node a gateway between the ad hoc network and the
Internet. In this way, DSR allows the coverage range around a wireless Internet base station,
for example, to be dynamically enlarged through multiple “hops” between nodes through the
ad hoc network. It is also possible for such a gateway node to operate as a Mobile IP home
agent or foreign agent [3], allowing nodes to visit the ad hoc network as a Mobile IP foreign
network, and allowing nodes whose home network is the ad hoc network to visit other
networks using Mobile IP.
This functionality of interconnection with the Internet is implemented through two
special reserved interface index values, used by gateway nodes to identify their
interconnection to the Internet. If the node has a separate physical network interface by which
it connects to the Internet, other than the network interface(s) that it uses for participation in
the ad hoc network, the reserved interface index is used to identify that interface. However, it
is also possible for a node to use a single network interface both for participation in 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 Internet connection, and the node uses another (locally assigned) interface index value to
identify this interface in its 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, the gateway node uses the reserved value
IF_INDEX_ROUTER. The distinction between the reserved index values for mobility agents
and for routers allows mobility agents to advertise their existence (as needed for Mobile 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 unicast Mobile IPAGENT SOLICITATION to the
corresponding address 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 reserved interface 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 node itself, 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_MA or
IF_INDEX_ROUTER, since this will prefer routes that lead directly to the destination node
within the ad hoc network.

4.7 Multicast Routing with DSR

DSR does not currently support true multicast routing, but does support an approximation of
this that is sufficient in many network contexts. Through an extension of the Route Discovery
mechanism, DSR supports the controlled flooding of a data packet to all nodes in the ad hoc
network that are within some specified number of hops of the originator; these nodes may
then apply destination address filtering (e.g., in software) to limit the packet to those nodes
subscribed to the packet’s indicated multicast destination address.
While this mechanism does not support pruning of the broadcast tree to conserve
network resources, it can be used to distribute information to all nodes in the ad hoc network
subscribed to the destination multicast address. This mechanism may also be useful for
sending application level packets to all nodes in a limited range around the sender.
To utilize this form of multicasting, when an application on a DSR node sends a packet
to a multicast destination address, DSR piggybacks the data from the packet inside a ROUTE
REQUEST targeted at the multicast address. The normal ROUTE REQUEST propagation
scheme described in Section 4.2 will result in 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 then individually examines
the destination address of the packet and discards the packet if it is destined to a multicast
address to which this node is not subscribed.

4.8 Location of DSR 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 atthe network
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 nodes that 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 from our contemplation of a
multi-hop propagating version of the Internet’s Address Resolution Protocol(ARP), as well as
from the routing mechanism used in IEEE 802 source routing bridges. These are layer 2
protocols.
Technically, DSR was designed to be simple enough that that it could be implemented
directly in the firmware inside wireless network interface cards [3], well below the layer 3
software within a mobile node. There is great potential in this for DSR running inside a cloud
of mobile nodes around a fixed base station, where DSR would act to transparently extend the
coverage range to these nodes. Mobile nodes that would otherwise be unable to communicate
with the base station due to factors such as distance, fading, or local interference sources
could then reach the base station 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 network interfaces of different types, as described in Section 4.6.
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 the same 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 state
extension 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.
4.10 DSR on 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 of DSR options in the DSR Options header is implied by the total length of the
DSR Options header.

4.10.1 Fixed Portion of DSR 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
 Figure 10: IPv4 Header Format

32 bits

Figure 11: Fixed Portion of DSR Options 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 (that is, 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
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 the gory details are omitted.
Route Request contains “Identification”, “Target Address” and “Address[1..n]” fields.
Route requests will be sent to the limited broadcast address“255.255.255.255”, and the
destination address where the source wants to find the route for is placed in “Target address”
field. Identification is a sequence number, used to distinguish between already seen and old
messages.“Address [1..n]” are used to store the addresses along the the path of Route
Discovery.
Route Reply contains “L”-bit, “Reserved” and “Address[1..n]” fields. Last Hop External
bit indicates that the 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 back to the originator of Route Request by
either the node that was the Target of the original Route Request or by some intermediate
node, as a Reply from Cache or as a gratuitous 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 the
DSR Source Route option triggering the error. “Error Source Address” is the address of the
node which encountered an error; “Error Destination Address” is the original source of the
failed packet. In the case of Node Unreachable message, type-specific information contains
the address of the unreachable node. Route Errors are sent to inform the source (and
intermediate nodes)of failed source routes.
 Acknowledgment Request contains “Identification” field. It is a unique value that will be
used in Acknowledgment response to create a link between the two. Acknowledgments are
used for ensuring the reliable delivery of Route Maintenance packets if no other form (e.g.
link-layer acknowledgments, passive acknowledgments by promiscuous mode) is available.
Acknowledgment contains “Identification”, “ACK Source Address”, and “ACK Destination
Address” fields. Identification is copied from the Request, ACK
Source Address is the address of the node originating the acknowledgment, and ACK
Destination Address isthe address to which the acknowledgment will be delivered to.
DSR Source Route contains “F” and “L” -bits, “Reserved”, “Salvage”, “Segments Left”,
and “Address [1..n]” fields. First and Last Hop External bits indicate whether the route leads
to or from outside of the DSR network; such paths must not be returned from the cache of
intermediate nodes. “Salvage” indicates the number of times the packet has been salvaged
(see section 4.5.1), that is, rewritten by an intermediate node to ensure delivery. “Segments
Left” indicate show many addresses in the option must still be traversed until reaching the
final destination. “Address[1..n]” lists these intermediate nodes which the packet has been,
and will be, through. DSR Source Route option is present in almost every packet.
Pad1 and PadN options include requested amount of padding, to ensure that the total
DSR Header will be properly aligned to a multiple of 4 bytes.
 5. FUTURE WORK

The scope of applicability of DSR needs to be more precisely defined. Interactions with
IPSEC, and routing protocol security in general should be studied. Interactions with packet
filters should be explored. The specification text should be clarified on some points,
especially regarding retransmissions. Especially a mixed network 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. Even though DSR is not meant for many hundreds of nodes,
comparisons with other MANET protocols with these amounts of nodes might be interesting.
 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 other MANET 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
 7. REFERENCES
[1] Josh Broch, David B. Johnson, and David A. Maltz. “The Dynamic Source Routing
Protocol for Mobile Ad Hoc Networks”. Internet-Draft, draft-ietf-manet-dsr-03.txt,
October 1999. Work in progress. Earlier revisions published June 1999, December
1998, and March 1998.

[2] Robert Casta˜neda and Samir R. Das. Query Localization Techniques for On-demand
Routing Protocols in Ad Hoc Networks. In Proceedings of the Fifth International
Conference on Mobile Computing and Networking (MobiCom’99).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 and Applications, pages 158–163.
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) and Physical 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 by Charles E. Perkins, Chapter 5, pp. 139-172, Addison-Wesley, 2001

[7] Pekka Savola: “DSR: Dynamic Source Routing”, CSC/FUNET, Helsinki University of
Technology.