draft-ietf-manet-dsr-01.txt   draft-ietf-manet-dsr-02.txt 
IETF MANET Working Group Josh Broch IETF MANET Working Group Josh Broch
INTERNET-DRAFT David B. Johnson INTERNET-DRAFT David B. Johnson
David A. Maltz David A. Maltz
Carnegie Mellon University Carnegie Mellon University
8 December 1998 25 June 1999
The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks
<draft-ietf-manet-dsr-01.txt> <draft-ietf-manet-dsr-02.txt>
Status of This Memo Status of This Memo
This document is a submission to the Mobile Ad-hoc Networks (manet) This document is an Internet-Draft and is in full conformance with
Working Group of the Internet Engineering Task Force (IETF). all provisions of Section 10 of RFC 2026 except that the right to
Comments should be submitted to the Working Group mailing list at produce derivative works is not granted.
"manet@itd.nrl.navy.mil". Distribution of this memo is unlimited.
This document is an Internet-Draft. Internet-Drafts are working Internet-Drafts are working documents of the Internet Engineering
documents of the Internet Engineering Task Force (IETF), its areas, Task Force (IETF), its areas, and its working groups. Note
and its working groups. Note that other groups may also distribute that other groups may also distribute working documents as
working documents as Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet-Drafts as reference any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check The list of current Internet-Drafts can be accessed at
the "1id-abstracts.txt" listing contained in the Internet-Drafts http://www.ietf.org/ietf/1id-abstracts.txt
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or The list of Internet-Draft Shadow Directories can be accessed at
ftp.isi.edu (US West Coast). http://www.ietf.org/shadow.html.
Abstract Abstract
Dynamic Source Routing (DSR) is a routing protocol designed Dynamic Source Routing (DSR) is a routing protocol designed
specifically for use in mobile ad hoc networks. The protocol allows specifically for use in mobile ad hoc networks. The protocol allows
nodes to dynamically discover a source route across multiple network nodes to dynamically discover a source route across multiple network
hops to any destination in the ad hoc network. When using source hops to any destination in the ad hoc network. When using source
routing, each packet to be routed carries in its header the complete, routing, each packet to be routed carries in its header the complete,
ordered list of nodes through which the packet must pass. A key ordered list of nodes through which the packet must pass. A key
advantage of source routing is that intermediate hops do not need advantage of source routing is that intermediate hops do not need
skipping to change at page 1, line 113 skipping to change at page 1, line 111
7.5.5. Salvaging a Packet . . . . . . . . . . . . . . . 33 7.5.5. Salvaging a Packet . . . . . . . . . . . . . . . 33
8. Optimizations 35 8. Optimizations 35
8.1. Leveraging the Route Cache . . . . . . . . . . . . . . . 35 8.1. Leveraging the Route Cache . . . . . . . . . . . . . . . 35
8.1.1. Promiscuous Learning of Source Routes . . . . . . 35 8.1.1. Promiscuous Learning of Source Routes . . . . . . 35
8.2. Preventing Route Reply Storms . . . . . . . . . . . . . . 36 8.2. Preventing Route Reply Storms . . . . . . . . . . . . . . 36
8.3. Piggybacking on Route Discoveries . . . . . . . . . . . . 37 8.3. Piggybacking on Route Discoveries . . . . . . . . . . . . 37
8.4. Discovering Shorter Routes . . . . . . . . . . . . . . . 37 8.4. Discovering Shorter Routes . . . . . . . . . . . . . . . 37
8.5. Rate Limiting the Route Discovery Process . . . . . . . . 38 8.5. Rate Limiting the Route Discovery Process . . . . . . . . 38
8.6. Improved Handling of Route Errors . . . . . . . . . . . . 39 8.6. Improved Handling of Route Errors . . . . . . . . . . . . 39
8.7. Increasing Scalability . . . . . . . . . . . . . . . . . 39
9. Constants 40 9. Constants 40
10. IANA Considerations 41 10. IANA Considerations 41
11. Security Considerations 42 11. Security Considerations 42
Location of DSR Functions in the ISO Model 43 Location of DSR Functions in the ISO Model 43
Implementation Status 44 Implementation Status 44
skipping to change at page 1, line 134 skipping to change at page 1, line 133
Acknowledgments 45 Acknowledgments 45
References 46 References 46
Chair's Address 48 Chair's Address 48
Authors' Addresses 49 Authors' Addresses 49
1. Introduction 1. Introduction
This document describes Dynamic Source Routing (DSR) [6, 7], a This document describes Dynamic Source Routing (DSR) [7, 8], a
protocol developed by the Monarch Project [8, 14] at Carnegie Mellon protocol developed by the Monarch Project [9, 16] at Carnegie Mellon
University for routing packets in a mobile ad hoc network [3]. University for routing packets in a mobile ad hoc network [4].
Source routing is a routing technique in which the sender of a packet Source routing is a routing technique in which the sender of a packet
determines the complete sequence of nodes through which to forward determines the complete sequence of nodes through which to forward
the packet; the sender explicitly lists this route in the packet's the packet; the sender explicitly lists this route in the packet's
header, identifying each forwarding "hop" by the address of the next header, identifying each forwarding "hop" by the address of the next
node to which to transmit the packet on its way to the destination node to which to transmit the packet on its way to the destination
node. node.
DSR offers a number of potential advantages over other routing DSR offers a number of potential advantages over other routing
protocols for mobile ad hoc networks. First, DSR uses no periodic protocols for mobile ad hoc networks. First, DSR uses no periodic
skipping to change at page 2, line 48 skipping to change at page 2, line 48
A bit string that consists of some number of initial bits of an A bit string that consists of some number of initial bits of an
address. address.
interface index interface index
An 7-bit quantity which uniquely identifies an interface among An 7-bit quantity which uniquely identifies an interface among
a given node's interfaces. Each node can assign interface a given node's interfaces. Each node can assign interface
indices to its interfaces using any scheme it wishes. indices to its interfaces using any scheme it wishes.
The index IF_INDEX_MA is reserved for use by Mobile IP [9] The index IF_INDEX_MA is reserved for use by Mobile IP [11]
mobility agents (home or foreign agents) to indicate that they mobility agents (home or foreign agents) to indicate that they
believe they can reach a destination via a connected internet believe they can reach a destination via a connected internet
infrastructure. The index IF_INDEX_ROUTER is reserved for infrastructure. The index IF_INDEX_ROUTER is reserved for
use by routers not acting as Mobile IP mobility agents to use by routers not acting as Mobile IP mobility agents to
indicate that they believe they can reach the destination via a indicate that they believe they can reach the destination via a
connected internet infrastructure. connected internet infrastructure.
The distinction between the index for mobility agents and The distinction between the index for mobility agents and
the index for routers, allows mobility agents to advertise the index for routers, allows mobility agents to advertise
their existence ``for free''. A node that processes a routing their existence ``for free''. A node that processes a routing
skipping to change at page 3, line 34 skipping to change at page 3, line 34
piggybacking piggybacking
Including two or more conceptually different types of data in Including two or more conceptually different types of data in
the same packet so that all data elements move through the the same packet so that all data elements move through the
network together. network together.
home address home address
An IP address that is assigned for an extended period of time An IP address that is assigned for an extended period of time
to a mobile node. It remains unchanged regardless of where to a mobile node. It remains unchanged regardless of where
the node is attached to the Internet [9]. If a node has more the node is attached to the Internet [11]. If a node has more
than one home address, it SHOULD select and use a single home than one home address, it SHOULD select and use a single home
address when participating in the ad hoc network. address when participating in the ad hoc network.
source route source route
A source route from a node S to some node D is an ordered list A source route from a node S to some node D is an ordered list
of home addresses and interface indexes that contains all the of home addresses and interface indexes that contains all the
information that would be needed to forward a packet through information that would be needed to forward a packet through
the ad hoc network. For each node that will transmit the the ad hoc network. For each node that will transmit the
packet, the source route provides the index of the interface packet, the source route provides the index of the interface
skipping to change at page 5, line 52 skipping to change at page 5, line 52
a unique identifier for this Route Discovery, generated by the a unique identifier for this Route Discovery, generated by the
initiator of the Discovery. Each node maintains an LRU cache of the initiator of the Discovery. Each node maintains an LRU cache of the
unique identifier from each recently received Route Request. By not unique identifier from each recently received Route Request. By not
propagating any copies of a Request after the first, the overhead of propagating any copies of a Request after the first, the overhead of
forwarding additional copies that reach this node along different forwarding additional copies that reach this node along different
paths is avoided. paths is avoided.
In addition, the Time-to-Live field in the IP header of the packet In addition, the Time-to-Live field in the IP header of the packet
carrying the Route Request MAY be used to limit the scope over which carrying the Route Request MAY be used to limit the scope over which
the Request will propagate, using the normal behavior of Time-to-Live the Request will propagate, using the normal behavior of Time-to-Live
defined by IP [12, 1]. Additional optimizations on the handling and defined by IP [14, 1]. Additional optimizations on the handling and
forwarding of Route Requests are also used to further reduce the forwarding of Route Requests are also used to further reduce the
Route Discovery overhead. Route Discovery overhead.
When the target of the Request (e.g., node D) receives the Route When the target of the Request (e.g., node D) receives the Route
Request, the recorded source route in the Request identifies the Request, the recorded source route in the Request identifies the
sequence of hops over which this copy of the Request reached D. sequence of hops over which this copy of the Request reached D.
Node D copies this recorded source route into a Route Reply packet Node D copies this recorded source route into a Route Reply packet
and sends this Route Reply back to the initiator of the Route Request and sends this Route Reply back to the initiator of the Route Request
(e.g., node S). (e.g., node S).
skipping to change at page 6, line 41 skipping to change at page 6, line 41
the network. Such route information MAY be learned either by the network. Such route information MAY be learned either by
promiscuously snooping on packets or when forwarding packets. promiscuously snooping on packets or when forwarding packets.
4.2. Packet Forwarding 4.2. Packet Forwarding
To represent a source route within a packet's header, DSR uses a To represent a source route within a packet's header, DSR uses a
Routing Header similar to the Routing Header format specified for Routing Header similar to the Routing Header format specified for
IPv6, adapted to the needs of DSR and to the use of DSR in IPv4 (or IPv6, adapted to the needs of DSR and to the use of DSR in IPv4 (or
in IPv6 in the future). The DSR Routing Header uses a unique Routing in IPv6 in the future). The DSR Routing Header uses a unique Routing
Type field value to distinguish it from the existing Type 0 Routing Type field value to distinguish it from the existing Type 0 Routing
Header defined within IPv6 [4]. Header defined within IPv6 [5].
To forward a packet, a receiving node N simply processes the Routing To forward a packet, a receiving node N simply processes the Routing
Header as specified in Section 7.3 and transmits the packet to Header as specified in Section 7.3 and transmits the packet to
the next hop. If a forwarding error occurs along the link to the the next hop. If a forwarding error occurs along the link to the
next hop in the route, this node N sends a Route Error back to the next hop in the route, this node N sends a Route Error back to the
originator S of this packet informing S that this link is "broken". originator S of this packet informing S that this link is "broken".
If node N's Route Cache contains a different route to the destination If node N's Route Cache contains a different route to the destination
of the original packet, then the packet is salvaged using the new of the original packet, then the packet is salvaged using the new
source route (Section 7.5.5). Otherwise, the packet is dropped. source route (Section 7.5.5). Otherwise, the packet is dropped.
skipping to change at page 11, line 11 skipping to change at page 11, line 11
DSR_MAXRXTSHIFT. In the later case, the removal of the packet from DSR_MAXRXTSHIFT. In the later case, the removal of the packet from
the Retransmission Buffer SHOULD result in a Route Error being the Retransmission Buffer SHOULD result in a Route Error being
returned to the initial source of the packet (Section 7.5). returned to the initial source of the packet (Section 7.5).
6. Packet Formats 6. Packet Formats
Dynamic Source Routing makes use of four options carrying control Dynamic Source Routing makes use of four options carrying control
information that can be piggybacked in any existing IP packet. information that can be piggybacked in any existing IP packet.
The mechanism used for these options is based on the design of the The mechanism used for these options is based on the design of the
Hop-by-Hop and Destination Options mechanisms in IPv6 [4]. The Hop-by-Hop and Destination Options mechanisms in IPv6 [5]. The
ability to generate and process such options must be added to an IPv4 ability to generate and process such options must be added to an IPv4
protocol stack. Specifically, the Protocol field in the IP header protocol stack. Specifically, the Protocol field in the IP header
is used to indicate that a Hop-by-Hop Options or Destination Options is used to indicate that a Hop-by-Hop Options or Destination Options
extension header exists between the IP header and the remaining extension header exists between the IP header and the remaining
portion of a packet's payload (such as a transport layer header). portion of a packet's payload (such as a transport layer header).
The Next Header field in each extension header will then indicate the The Next Header field in each extension header will then indicate the
type of header that follows it in a packet. type of header that follows it in a packet.
6.1. Destination Options Headers 6.1. Destination Options Headers
skipping to change at page 11, line 42 skipping to change at page 11, line 42
. . . .
. Options . . Options .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header Next Header
8-bit selector. Identifies the type of header immediately 8-bit selector. Identifies the type of header immediately
following the Destination Options header. Uses the same values following the Destination Options header. Uses the same values
as the IPv4 Protocol field [15]. as the IPv4 Protocol field [17].
Hdr Ext Len Hdr Ext Len
8-bit unsigned integer. Length of the Destination Options 8-bit unsigned integer. Length of the Destination Options
header in 4-octet units, not including the first 8 octets. header in 4-octet units, not including the first 8 octets.
Options Options
Variable-length field, of length such that the complete Variable-length field, of length such that the complete
Destination Options header is an integer multiple of 4 octets Destination Options header is an integer multiple of 4 octets
skipping to change at page 14, line 45 skipping to change at page 14, line 45
. . . .
. Options . . Options .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header Next Header
8-bit selector. Identifies the type of header immediately 8-bit selector. Identifies the type of header immediately
following the Hop-by-Hop Options header. Uses the same values following the Hop-by-Hop Options header. Uses the same values
as the IPv4 Protocol field [15]. as the IPv4 Protocol field [17].
Hdr Ext Len Hdr Ext Len
8-bit unsigned integer. Length of the Hop-by-Hop Options 8-bit unsigned integer. Length of the Hop-by-Hop Options
header in 4-octet units, not including the first 8 octets. header in 4-octet units, not including the first 8 octets.
Options Options
Variable-length field, of length such that the complete Variable-length field, of length such that the complete
Hop-by-Hop Options header is an integer multiple of 4 octets Hop-by-Hop Options header is an integer multiple of 4 octets
skipping to change at page 20, line 7 skipping to change at page 20, line 7
The home address of the node to which the Acknowledgment must The home address of the node to which the Acknowledgment must
be delivered. be delivered.
Data Source Address Data Source Address
The IP Source Address of the packet being acknowledged. The IP Source Address of the packet being acknowledged.
6.3. DSR Routing Header 6.3. DSR Routing Header
As specified for IPv6 [4], a Routing header is used by a source to As specified for IPv6 [5], a Routing header is used by a source to
list one or more intermediate nodes to be ``visited'' on the way to list one or more intermediate nodes to be ``visited'' on the way to
a packet's destination. This function is similar to IPv4's Loose a packet's destination. This function is similar to IPv4's Loose
Source and Record Route option, but the Routing header does not Source and Record Route option, but the Routing header does not
record the route taken as the packet is forwarded. The specific record the route taken as the packet is forwarded. The specific
processing steps required to implement the Routing header must be processing steps required to implement the Routing header must be
added to an IPv4 protocol stack. The Routing header is identified by added to an IPv4 protocol stack. The Routing header is identified by
a Next Header value of 43 in the immediately preceding header, and a Next Header value of 43 in the immediately preceding header, and
has the following format: has the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 24, line 23 skipping to change at page 24, line 23
RT.Out_Index[2] = Interface index used by B to reach C RT.Out_Index[2] = Interface index used by B to reach C
RT.Out_Index[3] = Interface index used by C to reach D RT.Out_Index[3] = Interface index used by C to reach D
RT.Address[1] = Home address of node B RT.Address[1] = Home address of node B
RT.Address[2] = Home address of node C RT.Address[2] = Home address of node C
RT.Address[3] = Home address of node D RT.Address[3] = Home address of node D
7.3. Processing a Routing Header 7.3. Processing a Routing Header
Excluding the exceptions listed here, a DSR Routing Header is Excluding the exceptions listed here, a DSR Routing Header is
processed using the same rules as outlined for Type 0 Routing Headers processed using the same rules as outlined for Type 0 Routing Headers
in IPv6 [4]. The Routing Header is only processed by the node whose in IPv6 [5]. The Routing Header is only processed by the node whose
address appears as the IP destination of the packet. The following address appears as the IP destination of the packet. The following
additional rules apply to processing the type specific data of a DSR additional rules apply to processing the type specific data of a DSR
Source Route: Source Route:
Let Let
SegLft = the value of Segments Left when the packet was received SegLft = the value of Segments Left when the packet was received
NumAddrs = the total number of addresses in the Routing Header NumAddrs = the total number of addresses in the Routing Header
1. The address of the next hop, Address[NumAddrs - SegLft + 1], 1. The address of the next hop, Address[NumAddrs - SegLft + 1],
skipping to change at page 29, line 21 skipping to change at page 29, line 21
REPPacket.Reply.OUT_Index[1] = REQPacket.Request.OUT_index[1] REPPacket.Reply.OUT_Index[1] = REQPacket.Request.OUT_index[1]
REPPacket.Reply.OUT_C_bit[1] = REQPacket.Request.OUT_C_bit[1] REPPacket.Reply.OUT_C_bit[1] = REQPacket.Request.OUT_C_bit[1]
REPPacket.Reply.Address[1] = The home address of node A REPPacket.Reply.Address[1] = The home address of node A
GOTO step 3. GOTO step 3.
2. Otherwise, build a Route Reply packet as follows: 2. Otherwise, build a Route Reply packet as follows:
REPPacket.IP.Source_Address = The home address of node A REPPacket.IP.Source_Address = The home address of node A
REPPacket.Reply.Target = REQPacket.IP.Source_Address REPPacket.Reply.Target = REQPacket.IP.Source_Address
REPPacket.Reply.OUT_Index[1..n]= REQPacket.Request.OUT_index[1..n] REPPacket.Reply.OUT_Index[1..n]=
REPPacket.Reply.OUT_C_bit[1..n]= REQPacket.Request.OUT_C_bit[1..n] REQPacket.Request.OUT_index[1..n]
REPPacket.Reply.OUT_C_bit[1..n]=
REQPacket.Request.OUT_C_bit[1..n]
REPPacket.Reply.Address[1..n] = REQPacket.Request.Address[1..n] REPPacket.Reply.Address[1..n] = REQPacket.Request.Address[1..n]
3. Send the Route Reply jittered by T milliseconds, where T 3. Send the Route Reply jittered by T milliseconds, where T
is a uniformly distributed random number between 0 and is a uniformly distributed random number between 0 and
BROADCAST_JITTER. DONE. BROADCAST_JITTER. DONE.
If sending a Route Reply packet to the originator of the Route If sending a Route Reply packet to the originator of the Route
Request requires performing a Route Discovery, the Route Reply Request requires performing a Route Discovery, the Route Reply
hop-by-hop option MUST be piggybacked on the packet that contains the hop-by-hop option MUST be piggybacked on the packet that contains the
Route Request. This prevents a loop wherein the target of the new Route Request. This prevents a loop wherein the target of the new
skipping to change at page 37, line 21 skipping to change at page 37, line 21
As described in Section 4.1, when one node needs to send a packet As described in Section 4.1, when one node needs to send a packet
to another, if the sender does not have a route cached to the to another, if the sender does not have a route cached to the
destination node, it must initiate a Route Discovery, buffering the destination node, it must initiate a Route Discovery, buffering the
original packet until the Route Reply is returned. The delay for original packet until the Route Reply is returned. The delay for
Route Discovery and the total number of packets transmitted can be Route Discovery and the total number of packets transmitted can be
reduced by allowing data to be piggybacked on Route Request packets. reduced by allowing data to be piggybacked on Route Request packets.
Since some Route Requests may be propagated widely within the ad hoc Since some Route Requests may be propagated widely within the ad hoc
network, though, the amount of data piggybacked must be limited. We network, though, the amount of data piggybacked must be limited. We
currently use piggybacking when sending a Route Reply or a Route currently use piggybacking when sending a Route Reply or a Route
Error packet, since both are naturally small in size. Small data Error packet, since both are naturally small in size. Small data
packets such as the initial SYN packet opening a TCP connection [13] packets such as the initial SYN packet opening a TCP connection [15]
could easily be piggybacked. could easily be piggybacked.
One problem, however, arises when piggybacking on Route Request One problem, however, arises when piggybacking on Route Request
packets. If a Route Request is received by a node that replies packets. If a Route Request is received by a node that replies
to the request based on its Route Cache without propagating the to the request based on its Route Cache without propagating the
Request (Section 8.1), the piggybacked data will be lost if the node Request (Section 8.1), the piggybacked data will be lost if the node
simply discards the Route Request. In this case, before discarding simply discards the Route Request. In this case, before discarding
the packet, the node must construct a new packet containing the the packet, the node must construct a new packet containing the
piggybacked data from the Route Request packet. The source route piggybacked data from the Route Request packet. The source route
in this packet MUST be constructed to appear as if the new packet in this packet MUST be constructed to appear as if the new packet
skipping to change at page 40, line 5 skipping to change at page 39, line 37
to support the caching of "negative" information in a node's Route to support the caching of "negative" information in a node's Route
Cache. The goal of negative information is to record that a given Cache. The goal of negative information is to record that a given
route was tried and found not to work, so that if the same route route was tried and found not to work, so that if the same route
is discovered again shortly after the failure, the Route Cache can is discovered again shortly after the failure, the Route Cache can
ignore or downgrade the metric of the failed route. ignore or downgrade the metric of the failed route.
We have not currently included this caching of negative information We have not currently included this caching of negative information
in our simulations, since it appears to be unnecessary if nodes also in our simulations, since it appears to be unnecessary if nodes also
promiscuously receive Route Error packets. promiscuously receive Route Error packets.
8.7. Increasing Scalability
We recently designed and began experimenting with ways to integrate
ad hoc networks with the Internet and with Mobile IP [11]. In
addition to this, we are also exploring ways to increase the
scalablity of ad hoc networks by taking advantage of their
cooperative nature and the fact that some hierarchy can be imposed
on an ad hoc network, just be assigning addresses to the nodes in a
reasonable way. These ideas are described in a workshop paper [3].
9. Constants 9. Constants
BROADCAST_JITTER 10 milliseconds BROADCAST_JITTER 10 milliseconds
MAX_ROUTE_LEN 15 nodes MAX_ROUTE_LEN 15 nodes
Interface Indexes Interface Indexes
IF_INDEX_INVALID 0x7F IF_INDEX_INVALID 0x7F
IF_INDEX_MA 0x7E IF_INDEX_MA 0x7E
IF_INDEX_ROUTER 0x7D IF_INDEX_ROUTER 0x7D
skipping to change at page 43, line 16 skipping to change at page 43, line 16
When designing DSR, we had to determine at what level within the When designing DSR, we had to determine at what level within the
protocol hierarchy to implement source routing. We considered two protocol hierarchy to implement source routing. We considered two
different options: routing at the link layer (ISO layer 2) and different options: routing at the link layer (ISO layer 2) and
routing at the network layer (ISO layer 3). Originally, we opted to routing at the network layer (ISO layer 3). Originally, we opted to
route at the link layer for the following reasons: route at the link layer for the following reasons:
- Pragmatically, running the DSR protocol at the link layer - Pragmatically, running the DSR protocol at the link layer
maximizes the number of mobile nodes that can participate in maximizes the number of mobile nodes that can participate in
ad hoc networks. For example, the protocol can route equally ad hoc networks. For example, the protocol can route equally
well between IPv4 [12], IPv6 [4], and IPX [5] nodes. well between IPv4 [14], IPv6 [5], and IPX [6] nodes.
- Historically, DSR grew from our contemplation of a multi-hop ARP - Historically, DSR grew from our contemplation of a multi-hop ARP
protocol [6, 7] and source routing bridges [10]. ARP [11] is a protocol [7, 8] and source routing bridges [12]. ARP [13] is a
layer 2 protocol. layer 2 protocol.
- Technically, we designed DSR to be simple enough that that it - Technically, we designed DSR to be simple enough that that it
could be implemented directly in network interface cards, well could be implemented directly in network interface cards, well
below the layer 3 software within a mobile node. We see great below the layer 3 software within a mobile node. We see great
potential for DSR running between clouds of mobile nodes around potential for DSR running between clouds of mobile nodes around
fixed base stations. DSR would act to transparently fill in the fixed base stations. DSR would act to transparently fill in the
coverage gaps between base stations. Mobile nodes that would coverage gaps between base stations. Mobile nodes that would
otherwise be unable to communicate with the base station due to otherwise be unable to communicate with the base station due to
factors such as distance, fading, or local interference sources factors such as distance, fading, or local interference sources
skipping to change at page 45, line 5 skipping to change at page 44, line 12
since this is the only layer at which we could realistically support since this is the only layer at which we could realistically support
nodes with multiple interfaces of different types. nodes with multiple interfaces of different types.
Implementation Status Implementation Status
We have implemented Dynamic Source Routing (DSR) under the We have implemented Dynamic Source Routing (DSR) under the
FreeBSD 2.2.7 operating system running on Intel x86 platforms. FreeBSD 2.2.7 operating system running on Intel x86 platforms.
FreeBSD is based on a variety of free software, including 4.4 BSD FreeBSD is based on a variety of free software, including 4.4 BSD
Lite from the University of California, Berkeley. Lite from the University of California, Berkeley.
During the 7 months from August 1998 to February 1999, we designed
and implemented a full-scale physical testbed to enable the
evaluation of ad hoc network performance in the field. The last
week of February and the first week of March included demonstrations
of this testbed to a number of our sponsors and partners, including
Lucent Technologies, Bell Atlantic, and DARPA. A complete description
of the testbed is available as a Technical Report [10].
Acknowledgments Acknowledgments
The protocol described in this draft has been designed within The protocol described in this draft has been designed within
the CMU Monarch Project, a research project at Carnegie Mellon the CMU Monarch Project, a research project at Carnegie Mellon
University which is developing adaptive networking protocols and University which is developing adaptive networking protocols and
protocol interfaces to allow truly seamless wireless and mobile node protocol interfaces to allow truly seamless wireless and mobile node
networking [8, 14]. The current members of the CMU Monarch Project networking [9, 16]. The current members of the CMU Monarch Project
include: include:
- Josh Broch - Josh Broch
- Yih-Chun Hu - Yih-Chun Hu
- Jorjeta Jetcheva - Jorjeta Jetcheva
- David B. Johnson - David B. Johnson
- Qifa Ke - Qifa Ke
- David A. Maltz - David A. Maltz
References References
[1] R. Braden, editor. Requirements for Internet Hosts -- [1] Robert Braden, editor. Requirements for Internet Hosts --
Communication Layers. RFC 1122, October 1989. Communication Layers. RFC 1122, October 1989.
[2] Scott Bradner. Key words for use in RFCs to Indicate [2] Scott Bradner. Key words for use in RFCs to Indicate
Requirement Levels. RFC 2119, March 1997. Requirement Levels. RFC 2119, March 1997.
[3] Scott Corson and Joseph Macker. Mobile Ad Hoc Networking [3] Josh Broch, David A. Maltz, and David B. Johnson. Supporting
Hierarchy and Heterogeneous Interfaces in Multi-Hop Wireless Ad
Hoc Networks. In Proceedings of I-SPAN'99, Perth, Australia,
June 1999. To appear.
[4] Scott Corson and Joseph Macker. Mobile Ad Hoc Networking
(MANET): Routing Protocol Performance Issues and Evaluation (MANET): Routing Protocol Performance Issues and Evaluation
Considerations. Internet-Draft, draft-ietf-manet-issues-00.txt, Considerations. RFC 2501, January 1999.
September 1997. Work in progress.
[4] Stephen E. Deering and Robert M. Hinden. Internet [5] S. Deering and R. Hinden. Internet Protocol, version 6 (IPv6)
Protocol, Version 6 (IPv6) Specification. Internet-Draft, Specification. RFC 2460, December 1998.
draft-ietf-ipngwg-ipv6-spec-v2-01.txt, November 1997. Work in
progress.
[5] IPX Router Specification. Novell Part Number 107-000029-001, [6] IPX Router Specification. Novell Part Number 107-000029-001,
Document Version 1.30, March 1996. Document Version 1.30, March 1996.
[6] David B. Johnson. Routing in ad hoc networks of mobile hosts. [7] David B. Johnson. Routing in Ad Hoc Networks of Mobile Hosts.
In Proceedings of the IEEE Workshop on Mobile Computing Systems In Proceedings of the IEEE Workshop on Mobile Computing Systems
and Applications, pages 158--163, December 1994. and Applications, pages 158--163, December 1994.
[7] David B. Johnson and David A. Maltz. Dynamic source routing in [8] David B. Johnson and David A. Maltz. Dynamic Source Routing in
ad hoc wireless networks. In Mobile Computing, edited by Tomasz Ad Hoc Wireless Networks. In Mobile Computing, edited by Tomasz
Imielinski and Hank Korth, chapter 5, pages 153--181. Kluwer Imielinski and Hank Korth, chapter 5, pages 153--181. Kluwer
Academic Publishers, 1996. Academic Publishers, 1996.
[8] David B. Johnson and David A. Maltz. Protocols for adaptive [9] David B. Johnson and David A. Maltz. Protocols for Adaptive
wireless and mobile networking. IEEE Personal Communications, Wireless and Mobile Networking. IEEE Personal Communications,
3(1):34--42, February 1996. 3(1):34--42, February 1996.
[9] Charles Perkins, editor. IP Mobility Support. RFC 2002, [10] David A. Maltz, Josh Broch, and David B. Johnson. Experiences
Designing and Building a Multi-Hop Wireless Ad Hoc Network
Testbed. Technical Report 99-116, School of Computer Science,
Carnegie Mellon University, March 1999.
[11] Charles Perkins, editor. IP Mobility Support. RFC 2002,
October 1996. October 1996.
[10] Radia Perlman. Interconnections: Bridges and Routers. [12] Radia Perlman. Interconnections: Bridges and Routers.
Addison-Wesley, Reading, Massachusetts, 1992. Addison-Wesley, Reading, Massachusetts, 1992.
[11] David C. Plummer. An Ethernet Address Resolution Protocol: Or [13] David C. Plummer. An Ethernet address resolution protocol:
Converting Network Protocol Address to 48.bit Ethernet Addresses Or converting network protocol addresses to 48.bit Ethernet
for Transmission on Ethernet Hardware. RFC 826, November 1982. addresses for transmission on Ethernet hardware. RFC 826,
November 1982.
[12] J. Postel, editor. Internet Protocol. RFC 791, September 1981. [14] J. Postel. Internet Protocol. RFC 791, September 1981.
[13] J. Postel, editor. Transmission Control Protocol. RFC 793, [15] J. Postel. Transmission Control Protocol. RFC 793, September
September 1981. 1981.
[14] The CMU Monarch Project. http://www.monarch.cs.cmu.edu/. [16] The CMU Monarch Project. http://www.monarch.cs.cmu.edu/.
Computer Science Department, Carnegie Mellon University. Computer Science Department, Carnegie Mellon University.
[15] J. Reynolds and J. Postel. Assigned Numbers. RFC 1700, October [17] J. Reynolds and J. Postel. Assigned Numbers. RFC 1700, October
1994. 1994.
Chair's Address Chair's Address
The Working Group can be contacted via its current chairs: The Working Group can be contacted via its current chairs:
M. Scott Corson M. Scott Corson
Institute for Systems Research Institute for Systems Research
University of Maryland University of Maryland
College Park, MD 20742 College Park, MD 20742
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/