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/