IETF MANET Working Group               David B. Johnson, Rice University
INTERNET-DRAFT                David A. Maltz, AON Networks
21 Carnegie Mellon University
24 February 2002 2003                            Yih-Chun Hu, Rice University
                         Jorjeta G. Jetcheva, Carnegie Mellon University

                  The Dynamic Source Routing Protocol
                    for Mobile Ad Hoc Networks (DSR)

                     <draft-ietf-manet-dsr-07.txt>

                     <draft-ietf-manet-dsr-08.txt>

Status of This Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC 2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note
   that other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at
   any time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft is a submission to the IETF Mobile Ad Hoc
   Networks (MANET) Working Group.  Comments on this draft may be sent
   to the Working Group at manet@itd.nrl.navy.mil, or may be sent
   directly to the authors.

Abstract

   The Dynamic Source Routing protocol (DSR) is a simple and efficient
   routing protocol designed specifically for use in multi-hop wireless
   ad hoc networks of mobile nodes.  DSR allows the network to be
   completely self-organizing and self-configuring, without the need
   for any existing network infrastructure or administration.  The
   protocol is composed of the two main mechanisms of "Route Discovery"
   and "Route Maintenance", which work together to allow nodes to
   discover and maintain source routes to arbitrary destinations in the ad hoc
   network.  The use of source routing allows packet routing
   to be trivially loop-free, avoids the need for up-to-date routing
   information in the intermediate nodes through which packets are
   forwarded, and allows nodes forwarding or overhearing packets to
   cache the routing information in them for their own future use.  All aspects of the protocol operate entirely on-demand,
   allowing the routing packet overhead of DSR to scale automatically
   to only that needed to react to changes in the routes currently in
   use.  This
   document specifies  The protocol allows multiple routes to any destination and
   allows each sender to select and control the operation routes used in routing
   its packets, for example for use in load balancing or for increased
   robustness.  Other advantages of the DSR protocol include easily
   guaranteed loop-free routing, support for routing
   unicast IPv4 packets use in multi-hop wireless ad hoc networks. networks containing
   unidirectional links, use of only "soft state" in routing, and very
   rapid recovery when routes in the network change.  The DSR protocol
   is designed mainly for mobile ad hoc networks with of up to
   around about two
   hundred nodes, and is designed to cope work well with relatively even very high
   rates of mobility.  This document specifies the operation of the DSR
   protocol for routing unicast IPv4 packets.

                                Contents

Status of This Memo                                                    i

Abstract                                                              ii

 1. Introduction                                                       1

 2. Assumptions                                                        3

 3. DSR Protocol Overview                                              5

     3.1. Basic DSR Route Discovery . . . . . . . . . . . . . . . .    5
     3.2. Basic DSR Route Maintenance . . . . . . . . . . . . . . .    7    8
     3.3. Additional Route Discovery Features . . . . . . . . . . .    9   10
           3.3.1. Caching Overheard Routing Information . . . . . .    9   10
           3.3.2. Replying to Route Requests using Cached Routes  .   10   11
           3.3.3. Preventing Route Reply Storms . . . . . . . . . .   11   12
           3.3.4. Route Request Hop Limits  . . . . . . . . . . . .   13   14
     3.4. Additional Route Maintenance Features . . . . . . . . . .   14   15
           3.4.1. Packet Salvaging  . . . . . . . . . . . . . . . .   14   15
           3.4.2. Queued Packets Destined over a Broken Link  . . .   14   15
           3.4.3. Automatic Route Shortening  . . . . . . . . . . .   15   16
           3.4.4. Increased Spreading of Route Error Messages . . .   16

 4. Conceptual Data Structures   17

     4.1. Route Cache .
     3.5. Optional DSR Flow State Extension . . . . . . . . . . . .   17
           3.5.1. Flow Establishment  . . . . . . . . . .   17
     4.2. Send Buffer . . . . .   18
           3.5.2. Receiving and Forwarding Establishment Packets  .   19
           3.5.3. Sending Packets Along Established Flows . . . . .   19
           3.5.4. Receiving and Forwarding Packets Sent Along
                          Established Flows  . . . . . . . . . . . .  20
     4.3.
           3.5.5. Processing Route Request Table Errors . . . . . . . . . . . . .   21
           3.5.6. Interaction with Automatic Route Shortening . . .   21
           3.5.7. Loop Detection  . . .   21
     4.4. Gratuitous Route Reply Table . . . . . . . . . . . . . .   22
     4.5. Network Interface Queue and Maintenance Buffer
           3.5.8. Acknowledgement Destination . . . . .   23
     4.6. Blacklist . . . . . .   22
           3.5.9. Crash Recovery  . . . . . . . . . . . . . . . . .   22
          3.5.10. Rate Limiting .   24

 5. DSR Header Format                                                 25

     5.1. Fixed Portion of DSR Header . . . . . . . . . . . . . . .   26
     5.2. Route Request Option . .   22
          3.5.11. Interaction with Packet Salvaging . . . . . . . .   23

 4. Conceptual Data Structures                                        24

     4.1. Route Cache . . . . . . . .   28
     5.3. Route Reply Option . . . . . . . . . . . . . . .   24
     4.2. Send Buffer . . . .   30
     5.4. Route Error Option . . . . . . . . . . . . . . . . . . .   32
     5.5. Acknowledgment   27
     4.3. Route Request Option Table . . . . . . . . . . . . . .   35
     5.6. Acknowledgment Option . . . . .   28
     4.4. Gratuitous Route Reply Table  . . . . . . . . . . . . .   36
     5.7. DSR Source Route Option .   29
     4.5. Network Interface Queue and Maintenance Buffer  . . . . .   30
     4.6. Blacklist . . . . . . . . . . .   37
     5.8. Pad1 Option . . . . . . . . . . . . .   31

 5. Additional Conceptual Data Structures for Flow State Extension    32

     5.1. Flow Table  . . . . . . . . . .   39
     5.9. PadN Option . . . . . . . . . . . . .   32
     5.2. Automatic Route Shortening Table  . . . . . . . . . .   40
 6. Detailed Operation                                                41

     6.1. General Packet Processing . .   33
     5.3. Default Flow ID Table . . . . . . . . . . . . . . . .   41
           6.1.1. Originating a Packet . .   33

 6. DSR Options Header Format                                         35

     6.1. Fixed Portion of DSR Options Header . . . . . . . . . . .   36
     6.2. Route Request Option  .   41
           6.1.2. Adding a DSR Header to a Packet . . . . . . . . .   41
           6.1.3. Adding a DSR Source . . . . . . . .   39
     6.3. Route Reply Option to a Packet  . .   42
           6.1.4. Processing a Received Packet . . . . . . . . . .   43
           6.1.5. Processing a Received DSR Source . . . . . . .   41
     6.4. Route Error Option  . .   45
     6.2. Route Discovery Processing . . . . . . . . . . . . . . .   48
           6.2.1. Originating a Route . .   43
           6.4.1. Node Unreachable Type-Specific Information  . . .   45
           6.4.2. Flow State Not Supported Type-Specific Information  45
           6.4.3. Option Not Supported Type-Specific Information  .   45
     6.5. Acknowledgement Request Option  . . . . . . . . . . .   48
           6.2.2. Processing a Received Route Request . .   46
     6.6. Acknowledgement Option  . . .   50
           6.2.3. Generating a Route Reply using the Route Cache .   52
           6.2.4. Originating a Route Reply . . . . . . . . . . . .   54
           6.2.5. Processing a Received .   47
     6.7. DSR Source Route Reply Option . . . .   56
     6.3. Route Maintenance Processing . . . . . . . . . . . . .   48
     6.8. Pad1 Option .   57
           6.3.1. Using Link-Layer Acknowledgments . . . . . . . .   57
           6.3.2. Using Passive Acknowledgments . . . . . . . . . .   58
           6.3.3. Using Network-Layer Acknowledgments . . . .   50
     6.9. PadN Option . . .   59
           6.3.4. Originating a Route Error . . . . . . . . . . . .   62
           6.3.5. Processing a Received Route Error Option . . . .   63
           6.3.6. Salvaging a Packet . . . .   51

 7. Additional Header Formats and Options for Flow State Extension    52

     7.1. DSR Flow State Header . . . . . . . . . . .   64

 7. Multiple Interface Support                                        66

 8. Fragmentation and Reassembly                                      67

 9. Protocol Constants . . . . . . .   53
     7.2. Options and Configuration Variables                    68

10. IANA Considerations Extensions in DSR Options Header  . . . . . .   54
           7.2.1. Timeout Option  . . . . . . . . . . . . . . . . .   54
           7.2.2. Destination and Flow ID Option  . . . . . . . . .   55
           7.2.3. New Error Type Value for Unknown Flow . . . . . .   56
           7.2.4. New Error Type Value for Default Flow Unknown . .   57
           7.2.5. Acknowledgement Request Option
                          Previous Hop Address Extension . . . . . .  58

 8. Detailed Operation                                                59

     8.1. General Packet Processing . . . . . . . . . . . . . . . .   59
           8.1.1. Originating a Packet  . . . . . . . . . . . . . .   59
           8.1.2. Adding a DSR Options Header to a Packet . . . . .   59
           8.1.3. Adding a DSR Source Route Option to a Packet  . .   60
           8.1.4. Processing a Received Packet  . . . . . . . . . .   61
           8.1.5. Processing a Received DSR Source Route Option . .   63
           8.1.6. Handling an Unknown DSR Option  . . . . . . . . .   65
     8.2. Route Discovery Processing  . . . . . . . . . . . . . . .   67
           8.2.1. Originating a Route Request . . . . . . . . . . .   67
           8.2.2. Processing a Received Route Request Option  . . .   69

11. Security Considerations                                           70

Appendix A. Link-MaxLife
           8.2.3. Generating a Route Reply using the Route Cache Description  .   71

Appendix B. Location
           8.2.4. Originating a Route Reply . . . . . . . . . . . .   73
           8.2.5. Processing a Received Route Reply Option  . . . .   75
     8.3. Route Maintenance Processing  . . . . . . . . . . . . . .   76
           8.3.1. Using Link-Layer Acknowledgements . . . . . . . .   76
           8.3.2. Using Passive Acknowledgements  . . . . . . . . .   77
           8.3.3. Using Network-Layer Acknowledgements  . . . . . .   78
           8.3.4. Originating a Route Error . . . . . . . . . . . .   81
           8.3.5. Processing a Received Route Error Option  . . . .   82
           8.3.6. Salvaging a Packet  . . . . . . . . . . . . . . .   83
     8.4. Multiple Interface Support  . . . . . . . . . . . . . . .   85
     8.5. Fragmentation and Reassembly  . . . . . . . . . . . . . .   86
     8.6. Flow State Processing . . . . . . . . . . . . . . . . . .   87
           8.6.1. Originating a Packet  . . . . . . . . . . . . . .   87
           8.6.2. Inserting a DSR Flow State Header . . . . . . . .   89
           8.6.3. Receiving a Packet  . . . . . . . . . . . . . . .   89
           8.6.4. Forwarding a Packet Using Flow IDs  . . . . . . .   94
           8.6.5. Promiscuously Receiving a Packet  . . . . . . . .   94
           8.6.6. Operation where the Layer below DSR Decreases
                          the IP TTL Non-Uniformly . . . . . . . . .  95
           8.6.7. Salvage Interactions with DSR . . . . . . . . . .   95

 9. Protocol Constants and Configuration Variables                    96

10. IANA Considerations                                               97

11. Security Considerations                                           98

Appendix A. Link-MaxLife Cache Description                            99

Appendix B. Location of DSR in the ISO Network Reference Model       101

Appendix C. Implementation and Evaluation Status                     102

Changes from Previous Version of the Draft                           104

Acknowledgements                                                     105

References                                                           106

Chair's Address                                                      110

Authors' Addresses                                                   111

1. Introduction

   The Dynamic Source Routing protocol (DSR) [15, 16] 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
   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.

   In designing DSR, we sought to create a routing protocol that had
   very low overhead yet was able to react very quickly to changes in
   the network.  The DSR protocol provides highly reactive service in
   order to help ensure successful delivery of data packets in spite of
   node movement or other changes in network conditions.

   The DSR protocol is composed of two main 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 and does 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 for subsequent packets to D.
       Route Maintenance for this route is used only when S is actually
       sending packets to D.

   In DSR, 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 layer within the network.  For
   example, DSR does not use any periodic routing advertisement, link
   status sensing, or neighbor detection packets, and does not rely on
   these functions from any underlying protocols in the network.  This
   entirely on-demand behavior 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.  Network topology changes not affecting routes
   currently in use are ignored and do not cause reaction from the
   protocol.

   All state maintained by DSR is "soft state" [6], in that the loss
   of any state will not interfere with the correct operation of the
   protocol; all state is discovered as needed and can easily and
   quickly be rediscovered if needed after a failure without significant
   impact on the protocol.  This use of only soft state allows the
   routing protocol to be very robust to problems such as dropped or
   delayed routing packets or node failures.  In particular, a node in
   DSR that fails and reboots can easily rejoin the network immediately
   after rebooting; if the failed node was involved in forwarding
   packets for other nodes as an intermediate hop along one or more
   routes, it can also resume this forwarding quickly after rebooting,
   with no or minimal interruption to the routing protocol.

   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 support for multiple
   routes 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 sender of
   a packet selects and controls the route used for its own packets,
   which together with support for multiple routes also allows features
   such as load balancing to be defined.  In addition, all routes used
   are easily guaranteed to be loop-free, since the sender can avoid
   duplicate hops in the routes selected.

   The operation of both Route Discovery and Route Maintenance in DSR
   are designed to allow unidirectional links and asymmetric routes
   to be easily supported.  In particular, as noted in Section 2, 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
   unidirectional links to be used when necessary, improving overall
   performance and network connectivity in the system.

   This document specifies the operation of the DSR protocol for
   routing unicast IPv4 packets in multi-hop wireless ad hoc networks.
   Advanced, optional features, such as Quality of Service (QoS) support
   and efficient multicast routing, and operation of DSR with IPv6 [7],
   are covered in other documents.  The specification of DSR in this
   document provides a compatible base on which such features can be
   added, either independently or by integration with the DSR operation
   specified here.

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [4].

2. Assumptions

   The DSR protocol as described here is designed mainly for mobile
   ad hoc networks of up to about two hundred nodes, and is designed
   to work well with even very high rates of mobility.  Other protocol
   features and enhancements that may allow DSR to scale to larger
   networks are outside the scope of this document.

   We assume in this document 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 ad hoc network SHOULD also be willing to forward
   packets for other nodes in the network.

   The diameter of an ad hoc network is 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.  We assume that this diameter 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.  We assume that 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.

   A common feature of many network interfaces, including most current
   LAN hardware for broadcast media such as wireless, is the ability
   to operate the network interface in "promiscuous" receive mode.
   This mode causes 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, 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 [16].  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.  Use of promiscuous receive mode is
   entirely optional.

   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 [1, 20].  That is, wireless communications
   between each pair of nodes will in many cases be able to operate
   bidirectionally, but at times the wireless link between two nodes
   may be only unidirectional, 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 unidirectional links.  Some
   MAC protocols, however, such as MACA [19], MACAW [2], or IEEE
   802.11 [13], limit unicast data packet transmission to bidirectional
   links, due to the required bidirectional exchange of RTS and CTS
   packets in these protocols and due to the link-layer 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 ability to reverse a source route to obtain a route back to the
   origin of the original route.

   The IP address used by a node using the DSR protocol MAY be assigned
   by any mechanism (e.g., static assignment or use of DHCP for dynamic
   assignment [8]), although the method of such assignment is outside
   the scope of this specification.

3. DSR Protocol Overview

   This section provides an overview of the operation of the DSR
   protocol.  The basic version of DSR uses explicit "source routing",
   in which each data packet sent carries in its header the complete,
   ordered list of nodes through which the packet will pass.  This use
   of explicit source routing allows the sender to select and control
   the routes used for its own packets, supports the use of multiple
   routes to any destination (for example, for load balancing), and
   allows a simple guarantee that the routes used are loop-free; by
   including this source route in the header of each data packet, other
   nodes forwarding or overhearing any of these packets can also easily
   cache this routing information for future use.  Section 3.1 describes
   this basic operation of Route Discovery, Section 3.2 describes basic
   Route Maintenance, and Sections 3.3 and 3.4 describe additional
   features of these two parts of DSR's operation.  Section 3.5 then
   describes an optional, compatible extension to DSR, known as "flow
   state", that allows the routing of most packets without an explicit
   source route header in the packet, while still preserves the
   fundamental properties of DSR's operation.

3.1. Basic DSR Route Discovery

   When some source node originates a new packet addressed to some
   destination node, the source node places in the header of the packet
   a "source route" giving the sequence of hops that the packet is to
   follow on its way to the destination.  Normally, the sender will
   obtain a suitable source route by searching its "Route Cache" of
   routes previously learned; if no route is found in its cache, it will
   initiate the Route Discovery protocol to dynamically find a new route
   to this destination node.  In this case, we call the source node
   the "initiator" and the destination node the "target" of the Route
   Discovery.

   For example, suppose a node A is attempting to discover a route to
   node E.  The Route Discovery initiated by node A in this example
   would proceed as follows:

            ^    "A"    ^   "A,B"   ^  "A,B,C"  ^ "A,B,C,D"
            |   id=2    |   id=2    |   id=2    |   id=2
         +-----+     +-----+     +-----+     +-----+     +-----+
         |  A  |---->|  B  |---->|  C  |---->|  D  |---->|  E  |
         +-----+     +-----+     +-----+     +-----+     +-----+
            |           |           |           |
            v           v           v           v

   To initiate the Route Discovery, node A transmits a "Route
   Request" as a single local broadcast packet, which is received by
   (approximately) all nodes currently within wireless transmission
   range of A, including node B in this example.  Each Route Request
   identifies the initiator and target of the Route Discovery, and
   also contains a unique request identification (2, in this example),
   determined by the initiator of the Request.  Each Route Request also
   contains a record listing the address of each intermediate node
   through which this particular copy of the Route Request has been
   forwarded.  This route record is initialized to an empty list by the
   initiator of the Route Discovery.  In this example, the route record
   initially lists only node A.

   When another node receives this Route Request (such as node B in this
   example), if it is the target of the Route Discovery, it returns
   a "Route Reply" 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 identification and target address, or if this node's own
   address is already listed in the route record in the Route Request,
   this node discards the Request.  Otherwise, this node appends its
   own address to the route record in the Route Request and propagates
   it by transmitting it as a local broadcast packet (with the same
   request identification).  In this example, node B broadcast the Route
   Request, which is received by node C; nodes C and D each also, in
   turn, broadcast the Request, resulting in a copy of the Request being
   received by node E.

   In returning the Route Reply to the initiator of the Route Discovery,
   such as in this example, node E replying back to node A, 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 SHOULD perform its own
   Route Discovery for target node A, but to avoid possible infinite
   recursion of Route Discoveries, it MUST piggyback this Route Reply
   on the packet containing its own Route Request for A.  It is also
   possible to piggyback other small data packets, such as a TCP SYN
   packet [31], on a Route Request using this same mechanism.

   Node E could instead simply reverse the sequence of hops in the route
   record that it is 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 bidirectional frame
   exchange as part of the MAC protocol [13], the discovered source
   route MUST be reversed in this way to return the Route Reply since it
   tests the discovered route to ensure it is bidirectional before the
   Route Discovery initiator begins using the route; this route reversal
   also avoids the overhead of a possible second Route Discovery.

   However, this route reversal technique will prevent the discovery of
   routes using unidirectional links, and in wireless environments where
   the use of unidirectional links is permitted, such routes may in some
   cases be more efficient than those with only bidirectional 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 (that triggered the Discovery) 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 logically associated with the time that it was
   placed into the Send 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
   MAY also be used to evict packets even 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 partitioned network, 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, a node SHOULD use
   an exponential back-off algorithm to limit the rate at which it
   initiates new Route Discoveries for the same target, doubling the
   timeout between each successive Discovery initiated for the same
   target.  If the node attempts to send additional data packets to this
   same destination node more frequently than this limit, the subsequent
   packets SHOULD be buffered in the Send Buffer until a Route Reply is
   received giving a route to this destination, 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 [3].

3.2. Basic DSR Route Maintenance

   When originating or forwarding a packet using a source route, each
   node transmitting the packet is responsible for confirming that data
   can flow over the link from that node to the next hop.  For example,
   in the situation shown below, node A has originated a packet for
   node E using a source route through intermediate nodes B, C, and D:

         +-----+     +-----+     +-----+     +-----+     +-----+
         |  A  |---->|  B  |---->|  C  |-->? |  D  |     |  E  |
         +-----+     +-----+     +-----+     +-----+     +-----+

   In this case, node A is responsible for the link from A to B, node B
   is responsible for the link from B to C, node C is responsible for
   the link from C to D, node D is responsible for the link from D to E.

   An acknowledgement can provide confirmation that a link is capable of
   carrying data, and in wireless networks, acknowledgements are often
   provided at no cost, either as an existing standard part of the MAC
   protocol in use (such as the link-layer acknowledgement frame defined
   by IEEE 802.11 [13]), or by a "passive acknowledgement" [18] (in
   which, for example, B confirms receipt at C by overhearing C transmit
   the packet when forwarding it on to D).

   If a built-in acknowledgement mechanism is not available, the
   node transmitting the packet can explicitly request a DSR-specific
   software acknowledgement be returned by the next node along the
   route; this software acknowledgement will normally be transmitted
   directly to the sending node, but if the link between these two nodes
   is unidirectional, this software acknowledgement could travel over a
   different, multi-hop path.

   After an acknowledgement has been received from some neighbor, a node
   MAY choose to not require acknowledgements from that neighbor for a
   brief period of time, unless the network interface connecting a node
   to that neighbor always receives an acknowledgement in response to
   unicast traffic.

   When a software acknowledgement is used, the acknowledgement
   request SHOULD be retransmitted up to a maximum number of times.
   A retransmission of the acknowledgement request can be sent as a
   separate packet, piggybacked on a retransmission of the original
   data packet, or piggybacked on any packet with the same next-hop
   destination that does not also contain a software acknowledgement.

   After the acknowledgement request has been retransmitted the maximum
   number of times, if no acknowledgement has been received, then the
   sender treats the link to this next-hop destination as currently
   "broken".  It SHOULD remove this link from its Route Cache and
   SHOULD return a "Route Error" to each node that has sent a packet
   routed over that link since an acknowledgement was last received.
   For example, in the situation shown above, if C does not receive
   an acknowledgement from D after some number of requests, it would
   return a Route Error to A, as well as any other node that may have
   used the link from C to D since C last received an acknowledgement
   from D. Node A then removes this broken link from its cache; any
   retransmission of the original packet can be performed by upper
   layer protocols such as TCP, if necessary.  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
   Route Replies 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
   SHOULD perform a new Route Discovery for this target (subject to the
   back-off described in Section 3.1).

3.3. Additional Route Discovery Features

3.3.1. Caching Overheard Routing Information

   A node forwarding or otherwise overhearing any packet SHOULD add all
   usable routing information from that packet to its own Route Cache.
   The usefulness of routing information in a packet depends on the
   directionality characteristics of the physical medium (Section 2), as
   well as the MAC protocol being used.  Specifically, three distinct
   cases are possible:

    -  Links in the network frequently are capable of operating only
       unidirectionally (not bidirectionally), and the MAC protocol in
       use in the network is capable of transmitting unicast packets
       over unidirectional links.

    -  Links in the network occasionally are capable of operating only
       unidirectionally (not bidirectionally), but this unidirectional
       restriction on any link is not persistent, almost all links
       are physically bidirectional, and the MAC protocol in use in
       the network is capable of transmitting unicast packets over
       unidirectional links.

    -  The MAC protocol in use in the network is not capable of
       transmitting unicast packets over unidirectional links;
       only bidirectional links can be used by the MAC protocol for
       transmitting unicast packets.  For example, the IEEE 802.11
       Distributed Coordination Function (DCF) MAC protocol [13]
       is capable of transmitting a unicast packet only over a
       bidirectional link, since the MAC protocol requires the return of
       a link-level acknowledgement packet from the receiver and also
       optionally requires the bidirectional exchange of an RTS and CTS
       packet between the transmitter and receiver nodes.

   In the first case above, for example, the source route used in a data
   packet, the accumulated route record in a Route Request, or the route
   being returned in a Route Reply SHOULD all be cached by any node in
   the "forward" direction; any node SHOULD cache this information from
   any such packet received, whether the packet was addressed to this
   node, sent to a broadcast (or multicast) MAC address, or overheard
   while the node's network interface is in promiscuous mode.  However,
   the "reverse" direction of the links identified in such packet
   headers SHOULD NOT be cached.

   For example, in the situation shown below, node A is using a source
   route to communicate with node E:

         +-----+     +-----+     +-----+     +-----+     +-----+
         |  A  |---->|  B  |---->|  C  |---->|  D  |---->|  E  |
         +-----+     +-----+     +-----+     +-----+     +-----+

   As node C forwards a data packet along the route from A to E, it
   SHOULD 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.  Node C SHOULD NOT, in this case, cache the
   "reverse" direction of the links identified in these packet headers,
   from itself back to B and from B to A, since these links might be
   unidirectional.

   In the second case above, in which links may occasionally operate
   unidirectionally, the links described above SHOULD be cached in both
   directions.  Furthermore, in this case, if node X overhears (e.g.,
   through promiscuous mode) a packet transmitted by node C that is
   using a source route from node A to E, node X SHOULD cache all of
   these links as well, also including the link from C to X over which
   it overheard the packet.

   In the final case, in which the MAC protocol requires physical
   bidirectionality for unicast operation, links from a source route
   SHOULD be cached in both directions, except when the packet also
   contains a Route Reply, in which case only the links already
   traversed in this source route SHOULD be cached, but the links not
   yet traversed in this route SHOULD NOT be cached.

3.3.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, this node sets the route record to list the sequence of
   hops over which this copy of the Route Request was forwarded to it,
   concatenated with the source route to this target obtained from its
   own 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, the figure below 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:

         +-----+     +-----+                 +-----+     +-----+
         |  A  |---->|  B  |-               >|  D  |---->|  E  |
         +-----+     +-----+ \             / +-----+     +-----+
                              \           /
                               \ +-----+ /
                                >|  C  |-
                                 +-----+
                                   | ^
                                   v |
           Route Request         +-----+
           Route: A - B - C - F  |  F  |  Cache: C - D - E
                                 +-----+

   The concatenation of the accumulated route record 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; this prohibition
   increases the probability that the resulting route is valid, since
   node F in this case should have received a Route Error if the route
   had previously stopped working.  Furthermore, this prohibition
   means that a future Route Error traversing the route is very likely
   to pass through any node that sent the Route Reply for the route
   (including node 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 node F, due to this
   restriction on returning a Route Reply based on information from its
   Route Cache, does not return such a Route Reply, node F propagates
   the Route Request normally.

3.3.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 3.3.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 neighbors have a route in their Route Caches,
   each neighbor may attempt to send a Route Reply, thereby wasting
   bandwidth and possibly increasing the number of network collisions in
   the area.

   For example, the figure below shows a situation in which nodes B, C,
   D, E, and F all receive A's Route Request for target G, and each has
   the indicated route cached for this target:

                +-----+                 +-----+
                |  D  |<               >|  C  |
                +-----+ \             / +-----+
      Cache: C - B - G   \           /  Cache: B - G
                          \ +-----+ /
                           -|  A  |-
                            +-----+\     +-----+     +-----+
                             |   |  \--->|  B  |     |  G  |
                            /     \      +-----+     +-----+
                           /       \     Cache: G
                          v         v
                    +-----+         +-----+
                    |  E  |         |  F  |
                    +-----+         +-----+
               Cache: F - B - G     Cache: B - G

   Normally, each of DSR these nodes would attempt to reply from its own
   Route Cache, and they would thus all send their Route Replies at
   about the same time, since they all received the broadcast Route
   Request at about the same time.  Such simultaneous Route Replies
   from different nodes all receiving the Route Request may cause local
   congestion in the ISO Network Reference Model        73

Appendix C. Implementation wireless network and Evaluation Status                      74

Changes from Previous Version may create packet collisions
   among some or all of these Replies if the Draft                            75

Acknowledgements                                                      76

References                                                            77

Chair's Address                                                       80

Authors' Addresses                                                    81

1. Introduction

   The Dynamic Source Routing MAC protocol (DSR) [13, 14] is in use does
   not provide sufficient collision avoidance for these packets.  In
   addition, it will often be the case that the different replies will
   indicate routes of different lengths, as shown in this example.

   In order to reduce these effects, if a simple and
   efficient routing protocol designed specifically node can put its network
   interface into promiscuous receive mode, it MAY delay sending its
   own Route Reply for use a short period, while listening to see if the
   initiating node begins using a shorter route first.  Specifically,
   this node MAY delay sending its own Route Reply for a random period

      d = H * (h - 1 + r)

   where h is the length in multi-hop
   wireless ad hoc networks number of mobile nodes.  Using DSR, the network hops for the route to be
   returned in this node's Route Reply, r is completely self-organizing a random floating point
   number between 0 and self-configuring, requiring no
   existing network infrastructure or administration.  Network nodes
   cooperate 1, and H is a small constant delay (at least
   twice the maximum wireless link propagation delay) to forward packets for be introduced
   per hop.  This delay effectively randomizes the time at which each other to allow communication
   over multiple "hops" between
   node sends its Route Reply, with all nodes not directly within wireless
   transmission range sending Route Replies
   giving routes of one another.  As length less than h sending their Replies before this
   node, and all nodes in sending Route Replies giving routes of length
   greater than h sending their Replies after this node.

   Within the network move
   about or join or leave delay period, this node promiscuously receives all
   packets, looking for data packets from the network, and as wireless transmission
   conditions such as sources initiator of interference change, all routing is
   automatically determined and maintained by this Route
   Discovery destined for the DSR routing protocol.
   Since target of the number or sequence Discovery.  If such a data
   packet received by this node during the delay period uses a source
   route of intermediate hops needed length less than or equal to reach any
   destination h, this node may change at any time, infer that the resulting network topology
   may be quite rich
   initiator of the Route Discovery has already received a Route Reply
   giving an equally good or better route.  In this case, this node
   SHOULD cancel its delay timer and rapidly changing.

   The DSR protocol allows nodes to dynamically discover SHOULD NOT send its Route Reply for
   this Route Discovery.

3.3.4. Route Request Hop Limits

   Each Route Request message contains a source
   route across multiple network hops "hop limit" that may be used
   to any destination in the ad hoc
   network.  Each data packet sent then carries in its header limit the
   complete, ordered list number of intermediate nodes through which the packet will pass,
   allowing packet routing allowed to be trivially loop-free and avoiding forward that
   copy of the
   need for up-to-date routing information Route Request.  This hop limit is implemented using the
   Time-to-Live (TTL) field in the intermediate nodes
   through which IP header of the packet carrying
   the Route Request.  As the Request is forwarded.  By including forwarded, this source
   route in limit is
   decremented, and the header of each data packet, other nodes forwarding or
   overhearing any of these packets Request packet is discarded if the limit reaches
   zero before finding the target.  This Route Request hop limit can also easily cache this routing
   information for future use.

   In designing DSR, we sought be
   used to create implement a routing protocol that had
   very low overhead yet was able to react very quickly to changes in variety of algorithms for controlling the network.  The DSR protocol provides highly reactive service in
   order to help ensure successful delivery spread
   of data packets in spite a Route Request during a Route Discovery attempt.

   For example, a node MAY use this hop limit to implement a
   "non-propagating" Route Request as an initial phase of a Route
   Discovery.  A node movement or other changes in network conditions.

   The DSR protocol is composed using this technique sends its first Route Request
   attempt for some target node using a hop limit of two main mechanisms 1, such that work
   together to allow any
   node receiving the discovery and maintenance initial transmission of source routes in the ad hoc network:

    - Route Discovery is Request will
   not forward the mechanism by which a node S wishing to
       send a packet to a destination node D obtains a source route Request to D. other nodes by re-broadcasting it.  This
   form of Route Discovery Request is used only when S attempts to send a
       packet to D and does not already know called a route to D.

    - "non-propagating" Route Maintenance is Request;
   it provides an inexpensive method for determining if the mechanism by which node S target is able
       to detect, while using
   currently a source route to D, if neighbor of the network
       topology initiator or if a neighbor node has changed such that it can no longer use its a
   route to D because a link along the route target cached (effectively using the neighbors' Route
   Caches as an extension of the initiator's own Route Cache).  If no longer works.  When
   Route
       Maintenance indicates a source route Reply is broken, S can attempt to
       use any other route it happens to know to D, or can invoke Route
       Discovery again to find received after a new route for subsequent packets to D. short timeout, then the node sends a
   "propagating" Route Maintenance Request (i.e., with no hop limit) for the target
   node.

   As another example, a node MAY use this route is used only when S is actually
       sending packets hop limit to D.

   In DSR, implement an
   "expanding ring" search for the target [16].  A node using this
   technique sends an initial non-propagating Route Discovery and Request as described
   above; if no Route Reply is received for it, the node originates
   another Route Maintenance Request with a hop limit of 2.  For each operate entirely
   "on demand".  In particular, unlike other protocols, DSR requires Route Request
   originated, if no
   periodic packets of any kind at any layer within Route Reply is received for it, the network.  For
   example, DSR does not use any periodic routing advertisement, link
   status sensing, or neighbor detection packets, and does not rely on
   these functions from any underlying protocols in node doubles
   the network.  This
   entirely on-demand behavior and lack of periodic activity allows hop limit used on the number of overhead packets caused by DSR previous attempt, to scale all progressively explore
   for the way
   down to zero, when all nodes are approximately stationary with
   respect target node without allowing the Route Request to each other and all routes needed for current communication propagate
   over the entire network.  However, this expanding ring search
   approach could have already been discovered.  As nodes begin to move more or
   as communication patterns change, the routing packet overhead effect of
   DSR automatically scales to only that needed to track the routes
   currently in use.  Network topology changes not affecting routes
   currently in use are ignored and do not cause reaction from increasing the
   protocol.

   In response to a single average latency of
   Route Discovery, since multiple Discovery (as well as through routing
   information from other packets overheard), a node may learn attempts and cache
   multiple routes to any destination.  This allows the reaction to
   routing changes to timeouts may
   be much more rapid, since needed before discovering a route to the target node.

3.4. Additional Route Maintenance Features

3.4.1. Packet Salvaging

   When an intermediate node with multiple
   routes to forwarding a destination can try another cached packet detects through Route
   Maintenance that the next hop along the route for that packet is
   broken, if the one it node has been using should fail.  This caching of multiple routes also
   avoids the overhead of needing another route to perform a new the packet's destination in
   its Route Discovery each
   time Cache, the node SHOULD "salvage" the packet rather than
   discarding it.  To salvage a packet, the node replaces the original
   source route in use breaks.

   The operation of both Route Discovery and on the packet with the route from its Route Maintenance in DSR
   are designed to allow unidirectional links and asymmetric routes Cache.  The
   node then forwards the packet to be easily supported.  In particular, as noted in Section 2, the next node indicated along this
   source route.  For example, in
   wireless networks, it is possible that a link between two nodes may
   not work equally well the situation shown in both directions, due to differing antenna
   or propagation patterns or sources the example of interference.  DSR allows such
   unidirectional links
   Section 3.2, if node C has another route cached to be used when necessary, improving overall
   performance and network connectivity node E, it can
   salvage the packet by replacing the original route in the system.

   This document specifies packet with
   this new route from its own Route Cache, rather than discarding the operation
   packet.

   When salvaging a packet, a count is maintained in the packet of the DSR protocol
   number of times that it has been salvaged, to prevent a single packet
   from being salvaged endlessly.  Otherwise, it could be possible for
   the packet to enter a routing unicast IPv4 packets in multi-hop wireless ad hoc networks.
   Advanced, optional features, such loop, as Quality of Service (QoS) support
   and efficient multicast routing, different nodes repeatedly
   salvage the packet and operation of DSR replace the source route on the packet with IPv6 [6],
   are covered
   routes to each other.

   As described in other documents.  The specification of DSR Section 3.2, an intermediate node, such as in this
   document provides
   case, that detects through Route Maintenance that the next hop along
   the route for a compatible base on packet that it is forwarding is broken, the node also
   SHOULD return a Route Error to the original sender of the packet,
   identifying the link over which such features can the packet could not be
   added, either independently or by integration with forwarded.
   If the DSR operation
   specified here.

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in node sends this
   document are Route Error, it SHOULD originate the Route
   Error before salvaging the packet.

3.4.2. Queued Packets Destined over a Broken Link

   When an intermediate node forwarding a packet detects through Route
   Maintenance that the next-hop link along the route for that packet
   is broken, in addition to be interpreted handling that packet as described in RFC 2119 [4].

2. Assumptions

   We assume defined for Route
   Maintenance, the node SHOULD also handle in a similar way any pending
   packets that it has queued that are destined over this new broken
   link.  Specifically, the node SHOULD search its Network Interface
   Queue and Maintenance Buffer (Section 4.5) for packets for which
   the next-hop link is this document new broken link.  For each such packet
   currently queued at this node, the node SHOULD process that all nodes wishing to communicate with
   other nodes within packet as
   follows:

    -  Remove the ad hoc network are willing packet from the node's Network Interface Queue and
       Maintenance Buffer.

    -  Originate a Route Error for this packet to participate
   fully in the protocols original sender of
       the network.  In particular, each node
   participating in packet, using the ad hoc network SHOULD also be willing to forward
   packets for other nodes procedure described in Section 8.3.4, as if
       the network.

   The diameter of an ad hoc network is node had already reached the minimum maximum number of hops
   necessary retransmission
       attempts for a that packet for Route Maintenance.  However, in
       sending such Route Errors for queued packets in response to reach from any a
       single new broken link detected, the node located at SHOULD send no more
       than one extreme
   edge Route Error to each original sender of any of these
       packets.

    -  If the ad hoc network to node has another route to the packet's IP
       Destination Address in its Route Cache, the node located at SHOULD
       salvage the opposite
   extreme.  We assume that this diameter will often be small (e.g.,
   perhaps 5 or 10 hops), but may often be greater than 1.

   Packets may packet as described in Section 8.3.6.  Otherwise, the
       node SHOULD discard the packet.

3.4.3. Automatic Route Shortening

   Source routes in use MAY be lost automatically shortened if one or corrupted more
   intermediate nodes in the route become no longer necessary.  This
   mechanism of automatically shortening routes in transmission on use is somewhat
   similar to the wireless
   network.  We assume that use of passive acknowledgements [18].  In particular,
   if a node receiving is able to overhear a corrupted packet can
   detect carrying a source route (e.g.,
   by operating its network interface in promiscuous receive mode), then
   this node examines the error and discard unexpended portion of that source route.  If
   this node is not the packet.

   Nodes within intended next-hop destination for the ad hoc network MAY move at any time without notice,
   and MAY even move continuously, packet
   but we assume is named in the later unexpended portion of the packet's source
   route, then it can infer that the speed with
   which intermediate nodes move is moderate with respect to before itself in
   the packet transmission
   latency and wireless transmission range of source route are no longer needed in the particular underlying
   network hardware route.  For example, the
   figure below illustrates an example in use. which node D has overheard a
   data packet being transmitted from B to C, for later forwarding to D
   and to E:

         +-----+     +-----+     +-----+     +-----+     +-----+
         |  A  |---->|  B  |---->|  C  |     |  D  |     |  E  |
         +-----+     +-----+     +-----+     +-----+     +-----+
                        \                       ^
                         \                     /
                          ---------------------

   In particular, DSR can support very
   rapid rates of arbitrary this case, this node mobility, but we assume that nodes do
   not continuously move so rapidly as (node D) SHOULD return a "gratuitous" Route
   Reply to make the flooding of every
   individual data 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 (node B), plus the only possible routing protocol.

   A common feature suffix of many network interfaces, including most current
   LAN hardware for broadcast media such as wireless, is the ability
   to operate original source
   route beginning with the network interface node returning the gratuitous Route Reply
   (node D). In this example, the route returned in "promiscuous" receive mode.
   This mode causes the hardware to deliver every received packet gratuitous Route
   Reply message sent from D to A gives the network driver software without filtering based on link-layer
   destination address.  Although we do not require this facility, some
   of our optimizations can take advantage of its availability.  Use
   of promiscuous mode does increase new route as the software overhead on sequence of
   hops from A to B to D to E.

   When deciding whether to return a gratuitous Route Reply in this way,
   a node MAY factor in additional information beyond the CPU,
   but we believe fact that wireless network speeds are more it
   was able to overhear the inherent
   limiting factor packet.  For example, the node MAY decide to performance
   return the gratuitous Route Reply only when the overheard packet is
   received with a signal strenth or signal-to-noise ratio above some
   specific threshold.  In addition, each node maintains a Gratuitous
   Route Reply Table, as described in current and future systems; we also
   believe that portions of Section 4.4, to limit the protocol are suitable rate at
   which it originates gratuitous Route Replies for the same returned
   route.

3.4.4. Increased Spreading of Route Error Messages

   When a source node receives a Route Error for implementation
   directly within a programmable network interface unit to avoid data packet that
   it originated, this
   overhead source node propagates this Route Error to its
   neighbors by piggybacking it on its next Route Request.  In this way,
   stale information in the CPU [14].  Use caches of promiscuous mode may also increase nodes around this source node will
   not generate Route Replies that contain the power consumption of same invalid link for
   which this source node received the network interface hardware, depending
   on Route Error.

   For example, in the design situation shown in the example of Section 3.2,
   node A learns from the receiver hardware, 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 has
   no other route to E in such cases, DSR can
   easily be used without its Route Cache).  On the optimizations Route Request
   packet initiating this Route Discovery, node A piggybacks a copy
   of this Route Error, ensuring that depend on promiscuous
   receive mode, or can be programmed to only periodically switch the
   interface into promiscuous mode.  Use of promiscuous receive mode is
   entirely optional.

   Wireless communication ability between Route Error spreads well to
   other nodes, and guaranteeing that any pair of nodes may at
   times Route Reply that it receives
   (including those from other node's Route Caches) in response to this
   Route Request does not work equally well contain a route that assumes the existence of
   this broken link.

3.5. 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 both directions, due for example to
   differing antenna or propagation patterns or sources the packet.  The
   DSR flow state extension further reduces the overhead of interference
   around the two nodes [1, 18].  That is, wireless communications
   between each pair protocol
   yet still preserves the fundamental properties of nodes will in many cases be able to operate
   bidirectionally, but at times DSR's operation.
   Once a sending node has discovered a source route such as through
   DSR's Route Discovery mechanism, the wireless link between two nodes
   may be only unidirectional, allowing one flow state mechanism allows the
   sending node to successfully send
   packets to establish hop-by-hop forwarding state within the other while no communication is possible in
   network, based on this source route, to enable each node along the
   reverse direction.  Although many routing protocols operate correctly
   only over bidirectional links, DSR can successfully discover and
   route to forward packets over paths that contain unidirectional links.  Some
   MAC protocols, however, such as MACA [17], MACAW [2], or IEEE
   802.11 [11], limit unicast data the packet transmission to bidirectional
   links, due to the required bidirectional exchange next hop based on the node's own
   local knowledge of RTS and CTS
   packets in these protocols the flow along which this packet is being routed.
   Flow state is dynamically initialized by the first packet using a
   source route and due is then able to route subsequent packets along
   the link-layer acknowledgment
   feature same flow without use of a source route header in IEEE 802.11; the packet.
   The state established at each hop along a flow is "soft state" and
   thus automatically expires when used no longer needed and can be quickly
   recreated as necessary.  Extending DSR's basic operation based on top an
   explicit source route in the header of MAC protocols such each packet routed, the flow
   state extension operates as
   these, DSR can take advantage a form of additional optimizations, such as "implicit source routing" by
   preserving DSR's basic operation but removing the ability explicit source
   route from packets.

3.5.1. Flow Establishment

   A source node sending packets to reverse some destination node MAY use the
   DSR flow state extension described here to establish a source route to obtain
   that destination as a flow.  A "flow" is a route back from the source to
   the
   origin of destination represented by hop-by-hop forwarding state within
   the nodes along the original route.

   The IP address used  Each flow is uniquely identified by a node using the DSR protocol MAY be assigned
   by any mechanism (e.g., static assignment or use
   combination of DHCP for dynamic
   assignment [7]), although the method of such assignment is outside the scope of this specification.

3. DSR Protocol Overview

3.1. Basic DSR Route Discovery

   When some source node originates a new packet addressed to some
   destination node, address, the source destination node places in the header of the packet address,
   and a source route giving the sequence of hops that flow identifier (flow ID) chosen by the packet source node.

   Each flow ID is to
   follow on its way to the destination.  Normally, a 16-bit unsigned integer.  Comparison between
   different flow IDs MUST be performed modulo 2**16.  For example,
   using an implementation in the sender will
   obtain C programming language, a suitable source route by searching its "Route Cache" of
   routes previously learned;
   flow ID value (a) is greater than another flow ID value (b) if no route
   ((short)((a) - (b)) > 0), if a C language "short" data type is found
   implemented as a 16-bit signed integer.

   A DSR Flow State header in its cache, it will
   initiate a packet identifies the Route Discovery protocol flow ID to dynamically find
   be followed in forwarding that packet.  From a new route
   to this destination node.  In this case, we call the given source node
   the "initiator" to
   some destination, any number of different flows MAY exist and
   be in use, for example following different sequences of hops to
   reach the destination node the "target" destination.  One of these flows may be considered to be
   the Route
   Discovery.

   For example, suppose a node A is attempting "default" flow from that source to discover that destination.  A node
   receiving a packet with neither a DSR Options header specifying the
   route to
   node E.  The be taken (with a Source Route Discovery initiated by node A option in this example
   would proceed as follows:

            ^    "A"    ^   "A,B"   ^  "A,B,C"  ^ "A,B,C,D"
            |   id=2    |   id=2    |   id=2    |   id=2
         +-----+     +-----+     +-----+     +-----+     +-----+
         |  A  |---->|  B  |---->|  C  |---->|  D  |---->|  E  |
         +-----+     +-----+     +-----+     +-----+     +-----+
            |           |           |           |
            v           v           v           v

   To initiate the Route Discovery, node A transmits a "Route
   Request" as DSR Options
   header) nor a single local broadcast packet, which DSR Flow State header specifying the flow ID to be
   followed, is received by
   (approximately) all nodes currently within wireless transmission
   range of A, including node B in this example.  Each Route Request
   identifies forwarded along the initiator and target of default flow for the Route Discovery, source and
   also contains a unique request identification (2,
   destination addresses specified in this example),
   determined by the initiator of the Request.  Each Route Request also
   contains packet's IP header.

   In establishing a record listing new flow, the address of each intermediate source node
   through which generates a nonzero
   16-bit flow ID greater than any unexpired flow IDs for this particular copy of
   (source, destination) pair.  If the Route Request has been
   forwarded.  This route record is initialized source wishes for this flow to an empty list by
   become the
   initiator default flow, the low bit of the Route Discovery.  In this example, flow ID MUST be set (the
   flow ID is an odd number); otherwise, the route record
   initially lists only node A.

   When another low bit MUST NOT be set
   (the flow ID is an even number).

   The source node receives this establishing the new flow then transmits a packet
   containing a DSR Options header with a Source Route Request (such as option; to
   establish the flow, the source node B also MUST include in this
   example), if it is the target of the Route Discovery, it returns packet
   a "Route Reply" DSR Flow State header, with the Flow ID field set to the initiator of chosen
   flow ID for the Route Discovery, giving new flow, and MUST include a copy of Timeout option in the accumulated route record
   DSR Options header, giving the lifetime after which state information
   about this flow is to expire.  This packet will generally be a normal
   data packet being sent from this sender to the Route Request;
   when receiver (for example,
   the initiator receives this Route Reply, it caches first packet sent after discovering the new route) but is also
   treated as a "flow establishment" packet.

   The source node records this route flow in its Route Cache Flow Table for use future use,
   setting the TTL in sending subsequent packets to this
   destination.

   Otherwise, if this node receiving Flow Table entry to be the Route Request has recently seen
   another Route Request message from this initiator bearing this same
   request identification value used in the
   TTL field in the packet's IP header and target address, or if setting the Lifetime in this node's own
   address is already listed
   entry to be the lifetime specified in the route record Timeout option in the Route Request, DSR
   Options header.

   Any further packets sent with this node discards flow ID before the Request.  Otherwise, timeout that
   also contain a DSR Options header with a Source Route option MUST use
   this node appends its
   own address to the same source route record in the Source Route Request option.

3.5.2. Receiving and propagates
   it by transmitting it Forwarding Establishment Packets

   Packets intended to establish a flow, as described in Section 3.5.1,
   contain a local broadcast packet (with DSR Options header with a Source Route option, and are
   forwarded along the same
   request identification).  In this example, indicated route.  A node B broadcast implementing the Route
   Request, which is received by node C; nodes C DSR
   flow state extension, when receiving and D each also, forwarding such a DSR
   packet, also keeps some state in
   turn, broadcast its own Flow Table to enable it
   to forward future packets that are sent along this flow with only
   the Request, resulting in flow ID specified.  Specifically, if the packet also contains
   a copy of DSR Flow State header, this packet SHOULD cause an entry to be
   established for this flow in the Request being
   received by Flow Table of each node E.

   In returning the Route Reply to along the initiator
   packet's route.

   The Hop Count field of the Route Discovery,
   such DSR Flow State header is also stored in
   the Flow Table, as is Lifetime option specified in this example, node E replying back to node A, node E will
   typically examine its own Route Cache the DSR Options
   header.

   If the Flow ID is odd and there is no flow in the Flow Table with
   Flow ID greater than the received Flow ID, set the default Flow ID
   for a route back this (IP Source Address, IP Destination Address) pair to A, the
   received Flow ID, and if
   found, will use it for the source route for TTL of the packet is recorded.

   The Flow ID option is removed before final delivery of the packet.

3.5.3. Sending Packets Along Established Flows

   When a flow is established as described in Section 3.5.1, a packet
   containing
   is sent which establishes state in each node along the Route Reply.  Otherwise, E SHOULD perform its own
   Route Discovery route.
   This state is soft; that is, the protocol contains mechanisms for target node A, but to avoid possible infinite
   recursion
   recovering from the loss of Route Discoveries, it MUST piggyback this Route Reply
   on state.  However, the packet containing its own Route Request use of these
   mechanisms may result in reduced performance for A.  It packets sent
   along flows with forgotten state.  As a result, it is also
   possible desirable
   to piggyback other small data packets, such as a TCP SYN
   packet [28], differentiate behavior based on whether or not the sender is
   reasonably certain that the flow state exists on each node along
   the route.  We define a Route Request using this same mechanism.

   Node E could instead simply reverse flow's state to be "established end-to-end"
   if the sequence Flow Tables of hops in all nodes on the route
   record contains forwarding
   information for that flow.  While it is trying impossible to send in detect whether
   or not a flow's state has been established end-to-end without sending
   packets, implementations may make reasonable assumptions about the Route Reply,
   retention of flow state and use this as the probability that an establishment
   packet has been seen by all nodes on the route.

   A source wishing to send a packet along an established flow
   determines if the flow state has been established end-to-end.  If
   it has not, a DSR Options header with Source Route option with this
   flow's route on is added to the packet carrying packet.  The source SHOULD set the Route Reply itself.  For
   MAC protocols such as IEEE 802.11 that require a bidirectional frame
   exchange as part
   Flow ID field of the MAC protocol [11], DSR Flow State header either to the discovered source
   route MUST be reversed in flow ID
   previously associated with this way flow's route or to return the Route Reply since zero.  If it
   tests sets
   the discovered route Flow ID field to ensure any other value, it is bidirectional before the
   Route Discovery initiator begins using MUST follow the route; this route reversal
   also avoids processing
   steps in Section 3.5.1 for establishing a new flow ID. If it sets the overhead of
   Flow ID field to a possible second Route Discovery.
   However, this route reversal technique will prevent nonzero value, it MUST include a Timeout option
   with a value not greater than the discovery of
   routes using unidirectional links, and timeout remaining in wireless environments where the use of unidirectional links node's
   Flow Table, and if its TTL is permitted, such routes may not equal to that specified in some
   cases be more efficient than those with only bidirectional links, or
   they may the Flow
   Table, the flow MUST NOT be used as a default flow in the only way future.

   Once flow state has been established end-to-end for non-default
   flows, a source adds a DSR Flow State header to achieve connectivity each packet it wishes
   to send along that flow, setting the target node.

   When initiating a Flow ID field to the flow ID of
   that flow.  A Source Route Discovery, option SHOULD NOT be added to the packet,
   though if one is, then the steps for processing flows that have not
   been established end to end MUST be followed.

   Once flow state has been established end-to-end for default flows,
   sources sending node saves a copy of
   the original packet (that triggered packets with IP TTL equal to the Discovery) TTL value in a the
   local buffer
   called Flow Table entry for this flow then transmit the "Send Buffer".  The Send Buffer contains a copy of each packet that cannot be transmitted by to the
   next hop.  In this node because it does not
   yet have case, a source route DSR Flow State header SHOULD NOT be added
   to the packet's destination.  Each packet in and a DSR Options header likewise SHOULD NOT be added
   to the Send Buffer is logically associated with packet; though if one is, the time that it was
   placed into steps for sending packets along
   non-default flows MUST be followed.  If the Send Buffer and IP TTL is discarded after residing not equal to
   the TTL value in the
   Send Buffer for some timeout period; if necessary for preventing local Flow Table, then the
   Send Buffer from overflowing, steps for processing
   a FIFO or other replacement strategy
   MAY also non-default flow MUST be used to evict followed.

3.5.4. Receiving and Forwarding Packets Sent Along Established Flows

   The handling of packets even before they expire.

   While containing a packet remains in the Send Buffer, the node SHOULD
   occasionally initiate DSR Options header with
   both a new Route Discovery for the packet's
   destination address.  However, the node MUST limit the rate at which
   such new nonzero Flow ID and a Source Route Discoveries for the same address are initiated, since
   it option is possible that the destination node described in
   Section 3.5.2.  The Flow ID is not currently reachable.
   In particular, due ignored when it is equal to zero.
   This section only describes handling of packets without a Source
   Route option.

   If a node receives a packet with a Flow ID in the limited wireless transmission range and DSR Options
   header that indicates an unexpired flow in the
   movement of node's Flow Table, it
   increments the nodes Hop Count in the network, DSR Options header and forwards 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 next hop indicated in the
   network, such network partitions may be rare or may be common. Flow Table.

   If a new Route Discovery was initiated for each node receives a packet sent by with a
   node in such Flow ID that indicates a partitioned network, flow not
   currently in the node's Flow Table, it returns a large number of unproductive Route Request packets would be propagated throughout Error of type
   UNKNOWN_FLOW with Error Destination and IP Destination addresses
   copied from the subset IP Source of the ad hoc network reachable from this node.  In order to
   reduce packet triggering the overhead from such Route Discoveries, a node error.  This
   error packet SHOULD use
   an exponential back-off algorithm be MAC-destined to limit the rate at node from which it
   initiates new Route Discoveries for the same target, doubling the
   timeout between each successive Discovery initiated for the same
   target.  If was
   received; if it cannot confirm reachability of the previous node attempts to
   using Route Maintenance, it MUST send additional data packets to this
   same destination node more frequently than this limit, the subsequent
   packets SHOULD be buffered error as described in
   Section 8.1.1.  The node sending the Send Buffer until a Route Reply is
   received giving a route error SHOULD attempt to this destination, but salvage
   the packet triggering the node MUST NOT
   initiate a new Route Discovery until Error.  If it does salvage the minimum allowable interval
   between new Route Discoveries for this target has been reached.  This
   limitation on
   packet, it MUST zero the maximum rate of Route Discoveries for Flow ID.

   If a node receives a packet with no DSR Options header and no DSR
   Flow State header, it checks the same
   target Default Flow Table.  If there is similar
   an entry, it forwards to the mechanism required by Internet nodes to
   limit next hop indicated in the rate at which ARP Requests are sent Flow Table
   for any single target
   IP address [3].

3.2. Basic DSR Route Maintenance

   When originating or forwarding the default flow.  Otherwise, it returns a Route Error of type
   DEFAULT_FLOW_UNKNOWN with Error Destination and IP Destination
   addresses copied from the IP Source of the packet using a source route, each
   node transmitting triggering the
   error.  This error packet is responsible for confirming that data
   can flow over SHOULD be MAC-destined to the link node from that
   which it was received; if it cannot confirm reachability of the
   previous node to using Route Maintenance, it MUST send the next hop.  For example, error as
   described in the situation shown below, Section 8.1.1.  The node A has originated a sending the error SHOULD
   attempt to salvage the packet for
   node E using a source route through intermediate nodes B, C, and D:

         +-----+     +-----+     +-----+     +-----+     +-----+
         |  A  |---->|  B  |---->|  C  |-->? |  D  |     |  E  |
         +-----+     +-----+     +-----+     +-----+     +-----+

   In this case, triggering the Route Error.  If it does
   salvage the packet, it MUST zero the Flow ID.

3.5.5. Processing Route Errors

   When a node A is responsible for receives a Route Error of type Unknown Flow, it marks
   the link from A flow to B, indicate that it has not been established end-to-end.
   When a node B
   is responsible for receives a Route Error of type Default Flow Unknown, it
   marks the link from B default flow to C, node C indicate that it has not been established
   end-to-end.

3.5.6. Interaction with Automatic Route Shortening

   Because a full source route is responsible not carried in every packet, an
   alternative method for
   the link from C to D, node D performing automatic route shortening is responsible
   necessary for packets using the link from D flow state extension.  Instead, nodes
   promiscuously listen to E.

   An acknowledgment can provide confirmation that a link is capable of
   carrying data, packets, and if a node receives a packet
   with (IP Source, IP Destination, Flow ID) found in wireless networks, acknowledgments are often
   provided at no cost, either as an existing standard part of the MAC
   protocol in use (such as Flow Table
   but the link-layer acknowledgment frame defined
   by IEEE 802.11 [11]), or by a "passive acknowledgment" [16] (in
   which, for example, B confirms receipt at C by overhearing C transmit MAC-layer (next hop) destination address of the packet when forwarding it on to D).

   If a built-in acknowledgment mechanism is
   not available, this node, the node
   transmitting determines whether the packet can explicitly request a DSR-specific
   software acknowledgment be returned was sent by the next
   an upstream or downstream node along by examining the route; Hop Count field in
   the DSR Flow State header.  If the Hop Count field is less than the
   expected Hop Count at this software acknowledgment will normally be transmitted directly
   to node, the sending node assumes that the packet
   was sent by an upstream node, but if and adds an entry for the packet to
   its Automatic Route Shortening Table, possibly evicting an earlier
   entry added to this table.  When the link between these two nodes packet is
   unidirectional, this software acknowledgment could travel over a
   different, multi-hop path.

   After an acknowledgment has been received from some neighbor, a node
   MAY choose then sent to not require acknowledgments from that neighbor node
   for forwarding, the node finds that it has previously received the
   packet by checking its Automatic Route Shortening Table, and returns
   a
   brief period gratuitous Route Reply to the source of time, unless the network interface connecting packet.

3.5.7. Loop Detection

   If a node
   to that neighbor always receives an acknowledgment in response to
   unicast traffic.

   When a software acknowledgment packet for forwarding with adjusted TTL lower
   than expected and default flow forwarding is being used, the acknowledgment request
   SHOULD be retransmitted up to it sends
   a maximum number of times.  A
   retransmission Route Error of type Default Flow Unknown back to the acknowledgment request IP source.
   It can be sent as a
   separate packet, piggybacked on a retransmission attempt delivery of the original
   data packet, or piggybacked on any packet by normal salvaging (subject
   to constraints described in Section 8.6.7) or by inserting a
   Flow ID option with the same next-hop
   destination Special TTL extension based on what that does node's
   understanding of the default Flow ID and TTL.

3.5.8. Acknowledgement Destination

   In packets sent using Flow State, the previous hop is not also contain a software acknowledgment.

   After necessarily
   known.  In order to allow nodes that have lost flow state to
   determine the acknowledgment request has been retransmitted previous hop, the maximum
   number address of times, if no acknowledgment has been received, then the
   sender treats previous hop can
   optionally be stored in the link to this next-hop destination as currently
   "broken".  It Acknowledgement Request.  This extension
   SHOULD remove this link from its NOT be used when a Source Route option is present, MAY be used
   when flow state routing is used without a Source Route Cache option, and
   SHOULD return a "Route Error" to each node be used before Route Maintenance determines that the next-hop
   destination is unreachable.

3.5.9. Crash Recovery

   Each node has sent a packet
   routed over maximum Timeout value that link since an acknowledgment was last received.
   For example, in it can possibly generate.
   This can be based on the situation shown above, if C does not receive
   an acknowledgment from D after some largest number of requests, it would
   return that can be set in a timeout
   option (2**16 - 1 seconds) or set in system software.  When a Route Error to A, as well as any other node that may have
   used the link from C
   crashes, it does not establish new flows for a period equal to D since C last received an acknowledgment
   from D. Node A then removes this broken link from
   maximum Timeout value, in order to avoid colliding with its cache; any
   retransmission of the original packet old
   Flow IDs.

3.5.10. Rate Limiting

   Flow IDs can be performed by upper
   layer protocols such as TCP, if necessary.  For sending such assigned with a
   retransmission or other packets counter.  More specifically, the
   "Current Flow ID" is kept.  When a new default Flow ID needs to this same destination E, be
   assigned, if A has the Current Flow ID is odd, the Current Flow ID is
   assigned as the Flow ID and the Current Flow ID is incremented by
   one; if the Current Flow ID is even, one plus the Current Flow ID is
   assigned as the Flow ID and the Current Flow ID is incremented by
   two.

   If Flow IDs are assigned in its Route Cache another route this way, one algorithm for avoiding
   duplicate, unexpired Flow IDs is to E (for example, from additional
   Route Replies from its earlier Route Discovery, or from having
   overheard sufficient routing information from other packets), it rate limit new Flow IDs to an
   average rate of n assignments per second, where n is 2**15 divided by
   the maximum Timeout value.  This can send be averaged over any period not
   exceeding the packet using maximum Timeout value.

3.5.11. Interaction with Packet Salvaging

   Salvaging is modified to zero the Flow ID field.  Also, any time the new route immediately.  Otherwise, it
   SHOULD perform a new Route Discovery for
   this target (subject document refers to the
   back-off described Salvage field in Section 3.1).

3.3. Additional Route Discovery Features

3.3.1. Caching Overheard Routing Information

   A node forwarding or otherwise overhearing any packet SHOULD add all
   usable routing information from that packet to its own the Source Route Cache.
   The usefulness of routing information option
   in a packet depends on the
   directionality characteristics of the physical medium (Section 2), as
   well as the MAC protocol being used.  Specifically, three distinct
   cases DSR Options header, packets without a Source Route option are possible:

    -  Links
   considered to have the value zero in the network frequently are capable Salvage field.

4. Conceptual Data Structures

   This document describes the operation of operating only
       unidirectionally (not bidirectionally), and the MAC DSR protocol in terms
   of a number of conceptual data structures.  This section describes
   each of these data structures and provides an overview of its use
   in the network is capable protocol.  In an implementation of transmitting unicast packets
       over unidirectional links.

    -  Links in the network occasionally are capable of operating only
       unidirectionally (not bidirectionally), but this unidirectional
       restriction on protocol, these data
   structures MAY be implemented in any link is not persistent, almost all links
       are physically bidirectional, and manner consistent with the MAC protocol in use
   external behavior described in
       the this document.

4.1. Route Cache

   All ad hoc network routing information needed by a node implementing
   DSR is capable of transmitting unicast packets over
       unidirectional links.

    -  The MAC protocol stored in use that node's Route Cache.  Each node in the network is not capable
   maintains its own Route Cache.  A node adds information to its
   Route Cache as it learns of
       transmitting unicast packets over unidirectional links;
       only bidirectional new links can be used by between nodes in the MAC protocol ad hoc
   network; for
       transmitting unicast packets.  For example, the IEEE 802.11
       Distributed Coordination Function (DCF) MAC protocol [11]
       is capable a node may learn of transmitting new links when it receives
   a unicast packet only over carrying a
       bidirectional link, since the MAC protocol requires the return
       of Route Request, Route Reply, or DSR source route.
   Likewise, a link-level acknowledgment packet node removes information from its Route Cache as it
   learns that existing links in the receiver and also
       optionally requires the bidirectional exchange of an RTS and CTS
       packet between the transmitter and receiver nodes.

   In the first case above, ad hoc network have broken; for
   example, the source route used in a data
   packet, the accumulated route record in node may learn of a broken link when it receives a packet
   carrying a Route Request, Error or through the route
   being returned link-layer retransmission
   mechanism reporting a failure in forwarding a packet to its next-hop
   destination.

   Anytime a Route Reply SHOULD all be cached by any node in adds new information to its Route Cache, the "forward" direction; any node
   SHOULD cache this information from
   any such packet received, whether the check each packet was addressed to this
   node, sent in its own Send Buffer (Section 4.2) to a broadcast (or multicast) MAC address, or overheard
   while
   determine whether a route to that packet's IP Destination Address
   now exists in the node's network interface is in promiscuous mode.  However, Route Cache (including the "reverse" direction of information just
   added to the Cache).  If so, the links identified in such packet
   headers SHOULD NOT then be cached.

   For example, in sent using
   that route and removed from the situation shown below, node A Send Buffer.

   It is using possible to interface a source
   route DSR network with other networks,
   external to communicate this DSR network.  Such external networks may, for
   example, be the Internet, or may be other ad hoc networks routed
   with node E:

         +-----+     +-----+     +-----+     +-----+     +-----+
         |  A  |---->|  B  |---->|  C  |---->|  D  |---->|  E  |
         +-----+     +-----+     +-----+     +-----+     +-----+

   As node C forwards a data packet along the route from A to E, it
   SHOULD add routing protocol other than DSR.  Such external networks may
   also be other DSR networks that are treated as external networks
   in order to its cache the presence improve scalability.  The complete handling of such
   external networks is beyond the "forward" direction
   links that it learns from the headers scope of these packets, from itself
   to D this document.  However,
   this document specifies a minimal set of requirements and from D features
   necessary to E.  Node C SHOULD NOT, in allow nodes only implementing this case, cache the
   "reverse" direction of the links identified in these packet headers,
   from itself back specification to B and from B
   interoperate correctly with nodes implementing interfaces to A, since these links might be
   unidirectional.

   In the second case above, in which links may occasionally operate
   unidirectionally, such
   external networks.  This minimal set of requirements and features
   involve the links described above SHOULD be cached in both
   directions.  Furthermore, First Hop External (F) and Last Hop External (L) bits
   in this case, if node X overhears (e.g.,
   through promiscuous mode) a packet transmitted by node C that is
   using DSR Source Route option (Section 6.7) and a source route from node A to E, node X SHOULD cache all of
   these links as well, Route Reply option
   (Section 6.3) in a packet's DSR Options header (Section 6).  These
   requirements also including include the addition of an External flag bit
   tagging each link from C to X over which
   it overheard the packet.

   In the final case, in which the MAC protocol requires physical
   bidirectionality for unicast operation, links Route Cache, copied from a source route
   SHOULD be cached the First Hop
   External (F) and Last Hop External (L) bits in both directions, except when the packet also
   contains a DSR Source Route Reply, in
   option or Route Reply option from which case only the links already
   traversed in this source route link was learned.

   The Route Cache SHOULD be cached, but support storing more than one route to each
   destination.  In searching the links not
   yet traversed in this Route Cache for a route SHOULD NOT be cached.

3.3.2. Replying to some
   destination node, the Route Requests using Cached Routes

   A Cache is indexed by destination node receiving
   address.  The following properties describe this searching function
   on a Route Request Cache:

    -  Each implementation of DSR at any node MAY choose any appropriate
       strategy and algorithm for which it is not the target,
   searches searching its own Route Cache for and
       selecting a "best" route to the target of the
   Request.  If found, the node generally returns destination from among those
       found.  For example, a Route Reply to the
   initiator itself rather than forwarding the Route Request.  In the
   Route Reply, this node sets MAY choose to select the shortest
       route record to list the destination (the shortest sequence of
   hops over which this copy of the Route Request was forwarded hops), or it
       MAY use an alternate metric to it,
   concatenated with select the source route to this target obtained from its
   own Route the Cache.

    -  However, before transmitting if there are multiple cached routes to a Route Reply packet that was generated
   using information from its destination,
       the selection of routes when searching the Route Cache in this way, a node MUST
   verify
       prefer routes that do not have the resulting route being returned in External flag set on any link.
       This preference will select routes that lead directly to the Route Reply,
   after this concatenation, contains no duplicate nodes listed in
       target node over routes that attempt to reach the target via any
       external networks connected to the DSR ad hoc network.

    -  In addition, any route record.  For example, selected when searching the figure below illustrates a case in
   which a Route Request Cache
       MUST NOT have the External bit set for target E has been received by node F, and
   node F already has any links other than
       possibly the first link, the last link, or both; the External bit
       MUST NOT be set for any intermediate hops in its the route selected.

   An implementation of a Route Cache MAY provide a fixed capacity
   for the cache, or the cache size MAY be variable.  The following
   properties describe the management of available space within a route from itself to E:

         +-----+     +-----+                 +-----+     +-----+
         |  A  |---->|  B  |-               >|  D  |---->|  E  |
         +-----+     +-----+ \             / +-----+     +-----+
                              \           /
                               \ +-----+ /
                                >|  C  |-
                                 +-----+
                                   | ^
                                   v | node's
   Route Request         +-----+
           Route: A - B - C - F  |  F  | Cache: C - D

    - E
                                 +-----+

   The concatenation  Each implementation of DSR at each node MAY choose any
       appropriate policy for managing the accumulated route record from the entries in its Route
   Request and Cache,
       such as when limited cache capacity requires a choice of which
       entries to retain in the cached route from F's Route Cache would include Cache.  For example, a
   duplicate node MAY chose a
       "least recently used" (LRU) cache replacement policy, in passing which
       the entry last used longest ago is discarded from C the cache if a
       decision needs to F and back be made to C.

   Node F allow space in this case could attempt to edit the route to eliminate cache for some
       new entry being added.

    -  However, the
   duplication, resulting in a route from A to B Route Cache replacement policy SHOULD allow routes
       to C be categorized based upon "preference", where routes with a
       higher preferences are less likely to D and be removed from the cache.
       For example, a node could prefer routes for which it initiated
       a Route Discovery over routes that it learned as the result of
       promiscuous snooping on to E,
   but in other packets.  In particular, a node
       SHOULD prefer routes that it is presently using over those that
       it is not.

   Any suitable data structure organization, consistent with this case, node F would not
   specification, MAY be on used to implement the Route Cache in any node.
   For example, the following two types of organization are possible:

    -  In DSR, the route that it returned in its own Route Reply.  DSR Route Discovery prohibits node F
   from returning such a each Route Reply from its cache; this prohibition
   increases the probability that the resulting route is valid, since
   node F in this case should have received
       by the initiator of a Route Error if the route
   had previously stopped working.  Furthermore, this prohibition
   means Discovery (or that is learned from
       the header of overhead packets, as described in Section 8.1.4)
       represents a future Route Error traversing complete path (a sequence of links) leading to the route
       destination node.  By caching each of these paths separately,
       a "path cache" organization for the Route Cache can be formed.
       A path cache is very likely simple to pass through any node implement and easily guarantees
       that sent the all routes are loop-free, since each individual route from
       a Route Reply or Route Request or used in a packet is loop-free.
       To search for the a route
   (including in a path cache data structure, the sending
       node F), which helps to ensure can simply search its Route Cache for any path (or prefix of
       a path) that stale data is removed
   from caches (such as at F) leads to the intended destination node.

       This type of organization for the Route Cache in DSR has been
       extensively studied through simulation [5, 10, 14, 21] and
       through implementation of DSR in a timely manner; otherwise, mobile outdoor testbed under
       significant workload [22, 23, 24].

    -  Alternatively, a "link cache" organization could be used for the next
       Route Discovery initiated by A might also be contaminated by a Cache, in which each individual link (hop) in the routes
       returned in Route Reply packets (or otherwise learned from F containing the same stale route.  If node F, due
       header of overhead packets) is added to this
   restriction on returning a Route Reply based on information from its
   Route Cache, does not return such unified graph data
       structure of this node's current view of the network topology.
       To search for a Route Reply, route in link cache, the sending node F propagates must use
       a more complex graph search algorithm, such as the Route Request normally.

3.3.3. Preventing Route Reply Storms

   The ability for nodes well-known
       Dijkstra's shortest-path algorithm, to reply find the current best path
       through the graph to the destination node.  Such an algorithm is
       more difficult to implement and may require significantly more
       CPU time to execute.

       However, a Route Request based on
   information in their Route Caches, as described in Section 3.3.2,
   could result in link cache organization is more powerful than a possible Route Reply "storm" path
       cache organization, in some cases.  In
   particular, if a node broadcasts a Route Request for its ability to effectively utilize all of
       the potential information that a target node
   for which might learn about the node's neighbors have a route in their state
       of the network.  In particular, links learned from different
       Route Caches,
   each neighbor may attempt Discoveries or from the header of any overheard packets can
       be merged together to send form new routes in the network, but this
       is not possible in a Route Reply, thereby wasting
   bandwidth and possibly increasing path cache due to the number separation of network collisions each
       individual path in the area.

   For example, cache.

       This type of organization for the figure below shows a situation in which nodes B, C,
   D, E, and F all receive A's Route Request for target G, and each Cache in DSR, including
       the effect of a range of implementation choices, has been studied
       through detailed simulation [10].

   The choice of data structure organization to use for the indicated route cached Route Cache
   in any DSR implementation is a local matter for this target:

                +-----+                 +-----+
                |  D  |<               >|  C  |
                +-----+ \             / +-----+
      Cache: C - B - G   \           /  Cache: B - G
                          \ +-----+ /
                           -|  A  |-
                            +-----+\     +-----+     +-----+
                             |   |  \--->|  B  |     |  G  |
                            /     \      +-----+     +-----+
                           /       \     Cache: G
                          v         v
                    +-----+         +-----+
                    |  E  |         |  F  |
                    +-----+         +-----+
               Cache: F - B - G     Cache: B - G

   Normally, each node and affects
   only performance; any reasonable choice of these nodes would attempt to reply from its own organization for the Route Cache,
   Cache does not affect either correctness or interoperability.

   Each entry in the Route Cache SHOULD have a timeout associated
   with it, to allow that entry to be deleted if not used within some
   time.  The particular choice of algorithm and they would thus all send their data structure used
   to implement the Route Replies at
   about Cache SHOULD be considered in choosing the same time, since they all received
   timeout for entries in the broadcast Route
   Request at about Cache.  The configuration variable
   RouteCacheTimeout defined in Section 9 specifies the same time.  Such simultaneous Route Replies
   from different nodes all receiving timeout to be
   applied to entries in the Route Request may cause local
   congestion Cache, although it is also possible
   to instead use an adaptive policy in the wireless network and may create packet collisions
   among some or choosing timeout values rather
   than using a single timeout setting for all of these Replies if entries; for example, the MAC protocol in use
   Link-MaxLife cache design (below) uses an adaptive timeout algorithm
   and does not provide sufficient collision avoidance for these packets.  In
   addition, it will often be the case that use the different replies will
   indicate routes RouteCacheTimeout configuration variable.

   As guidance to implementors, Appendix A describes a type of different lengths, link
   cache known as "Link-MaxLife" that has been shown in this example.

   In order to reduce these effects, if outperform
   other types of link caches and path caches studied in detailed
   simulation [10].  Link-MaxLife is an adaptive link cache in which
   each link in the cache has a timeout that is determined dynamically
   by the caching node can put its network
   interface into promiscuous receive mode, it MAY delay sending its
   own Route Reply for a short period, while listening according to see if its observed past behavior of the
   initiating node begins using
   two nodes at the ends of the link; in addition, when selecting a shorter
   route first.  Specifically,
   this node MAY delay sending its own Route Reply for a random period

      d = H * (h - 1 + r)

   where h is the packet being sent to some destination, among cached
   routes of equal length (number of hops) to that destination,
   Link-MaxLife selects the route with the longest expected lifetime
   (highest minimum timeout of any link in number the route).  Use of network hops
   the Link-MaxLife design for the Route Cache is recommended in
   implementations of DSR.

4.2. Send Buffer

   The Send Buffer of a node implementing DSR is a queue of packets that
   cannot be sent by that node because it does not yet have a source
   route to be
   returned each such packet's destination.  Each packet in this node's Route Reply, r the Send
   Buffer is a random floating point
   number between 0 logically associated with the time that it was placed into
   the Buffer, and 1, SHOULD be removed from the Send Buffer and H is silently
   discarded after a small constant delay (at least
   twice period of SendBufferTimeout after initially being
   placed in the maximum wireless link propagation delay) Buffer.  If necessary, a FIFO strategy SHOULD be used
   to evict packets before they timeout to prevent the buffer from
   overflowing.

   Subject to the rate limiting defined in Section 8.2, a Route
   Discovery SHOULD be introduced
   per hop.  This delay effectively randomizes initiated as often as possible for the time at which each
   node sends its
   destination address of any packets residing in the Send Buffer.

4.3. Route Reply, with all nodes sending Request Table

   The Route Replies
   giving routes Request Table of length less than h sending their Replies before this
   node, and all nodes sending a node implementing DSR records
   information about Route Replies giving routes of length
   greater than h sending their Replies after Requests that have been recently originated
   or forwarded by this node.

   Within  The table is indexed by IP address.

   The Route Request Table on a node records the delay period, following information
   about nodes to which this node promiscuously receives all
   packets, looking for data packets from has initiated a Route Request:

    -  The Time-to-Live (TTL) field used in the initiator IP header of this the Route
   Discovery destined
       Request for the target of the Discovery.  If such a data
   packet received last Route Discovery initiated by this node during for
       that target node.  This value allows the delay period uses node to implement a source
   route
       variety of length less than or equal to h, algorithms for controlling the spread of its Route
       Request on each Route Discovery initiated for a target.  As
       examples, two possible algorithms for this use of the TTL field
       are described in Section 3.3.4.

    -  The time that this node may infer last originated a Route Request for that the
   initiator
       target node.

    -  The number of the consecutive Route Discovery has already received Discoveries initiated for this
       target since receiving a valid Route Reply giving an equally good or better route.  In this case, a route to that
       target node.

    -  The remaining amount of time before which this node
   SHOULD cancel its delay timer and SHOULD NOT send its MAY next
       attempt at a Route Reply Discovery for
   this Route Discovery.

3.3.4. that target node.  When the
       node initiates a new Route Request Hop Limits

   Each Discovery for this target node, this
       field in the Route Request message contains a "hop limit" Table entry for that may be used
   to limit the number of intermediate nodes allowed target node is
       initialized to forward the timeout for that
   copy of Route Discovery, after which
       the node MAY initiate a new Discovery for that target.  Until
       a valid Route Request.  This hop limit Reply is implemented received for this target node address,
       a node MUST implement a back-off algorithm in determining this
       timeout value for each successive Route Discovery initiated
       for this target using the same Time-to-Live (TTL) field value in the
       IP header of the packet carrying
   the Route Request.  As Request packet.  The timeout between
       such consecutive Route Discovery initiations SHOULD increase by
       doubling the timeout value on each new initiation.

   In addition, the Route Request is forwarded, Table on a node also records the
   following information about initiator nodes from which this limit is
   decremented, node has
   received a Route Request:

    -  A FIFO cache of size RequestTableIds entries containing the
       Identification value and target address from the most recent
       Route Requests received by this node from that initiator node.

   Nodes SHOULD use an LRU policy to manage the entries in their Route
   Request packet is discarded if Table.

   The number of Identification values to retain in each Route
   Request Table entry, RequestTableIds, MUST NOT be unlimited, since,
   in the limit reaches
   zero before finding worst case, when a node crashes and reboots, the target.  This first
   RequestTableIds Route Request hop limit can Discoveries it initiates after rebooting
   could appear to be
   used duplicates to implement the other nodes in the network.
   In addition, a variety of algorithms node SHOULD base its initial Identification value,
   used for controlling the spread Route Discoveries after rebooting, on a battery backed-up
   clock or other persistent memory device, in order to help avoid
   any possible such delay in successfully discovering new routes
   after rebooting; if no such source of initial Identification
   value is available, a Route Request during node after rebooting SHOULD base its initial
   Identification value on a random number.

4.4. Gratuitous Route Discovery attempt.

   For example, Reply Table

   The Gratuitous Route Reply Table of a node MAY use this hop limit to implement a
   "non-propagating" implementing DSR records
   information about "gratuitous" Route Request Replies sent by this node as an initial phase
   part of automatic route shortening.  As described in Section 3.4.3,
   a Route
   Discovery.  A node using this technique sends its first returns a gratuitous Route Request
   attempt for some target node using Reply when it overhears a hop limit of 1, such that any
   node receiving packet
   transmitted by some node, for which the initial transmission of node overhearing the Route Request will
   packet was not forward the Request to other nodes by re-broadcasting it.  This
   form of Route Request is called a "non-propagating" Route Request;
   it provides an inexpensive method for determining if intended next-hop node but was named later in
   the target is
   currently a neighbor unexpended hops of the initiator or if a neighbor node has a source route to in that packet; the target cached (effectively using node
   overhearing the neighbors' packet returns a gratuitous Route
   Caches as an extension Reply to the
   original sender of the initiator's own Route Cache).  If no
   Route Reply is received after a short timeout, then packet, listing the node sends a
   "propagating" Route Request (i.e., with no hop limit) for shorter route (not
   including the target
   node.

   As another example, a node MAY use this hop limit to implement an
   "expanding ring" search for hops of the target [14]. source route "skipped over" by this
   packet).  A node using this
   technique sends an initial non-propagating Route Request as described
   above; if no uses its Gratuitous Route Reply is received for it, Table to limit the node
   rate at which it originates
   another gratuitous Route Request with Replies to the same
   original sender for the same node from which it overheard a hop limit of 2.  For each packet to
   trigger the gratuitous Route Request
   originated, if no Reply.

   Each entry in the Gratuitous Route Reply is received for it, the Table of a node doubles contains the hop limit used on
   following fields:

    -  The address of the previous attempt, node to progressively explore
   for the target which this node without allowing the originated a
       gratuitous Route Request to propagate
   over Reply.

    -  The address of the entire network.  However, node from which this expanding ring search
   approach could have node overheard the effect of increasing packet
       triggering that gratuitous Route Reply.

    -  The remaining time before which this entry in the average latency of Gratuitous
       Route Discovery, since multiple Discovery attempts Reply Table expires and timeouts may SHOULD be needed before discovering a route to deleted by the target node.

3.4. Additional
       When a node creates a new entry in its Gratuitous Route Maintenance Features

3.4.1. Packet Salvaging Reply
       Table, the timeout value for that entry should be initialized to
       the value GratReplyHoldoff.

   When an intermediate a node forwarding overhears a packet detects through Route
   Maintenance that would trigger a gratuitous
   Route Reply, if a corresponding entry already exists in the next hop along node's
   Gratuitous Route Reply Table, then the route node SHOULD NOT send a
   gratuitous Route Reply for that packet is
   broken, if packet.  Otherwise (no corresponding
   entry already exists), the node has another route to the packet's destination SHOULD create a new entry in its
   Gratuitous Route Cache, Reply Table to record that gratuitous Route Reply,
   with a timeout value of GratReplyHoldoff.

4.5. Network Interface Queue and Maintenance Buffer

   Depending on factors such as the node SHOULD "salvage" structure and organization of
   the operating system, protocol stack implementation, network
   interface device driver, and network interface hardware, a packet rather than
   discarding it.  To salvage
   being transmitted could be queued in a packet, variety of ways.  For
   example, outgoing packets from the node replaces network protocol stack might be
   queued at the original
   source route on operating system or link layer, before transmission
   by the packet with network interface.  The network interface might also
   provide a retransmission mechanism for packets, such as occurs in
   IEEE 802.11 [13]; the route from its DSR protocol, as part of Route Cache. Maintenance,
   requires limited buffering of packets already transmitted for
   which the reachability of the next-hop destination has not yet been
   determined.  The operation of DSR is defined here in terms of two
   conceptual data structures that together incorporate this queuing
   behavior.

   The Network Interface Queue of a node then forwards implementing DSR is an output
   queue of packets from the packet network protocol stack waiting to be
   transmitted by the next node indicated along this
   source route.  For network interface; for example, in the situation shown in the example of
   Section 3.2, if node C has another route cached to node E, it can
   salvage the packet by replacing 4.4BSD
   Unix network protocol stack implementation, this queue for a network
   interface is represented as a "struct ifqueue" [36].  This queue is
   used to hold packets while the original route network interface is in the packet with process of
   transmitting another packet.

   The Maintenance Buffer of a node implementing DSR is a queue of
   packets sent by this new route from its own node that are awaiting next-hop reachability
   confirmation as part of Route Cache, rather than discarding Maintenance.  For each packet in
   the
   packet.

   When salvaging Maintenance Buffer, a packet, node maintains a count is maintained in the packet of the number
   of times that it has been salvaged, to prevent a single packet
   from being salvaged endlessly.  Otherwise, it could be possible for retransmissions and the time of the last retransmission.  The
   Maintenance Buffer MAY be of limited size; when adding a new packet
   to enter a routing loop, as different nodes repeatedly
   salvage the packet and replace Maintenance Buffer, if the source route on buffer size is insufficient to hold
   the new packet, the new packet with
   routes SHOULD be silently discarded.  If,
   after MaxMaintRexmt attempts to each other.

   As described in Section 3.2, an intermediate confirm next-hop reachability of
   some node, such as no confirmation is received, all packets in this
   case, that detects through Route node's
   Maintenance that the next hop along Buffer with this next-hop destination SHOULD be removed
   from the route for a packet that it is forwarding is broken, Maintenance Buffer; in this case, the node also SHOULD return
   originate a Route Error for this packet to the each original sender of the packet,
   identifying the link over which the packet could not be forwarded.
   If the node sends this Route Error, it SHOULD originate the Route
   Error before salvaging the packet.

3.4.2. Queued Packets Destined over a Broken Link

   When an intermediate node forwarding source of
   a packet detects through removed in this way (Section 8.3) and SHOULD salvage each
   packet removed in this way (Section 8.3.6) if it has another route
   to that packet's IP Destination Address in its Route
   Maintenance Cache.  The
   definition of MaxMaintRexmt conceptually includes any retransmissions
   that might be attempted for a packet at the next-hop link along layer or within
   the route for that packet
   is broken, in addition network interface hardware.  The timeout value to handling that packet as defined use for Route
   Maintenance, each
   transmission attempt for an acknowledgement request depends on the node SHOULD also handle
   type of acknowledgement mechanism used by Route Maintenance for that
   attempt, as described in Section 8.3.

4.6. Blacklist

   When a similar way any pending
   packets node using the DSR protocol is connected through an
   interface that requires physically bidirectional links for unicast
   transmission, it has queued MUST maintain a blacklist.  A Blacklist is a table,
   indexed by neighbor address, that indicates that are destined over this new broken
   link.  Specifically, the node SHOULD search its Network Interface
   Queue and Maintenance Buffer (Section 4.5) for packets for which the next-hop link is this new broken link.  For each such packet
   currently queued at between
   this node, node and the specified neighbor may not be bidirectional.  A
   node SHOULD process places another node's address in this list when it believes that packet as
   follows:

    -  Remove the packet
   broadcast packets from the node's Network Interface Queue and
       Maintenance Buffer.

    -  Originate a Route Error for that other node reach this packet to the original sender of
       the packet, using node, but that
   unicast transmission between the procedure described in Section 6.3.4, as two nodes is not possible.  For
   example, if
       the a node had already reached forwarding a Route Reply discovers that the maximum number of retransmission
       attempts for next
   hop is unreachable, it places that packet for Route Maintenance.  However, in
       sending such Route Errors for queued packets next hop in response to a
       single new broken link detected, the node's blacklist.

   Once a node SHOULD send no more
       than discovers that it can communicate bidirectionally with
   one Route Error to each original sender of any of these
       packets.

    -  If the node has another route to the packet's IP
       Destination Address nodes listed in its Route Cache, the node blacklist, it SHOULD
       salvage the packet as described in Section 6.3.6.  Otherwise, the remove that
   node SHOULD discard from the packet.

3.4.3. Automatic Route Shortening

   Source routes in use MAY be automatically shortened blacklist.  For example, if one or more
   intermediate nodes node A has node B in its
   blacklist, but A hears B forward a Route Request with a hop list
   indicating that the route become no longer necessary.  This
   mechanism of automatically shortening routes in use is somewhat
   similar broadcast from A to the use of passive acknowledgments [16].  In particular,
   if a B was successful, then A
   SHOULD remove B from its blacklist.

   A node is able to overhear a packet carrying MUST associate a source route (e.g.,
   by operating its network interface in promiscuous receive mode), then
   this state with each node examines in the unexpended portion of that source route.  If
   this node is not blacklist,
   specifying whether the intended next-hop destination for unidirectionality is "questionable"
   or "probable".  Each time the packet
   but unreachability is named in positively
   determined, the node SHOULD set the state to "probable".  After the later unexpended portion
   unreachability has not been positively determined for some amount of
   time, the packet's source
   route, then it can infer that the intermediate state should revert to "questionable".  A node MAY expire
   nodes before itself in from its blacklist after a reasonable amount of time.

5. Additional Conceptual Data Structures for Flow State Extension

   This section defines additional conceptual data structures used by
   the source route are no longer needed in optional "flow state" extension to DSR.  In an implementation of
   the route.  For example, protocol, these data structures MAY be implemented in any manner
   consistent with the
   figure below illustrates an example external behavior described in which this document.

5.1. Flow Table

   A node D has overheard implementing the flow state extension MUST implement a Flow
   Table or other data packet being transmitted from B to C, for later forwarding to D
   and to E:

         +-----+     +-----+     +-----+     +-----+     +-----+
         |  A  |---->|  B  |---->|  C  |     |  D  |     |  E  |
         +-----+     +-----+     +-----+     +-----+     +-----+
                        \                       ^
                         \                     /
                          ---------------------

   In this case, structure consistent with the external behavior
   described in this section.  A node (node D) not implementing the flow state
   extension SHOULD return NOT implement a "gratuitous" Route
   Reply to the original sender of the packet (node A). Flow Table.

   The Route
   Reply gives Flow Table records information about flows from which packets
   recently have been sent or forwarded by this node.  The table is
   indexed by a triple (IP Source Address, IP Destination Address,
   Flow ID), where Flow ID is a 16-bit token assigned by the shorter route source as
   described in Section 3.5.1.  Each entry in the concatenation Flow Table contains
   the following fields:

    -  The MAC address of the portion next-hop node along this flow.

    -  An indication of the original source route up through the outgoing network interface on this node that transmitted the
   overheard packet (node B), plus the suffix to
       be used in transmitting packets along this flow.

    -  The MAC address of the original source
   route beginning with the previous-hop node returning the gratuitous Route Reply
   (node D). In along this example, the route returned in flow.

    -  An indication of the gratuitous Route
   Reply message sent network interface on this node from D to A gives the new route as the sequence of
   hops which
       packets from that previous-hop node are received.

    -  A to B to D to E.

   When deciding whether to return a gratuitous Route Reply in timeout after which this way,
   a node MAY factor entry in additional information beyond the fact that it
   was able to overhear the packet.  For example, the node MAY decide to
   return Flow Table MUST be
       deleted.

    -  The expected value of the gratuitous Route Reply only when Hop Count field in the overheard packet is DSR Flow State
       header for packets received for forwarding along this field (for
       use with packets containing a signal strenth DSR Flow State header).

    -  An indication of whether or signal-to-noise ratio above some
   specific threshold.  In addition, each node maintains a Gratuitous
   Route Reply Table, not this flow can be used as described in Section 4.4, to limit a
       default flow for packets originated by this node (the flow IP
       MUST be odd).

    -  The entry SHOULD record the rate at
   which it originates gratuitous complete source route for the flow.
       (Nodes not recording the complete source route cannot participate
       in Automatic Route Replies for Shortening.)

    -  The entry MAY contain a field recording the same returned
   route.

3.4.4. Increased Spreading of time this entry was
       last used.

   The entry MUST be deleted when its timeout expires.

5.2. Automatic Route Error Messages

   When a source Shortening Table

   A node receives a implementing the flow state extension SHOULD implement an
   Automatic Route Error for a Shortening Table or other data packet that
   it originated, structure consistent
   with the external behavior described in this source section.  A node propagates this
   not implementing the flow state extension SHOULD NOT implement an
   Automatic Route Error to its
   neighbors by piggybacking it on its next Shortening Table.

   The Automatic Route Request.  In this way,
   stale Shortening Table records information about
   received packets for which Automatic Route Shortening may be
   possible.  The table is indexed by a triple (IP Source Address, IP
   Destination Address, Flow ID). Each entry in the caches of nodes around this source node will
   not generate Automatic Route Replies
   Shortening Table contains a list of (packet identifier, Hop Count)
   pairs for that contain flow.  The packet identifier in the same invalid link list may be any
   unique identifier for
   which this source node received the Route Error.

   For received packet; for example, in the situation shown in for IPv4
   packets, the example combination of Section 3.2,
   node A learns from the Route Error message following fields from C, that the link
   from C to D is currently broken.  It thus removes this link from
   its own Route Cache and initiates packet's
   IP header MAY be used as a new Route Discovery (if it has
   no other route to E unique identifier for the packet:  Source
   Address, Destination Address, Identification, Protocol, Fragment,
   and Total Length.  The Hop Count in the list in the entry is copied
   from the Hop Count field in its Route Cache).  On the Route Request DSR Flow State header of the received
   packet initiating for which this Route Discovery, node A piggybacks a copy
   of table entry was created.  Any packet identifier
   SHOULD appear at most once in the list in an entry, and this Route Error, ensuring list
   item SHOULD record the minimum Hop Count value received for that
   packet (if the Route Error spreads well wireless signal strength or signal-to-noise ratio at
   which a packet is received is available to
   other nodes, and guaranteeing that any Route Reply that it receives
   (including those from other node's Route Caches) the DSR implementation
   in response to this
   Route Request does not contain a route that assumes node, the existence of node MAY, for example, remember instead in this broken link.

4. Conceptual Data Structures

   This document describes list
   the operation of minimum Hop Count value for which the DSR protocol received packet's signal
   strength or signal-to-noise ratio exceeded some threshold).

   Space in terms the Automatic Route Shortening Table of a number of conceptual data structures.  This section describes
   each of these data structures and provides an overview of its use node MAY be
   dynamically managed by any local algorithm at the node.  For example,
   in order to limit the protocol.  In an implementation amount of memory used to store the protocol, these data
   structures table, any
   existing entry MAY be implemented in deleted at any manner consistent with time, and the
   external behavior described in this document.

4.1. Route Cache

   All ad hoc network routing information needed by a node implementing
   DSR is stored number of packets
   listed in that node's Route Cache.  Each node each entry MAY be limited.  However, when reclaiming space
   in the network
   maintains its own Route Cache.  A node adds table, nodes SHOULD favor retaining information to its
   Route Cache about more
   flows in the table rather than more packets listed in each entry
   in the table, as it learns long as at least the listing of new links between nodes some small number
   of packets (e.g., 3) can be retained in each entry.  In addition,
   subject to any implementation limit on the ad hoc
   network; for example, a node may learn number of new links when it receives packets listed
   in each entry in the table, information about a packet carrying a Route Request, Route Reply, or DSR source route.
   Likewise, a node removes information from its Route Cache as it
   learns that existing links listed in an
   entry SHOULD be retained until the ad hoc network have broken; for
   example, a node may learn expiration of the packet's IP TTL.

5.3. Default Flow ID Table

   A node implementing the flow state extension MUST implement a broken link when it receives a packet
   carrying a Route Error Default
   Flow Table or through other data structure consistent with the link-layer retransmission
   mechanism reporting a failure external
   behavior described in forwarding a packet to its next-hop
   destination.

   Anytime a this section.  A node adds new information to its Route Cache, not implementing the node flow
   state extension SHOULD check NOT implement a Default Flow Table.

   For each packet in its own Send Buffer (Section 4.2) to
   determine whether (source, destination) pair for which a route to that packet's IP Destination Address
   now exists in the node's Route Cache (including the information just
   added to node forwards
   packets, the Cache).  If so, node MUST record:

    -  the packet SHOULD then be sent using largest odd Flow ID value seen

    -  the time at which all of this (source, destination) pair's flows
       that route and removed from are forwarded by this node expire

    -  the Send Buffer.

   It current default Flow ID

    -  a flag indicating whether or not the current default Flow ID is possible to interface
       valid

   If a DSR network with other networks,
   external to node deletes this DSR network.  Such external networks may, record for
   example, be the Internet, or may be other ad hoc networks routed
   with a routing protocol other than DSR.  Such external networks may (source, destination) pair,
   it MUST also be other DSR networks delete all Flow Table entries for that are treated as external networks
   in order to improve scalability.  The complete handling of such
   external networks is beyond the scope (source,
   destination) pair.  Nodes MUST delete table entries if all of this document.  However,
   this document specifies a minimal set of requirements and features
   necessary to allow nodes only implementing
   (source, destination) pair's flows that are forwarded by this specification to
   interoperate correctly with nodes implementing interfaces to such
   external networks.  This minimal set of requirements and features
   involve the First Hop External (F) and Last Hop External (L)
   bits in a node
   expire.

6. DSR Options Header Format

   The Dynamic Source Route option (Section 5.7) and Routing protocol makes use of a Route Reply
   option (Section 5.3) special header
   carrying control information that can be included in a packet's any existing
   IP packet.  This DSR Options header (Section 5).  These
   requirements also include the addition of an External flag bit
   tagging each link in the Route Cache, copied from the First Hop
   External (F) and Last Hop External (L) bits in the DSR Source Route
   option a packet contains a small
   fixed-sized, 4-octet portion, followed by a sequence of zero or Route Reply option from which this link was learned.

   The Route Cache SHOULD support storing more than one route to each
   destination.  In searching
   DSR options carrying optional information.  The end of the Route Cache for a route to some
   destination node, sequence
   of DSR options in the Route Cache DSR Options header is indexed implied by destination node
   address.  The following properties describe this searching function
   on a Route Cache:

    -  Each implementation total length
   of DSR at any node MAY choose any appropriate
       strategy and algorithm for searching its Route Cache and
       selecting a "best" route to the destination from among those
       found. DSR Options header.

   For example, a node MAY choose to select IPv4, the shortest
       route to DSR Options header MUST immediately follow the destination (the shortest sequence of hops), or it
       MAY use an alternate metric to select IP
   header in the route from packet.  (If a Hop-by-Hop Options extension header, as
   defined in IPv6 [7], becomes defined for IPv4, the Cache.

    -  However, DSR Options header
   MUST immediately follow the Hop-by-Hop Options extension header, if there are multiple cached routes
   one is present in the packet, and MUST otherwise immediately follow
   the IP header.)

   To add a DSR Options header to a destination,
       the selection of routes when searching packet, the Route Cache MUST
       prefer routes that do not have DSR Options header is
   inserted following the External flag set on packet's IP header, before any link.
       This preference will select routes that lead directly to following
   header such as a traditional (e.g., TCP or UDP) transport layer
   header.  Specifically, the Protocol field in the
       target node over routes that attempt IP header is used
   to reach indicate that a DSR Options header follows the target via any
       external networks connected to IP header, and the
   Next Header field in the DSR ad hoc network.

    -  In addition, any route selected when searching Options header is used to indicate the Route Cache
       MUST NOT have
   type of protocol header (such as a transport layer header) following
   the External bit set for DSR Options header.

   If any links other than
       possibly headers follow the first link, DSR Options header in a packet, the last link, or both; total
   length of the External bit DSR Options header (and thus the total, combined length
   of all DSR options present) MUST NOT be set for any intermediate hops a multiple of 4 octets.  This
   requirement preserves the alignment of these following headers in the route selected.

   An implementation
   packet.

6.1. Fixed Portion of a Route Cache MAY provide a DSR Options Header

   The fixed capacity
   for the cache, or portion of the cache size MAY DSR Options header is used to carry
   information that must be variable.  The following
   properties describe the management present in any DSR Options header.  This
   fixed portion of available space within a node's
   Route Cache:

    -  Each implementation the DSR Options header has the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  |F|   Reserved  |        Payload Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                            Options                            .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Next Header

         8-bit selector.  Identifies the type of header immediately
         following the DSR at each node MAY choose any
       appropriate policy for managing Options header.  Uses the entries in its Route Cache,
       such same values as when limited cache capacity requires a choice of which
       entries the
         IPv4 Protocol field [32].

      Flow State Header (F)

         Flag bit.  MUST be set to retain 0.  This bit is set in the Cache.  For example, a node MAY chose a
       "least recently used" (LRU) cache replacement policy, DSR Flow
         State header (Section 7.1) and clear in which
       the entry last used longest ago is discarded from the cache if a
       decision needs to DSR Options header.

      Reserved

         MUST be made to allow space in sent as 0 and ignored on reception.

      Payload Length

         The length of the cache for some
       new entry being added.

    -  However, DSR Options header, excluding the Route Cache replacement policy SHOULD allow routes
       to be categorized based upon "preference", where routes with a
       higher preferences are less likely to be removed from 4-octet
         fixed portion.  The value of the cache.
       For example, a node could prefer routes for which it initiated
       a Route Discovery over routes that it learned as Payload Length field defines
         the result total length of
       promiscuous snooping on other packets.  In particular, a node
       SHOULD prefer routes that it is presently using over those that
       it is not.

   Any suitable data structure organization, consistent with this
   specification, MAY be used to implement the Route Cache all options carried in any node.
   For example, the following two types of organization are possible:

    -  In DSR, DSR Options
         header.

      Options

         Variable-length field; the length of the route returned in each Route Reply that Options field is received
         specified by the initiator Payload Length field in this DSR Options
         header.  Contains one or more pieces of a Route Discovery (or that is learned from optional information
         (DSR options), encoded in type-length-value (TLV) format (with
         the header exception of overhead packets, as the Pad1 option, described in Section 6.1.4)
       represents a complete path (a sequence 6.8).

   The placement of links) leading to DSR options following the
       destination node.  By caching each fixed portion of these paths separately,
       a "path cache" organization for the Route Cache can DSR
   Options header MAY be formed.
       A path cache is very simple padded for alignment.  However, due to implement and easily guarantees
       that all routes are loop-free, since each individual route from
       a Route Reply or Route Request or used the
   typically limited available wireless bandwidth in ad hoc networks,
   this padding is not required, and receiving nodes MUST NOT expect
   options within a packet DSR Options header to be aligned.

   Each DSR option is loop-free.
       To search for assigned a route in unique Option Type code.  The most
   significant 3 bits (that is, Option Type & 0xE0) allow a path cache data structure, the sending node can simply search its Route Cache not
   implementing processing for any path (or prefix of
       a path) that leads this Option Type value to behave in the intended destination node.

       This type of organization
   manner closest to correct for the Route Cache that type:

    -  The most significant bit in the Option Type value (that is,
       Option Type & 0x80) represents whether or not a node receiving
       this Option Type SHOULD respond to such a DSR has been
       extensively studied through simulation [5, 9, 12, 19] and
       through implementation option with a Route
       Error of DSR type OPTION_NOT_SUPPORTED, except that such a Route
       Error SHOULD never be sent in response to a mobile outdoor testbed under
       significant workload [20, 21, 22].

    -  Alternatively, packet containing a "link cache" organization could be used for the
       Route Cache, in which each individual link (hop) in the routes
       returned Request option.

    -  The two follow bits in Route Reply packets (or otherwise learned from the
       header of overhead packets) is added to Option Type value (that is,
       Option Type & 0x60) are a unified graph data
       structure of two-bit field indicating how such a
       node that does not support this node's current view of Option Type MUST process the network topology.
       To search for
       packet:

          00 = Ignore Option
          01 = Remove Option
          10 = Mark Option
          11 = Drop Packet

       When these two bits are zero (that is, Option Type & 0x60 == 0),
       a route in link cache, the sending node must not implementing processing for that Option Type
       MUST use
       a more complex graph search algorithm, such as the well-known
       Dijkstra's shortest-path algorithm, Opt Data Len field to find skip over the current best path
       through option and
       continue processing.  When these two bits are 01 (that is,
       Option Type & 0x60 == 0x20), a node not implementing processing
       for that Option Type MUST use the graph Opt Data Len field to remove
       the destination node.  Such an algorithm is
       more difficult to implement option from the packet and may require significantly more
       CPU time to execute.

       However, a link cache organization is more powerful than a path
       cache organization, continue processing as if the
       option had not been included in its ability to effectively utilize all of the potential information that received packet.  When these
       two bits are 10 (that is, Option Type & 0x60 == 0x40), a node might learn about not
       implementing processing for that Option Type MUST set the state
       of most
       significant bit following the network.  In particular, links learned from different
       Route Discoveries or from Opt Data Len field, MUST ignore the header
       contents of any overheard packets can
       be merged together to form new routes in the network, but this
       is not possible in option using the Opt Data Len field, and MUST
       continue processing the packet.  Finally, when these two bits are
       11 (that is, Option Type & 0x60 == 0x60), a path cache due to node not implementing
       processing for that Option Type MUST drop the separation packet.

   The following types of each
       individual path DSR options are defined in the cache.

       This type of organization this document for the
   use within a DSR Options header:

    -  Route Cache Request option (Section 6.2)

    -  Route Reply option (Section 6.3)

    -  Route Error option (Section 6.4)

    -  Acknowledgement Request option (Section 6.5)

    -  Acknowledgement option (Section 6.6)

    -  DSR Source Route option (Section 6.7)

    -  Pad1 option (Section 6.8)

    -  PadN option (Section 6.9)

6.2. Route Request Option

   The Route Request option in DSR, including
       the effect of a range of implementation choices, has been studied
       through detailed simulation [9].

   The choice of data structure organization DSR Options header is encoded as
   follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Option Type  |  Opt Data Len |         Identification        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Target Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Address[1]                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Address[2]                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Address[n]                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IP fields:

      Source Address

         MUST be set to use for the Route Cache
   in any DSR implementation is a local matter for each node and affects
   only performance; any reasonable choice address of organization for the Route
   Cache does not affect either correctness or interoperability.

   Each entry in the Route Cache SHOULD have a timeout associated
   with it, to allow node originating this packet.
         Intermediate nodes that entry to be deleted if not used within some
   time.  The particular choice of algorithm and data structure used
   to implement the Route Cache SHOULD be considered in choosing retransmit the
   timeout for entries in packet to propagate the
         Route Cache.  The configuration variable
   RouteCacheTimeout defined in Section 9 specifies the timeout to Request MUST NOT change this field.

      Destination Address

         MUST be
   applied set to entries in the Route Cache, although it is also possible IP limited broadcast address
         (255.255.255.255).

      Hop Limit (TTL)

         MAY be varied from 1 to instead use an adaptive policy in choosing timeout values rather
   than using a single timeout setting for all entries; 255, for example, the
   Link-MaxLife cache design (below) uses an adaptive timeout algorithm
   and does not use the RouteCacheTimeout configuration variable.

   As guidance to implementors, Appendix A describes a type of link
   cache known as "Link-MaxLife" that has been shown example to outperform
   other types of link caches implement
         non-propagating Route Requests and path caches studied in detailed
   simulation [9].  Link-MaxLife is an adaptive link cache in which each
   link Route Request expanding-ring
         searches (Section 3.3.4).

   Route Request fields:

      Option Type

         2

      Opt Data Len

         8-bit unsigned integer.  Length of the option, in octets,
         excluding the cache has a timeout that is determined dynamically Option Type and Opt Data Len fields.

      Identification

         A unique value generated by the
   caching node according to its observed past behavior of the two nodes
   at the ends initiator (original sender) of
         the link; in addition, when selecting Route Request.  Nodes initiating a route Route Request generate
         a new Identification value for each Route Request, for example
         based on a
   packet being sent to some destination, among cached routes of equal
   length (number sequence number counter of hops) to that destination, Link-MaxLife selects the
   route with all Route Requests
         initiated by the longest expected lifetime (highest minimum timeout node.

         This value allows a receiving node to determine whether it
         has recently seen a copy of
   any link this Route Request:  if this
         Identification value is found by this receiving node in its
         Route Request Table (in the route).  Use cache of Identification values
         in the Link-MaxLife design entry there for this initiating node), this receiving
         node MUST discard the Route
   Cache is recommended in implementations Request.  When propagating a Route
         Request, this field MUST be copied from the received copy of DSR.

4.2. Send Buffer
         the Route Request being propagated.

      Target Address

         The Send Buffer address of a the node implementing DSR is a queue of packets that
   cannot be sent by that node because it does not yet have a source
   route to each such packet's destination.  Each packet in the Send
   Buffer is logically associated with the time that it was placed into target of the Buffer, and SHOULD be removed from Route
         Request.

      Address[1..n]

         Address[i] is the Send Buffer and silently
   discarded after a period address of SendBufferTimeout after initially being
   placed in the Buffer.  If necessary, a FIFO strategy SHOULD be used
   to evict packets before they timeout to prevent i-th node recorded in the buffer from
   overflowing.

   Subject to
         Route Request option.  The address given in the rate limiting defined Source Address
         field in Section 6.2, a the IP header is the address of the initiator of
         the Route Discovery SHOULD and MUST NOT be initiated as often as possible for listed in the Address[i]
         fields; the address given in Address[1] is thus the
   destination address
         of any packets residing the first node on the path after the initiator.  The
         number of addresses present in this field is indicated by the
         Opt Data Len field in the option (n = (Opt Data Len - 6) / 4).
         Each node propagating the Send Buffer.

4.3. Route Request Table adds its own address to
         this list, increasing the Opt Data Len value by 4 octets.

   The Route Request Table of option MUST NOT appear more than once within a node implementing DSR records
   information about
   Options header.

6.3. Route Requests that have been recently originated
   or forwarded by this node.  The table is indexed by IP address. Reply Option

   The Route Request Table on Reply option in a node records the following information
   about nodes DSR Options header is encoded as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |  Option Type  |  Opt Data Len |L|   Reserved  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Address[1]                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Address[2]                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Address[n]                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IP fields:

      Source Address

         Set to which this node has initiated a Route Request:

    -  The Time-to-Live (TTL) field used in the IP header address of the node sending the Route
       Request for Reply.
         In the last case of a node sending a reply from its Route Discovery initiated by
         Cache (Section 3.3.2) or sending a gratuitous Route Reply
         (Section 3.4.3), this node for address can differ from the address that
         was the target node.  This value allows of the node Route Discovery.

      Destination Address

         MUST be set to implement a
       variety the address of algorithms for controlling the spread source node of its the route
         being returned.  Copied from the Source Address field of the
         Route Request on each generating the Route Discovery initiated for Reply, or in the case of a target.  As
       examples, two possible algorithms for
         gratuitous Route Reply, copied from the Source Address field of
         the data packet triggering the gratuitous Reply.

   Route Reply fields:

      Option Type

         1.  Nodes not understanding this use option will ignore this
         option.

      Opt Data Len

         8-bit unsigned integer.  Length of the TTL field
       are described option, in Section 3.3.4.

    -  The time octets,
         excluding the Option Type and Opt Data Len fields.

      Last Hop External (L)

         Set to indicate that this node the last originated a Route Request for that
       target node.

    -  The number of consecutive Route Discoveries initiated for this
       target since receiving a valid hop given by the Route Reply giving a route
         (the link from Address[n-1] to that
       target node.

    -  The remaining amount of time before which this node MAY next
       attempt at Address[n]) is actually an
         arbitrary path in a Route Discovery for that target node.  When network external to the DSR network; the
         exact route outside the DSR network is not represented in the
       node initiates a new
         Route Discovery for this target node, Reply.  Nodes caching this
       field hop in the their Route Request Table entry for that target node is
       initialized to Cache MUST
         flag the timeout for that Route Discovery, after which cached hop with the node MAY initiate a new Discovery for that target.  Until External flag.  Such hops MUST NOT
         be returned in a valid cached Route Reply is received for this target node address,
       a node MUST implement a back-off algorithm in determining generated from this
       timeout value for each successive Route Discovery initiated
       for this target using the same Time-to-Live (TTL) value in the
       IP header
         Cache entry, and selection of routes from the Route Request packet. Cache to
         route a packet being sent MUST prefer routes that contain no
         hops flagged as External.

      Reserved

         MUST be sent as 0 and ignored on reception.

      Address[1..n]

         The timeout between
       such consecutive Route Discovery initiations SHOULD increase source route being returned by
       doubling the timeout value on each new initiation.

   In addition, the Route Request Table on Reply.  The route
         indicates a node also records sequence of hops, originating at the
   following information about initiator nodes from which this source node has
   received a Route Request:

    -  A FIFO cache
         specified in the Destination Address field of size RequestTableIds entries containing the
       Identification value and target address from IP header
         of the packet carrying the most recent Route Requests received by this node from that initiator node.

   Nodes SHOULD use an LRU policy to manage Reply, through each of the entries
         Address[i] nodes in their the order listed in the Route
   Request Table. Reply,
         ending with the destination node indicated by Address[n].
         The number of Identification values to retain in each Route
   Request Table entry, RequestTableIds, MUST NOT be unlimited, since, addresses present in the worst case, when a node crashes and reboots, the first
   RequestTableIds Route Discoveries it initiates after rebooting
   could appear to be duplicates to Address[1..n]
         field is indicated by the other nodes Opt Data Len field in the network.
   In addition, a node SHOULD base its initial Identification value,
   used for option
         (n = (Opt Data Len - 1) / 4).

   A Route Discoveries after rebooting, on a battery backed-up
   clock Reply option MAY appear one or other persistent memory device, in order to help avoid
   any possible such delay in successfully discovering new routes
   after rebooting; if no such source of initial Identification
   value is available, a node after rebooting SHOULD base its initial
   Identification value on more times within a random number.

4.4. Gratuitous DSR
   Options header.

6.4. Route Reply Table Error Option

   The Gratuitous Route Reply Table of Error option in a node implementing DSR records
   information about "gratuitous" Route Replies sent by Options header is encoded as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Option Type  |  Opt Data Len |   Error Type  |Reservd|Salvage|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Error Source Address                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Error Destination Address                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                   Type-Specific Information                   .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Option Type

         2.  Nodes not understanding this node as
   part option will ignore this
         option.

      Opt Data Len

         8-bit unsigned integer.  Length of automatic route shortening.  As described the option, in Section 3.4.3,
   a node returns a gratuitous Route Reply when it overhears a packet
   transmitted by some node, for which octets,
         excluding the node overhearing Option Type and Opt Data Len fields.

         For the
   packet was not current definition of the intended next-hop node but was named later in Route Error option,
         this field MUST be set to 10, plus the unexpended hops size of the source route any
         Type-Specific Information present in that packet; the node
   overhearing the packet returns a gratuitous Route Reply Error.  Further
         extensions to the
   original sender Route Error option format may also be
         included after the Type-Specific Information portion of the packet, listing
         Route Error option specified above.  The presence of such
         extensions will be indicated by the shorter route (not
   including Opt Data Len field.
         When the hops Opt Data Len is greater than that required for
         the fixed portion of the source route "skipped over" by this
   packet).  A node uses its Gratuitous Route Reply Table to limit Error plus the
   rate at which it originates gratuitous Route Replies to necessary
         Type-Specific Information as indicated by the same
   original sender for Option Type
         value in the same node option, the remaining octets are interpreted as
         extensions.  Currently, no such further extensions have been
         defined.

      Error Type

         The type of error encountered.  Currently, the following type
         values are defined:

             1 = NODE_UNREACHABLE
             2 = FLOW_STATE_NOT_SUPPORTED
             3 = OPTION_NOT_SUPPORTED
         Other values of the Error Type field are reserved for future
         use.

      Reservd

         Reserved.  MUST be sent as 0 and ignored on reception.

      Salvage

         A 4-bit unsigned integer.  Copied from which it overheard a packet to
   trigger the gratuitous Route Reply.

   Each entry Salvage field in
         the Gratuitous DSR Source Route Reply Table option of a node contains the
   following fields:

    -  The address of packet triggering the node to which this node originated a
       gratuitous Route Reply.

    -
         Error.

         The address "total salvage count" of the node Route Error option is derived
         from which this node overheard the packet
       triggering that gratuitous Route Reply.

    -  The remaining time before which this entry value in the Gratuitous Salvage field of this Route Reply Table expires Error option
         and SHOULD be deleted by the node.
       When a node creates a new entry in its Gratuitous all preceding Route Reply
       Table, the timeout value for that entry should be initialized to Error options in the value GratReplyHoldoff.

   When a node overhears a packet that would trigger a gratuitous
   Route Reply, if a corresponding entry already exists in as follows:
         the node's
   Gratuitous Route Reply Table, then total salvage count is the node SHOULD NOT send a
   gratuitous Route Reply sum of, for that packet.  Otherwise (no corresponding
   entry already exists), each such Route
         Error option, one plus the node SHOULD create a new entry value in its
   Gratuitous Route Reply Table to record the Salvage field of that gratuitous
         Route Reply,
   with a timeout value Error option.

      Error Source Address

         The address of GratReplyHoldoff.

4.5. Network Interface Queue and Maintenance Buffer

   Depending on factors such as the structure and organization of node originating the operating system, protocol stack implementation, network
   interface device driver, and network interface hardware, Route Error (e.g., the
         node that attempted to forward a packet
   being transmitted could be queued in a variety and discovered the link
         failure).

      Error Destination Address

         The address of ways. the node to which the Route Error must be
         delivered For example, outgoing packets from when the network protocol stack might Error Type field is set to
         NODE_UNREACHABLE, this field will be
   queued at set to the operating system or link layer, before transmission
   by address of the network interface.  The network interface might also
   provide a retransmission mechanism for packets, such as occurs
         node that generated the routing information claiming that the
         hop from the Error Source Address to Unreachable Node Address
         (specified in
   IEEE 802.11 [11]; the DSR protocol, as part Type-Specific Information) was a valid hop.

      Type-Specific Information

         Information specific to the Error Type of this Route Maintenance,
   requires limited buffering of packets already transmitted for
   which Error
         message.

   A Route Error option MAY appear one or more times within a DSR
   Options header.

6.4.1. Node Unreachable Type-Specific Information

   When the reachability Route Error is of type NODE_UNREACHABLE, the next-hop destination has not yet been
   determined.  The operation of DSR
   Type-Specific Information field is defined here in terms of two
   conceptual data structures that together incorporate this queueing
   behavior. as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Unreachable Node Address                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Unreachable Node Address

         The Network Interface Queue of a node implementing DSR is an output
   queue address of packets from the network protocol stack waiting node that was found to be
   transmitted by unreachable
         (the next-hop neighbor to which the network interface; for example, in node with address
         Error Source Address was attempting to transmit the 4.4BSD
   Unix network protocol stack implementation, this queue for a network
   interface is represented as a "struct ifqueue" [33].  This queue packet).

6.4.2. Flow State Not Supported Type-Specific Information

   When the Route Error is
   used to hold packets while of type FLOW_STATE_NOT_SUPPORTED, the network interface
   Type-Specific Information field is in empty.

6.4.3. Option Not Supported Type-Specific Information

   When the process of
   transmitting another packet.

   The Maintenance Buffer of a node implementing DSR Route Error is a queue of
   packets sent by this node that are awaiting next-hop reachability
   confirmation type OPTION_NOT_SUPPORTED, the
   Type-Specific Information field is defined as part follows:

    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |Unsupported Opt|
   +-+-+-+-+-+-+-+-+

      Unsupported Opt

         The type of option triggering the Route Maintenance.  For each packet Error.

6.5. Acknowledgement Request Option

   The Acknowledgement Request option in
   the Maintenance Buffer, a node maintains a count of DSR Options header is encoded
   as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Option Type  |  Opt Data Len |         Identification        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Option Type

         160.  Nodes not understanding this option will remove the number
   of retransmissions
         option and the time of the last retransmission.  The
   Maintenance Buffer MAY be of limited size; when adding return a new packet
   to Route Error.

      Opt Data Len

         8-bit unsigned integer.  Length of the Maintenance Buffer, if option, in octets,
         excluding the buffer size Option Type and Opt Data Len fields.

      Identification

         The Identification field is insufficient set to hold
   the new packet, a unique value and is copied
         into the new packet SHOULD be silently discarded.  If,
   after MaxMaintRexmt attempts to confirm next-hop reachability Identification field of
   some node, no confirmation is received, all packets in this node's
   Maintenance Buffer with this next-hop destination SHOULD be removed
   from the Maintenance Buffer; in this case, Acknowledgement option
         when returned by the node also SHOULD
   originate a Route Error for this receiving the packet to each original source of over this hop.

   An Acknowledgement Request option MUST NOT appear more than once
   within a packet removed DSR Options header.

6.6. Acknowledgement Option

   The Acknowledgement option in a DSR Options header is encoded as
   follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Option Type  |  Opt Data Len |         Identification        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       ACK Source Address                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     ACK Destination Address                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Option Type

         32.  Nodes not understanding this way (Section 6.3) option will remove the
         option.

      Opt Data Len

         8-bit unsigned integer.  Length of the option, in octets,
         excluding the Option Type and SHOULD salvage each Opt Data Len fields.

      Identification

         Copied from the Identification field of the Acknowledgement
         Request option of the packet removed in this way (Section 6.3.6) if it has another route
   to that packet's IP Destination being acknowledged.

      ACK Source Address in its Route Cache.

         The
   definition address of MaxMaintRexmt conceptually includes any retransmissions
   that might be attempted for a packet at the link layer or within the network interface hardware. node originating the acknowledgement.

      ACK Destination Address

         The timeout value address of the node to use for each
   transmission attempt for an acknowledgment request depends on which the
   type of acknowledgment mechanism used for acknowledgement is to be
         delivered.

   An Acknowledgement option MAY appear one or more times within a DSR
   Options header.

6.7. DSR Source Route Maintenance for that
   attempt, as described Option

   The DSR Source Route option in Section 6.3.

4.6. Blacklist

   When a node using the DSR protocol is connected through an
   interface that requires physically bidirectional links for unicast
   transmission, it MUST keep a blacklist.  A Blacklist Options header is a table,
   indexed by neighbor address, that indicates that the link between encoded as
   follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Option Type  |  Opt Data Len |F|L|Reservd|Salvage| Segs Left |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Address[1]                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Address[2]                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Address[n]                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Option Type

         96.  Nodes not understanding this node and option will drop the specified neighbor may not be bidirectional.  A
   node places another node's address packet.

      Opt Data Len

         8-bit unsigned integer.  Length of the option, in this list when it believes that
   broadcast packets from that other node reach this node, but that
   unicast transmission between octets,
         excluding the two nodes is not possible. Option Type and Opt Data Len fields.  For
   example, if a node forwarding a the
         format of the DSR Source Route Reply discovers that option defined here, this field
         MUST be set to the next
   hop value (n * 4) + 2, where n is unreachable, it places that next hop in the node's blacklist.

   Once a node discovers that it can communicate bidirectionally with
   one number of the nodes listed
         addresses present in the blacklist, it SHOULD remove Address[i] fields.

      First Hop External (F)

         Set to indicate that node
   from the blacklist.  For example, if A has B in its blacklist, but
   A hears B forward a Route Request with a first hop list indicating that indicated by the broadcast from A to B was successful, A SHOULD remove B from its
   blacklist.

   A node MUST associate a state with each node DSR
         Source Route option is actually an arbitrary path in a network
         external to the blacklist,
   specifying whether DSR network; the unidirectionality is "questionable" or
   "probable." Each time exact route outside the unreachability DSR
         network is positively determined,
   the node SHOULD set the state to "probable." After the unreachability
   has not been positively determined for some amount of time, represented in the state
   should revert to "questionable." A node MAY expire nodes from its
   blacklist after a reasonable amount of time.

5. DSR Header Format

   The Dynamic Source Routing protocol makes use of a special header
   carrying control information that can be included Route option.
         Nodes caching this hop in any existing IP
   packet.  This DSR header their Route Cache MUST flag the
         cached hop with the External flag.  Such hops MUST NOT be
         returned 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 Route Reply generated from this Route Cache
         entry, and selection of routes from the sequence of DSR
   options in Route Cache to route
         a packet being sent MUST prefer routes that contain no hops
         flagged as External.

      Last Hop External (L)

         Set to indicate that the DSR header is implied last hop indicated by total length of the DSR
   header.

   For IPv4, Source
         Route option is actually an arbitrary path in a network
         external to the DSR header MUST immediately follow network; the IP header in exact route outside the
   packet.  (If a Hop-by-Hop Options extension header, as defined DSR
         network is not represented in
   IPv6 [6], becomes defined for IPv4, the DSR header Source Route option.

         Nodes caching this hop in their Route Cache MUST immediately
   follow flag the Hop-by-Hop Options extension header, if one is present in
         cached hop with the packet, and External flag.  Such hops MUST otherwise immediately follow the IP header.)

   To add NOT be
         returned in a DSR header Route Reply generated from this Route Cache
         entry, and selection of routes from the Route Cache to route
         a packet, the DSR header is inserted following
   the packet's IP header, before any following header such packet being sent MUST prefer routes that contain no hops
         flagged as External.

      Reserved

         MUST be sent as 0 and ignored on reception.

      Salvage

         A 4-bit unsigned integer.  Count of number of times that
         this packet has been salvaged as a
   traditional (e.g., TCP or UDP) transport layer header.  Specifically, part of DSR routing
         (Section 3.4.1).

      Segments Left (Segs Left)

         Number of route segments remaining, i.e., number of explicitly
         listed intermediate nodes still to be visited before reaching
         the final destination.

      Address[1..n]

         The sequence of addresses of the Protocol field in source route.  In routing
         and forwarding the IP header is used to indicate that a DSR
   header follows packet, the IP header, source route is processed as
         described in Sections 8.1.3 and the Next Header field 8.1.5.  The number of addresses
         present in the DSR
   header Address[1..n] field is used to indicate the type of protocol header (such as a
   transport layer header) following indicated by the DSR header.

   If any headers follow
         Opt Data Len field in the option (n = (Opt Data Len - 2) / 4).

   When forwarding a packet along a DSR header in source route using a packet, the total length
   of the DSR header (and thus Source
   Route option in the total, combined length of all packet's DSR
   options present) MUST be a multiple of 4 octets.  This requirement
   preserves Options header, the alignment of these following headers Destination
   Address field in the packet.

5.1. Fixed Portion of DSR Header

   The fixed portion of the DSR packet's IP header is used always set to carry information that
   must be present in any DSR header.  This fixed portion the address
   of the packet's ultimate destination.  A node receiving a packet
   containing a DSR
   header has the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  |    Reserved   |        Payload Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   . Options                            .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Next Header

         8-bit selector.  Identifies the type of header immediately
         following with a DSR Source Route option MUST
   examine the DSR header.  Uses indicated source route to determine if it is the same values as intended
   next-hop node for the IPv4
         Protocol field [29].

      Reserved

         MUST be sent packet and determine how to forward the packet,
   as 0 defined in Sections 8.1.4 and ignored on reception.

      Payload Length 8.1.5.

6.8. Pad1 Option

   The length of the Pad1 option in a DSR header, excluding Options header is encoded as follows:

   +-+-+-+-+-+-+-+-+
   |  Option Type  |
   +-+-+-+-+-+-+-+-+

      Option Type

         224.  Nodes not understanding this option will drop the 4-octet fixed
         portion.  The value of packet
         and return a Route Error.

   A Pad1 option MAY be included in the Payload Length Options field defines the
         total length of all options carried a DSR Options
   header in the order to align subsequent DSR options, but such alignment
   is not required and MUST NOT be expected by a node receiving a packet
   containing a DSR Options header.

   If any headers follow the DSR Options

         Variable-length field; header in a packet, the total
   length of the a DSR Options field is
         specified header, indicated by the Payload Length field
   in this the DSR header.
         Contains one or more pieces Options header MUST be a multiple of optional information (DSR
         options), encoded 4 octets.  In this
   case, when building a DSR Options header in type-length-value (TLV) format (with the
         exception of the a packet, sufficient Pad1 option, described in Section 5.8).

   The placement of DSR
   or PadN options following MUST be included in the fixed portion Options field of the DSR
   Options header MAY be padded for alignment.  However, due to make the typically
   limited available wireless bandwidth in ad hoc networks, this padding
   is not required, and receiving nodes MUST NOT expect options within total length a
   DSR header to be aligned.

   The following types multiple of 4 octets.

   If more than one consecutive octet of DSR options are defined padding is being inserted in this document for
   use within
   the Options field of a DSR header:

    -  Route Request option (Section 5.2)

    -  Route Reply option (Section 5.3)

    -  Route Error option (Section 5.4)

    -  Acknowledgment Request option (Section 5.5)

    -  Acknowledgment option (Section 5.6)

    -  DSR Source Route option (Section 5.7)

    - Options header, the PadN option, described
   next, SHOULD be used, rather than multiple Pad1 options.

   Note that the format of the Pad1 option (Section 5.8)

    - is a special case; it does
   not have an Opt Data Len or Option Data field.

6.9. PadN option (Section 5.9)

5.2. Route Request Option

   The Route Request PadN option in a DSR Options header is encoded as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
   |  Option Type  |  Opt Data Len |         Identification        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Target Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Address[1]                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Address[2]                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Address[n]                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IP fields:

      Source Address

         MUST be set to the address of the node originating this packet.
         Intermediate nodes that retransmit the packet to propagate the
         Route Request MUST NOT change this field.

      Destination Address

         MUST be set to the IP limited broadcast address
         (255.255.255.255).

      Hop Limit (TTL)

         MAY be varied from 1 to 255, for example to implement
         non-propagating Route Requests and Route Request expanding-ring
         searches (Section 3.3.4).

   Route Request fields:   Option Data
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -

      Option Type

         2

         0.  Nodes not understanding this option will ignore this
         option.

      Opt Data Len

         8-bit unsigned integer.  Length of the option, in octets,
         excluding the Option Type and Opt Data Len fields.

      Identification

      Option Data

         A unique value generated by the initiator (original sender) number of zero-valued octets equal to the Route Request.  Nodes initiating Opt Data Len.

   A PadN option MAY be included in the Options field of a Route Request generate DSR Options
   header in order to align subsequent DSR options, but such alignment
   is not required and MUST NOT be expected by a new Identification value for each Route Request, for example
         based on node receiving a sequence number counter packet
   containing a DSR Options header.

   If any headers follow the DSR Options header in a packet, the total
   length of all Route Requests
         initiated a DSR Options header, indicated by the node.

         This value allows a receiving node to determine whether it
         has recently seen Payload Length field
   in the DSR Options header MUST be a copy multiple of 4 octets.  In this Route Request:  if this
         Identification value is found by this receiving node
   case, when building a DSR Options header in a packet, sufficient Pad1
   or PadN options MUST be included in its
         Route Request Table (in the cache Options field of Identification values
         in the entry there DSR
   Options header to make the total length a multiple of 4 octets.

7. Additional Header Formats and Options for this initiating node), this receiving
         node MUST discard Flow State Extension

   The optional DSR flow state extension requires a new header type, the
   DSR Flow State header.

   In addition, the DSR flow state extension adds the following options
   for the DSR Options header defined in Section 6:

    -  Timeout option

    -  Destination and Flow ID option

   Two new Error Type values are also defined for use in the Route Request.  When propagating Error
   option in a Route
         Request, this field MUST be copied from the received copy of DSR Options header:

    -  Unknown Flow

    -  Default Flow Unknown

   Finally, an extension to the Route Acknowledgement Request being propagated.

      Target option in a DSR
   Options header is also defined:

    -  Previous Hop Address

         The address

   This section defines each of these new header or option formats.

7.1. DSR Flow State Header

   The DSR Flow State header is a small 4-byte header optionally used
   to carry the node that flow ID and hop count for a packet being sent along a
   DSR flow.  It is distinguished from the target of fixed DSR Options header
   (Section 6.1) in that the Route
         Request.

      Address[1..n]

         Address[i] Flow State Header (F) bit is set in the address DSR
   Flow State header and is clear in the fixed DSR Options header.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  |F|  Hop Count  |        Flow Identifier        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Next Header

         8-bit selector.  Identifies the type of header immediately
         following the i-th node recorded in DSR Flow State header.  Uses the
         Route Request option. same values as
         the IPv4 Protocol field [32].

      Flow State Header (F)

         Flag bit.  MUST be set to 1.  This bit is set in a DSR Flow
         State header and clear in a DSR Options header (Section 6.1).

      Hop Count

         7-bit unsigned integer.  The address given number of hops through which this
         packet has been forwarded.

      Flow Identification

         The flow ID for this flow, as described in Section 3.5.1.

7.2. Options and Extensions in the Source Address
         field DSR Options Header

7.2.1. Timeout Option

   The Timeout option is defined for use in the IP a DSR Options header is to
   indicate the address amount of time before the initiator expiration of the Route Discovery and MUST NOT be listed in the Address[i]
         fields; flow ID
   along which the address given in Address[1] packet is thus being sent.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Option Type  | Option Length |            Timeout            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Option Type

         128.  Nodes not understanding this option will ignore the address
         option and return a Route Error.

      Opt Data Len

         8-bit unsigned integer.  Length of the first node on the path after the initiator.  The
         number of addresses present option, in this field is indicated by octets,
         excluding the Option Type and Opt Data Len field in fields.

         When no extensions are present, the option (n = (Opt Opt Data Len - 6) / 4).
         Each node propagating the Route Request adds its own address of a Timeout
         option is 2.  Further extensions to
         this list, increasing the DSR may include additional
         data in a Timeout option.  The presence of such extensions is
         indicated by an Opt Data Len value by 4 octets. greater than 2.  Currently, no
         such extensions have been defined.

      Timeout

         The Route Request number of seconds for which this flow remains valid.

   The Timeout option MUST NOT appear more than once within a DSR
   Options header.

5.3. Route Reply

7.2.2. Destination and Flow ID Option

   The Route Reply Destination and Flow ID option is defined for use in a DSR
   Options header is encoded as follows: to send a packet to an intermediate host along one
   flow, for eventual forwarding to the final destination along a
   different flow.  This option enables the aggregation of the state of
   multiple flows.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Option Type  |  Opt Data Len |L|   Reserved  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Address[1]                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Address[2]                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Length |                              ...      New Flow Identifier      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Address[n]                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                   New IP fields:

      Source Address

         Set to the address of the node sending the Route Reply.
         In the case of a node sending a reply from its Route
         Cache (Section 3.3.2) or sending a gratuitous Route Reply
         (Section 3.4.3), this address can differ from the address that
         was the target of the Route Discovery. Destination Address

         MUST be set to the address of the source node of the route
         being returned.  Copied from the Source Address field of the
         Route Request generating the Route Reply, or in                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Option Type

         129.  Nodes not understanding this option will ignore the case of
         option and return a
         gratuitous Route Reply, copied from the Source Address field of
         the data packet triggering the gratuitous Reply. Route Reply fields:

      Option Type

         3 Error.

      Opt Data Len

         8-bit unsigned integer.  Length of the option, in octets,
         excluding the Option Type and Opt Data Len fields.

      Last Hop External (L)

         Set to indicate that the last hop given by

         When no extensions are present, the Route Reply
         (the link from Address[n-1] Opt Data Len of a
         Destination and Flow ID option is 6.  Further extensions to Address[n])
         DSR may include additional data in a Destination and Flow ID
         option.  The presence of such extensions is actually indicated by an
         arbitrary path
         Opt Data Len greater than 6.  Currently, no such extensions
         have been defined.

      New Flow Identifier

         Indicates the next identifier to store in a network external the Flow ID field of
         the DSR Options header.

      New IP Destination Address

         Indicates the next address to store in the DSR network; the
         exact route outside Destination Address
         field of the IP header.

   The Destination and Flow ID option MAY appear one or more times
   within a DSR network Options header.

7.2.3. New Error Type Value for Unknown Flow

   A new Error Type value of 129 (Unknown Flow) is not represented in the
         Route Reply.  Nodes caching this hop defined for use in their
   a Route Cache MUST
         flag the cached hop with the External flag.  Such hops MUST NOT
         be returned Error option in a cached Route Reply generated from DSR Options header.  The Type-Specific
   Information for errors of this Route
         Cache entry, and selection type is encoded as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Original IP Destination Address                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Flow ID            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Original IP Destination Address

         The IP Destination Address of routes from the Route Cache to
         route a packet being sent MUST prefer routes that contain no
         hops flagged as External.

      Reserved

         MUST be sent as 0 and ignored on reception.

      Address[1..n] caused the error.

      Flow ID

         The source route being returned by Flow ID contained in the DSR Flow ID option that caused the
         error.

7.2.4. New Error Type Value for Default Flow Unknown

   A new Error Type value of 130 (Default Flow Unknown) is defined
   for use in a Route Reply.  The route
         indicates Error option in a sequence DSR Options header.  The
   Type-Specific Information for errors of hops, originating at the source node
         specified in the this type is encoded as
   follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Original IP Destination Address field of the                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Original IP header Destination Address

         The IP Destination Address of the packet carrying the Route Reply, through each of the
         Address[i] nodes in the order listed in that caused the Route Reply,
         ending with error.

7.2.5. Acknowledgement Request Option Previous Hop Address Extension

   When the destination node indicated by Address[n].
         The number Option Length field of addresses present an Acknowledgement Request option
   in the Address[1..n]
         field a DSR Options header is indicated by the Opt Data Len field in the option
         (n = (Opt Data Len - 1) / 4).

   A Route Reply option MAY appear one greater than or more times within equal to 6, a DSR
   header.

5.4. Route Error Option Previous
   Hop Address Extension is present.  The Route Error option in a DSR header is encoded then formatted as
   follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Option Type  |  Opt Data Len Option Length |       Packet Identifier       |   Error Type  |Reservd|Salvage|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Error                   ACK Request Source Address                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Option Type

         5

      Option Length

         8-bit unsigned integer.  Length of the option, in octets,
         excluding the Option Type and Option Length fields.

         When no extensions are presents, the Option Length of a
         Acknowledgement Request option is 2.  Further extensions to
         DSR may include additional data in a Acknowledgement Request
         option.  The presence of such extensions is indicated by an
         Opt Data Len greater than 2.

         Currently, one such extension has been defined.  If the
         Option Length is at least 6, then a ACK Request Source Address
         is present.

      Packet Identifier

         The Packet Identifier field is set to a unique number and is
         copied into the Identification field of the DSR Acknowledgement
         option when returned by the node receiving the packet over this
         hop.

      ACK Request Source Address                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Error Destination Address                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                   Type-Specific Information                   .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Option Type

         4

      Opt Data Len

         8-bit unsigned integer.  Length

         The address of the option, in octets,
         excluding node requesting the Option Type and Opt Data Len fields.

         For DSR Acknowledgement.

8. Detailed Operation

8.1. General Packet Processing

8.1.1. Originating a Packet

   When originating any packet, a node using DSR routing MUST perform
   the current definition following sequence of steps:

    -  Search the node's Route Error option,
         this field MUST be set Cache for a route to 10, plus the size of any
         Type-Specific Information present address given in
       the IP Destination Address field in the packet's header.

    -  If no such route is found in the Route Error.  Further
         extensions to Cache, then perform
       Route Discovery for the Destination Address, as described in
       Section 8.2.  Initiating a Route Error Discovery for this target node
       address results in the node adding a Route Request option format may also be
         included after in
       a DSR Options header in this existing packet, or saving this
       existing packet to its Send Buffer and initiating the Type-Specific Information portion of Route
       Discovery by sending a separate packet containing such a Route
       Request option.  If the node chooses to initiate the Route Error
       Discovery by adding the Route Request option specified above.  The presence of such
         extensions to this existing
       packet, it will be indicated by replace the Opt Data Len field.
         When IP Destination Address field with the
       IP "limited broadcast" address (255.255.255.255) [3], copying the Opt Data Len is greater than that required for
       original IP Destination Address to the fixed portion Target Address field of
       the new Route Error plus Request option added to the necessary
         Type-Specific Information packet, as indicated by the Option Type
         value described in
       Section 8.2.1.

    -  If the packet now does not contain a Route Request option, the remaining octets are interpreted as
         extensions.  Currently, no such further extensions
       then this node must have been
         defined.

      Error Type

         The type of error encountered.  Currently, a route to the following type
         value is defined:

             1 = NODE_UNREACHABLE

         Other values Destination Address
       of the Error Type field are reserved for future
         use.

      Reservd

         Reserved.  MUST be sent as 0 and ignored on reception.

      Salvage

         A 4-bit unsigned integer.  Copied from the Salvage field in packet; if the DSR Source Route option of node has more than one route to this
       Destination Address, the packet triggering node selects one to use for this packet.
       If the Route
         Error.

         The "total salvage count" length of the Route Error option this route is derived greater than 1 hop, or if the
       node determines to request a DSR network-layer acknowledgement
       from the value first-hop node in that route, then insert a DSR Options
       header into the Salvage field of this Route Error option packet, as described in Section 8.1.2, and all preceding insert
       a DSR Source Route Error options option, as described in Section 8.1.3.  The
       source route in the packet as follows:
         the total salvage count is initialized from the sum of, for each such Route
         Error option, one plus the value in selected route
       to the Salvage field of that
         Route Error option.

      Error Source Destination Address

         The address of the node originating packet.

    -  Transmit the Route Error (e.g., packet to the first-hop node that attempted address given in
       selected source route, using Route Maintenance to forward a packet and discovered determine the link
         failure).

      Error Destination Address

         The address
       reachability of the next hop, as described in Section 8.3.

8.1.2. Adding a DSR Options Header to a Packet

   A node originating a packet adds a DSR Options header to which the Route Error must be
         delivered For example, when packet,
   if necessary, to carry information needed by the Error Type field routing protocol.
   A packet MUST NOT contain more than one DSR Options header.  A DSR
   Options header is set to
         NODE_UNREACHABLE, this field will be set added to a packet by performing the address following
   sequence of the
         node steps (these steps assume that generated the routing information claiming packet contains no
   other headers that the
         hop from the Error Source Address to Unreachable Node Address
         (specified MUST be located in the Type-Specific Information) was packet before the DSR
   Options header):

    -  Insert a valid hop.

      Type-Specific Information

         Information specific to DSR Options header after the Error Type of this Route Error
         message.

   Currently, IP header but before any
       other header that may be present.

    -  Set the Type-Specific Information Next Header field is defined only for
   Route Error messages of type NODE_UNREACHABLE.  In this case, the
   Type-Specific Information DSR Options header to the
       Protocol number field is defined as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Unreachable Node Address                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      Unreachable Node Address

         The address of the packet's IP header.

    -  Set the Protocol field of the packet's IP header to the Protocol
       number assigned for a DSR Options header (TBA???).

8.1.3. Adding a DSR Source Route Option to a Packet

   A node that was found originating a packet adds a DSR Source Route option to be unreachable
         (the next-hop neighbor the
   packet, if necessary, in order to which carry the source route from this
   originating node with to the final destination address
         Error of the packet.
   Specifically, the node adding the DSR Source Address was attempting to transmit Route option constructs
   the packet).

   A DSR Source Route Error option MAY appear one or more times within and modifies the IP packet according to
   the following sequence of steps:

    -  The node creates a DSR
   header.

5.5. Acknowledgment Request Option

   The Acknowledgment Request option Source Route option, as described
       in a Section 6.7, and appends it to the DSR Options header in
       the packet.  (A DSR Options header is encoded added, as
   follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Option Type  |  Opt Data Len |         Identification        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Option Type

         5

      Opt Data Len

         8-bit unsigned integer.  Length described in
       Section 8.1.2, if not already present.)

    -  The number of Address[i] fields to include in the option, DSR Source
       Route option (n) is the number of intermediate nodes in octets, the
       source route for the packet (i.e., excluding address of the Option Type
       originating node and Opt Data Len fields.

      Identification the final destination address of the
       packet).  The Identification Segments Left field in the DSR Source Route option
       is set initialized equal to a unique value and is n.

    -  The addresses within the source route for the packet are copied
       into sequential Address[i] fields in the Identification field of DSR Source Route option,
       for i = 1, 2, ..., n.

    -  The First Hop External (F) bit in the Acknowledgment DSR Source Route option when
         returned by is
       copied from the node receiving External bit flagging the packet over this hop.

   An Acknowledgment Request option MUST NOT appear more than once
   within a DSR header.

5.6. Acknowledgment Option first hop in the source
       route for the packet, as indicated in the Route Cache.

    -  The Acknowledgment option Last Hop External (L) bit in a the DSR header Source Route option is encoded
       copied from the External bit flagging the last hop in the source
       route for the packet, as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Option Type  |  Opt Data Len |         Identification        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       ACK indicated in the Route Cache.

    -  The Salvage field in the DSR Source Address                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     ACK Destination Address                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Option Type

         6

      Opt Data Len

         8-bit unsigned integer.  Length Route option is
       initialized to 0.

8.1.4. Processing a Received Packet

   When a node receives any packet (whether for forwarding, overheard,
   or as the final destination of the packet), if that packet contains
   a DSR Options header, then that node MUST process any options
   contained in that DSR Options header, in the order contained there.
   Specifically:

    -  If the DSR Options header contains a Route Request option, in octets,
         excluding the Option Type and Opt Data Len fields.

      Identification

         Copied from
       node SHOULD extract the Identification field of source route from the Acknowledgment Route Request option of and
       add this routing information to its Route Cache, subject to the packet being acknowledged.

      ACK Source Address
       conditions identified in Section 3.3.1.  The address of routing information
       from the node originating Route Request is the acknowledgment.

      ACK Destination Address

         The address sequence of hop addresses

          initiator, Address[1], Address[2], ..., Address[n]

       where initiator is the node to which value of the acknowledgment is to be
         delivered.

   An Acknowledgment option MAY appear one or more times within a DSR
   header.

5.7. DSR Source Route Option

   The DSR Source Route option Address field in a DSR
       the IP header is encoded as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Option Type  |  Opt Data Len |F|L|Reservd|Salvage| Segs Left |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Address[1]                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Address[2]                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Address[n]                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Option Type

         7

      Opt Data Len

         8-bit unsigned integer.  Length of the option, in octets,
         excluding packet carrying the Option Type and Opt Data Len fields.  For Route Request (the
       address of the
         format initiator of the DSR Source Route option defined here, Discovery), and each
       Address[i] is a node through which this field
         MUST be set to the Route Request has passed,
       in turn, during this Route Discovery.  The value (n * 4) + 2, where n here is the
       number of addresses present recorded in the Address[i] fields.

      First Hop External (F)

         Set Route Request option, or
       (Opt Data Len - 6) / 4.

       After possibly updating the node's Route Cache in response to indicate that
       the first hop indicated by routing information in the Route Request option, the node
       MUST then process the DSR
         Source Route Request option is actually an arbitrary path as described in a network
         external to
       Section 8.2.2.

    -  If the DSR network; Options header contains a Route Reply option, the exact route outside node
       SHOULD extract the DSR
         network is not represented in source route from the DSR Source Route option.
         Nodes caching Reply and add this hop
       routing information to its Route Cache, subject to the conditions
       identified in their Section 3.3.1.  The source route from the Route Cache MUST flag
       Reply is the
         cached sequence of hop with addresses

          initiator, Address[1], Address[2], ..., Address[n]

       where initiator is the External flag.  Such hops MUST NOT be
         returned value of the Destination Address field in a
       the IP header of the packet carrying the Route Reply generated from this Route Cache
         entry, and selection (the address
       of the initiator of routes from the Route Cache to route Discovery), and each Address[i]
       is a packet being sent MUST prefer routes that contain no hops
         flagged as External.

      Last Hop External (L)

         Set node through which the source route passes, in turn, on
       the route to indicate that the last hop indicated by target of the DSR Source Route option Discovery.  Address[n] is actually an arbitrary path in a network
         external to
       the DSR network; address of the exact route outside target.  If the DSR
         network Last Hop External (L) bit is not represented
       set in the DSR Source Route option.
         Nodes caching this hop in their Route Cache Reply, the node MUST flag the
         cached last hop with from
       the External flag.  Such hops MUST NOT be
         returned in a Route Reply generated (the link from this Address[n-1] to Address[n]) in
       its Route Cache
         entry, and selection as External.  The value n here is the number of routes from
       addresses in the source route being returned in the Route Reply
       option, or (Opt Data Len - 1) / 4.

       After possibly updating the node's Route Cache in response to route
         a packet being sent MUST prefer routes that contain no hops
         flagged as External.

      Reserved

         MUST be sent as 0 and ignored on reception.

      Salvage

         A 4-bit unsigned integer.  Count of number
       the routing information in the Route Reply option, then if the
       packet's IP Destination Address matches one of times that this packet has been salvaged node's IP
       addresses, the node MUST then process the Route Reply option as a part of
       described in Section 8.2.5.

    -  If the DSR routing
         (Section 3.4.1).

      Segments Left (Segs Left)

         Number of route segments remaining, i.e., number of explicitly
         listed intermediate nodes still to be visited before reaching Options header contains a Route Error option,
       the final destination.

      Address[1..n]

         The sequence of addresses of node MUST process the source route.  In routing
         and forwarding Route Error option as described in
       Section 8.3.5.

    -  If the packet, DSR Options header contains an Acknowledgement Request
       option, the source route is processed node MUST process the Acknowledgement Request option
       as described in Sections 6.1.3 and 6.1.5.  The number of addresses
         present Section 8.3.3.

    -  If the DSR Options header contains an Acknowledgement option,
       then subject to the conditions identified in Section 3.3.1, the Address[1..n] field is indicated by
       node SHOULD add to its Route Cache the
         Opt Data Len field in single link from the option (n = (Opt Data Len - 2) / 4).

   When forwarding a packet along a DSR source route using a DSR node
       identified by the ACK Source
   Route option in Address field to the packet's DSR header, node identified
       by the ACK Destination Address
   field in field.

       After possibly updating the packet's IP header is always set node's Route Cache in response to
       the address of routing information in the Acknowledgement option, the
   packet's ultimate destination.  A node receiving a packet containing
   a
       MUST then process the Acknowledgement option as described in
       Section 8.3.3.

    -  If the DSR Options header with contains a DSR Source Route option MUST examine option, the
       node SHOULD extract the
   indicated source route to determine if it is the intended next-hop
   node for from the packet DSR Source Route
       and determine how add this routing information to its Route Cache, subject to forward
       the packet, as
   defined conditions identified in Sections 6.1.4 and 6.1.5.

5.8. Pad1 Option

   The Pad1 option Section 3.3.1.  If the value of the
       Salvage field in a the DSR header is encoded as follows:

   +-+-+-+-+-+-+-+-+
   |  Option Type  |
   +-+-+-+-+-+-+-+-+

      Option Type

         0

   A Pad1 Source Route option MAY be included in is zero, then the
       routing information from the Options field of a DSR header
   in order to align subsequent DSR options, but such alignment Source Route is
   not required the sequence of
       hop addresses

          source, Address[1], Address[2], ..., Address[n], destination

       and MUST NOT be expected by a node receiving a packet
   containing a otherwise (Salvage is nonzero), the routing information from
       the DSR header.

   If any headers follow Source Route is the DSR header in a packet, sequence of hop addresses

          Address[1], Address[2], ..., Address[n], destination

       where source is the total length value of
   a DSR header, indicated by the Payload Length Source Address field in the DSR IP
       header
   MUST be a multiple of 4 octets.  In this case, when building a DSR
   header in a packet, sufficient Pad1 or PadN options MUST be included
   in the Options field of packet carrying the DSR header to make the total length a
   multiple of 4 octets.

   If more than one consecutive octet Source Route option (the
       original sender of padding the packet), each Address[i] is being inserted the value in
       the Options Address[i] field of a in the DSR header, Source Route, and destination is
       the PadN option, described next,
   SHOULD be used, rather than multiple Pad1 options.

   Note that value of the format Destination Address field in the packet's IP
       header (the last-hop address of the Pad1 option is a special case; it does
   not have an Opt Data Len or Option Data field.

5.9. PadN Option source route).  The PadN option value n
       here is the number of addresses in a source route in the DSR header is encoded as follows:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
   |  Option Type  |  Opt Source
       Route option, or (Opt Data Len |   Option Data
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -

      Option Type

         1

      Opt Data Len

         8-bit unsigned integer.  Length of 2) / 4.

       After possibly updating the option, node's Route Cache in octets,
         excluding the Option Type and Opt Data Len fields.

      Option Data

         A number of zero-valued octets equal response to
       the Opt Data Len.

   A PadN routing information in the DSR Source Route option, the node
       MUST then process the DSR Source Route option MAY be included as described in
       Section 8.1.5.

    -  Any Pad1 or PadN options in the DSR Options field header are ignored.

   Finally, if the Destination Address in the packet's IP header matches
   one of a this receiving node's own IP address(es), remove the DSR
   Options header and all the included DSR options in order the header, and
   pass the rest of the packet to align subsequent the network layer.

8.1.5. Processing a Received DSR options, but such alignment is
   not required and MUST NOT be expected by Source Route Option

   When a node receiving receives a packet containing a DSR header.

   If any headers follow the DSR header in a packet, Source Route option
   (whether for forwarding, overheard, or as the total length final destination of
   a DSR header, indicated by
   the Payload Length field in packet), that node SHOULD examine the DSR header
   MUST be a multiple packet to determine if
   the receipt of 4 octets.  In this case, when building a DSR
   header that packet indicates an opportunity for automatic
   route shortening, as described in a packet, sufficient Pad1 or PadN options MUST be included Section 3.4.3.  Specifically, if
   this node is not the intended next-hop destination for the packet
   but is named in the Options field later unexpended portion of the source route in
   the packet's DSR header to make Source Route option, then this packet indicates an
   opportunity for automatic route shortening:  the total length a
   multiple of 4 octets.

6. Detailed Operation

6.1. General Packet Processing

6.1.1. Originating a Packet

   When originating any packet, a intermediate nodes
   after the node from which this node overheard the packet and before
   this node using DSR routing MUST itself, are no longer necessary in the source route.  In
   this case, this node SHOULD perform the following sequence of steps: steps
   as part of automatic route shortening:

    -  Search the node's  The node searches its Gratuitous Route Cache Reply Table for an entry
       describing a route to gratuitous Route Reply earlier sent by this node,
       for which the address given in original sender of the IP Destination Address field packet triggering the
       gratuitous Route Reply and the transmitting node from which this
       node overheard that packet in order to trigger the packet's header.

    - gratuitous
       Route Reply, both match the respective node addresses for this
       new received packet.  If no such route an entry is found in the node's
       Gratuitous Route Cache, then Reply Table, the node SHOULD NOT perform
       automatic route shortening in response to this receipt of this
       packet.

    -  Otherwise, the node creates an entry for this overheard packet in
       its Gratuitous Route Discovery Reply Table.  The timeout value for this new
       entry SHOULD be initialized to the Destination Address, value GratReplyHoldoff.  After
       this timeout has expired, the node SHOULD delete this entry from
       its Gratuitous Route Reply Table.

    -  After creating the new Gratuitous Route Reply Table entry
       above, the node originates a gratuitous Route Reply to the
       IP Source Address of this overheard packet, as described in
       Section 6.2.  Initiating a Route Discovery for 3.4.3.

       If the MAC protocol in use in the network is not capable of
       transmitting unicast packets over unidirectional links, as
       discussed in Section 3.3.1, then in originating this target Route Reply,
       the node
       address results in MUST use a source route for routing the Route Reply
       packet that is obtained by reversing the node adding a sequence of hops over
       which the packet triggering the gratuitous Route Request option in
       a DSR header Reply was routed
       in reaching and being overheard by this existing packet, or saving node; this existing
       packet reversing of
       the route uses the gratuitous Route Reply to its Send Buffer and initiating test this sequence
       of hops for bidirectionality, preventing the gratuitous Route Discovery
       Reply from being received by sending a separate packet containing such a Route Request
       option.  If the node chooses to initiate initiator of the Route Discovery
       by adding
       unless each of the hops over which the gratuitous Route Request option to this existing packet,
       it will replace Reply is
       returned is bidirectional.

    -  Discard the IP Destination Address field with overheard packet, since the IP
       "limited broadcast" address (255.255.255.255) [3], copying packet has been received
       before its normal traversal of the
       original IP Destination Address packet's source route would
       have caused it to reach this receiving node.  Another copy of
       the Target Address field packet will normally arrive at this node as indicated in
       the packet's source route; discarding this initial copy of the new
       packet, which triggered the gratuitous Route Request option added to Reply, will prevent
       the packet, as described in
       Section 6.2.1.

    - duplication of this packet that would otherwise occur.

   If the packet now does is not contain a Route Request option, discarded as part of automatic route shortening
   above, then this the node must have a route MUST process the option according to the Destination Address
   following sequence of steps:

    -  If the value of the packet; if Segments Left field in the DSR Source Route
       option equals 0, then remove the DSR Source Route option from the
       DSR Options header.

    -  Else, let n equal (Opt Data Len - 2) / 4.  This is the node has more than one route to this
       Destination Address, number of
       addresses in the node selects one to use for this packet. DSR Source Route option.

    -  If the length value of this route the Segments Left field is greater than 1 hop, or if the
       node determines n, then
       send an ICMP Parameter Problem, Code 0, message [29] to request a DSR network-layer acknowledgment
       from the first-hop node in that route, then insert a DSR header
       into IP
       Source Address, pointing to the packet, as described in Section 6.1.2, Segments Left field, and insert a discard
       the packet.  Do not process the DSR Source Route option, as described in Section 6.1.3.  The source
       route in option further.

    -  Else, decrement the packet value of the Segments Left field by 1.  Let i
       equal n minus Segments Left.  This is initialized from the selected route index of the next
       address to be visited in the Address vector.

    -  If Address[i] or the IP Destination Address of is a multicast
       address, then discard the packet.

    -  Transmit the packet to  Do not process the first-hop node address given in
       selected source route, using DSR Source
       Route Maintenance to determine option further.

    -  If the
       reachability MTU of the next hop, as described in Section 6.3.

6.1.2. Adding a DSR Header to a Packet

   A link over which this node originating a would transmit
       the packet adds a DSR header to the packet, if
   necessary, forward it to carry information needed by the routing protocol.  A
   packet MUST NOT contain more than one DSR header.  A DSR header is
   added to a packet by performing node Address[i] is less than
       the following sequence size of steps
   (these steps assume that the packet contains no other headers that packet, the node MUST be located in either discard the
       packet before the DSR header):

    -  Insert a DSR header after and send an ICMP Packet Too Big message to the IP header but before any other
       header that may be present. packet's
       Source Address [29] or fragment it as specified in Section 8.5.

    -  Set the Next Header field of  Forward the DSR header packet to the Protocol
       number IP address specified in the Address[i]
       field of the packet's IP header.

    -  Set header, following normal IP forwarding
       procedures, including checking and decrementing the Protocol Time-to-Live
       (TTL) field of in the packet's IP header to [30, 3].  In this
       forwarding of the Protocol
       number assigned for a DSR header (TBA???).

6.1.3. Adding packet, the next-hop node (identified by
       Address[i]) MUST be treated as a DSR Source Route Option direct neighbor node:  the
       transmission to a Packet

   A that next node originating a packet adds MUST be done in a DSR Source single IP
       forwarding hop, without Route option to Discovery and without searching the
   packet, if necessary, in order to carry
       Route Cache.

    -  In forwarding the source route from this
   originating node to packet, perform Route Maintenance for the final destination address
       next hop of the packet.
   Specifically, packet, by verifying that the next-hop node adding the DSR Source Route option constructs
   the is
       reachable, as described in Section 8.3.

   Multicast addresses MUST NOT appear in a DSR Source Route option and modifies or
   in the IP packet according to
   the following sequence Destination Address field of steps:

    -  The node creates a packet carrying a DSR Source
   Route option, as described option in a DSR Options header.

8.1.6. Handling an Unknown DSR Option

   Nodes implementing DSR MUST handle all options specified in
       Section 5.7, and appends it this
   document, except those options pertaining to the optional flow
   state extension (Section 7).  However, further extensions to
   DSR header in may include other option types that may not be understood by
   implementations conforming to this version of the packet.
       (A DSR header is added, as described in Section 6.1.2, if specification.
   In DSR, Option Type codes encode required behavior for nodes not
       already present.)

    -  The number
   implementing that type of Address[i] fields to include option.  These behaviors are included in
   the DSR Source
       Route option (n) is the number most significant three bits of intermediate nodes in the
       source route for Option Type.

   If the packet (i.e., excluding address most significant bit of the
       originating node Option Type is set (that is,
   Option Type & 0x80 is nonzero), and this packet does not contain
   a Route Request option, a node SHOULD return a Route Error to the final destination address of
   IP Source Address, following the
       packet).  The Segments Left field steps described in Section 8.3.4,
   except that the DSR Source Route option
       is initialized equal Error Type MUST be set to n.

    -  The addresses within OPTION_NOT_SUPPORTED and
   the source route for Unsupported Opt field MUST be set to the packet are copied
       into sequential Address[i] fields in Option Type triggering
   the DSR Source Route option,
       for i = 1, 2, ..., n.

    -  The First Hop External (F) bit in the DSR Source Error.

   Whether or not a Route option Error is
       copied from the External bit flagging the first hop sent in response to this DSR option,
   as described above, the source
       route node also MUST examine the next two most
   significant bits (that is, Option Type & 0x60):

    -  When these two bits are zero (that is, Option Type & 0x60 == 0),
       a node not implementing processing for that Option Type MUST
       use the packet, as indicated in Opt Data Len field to skip over the Route Cache. option and continue
       processing.

    -  The Last Hop External (L) bit in  When these two 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 DSR Source Route option is
       copied from the External bit flagging packet and
       continue processing as if the last hop option had not been included in the source
       route
       received packet.

    -  When these two bits are 10 (that is, Option Type & 0x60 == 0x40),
       a node not implementing processing for that Option Type MUST set
       the packet, as indicated in most significant bit following the Route Cache.

    -  The Salvage field Opt Data Len field; in
       addition, the DSR Source Route option is
       initialized to 0.

6.1.4. Processing a Received Packet

   When a node receives any packet (whether for forwarding, overheard,
   or as MUST then ignore the final destination contents of the packet), if that packet contains a
   DSR header, then that node option
       using the Opt Data Len field, and MUST process any options contained in that
   DSR header, in continue processing the order contained there.  Specifically:
       packet.

    -  If the DSR header contains  Finally, when these two bits are 11 (that is,
       Option Type & 0x60 == 0x60), a Route Request option, the node
       SHOULD extract the source route from not implementing processing
       for that Option Type MUST drop the packet.

8.2. Route Request and add
       this routing information Discovery Processing

   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 its D.  Route Cache, subject
   Discovery is used only when S attempts to the
       conditions identified in Section 3.3.1. send a packet to D and
   does not already know a route to D.  The routing information
       from the node initiating a Route Request is the sequence of hop addresses

          initiator, Address[1], Address[2], ..., Address[n]

       where initiator
   Discovery is known as the value "initiator" of the Source Address field in
       the IP header of Route Discovery, and the packet carrying
   destination node for which the Route Request (the
       address of Discovery is initiated is known
   as the initiator "target" of the Route Discovery), and each
       Address[i] is Discovery.

   Route Discovery operates entirely on demand, with a node through which this Route Request has passed,
       in turn, during this initiating
   Route Discovery.  The value n here is the
       number Discovery based on its own origination of addresses recorded in the new packets for
   some destination address to which it does not currently know a
   route.  Route Request option, Discovery does not depend on any periodic or
       (Opt Data Len - 6) / 4.

       After possibly updating the node's Route Cache in response to
       the background
   exchange of routing information in the Route Request option, the or neighbor node
       MUST then process the Route Request option as described detection at any
   layer in
       Section 6.2.2.

    -  If the DSR header contains a network protocol stack at any node.

   The Route Reply option, the node SHOULD
       extract the source route from the Discovery procedure utilizes two types of messages, a Route Reply
   Request (Section 6.2) and add this
       routing information to its Route Cache, subject to the conditions
       identified in Section 3.3.1.  The source route from the a Route Reply is the sequence of hop addresses

          initiator, Address[1], Address[2], ..., Address[n]

       where initiator is (Section 6.3), to actively
   search the value of ad hoc network for a route to the Destination Address field desired destination.
   These DSR messages MAY be carried in
       the any type of IP header packet, through
   use of the packet carrying the DSR Options header as described in Section 6.

   Except as discussed in Section 8.3.5, a Route Reply (the Discovery for a
   destination address
       of the initiator of SHOULD NOT be initiated unless the initiating
   node has a packet in its Send Buffer requiring delivery to that
   destination.  A Route Discovery), and each Address[i]
       is Discovery for a given target node through which MUST NOT be
   initiated unless permitted by the source route passes, rate-limiting information contained
   in turn, on the route to Route Request Table.  After each Route Discovery attempt, the
   interval between successive Route Discoveries for this target SHOULD
   be doubled, up to a maximum of the MaxRequestPeriod, until a valid Route Discovery.  Address[n]
   Reply is
       the address of the received for this target.  If the Last Hop External (L) bit is
       set in the

8.2.1. Originating a Route Reply, the Request

   A node MUST flag the last hop from
       the initiating a Route Reply (the link from Address[n-1] to Address[n]) in
       its Discovery for some target creates and
   initializes a Route Cache as External.  The value n here is the number of
       addresses Request option in the source route being returned a DSR Options header in the some
   IP packet.  This MAY be a separate IP packet, used only to carry
   this Route Reply Request option, or (Opt Data Len - 1) / 4.

       After possibly updating the node's node MAY include the Route Cache Request
   option in response some existing packet that it needs to send to the routing information in the Route Reply option, then if target
   node (e.g., the
       packet's IP Destination Address matches one of packet originated by this node's IP
       addresses, node, that caused the
   node MUST then process to attempt Route Discovery for the destination address of the
   packet).  The Route Reply Request option as
       described MUST be included in Section 6.2.5.

    -  If the a DSR Options
   header contains a Route Error option, in the node MUST
       process packet.  To initialize the Route Error option as described in Section 6.3.5.

    -  If the DSR header contains an Acknowledgment Request option, the
   node MUST process performs the Acknowledgment Request option as described
       in Section 6.3.3. following sequence of steps:

    -  If  The Option Type in the DSR header contains an Acknowledgment option, then subject option MUST be set to the conditions identified value 2.

    -  The Opt Data Len field in Section 3.3.1, the node SHOULD
       add option MUST be set to its Route Cache the single link from value 6.
       The total size of the node identified
       by Route Request option when initiated
       is 8 octets; the ACK Source Address Opt Data Len field to excludes the node identified by size of the
       ACK Destination Address field.

       After possibly updating
       Option Type and Opt Data Len fields themselves.

    -  The Identification field in the node's option MUST be set to a new
       value, different from that used for other Route Cache Requests recently
       initiated by this node for this same target address.  For
       example, each node MAY maintain a single counter value for
       generating a new Identification value for each Route Request it
       initiates.

    -  The Target Address field in response the option MUST be set to the routing information in IP
       address that is the Acknowledgment option, target of this Route Discovery.

   The Source Address in the node IP header of this packet MUST then process be the Acknowledgment option as described node's
   own IP address.  The Destination Address in
       Section 6.3.3.

    -  If the DSR IP header contains a DSR Source Route option, of this
   packet MUST be the IP "limited broadcast" address (255.255.255.255).

   A node
       SHOULD extract the source route from the DSR Source MUST maintain in its Route and
       add this routing Request Table, information to its about
   Route Cache, subject to the
       conditions identified in Section 3.3.1.  If the value of the
       Salvage field in the DSR Source Requests that it initiates.  When initiating a new Route option is zero, then
   Request, the node MUST use the
       routing information from recorded in the DSR Source Route is
   Request Table entry for the sequence target of
       hop addresses

          source, Address[1], Address[2], ..., Address[n], destination that Route Request, and otherwise (Salvage is nonzero), the routing it MUST
   update that information from
       the DSR Source Route is in the sequence of hop addresses

          Address[1], Address[2], ..., Address[n], destination

       where source is table entry for use in the value of next Route
   Request initiated for this target.  In particular:

    -  The Route Request Table entry for a target node records the Source Address
       Time-to-Live (TTL) field used in the IP header of the packet carrying the DSR Source Route option (the
       original sender of the packet), each Address[i] is
       Request for the last Route Discovery initiated by this node for
       that target node.  This value in
       the Address[i] field in allows the DSR Source Route, and destination is node to implement a
       variety of algorithms for controlling the value spread of its Route
       Request on each Route Discovery initiated for a target.  As
       examples, two possible algorithms for this use of the Destination Address TTL field
       are described in the packet's IP
       header (the last-hop address of the source route). Section 3.3.4.

    -  The value n
       here is Route Request Table entry for a target node records the
       number of addresses in source route in the DSR Source consecutive Route option, or (Opt Data Len - 2) / 4.

       After possibly updating the node's Requests initiated for this target
       since receiving a valid Route Cache in response Reply giving a route to that target
       node, and the routing information in the DSR Source remaining amount of time before which this node MAY
       next attempt at a Route option, the Discovery for that target node.

       A node MUST then process use these values to implement a back-off algorithm to
       limit the DSR Source rate at which this node initiates new Route option as described in
       Section 6.1.5.

    -  Any Pad1 or PadN options in the DSR header are ignored.

   Finally, if Discoveries
       for the Destination Address in same target address.  In particular, until a valid Route
       Reply is received for this target node address, the packet's IP header matches
   one of timeout
       between consecutive Route Discovery initiations for this receiving node's own IP address(es), remove target
       node with the same hop limit SHOULD increase by doubling the
       timeout value on each new initiation.

   The behavior of a node processing a packet containing DSR Options
   header and all the included with both a DSR options in the header, Source Route option and a Route Request option
   is unspecified.  Packets SHOULD NOT contain both a DSR Source Route
   option and pass the
   rest a Route Request option.

   Packets containing a Route Request option SHOULD NOT include
   an Acknowledgement Request option, SHOULD NOT expect link-layer
   acknowledgement or passive acknowledgement, and SHOULD NOT be
   retransmitted.  The retransmission of packets containing a Route
   Request option is controlled solely by the packet to the network layer.

6.1.5. logic described in this
   section.

8.2.2. Processing a Received DSR Source Route Request Option

   When a node receives a packet containing a DSR Source Route option
   (whether for forwarding, overheard, or as the final destination of
   the packet), Request option, that
   node SHOULD examine MUST process the packet option according to determine if
   the receipt of that packet indicates an opportunity for automatic
   route shortening, as described in Section 3.4.3.  Specifically, if
   this node is not the intended next-hop destination for the packet
   but is named in the later unexpended portion following sequence of
   steps:

    -  If the source route Target Address field in the packet's DSR Source Route option, then Request matches this packet indicates an
   opportunity for automatic route shortening:  the intermediate nodes
   after
       node's own IP address, then the node from which this node overheard SHOULD return a Route Reply
       to the packet and before initiator of this node itself, are no longer necessary Route Request (the Source Address in the
       IP header of the packet), as described in Section 8.2.4.  The
       source route.  In
   this case, route for this node SHOULD perform Reply is the following sequence of steps
   as part hop addresses

          initiator, Address[1], Address[2], ..., Address[n], target

       where initiator is the address of automatic route shortening:

    -  The node searches its Gratuitous the initiator of this
       Route Reply Table for Request, each Address[i] is an entry
       describing a gratuitous address from the Route Reply earlier sent by this node,
       for which
       Request, and target is the original sender target of the packet triggering Route Request (the
       Target Address field in the
       gratuitous Route Reply and Request).  The value n here
       is the transmitting node from which this
       node overheard that packet number of addresses recorded in order to trigger the gratuitous Route Reply, both match the respective Request, or
       (Opt Data Len - 6) / 4.

       The node addresses for this
       new received packet.  If such an entry is found then MUST replace the Destination Address field in
       the node's
       Gratuitous Route Reply Table, Request packet's IP header with the node SHOULD NOT perform
       automatic route shortening value in response to this receipt of this
       packet.

    -  Otherwise, the node creates an entry for this overheard packet
       Target Address field in
       its Gratuitous the Route Reply Table.  The timeout value for this new
       entry SHOULD be initialized to Request option, and continue
       processing the value GratReplyHoldoff.  After
       this timeout has expired, rest of the node SHOULD delete this entry from
       its Gratuitous Route Reply Table.

    -  After creating Request packet normally.  The
       node MUST NOT process the new Gratuitous Route Reply Table entry
       above, Request option further and MUST
       NOT retransmit the node originates a gratuitous Route Reply Request to propagate it to other nodes
       as part of the Route Discovery.

    -  Else, the node MUST examine the route recorded in the Route
       Request option (the IP Source Address field and the sequence of
       Address[i] fields) to determine if this overheard packet, as described node's own IP address
       already appears in
       Section 3.4.3. this list of addresses.  If so, the node MUST
       discard the entire packet carrying the Route Request option.

    -  Else, if the Route Request was received through a network
       interface that requires physically bidirectional links for
       unicast transmission, the MAC protocol in use in node MUST check if the network Request was last
       forwarded by a node on its blacklist.  If such an entry is not capable found,
       and the state of
       transmitting unicast packets over the unidirectional links, as
       discussed in Section 3.3.1, link is "probable", then in originating this Route Reply, the node
       Request MUST use a source route for routing be silently discarded.

    -  Else, if the Route Reply
       packet Request was received through a network
       interface that is obtained by reversing the sequence of hops over
       which requires physically bidirectional links for
       unicast transmission, the packet triggering node MUST check if the gratuitous Route Reply Request was routed
       in reaching and being overheard last
       forwarded by this node; this reversing a node on its blacklist.  If such an entry is found,
       and the state of the route uses unidirectional link is "questionable",
       then the gratuitous node MUST create and unicast a Route Reply Request packet to test this sequence
       of hops for bidirectionality, preventing
       that previous node, setting the gratuitous Route
       Reply IP Time-To-Live (TTL) to 1 to
       prevent the Request from being received by the initiator of the Route Discovery
       unless each of the hops over which propagated.  If the gratuitous node receives
       a Route Reply is
       returned is bidirectional.

    -  Discard the overheard packet, since the packet has been received
       before its normal traversal of in response to the packet's source route would
       have caused new Request, it to reach this receiving node.  Another copy of MUST remove the packet will normally arrive at this node as indicated in
       blacklist entry for that node, and SHOULD continue processing.
       If the packet's source route; discarding this initial copy node does not receive a Route Reply within some reasonable
       amount of time, MUST silently discard the
       packet, which triggered Route Request packet.

    -  Else, the gratuitous node MUST search its Route Reply, will prevent Request Table for an entry
       for the duplication initiator of this packet that would otherwise occur. Route Request (the IP Source Address
       field).  If the packet such an entry is not discarded as part of automatic route shortening
   above, then found in the table, the node MUST process
       search the option according cache of Identification values of recently received
       Route Requests in that table entry, to determine if an entry
       is present in the
   following sequence of steps:

    -  If cache matching the Identification value of the Segments Left field
       and target node address in this Route Request.  If such an
       (Identification, target address) entry is found in this cache in
       this entry in the DSR Source Route
       option equals 0, Request Table, then remove the DSR Source Route option from node MUST discard
       the
       DSR header. entire packet carrying the Route Request option.

    -  Else, let n equal (Opt Data Len - 2) / 4.  This is this node SHOULD further process the number Route Request
       according to the following sequence of
       addresses steps:

        o  Add an entry for this Route Request in the DSR Source its cache of
           (Identification, target address) values of recently received
           Route option.

    -  If the value Requests.

        o  Conceptually create a copy of this entire packet and perform
           the Segments Left field is greater than n, then
       send an ICMP Parameter Problem, Code 0, message [26] to following steps on the copy of the packet.

        o  Append this node's own IP
       Source Address, pointing address to the Segments Left field, and discard
       the packet.  Do not process list of Address[i]
           values in the DSR Source Route option further.

    -  Else, decrement Request, and increase the value of the Segments Left
           Opt Data Len field in the Route Request by 1.  Let i
       equal n minus Segments Left. 4 (the size of an
           IP address).

        o  This is node SHOULD search its own Route Cache for a route
           (from itself, as if it were the index source of the next
       address a packet) to be visited in the Address vector.

    -
           target of this Route Request.  If Address[i] or the IP Destination Address is such a multicast
       address, route is found in
           its Route Cache, then discard the packet.  Do not process this node SHOULD follow the DSR Source procedure
           outlined in Section 8.2.3 to return a "cached Route option further.

    -  If Reply"
           to the MTU initiator of the link over which this node would transmit Route Request, if permitted by the packet to forward it to
           restrictions specified there.

        o  If the node Address[i] is less than
       the size does not return a cached Route Reply, then this
           node SHOULD link-layer re-broadcast this copy of the packet,
           with a short jitter delay before the node MUST either discard the
       packet broadcast is sent.  The
           jitter period SHOULD be chosen as a random period, uniformly
           distributed between 0 and send an ICMP Packet Too Big message to BroadcastJitter.

8.2.3. Generating a Route Reply using the packet's
       Source Address [26] or fragment it as specified Route Cache

   As described in Section 8.

    -  Forward 3.3.2, it is possible for a node processing a
   received Route Request to avoid propagating the Route Request further
   toward the packet to target of the IP address specified Request, if this node has in its Route Cache
   a route from itself to this target.  Such a Route Reply generated by
   a node from its own cached route to the Address[i]
       field target of the IP header, following normal IP forwarding
       procedures, including checking a Route Request is
   called a "cached Route Reply", and decrementing the Time-to-Live
       (TTL) field in the packet's IP header [27, 3].  In this
       forwarding of mechanism can greatly reduce
   the packet, overall overhead of Route Discovery on the next-hop node (identified network by
       Address[i]) MUST be treated as reducing
   the flood of Route Requests.  The general processing of a direct neighbor node: received
   Route Request is described in Section 8.2.2; this section specifies
   the
       transmission to additional requirements that next node MUST be done in met before a single IP
       forwarding hop, without cached Route Discovery
   Reply may be generated and without searching returned and specifies the procedure for
   returning such a cached Route Cache.

    -  In forwarding the packet, perform Reply.

   While processing a received Route Maintenance Request, for a node to possibly
   return a cached Route Reply, it MUST have in its Route Cache a route
   from itself to the
       next hop target of this Route Request.  However, before
   generating a cached Route Reply for this Route Request, the packet, by verifying that the next-hop node is
       reachable, as described in Section 6.3.

   Multicast addresses MUST NOT appear
   verify that there are no duplicate addresses listed in a DSR Source Route option or the route
   accumulated in the Route Request together with the route from this
   node's Route Cache.  Specifically, there MUST be no duplicates among
   the following addresses:

    -  The IP Destination Source Address field of a the packet carrying a DSR Source containing the Route option Request,

    -  The Address[i] fields in a DSR header.

6.2. the Route Discovery Processing Request, and

    -  The nodes listed in the route obtained from this node's Route Discovery is
       Cache, excluding the mechanism by which a address of this node S wishing to send a
   packet to a destination itself (this node D obtains a source
       itself is the common point between the route to D. accumulated in the
       Route
   Discovery is used only when S attempts to send a packet to D Request and
   does not already know a the route to D.  The obtained from the Route Cache).

   If any duplicates exist among these addresses, then the node initiating MUST NOT
   send a cached Route
   Discovery is known as Reply.  The node SHOULD continue to process the "initiator" of
   Route Request as described in Section 8.2.2.

   If the Route Discovery, Request and the
   destination node for which route from the Route Discovery is initiated is known
   as Cache meet the "target" of
   restriction above, then the Route Discovery.

   Route Discovery operates entirely on demand, with a node initiating
   Route Discovery based on its own origination of new packets for
   some destination address to which it does not currently know SHOULD construct and return a
   route. cached
   Route Discovery does not depend on any periodic or background
   exchange Reply as follows:

    -  The source route for this reply is the sequence of routing information or neighbor node detection at any
   layer in hop addresses

          initiator, Address[1], Address[2], ..., Address[n], c-route

       where initiator is the network protocol stack at any node.

   The Route Discovery procedure utilizes two types address of the initiator of messages, a this Route
   Request (Section 5.2)
       Request, each Address[i] is an address from the Route Request,
       and a c-route is the sequence of hop addresses in the source route
       to this target node, obtained from the node's Route Reply (Section 5.3), Cache.  In
       appending this cached route to actively
   search the ad hoc network source route for the reply,
       the address of this node itself MUST be excluded, since it is
       already listed as Address[n].

    -  Send a route Route Reply to the desired destination.
   These DSR messages MAY be carried in any type of IP packet, through
   use initiator of the DSR header as described in Section 5.

   Except as discussed Route Request, using
       the procedure defined in Section 6.3.5, a 8.2.4.  The initiator of the
       Route Discovery for a
   destination address SHOULD NOT be initiated unless Request is indicated in the Source Address field in the
       packet's IP header.

   If the initiating node has returns a packet in its Send Buffer requiring delivery to that
   destination.  A cached Route Discovery for a given target Reply as described above,
   then the node MUST NOT be
   initiated unless permitted by the rate-limiting information contained
   in propagate the Route Request Table.  After each Route Discovery attempt, further (i.e.,
   the
   interval between successive Route Discoveries for this target SHOULD
   be doubled, up to a maximum of MaxRequestPeriod, until a valid Route
   Reply is received for this target.

6.2.1. Originating a Route Request

   A node initiating a Route Discovery for some target creates and
   initializes a MUST NOT rebroadcast the Route Request option in a DSR header in some IP packet.
   This MAY be a separate IP packet, used only to carry Request).  In this case,
   instead, if the packet contains no other DSR options and contains
   no payload after the DSR Options header (e.g., the Route Request option, is
   not piggybacked on a TCP or UDP packet), then the node MAY include SHOULD simply
   discard the packet.  Otherwise (if the Route Request option
   in some existing packet that it needs to send to contains other DSR
   options or contains any payload after the DSR Options header), the target
   node
   (e.g., SHOULD forward the IP packet originated by this node, that caused along the node cached route to
   attempt Route Discovery for the destination address target
   of the packet).
   The Route Request option MUST be included in a DSR header in the
   packet.  To initialize the Route Request option, Request.  Specifically, if the node performs does so, it MUST use
   the following sequence of steps:

    -  The Option Type in  Copy the Target Address from the Route Request option MUST be set in the DSR
       Options header to the value 2.

    -  The Opt Data Len Destination Address field in the option MUST be set to the value 6.
       The total size of packet's
       IP header.

    -  Remove the Route Request option when initiated
       is 8 octets; the Opt Data Len field excludes the size of from the
       Option Type and Opt Data Len fields themselves.

    -  The Identification field DSR Options header in
       the option MUST be set to a new
       value, different from that used for other Route Requests recently
       initiated by this node for this same target address.  For
       example, each node MAY maintain a single counter value for
       generating packet, and add a new Identification value for each DSR Source Route Request it
       initiates.

    -  The Target Address field in the option MUST be to the packet's DSR
       Options header.

    -  In the DSR Source Route option, set to the IP
       address that is Address[i] fields
       to represent the target of source route found in this node's Route Discovery.

   The Source Address in
       Cache to the IP header original target of this packet MUST be the node's
   own Route Discovery (the
       new IP address.  The Destination Address in the IP header of this
   packet MUST be the IP "limited broadcast" address (255.255.255.255).

   A node MUST maintain in its Route Request Table, information about
   Route Requests that it initiates.  When initiating a new Route
   Request, packet).  Specifically,
       the node MUST use copies the information recorded hop addresses of the source route into
       sequential Address[i] fields in the DSR Source Route
   Request Table entry option,
       for i = 1, 2, ..., n.  Address[1] here is the target address of that Route Request, and it MUST
   update that information this
       node itself (the first address in the table entry for use in source route found from
       this node to the original target of the next Route
   Request initiated for this target.  In particular:

    - Discovery).  The Route Request Table entry for a target node records
       value n here is the
       Time-to-Live (TTL) number of hop addresses in this source route,
       excluding the destination of the packet (which is instead already
       represented in the Destination Address field used in the packet's IP header of
       header).

    -  Initialize the Segments Left field in the DSR Source Route
       Request for option
       to n as defined above.

    -  The First Hop External (F) bit in the last DSR Source Route Discovery initiated by this node for
       that target node.  This value allows option is
       copied from the node to implement a
       variety of algorithms External bit flagging the first hop in the source
       route for controlling the spread of its packet, as indicated in the Route
       Request on each Cache.

    -  The Last Hop External (L) bit in the DSR Source Route Discovery initiated for a target.  As
       examples, two possible algorithms option is
       copied from the External bit flagging the last hop in the source
       route for this use of the TTL field
       are described packet, as indicated in Section 3.3.4. the Route Cache.

    -  The Route Request Table entry for a target node records Salvage field in the
       number of consecutive DSR Source Route Requests initiated for option MUST be
       initialized to some nonzero value; the particular nonzero value
       used SHOULD be MAX_SALVAGE_COUNT.  By initializing this target
       since receiving field to
       a valid Route Reply giving nonzero value, nodes forwarding or overhearing this packet will
       not consider a route link to that target
       node, and exist between the remaining amount IP Source Address of time before which this node MAY
       next attempt at a the
       packet and the Address[1] address in the DSR Source Route Discovery for that target node.

       A node MUST use these values option
       (e.g., they will not attempt to implement a back-off algorithm add this to
       limit their Route Cache as
       a link).  By choosing MAX_SALVAGE_COUNT as the rate at nonzero value to
       which this node initiates new Route Discoveries
       for the same target address.  In particular, until a valid Route
       Reply is received for this target node address, the timeout
       between consecutive Route Discovery initiations for initializes this target
       node with field, nodes furthermore will not
       attempt to salvage this packet.

    -  Transmit the same hop limit SHOULD increase by doubling packet to the
       timeout value next-hop node on each the new initiation.

   The behavior of source route
       in the packet, using the forwarding procedure described in
       Section 8.1.5.

8.2.4. Originating a Route Reply

   A node processing originates a packet containing DSR header
   with both Route Reply in order to reply to a DSR Source received and
   processed Route option Request, according to the procedures described in
   Sections 8.2.2 and a 8.2.3.  The Route Request option Reply is
   unspecified.  Packets SHOULD NOT contain both returned in a DSR Source Route
   Reply option and a (Section 6.3).  The Route Reply option MAY be returned
   to the initiator of the Route Request option.

   Packets containing in a separate IP packet, used
   only to carry this Route Request option SHOULD NOT include
   an Acknowledgment Request Reply option, SHOULD NOT expect link-layer
   acknowledgment or passive acknowledgment, and SHOULD NOT it MAY be
   retransmitted. included in any
   other IP packet being sent to this address.

   The retransmission of packets containing a Route
   Request Reply option is controlled solely by the logic described MUST be included in this
   section.

6.2.2. Processing a Received Route Request Option

   When a node receives a DSR Options header in
   the packet containing a returned to the initiator.  To initialize the Route Request Reply
   option, that the node performs the following sequence of steps:

    -  The Option Type in the option MUST process be set to the value 3.

    -  The Opt Data Len field in the option according MUST be set to the value
       (n * 4) + 3, where n is the number of addresses in the source
       route being returned (excluding the Route Discovery initiator
       node's address).

    -  The Last Hop External (L) bit in the option MUST be
       initialized to 0.

    -  The Reserved field in the option MUST be initialized to the following sequence of
   steps: 0.

    -  If  The Route Request Identifier MUST be initialized to the Target Address
       Identifier field in of the Route Request matches that this
       node's own IP address, then reply is sent in
       response to.

    -  The sequence of hop addresses in the node SHOULD return a Route Reply source route are copied into
       the Address[i] fields of the option.  Address[1] MUST be set to
       the first-hop address of the route after the initiator of this the
       Route Request Discovery, Address[n] MUST be set to the last-hop address
       of the source route (the Source address of the target node), and each
       other Address[i] MUST be set to the next address in sequence in
       the source route being returned.

   The Destination Address field in the IP header of the packet), as described in Section 6.2.4.  The
       source route for this Reply is packet carrying
   the sequence of hop addresses

          initiator, Address[1], Address[2], ..., Address[n], target

       where initiator is Route Reply option MUST be set to the address of the initiator
   of this
       Route Request, each Address[i] is an address from the Route Discovery (i.e., for a Route Reply being returned in
   response to some Route Request, and target is the target IP Source Address of the Route Request (the
       Target Address field in
   Request).

   After creating and initializing the Route Request).  The value n here
       is Reply option and the number of addresses recorded in IP
   packet containing it, send the Route Request, or
       (Opt Data Len - 6) / 4.

       The Reply.  In sending the Route
   Reply from this node then MUST replace (but not from nodes forwarding the Destination Address field in Route Reply),
   this node SHOULD delay the Reply by a small jitter period chosen
   randomly between 0 and BroadcastJitter.

   When returning any Route Request packet's IP header with Reply in the value case in which the
       Target Address field MAC protocol
   in use in the network is not capable of transmitting unicast packets
   over unidirectional links, the source route used for routing the
   Route Request option, and continue
       processing Reply packet MUST be obtained by reversing the rest sequence of
   hops in the Route Request packet normally.  The
       node MUST NOT process (the source route that is then
   returned in the Route Request option further and MUST
       NOT retransmit Reply).  This restriction on returning a Route
   Reply enables the Route Request to propagate it Reply to other nodes
       as part test this sequence of hops for
   bidirectionality, preventing the Route Reply from being received by
   the initiator of the Route Discovery.

    -  Else, Discovery unless each of the node MUST examine hops over
   which the Route Reply is returned (and thus each of the hops in the
   source route recorded being returned in the Reply) is bidirectional.

   If sending a Route
       Request option (the IP Source Address field and the sequence of
       Address[i] fields) Reply to determine if this node's own IP address
       already appears in this list the initiator of addresses.  If so, the node Route Request
   requires performing a Route Discovery, the Route Reply option MUST
       discard
   be piggybacked on the entire packet carrying the Route Request option.

    -  Else, if that contains the Route Request through Request.  This
   piggybacking prevents a network interface that
       requires physically bidirectional links for unicast transmission, loop wherein the node MUST check if target of the new Route
   Request (which was last forwarded by a node
       on its blacklist.  If such an entry is found, and itself the state initiator of the unidirectional link is "probable," then original Route
   Request) must do another Route Request in order to return its
   Route Reply.

   If sending the Route Reply to the Request MUST be
       silently discarded.

    -  Else, if initiator of the Route Request through
   does not require performing a Route Discovery, a node SHOULD send a network interface that
       requires physically bidirectional links for
   unicast transmission, Route Reply in response to every Route Request it receives
   for which it is the node MUST check if target node.

8.2.5. Processing a Received Route Reply Option

   Section 8.1.4 describes the Request was last forwarded by general processing for a node
       on its blacklist.  If such an entry is found, and received packet,
   including the state addition of routing information from options in the unidirectional link is "questionable," then
   packet's DSR Options header to the node MUST
       create and unicast a receiving node's Route Request Cache.

   If the received packet to that previous node,
       setting contains a Route Reply, no additional special
   processing of the IP Time-To-Live (TTL) to 1 Route Reply option is required beyond what is
   described there.  As described in Section 4.1 anytime a node adds
   new information to prevent its Route Cache (including the Request information added
   from being propagated.  If this Route Reply option), the node receives SHOULD check each packet in
   its own Send Buffer (Section 4.2) to determine whether a Route Reply route to
   that packet's IP Destination Address now exists in
       response the node's Route
   Cache (including the information just added to the new Request, it MUST remove Cache).  If so,
   the blacklist entry
       for packet SHOULD then be sent using that node, route and SHOULD continue processing.  If removed from the node does
       not receive
   Send Buffer.  This general procedure handles all processing required
   for a received Route Reply within some reasonable amount option.

   When a MAC protocol requires bidirectional links for unicast
   transmission, a unidirectional link may be discovered by the
   propagation of time, MUST
       silently discard the Route Request packet.

    -  Else, Request.  When the Route Reply is sent over
   the reverse path, a forwarding node may discover that the next-hop is
   unreachable.  In this case, it MUST search add the next-hop address to its
   blacklist.

8.3. Route Request Table for an entry
       for the initiator of this Maintenance Processing

   Route Request (the IP Source Address
       field).  If such an entry Maintenance is found in the table, the mechanism by which a source node MUST
       search the cache of Identification values of recently received
       Route Requests in that table entry, S is able
   to determine detect, while using a source route to some destination node D,
   if an entry
       is present in the cache matching network topology has changed such that it can no longer use
   its route to D because a link along the Identification value
       and target node address in this route no longer works.  When
   Route Request.  If such an
       (Identification, target address) entry Maintenance indicates that a source route is found in this cache in
       this entry in the broken, S can
   attempt to use any other route it happens to know to D, or can invoke
   Route Request Table, then the node MUST discard
       the entire packet carrying the Discovery again to find a new route for subsequent packets
   to D.  Route Request option.

    -  Else, Maintenance for this node SHOULD further process the Route Request
       according route is used only when S is
   actually sending packets to D.

   Specifically, when forwarding a packet, a node MUST attempt
   to confirm the following sequence of steps:

        o  Add an entry for this Route Request in its cache of
           (Identification, target address) values reachability of recently the next-hop node, unless such
   confirmation had been received
           Route Requests.

        o  Conceptually create a copy in the last MaintHoldoffTime.
   Individual implementations MAY choose to bypass such confirmation
   for some limited number of this entire packet and perform packets, as long as those packets all
   fall within MaintHoldoffTime within the following steps on last confirmation.  If no
   confirmation is received after the copy retransmission of MaxMaintRexmt
   acknowledgement requests, after the packet.

        o  Append this node's own IP address to the list initial transmission of Address[i]
           values in the Route Request,
   packet, and increase conceptually including all retransmissions provided
   by the value of MAC layer, the
           Opt Data Len field in node determines that the Route Request by 4 (the size link for this
   next-hop node of an
           IP address).

        o the source route is "broken".  This confirmation
   from the next-hop node SHOULD search its own Route Cache for Route Maintenance can be implemented
   using a route
           (from itself, as if it were the source of link-layer acknowledgement (Section 8.3.1), using a packet) to
   "passive acknowledgement" (Section 8.3.2), or using a network-layer
   acknowledgement (Section 8.3.3); the
           target particular strategy for
   retransmission timing depends on the type of this Route Request. acknowledgement
   mechanism used.  When passive acknowledgements are being used, each
   retransmitted acknowledgement request SHOULD be explicit software
   acknowledgement requests.  If such a route no acknowledgement is found in
           its Route Cache, then this received after
   MaxMaintRexmt retransmissions (if necessary), the node SHOULD follow
   originate a Route Error to the procedure
           outlined original sender of the packet, as
   described in Section 6.2.3 8.3.4.

   In deciding whether or not to return send a "cached Route Reply" Error in response to
   attempting to forward a packet from some sender over a broken link,
   a node MUST limit the initiator number of this Route Request, if permitted by consecutive packets from a single
   sender that the
           restrictions specified there.

        o  If node attempts to forward over this same broken
   link for which the node does chooses not to return a cached Route Reply, then this
           node SHOULD link-layer re-broadcast Error; this copy of the packet,
           with a short jitter delay before the broadcast is sent.  The
           jitter period SHOULD
   requirement MAY be chosen as a random period, uniformly
           distributed between 0 and BroadcastJitter.

6.2.3. Generating satisfied by returning a Route Reply using the Route Cache

   As described in Section 3.3.2, it is possible Error for a each
   packet that the node processing attempts to forward over a
   received Route Request broken link.

8.3.1. Using Link-Layer Acknowledgements

   If the MAC protocol in use provides feedback as to avoid propagating the Route Request further
   toward successful
   delivery of a data packet (such as is provided by the target link-layer
   acknowledgement frame defined by IEEE 802.11 [13]), then the use
   of the Request, if this DSR Acknowledgement Request and Acknowledgement options
   is not necessary.  If such link-layer feedback is available, it
   SHOULD be used instead of any other acknowledgement mechanism
   for Route Maintenance, and the node has in its SHOULD NOT use either passive
   acknowledgements or network-layer acknowledgements for Route Cache
   a route from itself to this target.  Such a
   Maintenance.

   When using link-layer acknowledgements for Route Reply generated Maintenance, the
   retransmission timing and the timing at which retransmission attempts
   are scheduled are generally controlled by
   a node from its own cached route to the target of a Route Request particular link layer
   implementation in use in the network.  For example, in IEEE 802.11,
   the link-layer acknowledgement is
   called a "cached Route Reply", and this mechanism can greatly reduce returned after the overall overhead data packet as
   a part of Route Discovery on the network by reducing the flood basic access method of Route Requests.  The general processing of a received
   Route Request is described in Section 6.2.2; this section specifies the additional requirements that MUST be met before a cached Route
   Reply may be generated and returned IEEE 802.11 Distributed
   Coordination Function (DCF) MAC protocol; the time at which the
   acknowledgement is expected to arrive and specifies the procedure for
   returning such time at which the next
   retransmission attempt (if necessary) will occur are controlled by
   the MAC protocol implementation.

   When a cached Route Reply.

   While processing node receives a received Route Request, link-layer acknowledgement for a any packet in
   its Maintenance Buffer, that node to possibly
   return a cached Route Reply, it MUST have SHOULD remove that packet, as well
   as any other packets in its Maintenance Buffer with the same next-hop
   destination, from its Maintenance Buffer.

8.3.2. Using Passive Acknowledgements

   When link-layer acknowledgements are not available, but passive
   acknowledgements [18] are available, passive acknowledgements SHOULD
   be used for Route Cache Maintenance when originating or forwarding a route
   from itself packet
   along any hop other than the last hop (the hop leading to the target IP
   Destination Address node of this Route Request.  However, before
   generating a cached the packet).  In particular, passive
   acknowledgements SHOULD be used for Route Reply Maintenance in such cases
   if the node can place its network interface into "promiscuous"
   receive mode, and network links used for data packets generally
   operate bidirectionally.

   A node MUST NOT attempt to use passive acknowledgements for this Route Request,
   Maintenance for a packet originated or forwarded over its last hop
   (the hop leading to the IP Destination Address node MUST
   verify that there are no duplicate addresses listed in of the route
   accumulated in packet),
   since the Route Request together with receiving node will not be forwarding the route from packet and thus
   no passive acknowledgement will be available to be heard by this
   node's
   node.  Beyond this restriction, a node MAY utilize a variety of
   strategies in using passive acknowledgements for Route Cache.  Specifically, there MUST be no duplicates among Maintenance of
   a packet that it originates or forwards.  For example, the following addresses:
   two strategies are possible:

    -  The  Each time a node receives a packet to be forwarded to a node
       other than the final destination (the IP Source Destination Address
       of the packet containing the Route Request,

    -  The Address[i] fields in the Route Request, and

    -  The nodes listed in the route obtained from this node's Route
       Cache, excluding packet), that node sends the address original transmission of this node itself (this node
       itself
       that packet without requesting a network-layer acknowledgement
       for it.  If no passive acknowledgement is received within
       PassiveAckTimeout after this transmission, the common point between the route accumulated in the
       Route Request and node retransmits
       the route obtained from packet, again without requesting a network-layer
       acknowledgement for it; the Route Cache). same PassiveAckTimeout timeout value
       is used for each such attempt.  If any duplicates exist among these addresses, then the node MUST NOT
   send no acknowledgement has been
       received after a cached Route Reply.  The node SHOULD continue to process total of TryPassiveAcks retransmissions of
       the
   Route Request as packet, network-layer acknowledgements (as described in
       Section 6.2.2.

   If the Route Request and the route from the Route Cache meet the
   restriction above, then the 8.3.3) are used for all remaining attempts for that
       packet.

    -  Each node SHOULD construct and return maintains a cached
   Route Reply as follows:

    -  The source route for this reply is the sequence of hop addresses

          initiator, Address[1], Address[2], ..., Address[n], c-route

       where initiator is the address table of possible next-hop destination
       nodes, noting whether or not passive acknowledgements can
       typically be expected from transmission to that node, and the initiator
       expected latency and jitter of this Route
       Request, each Address[i] is an address a passive acknowledgement from
       that node.  Each time a node receives a packet to be forwarded
       to a node other than the Route Request,
       and c-route is IP Destination Address, the sequence node checks
       its table of hop addresses in the source route next-hop destination nodes to determine whether to
       use a passive acknowledgement or a network-layer acknowledgement
       for that transmission to that node.  The timeout for this target node, obtained packet
       can also be derived from the node's Route Cache.  In
       appending this cached route table.  A node using this method
       SHOULD prefer using passive acknowledgements to the source route network-layer
       acknowledgements.

   In using passive acknowledgements for a packet that it originates or
   forwards, a node considers the reply,
       the address later receipt of this node itself MUST be excluded, since it is
       already listed as Address[n].

    -  Send a Route Reply new packet (e.g.,
   with promiscuous receive mode enabled on its network interface) to be
   an acknowledgement of this first packet if both of the following two
   tests succeed:

    -  The Source Address, Destination Address, Protocol,
       Identification, and Fragment Offset fields in the initiator IP header
       of the two packets MUST match [30], and

    -  If either packet contains a DSR Source Route Request, using header, both packets
       MUST contain one, and the procedure defined value in Section 6.2.4.  The initiator of the
       Route Request is indicated Segments Left field in the
       DSR Source Address field in Route header of the
       packet's IP header.

   If new packet MUST be less than that
       in the first packet.

   When a node returns hears such a cached Route Reply passive acknowledgement for any packet in
   its Maintenance Buffer, that node SHOULD remove that packet, as described above, then well
   as any other packets in its Maintenance Buffer with the same next-hop
   destination, from its Maintenance Buffer.

8.3.3. Using Network-Layer Acknowledgements

   When a node MUST NOT propagate the Route Request further (i.e., originates or forwards a packet and has no other
   mechanism of acknowledgement available to determine reachability
   of the next-hop node MUST NOT rebroadcast in the source route for Route Request).  In this case, instead,
   if Maintenance,
   that node SHOULD request a network-layer acknowledgement from that
   next-hop node.  To do so, the packet contains no other DSR options and contains no payload
   after node inserts an Acknowledgement Request
   option in the DSR Options header (e.g., in the Route packet.  The Identification
   field in that Acknowledgement Request is not piggybacked
   on option MUST be set to a TCP or UDP packet), then the value
   unique over all packets transmitted by this node SHOULD simply discard the
   packet.  Otherwise (if to the packet contains other DSR options same next-hop
   node that are either unacknowledged or
   contains any payload after the DSR header), the recently acknowledged.

   When a node SHOULD forward
   the receives a packet along the cached route to containing an Acknowledgement Request
   option, then that node performs the target of following tests on the Route Request.
   Specifically, if packet:

    -  If the indicated next-hop node address for this packet does so, it not
       match any of this node's own IP addresses, then this node MUST use
       NOT process the following
   steps:

    -  Copy Acknowledgement Request option.  The indicated
       next-hop node address is the Target Address from next Address[i] field in the DSR
       Source Route Request option in the DSR Options header to in the packet, or
       is the IP Destination Address field in the packet's IP
       header.

    -  Remove the Route Request option from the DSR header in packet if the
       packet, and add packet does
       not contain a DSR Source Route option to or the packet's DSR
       header. Segments Left there
       is zero.

    -  In  If the DSR Source Route packet contains an Acknowledgement option, set the Address[i] fields
       to represent the source route found in then this node's Route
       Cache to the original target of node
       MUST NOT process the Route Discovery (the
       new IP Destination Address Acknowledgement Request option.

   If neither of the packet).  Specifically,
       the tests above fails, then this node copies MUST process the hop addresses of
   Acknowledgement Request option by sending an Acknowledgement option
   to the source route into
       sequential Address[i] fields in previous-hop node; to do so, the DSR Source Route option,
       for i = 1, 2, ..., n.  Address[1] here is node performs the address following
   sequence of this
       node itself (the first address in steps:

    -  Create a packet and set the source route found from
       this node IP Protocol field to the original target of protocol
       number assigned for a DSR Options header (TBA???).

    -  Set the Route Discovery).  The
       value n here is IP Source Address field in this packet to the number IP address
       of hop addresses in this node, copied from the source route,
       excluding route in the destination DSR Source
       Route option in that packet (or from the IP Destination Address
       field of the packet, if the packet (which is instead already
       represented in does not contain a DSR Source
       Route option).

    -  Set the IP Destination Address field in this packet to the packet's IP
       header).

    -  Initialize
       address of the Segments Left field previous-hop node, copied from the source route
       in the DSR Source Route option
       to n as defined above.

    -  The First Hop External (F) bit in that packet (or from the IP
       Source Address field of the packet, if the packet does not
       contain a DSR Source Route option is
       copied from option).

    -  Add a DSR Options header to the External bit flagging packet, and set the first hop in DSR Options
       header's Next Header field to the source
       route for "No Next Header" value.

    -  Add an Acknowledgement option to the packet, as indicated DSR Options header in the Route Cache.

    -  The Last Hop External (L) bit in
       packet; set the DSR Source Route option is
       copied from Acknowledgement option's Option Type field to 6
       and the External bit flagging Opt Data Len field to 10.

    -  Copy the last hop in Identification field from the source
       route for received Acknowledgement
       Request option into the packet, as indicated Identification field in the Route Cache.
       Acknowledgement option.

    -  The Salvage  Set the ACK Source Address field in the DSR Source Route Acknowledgement option MUST be
       initialized to some nonzero value; the particular nonzero value
       used SHOULD
       be MAX_SALVAGE_COUNT.  By initializing this field to
       a nonzero value, nodes forwarding or overhearing the IP Source Address of this new packet will
       not consider a link (set above to exist between be the
       IP Source Address address of this node).

    -  Set the
       packet and the Address[1] address ACK Destination Address field in the DSR Source Route Acknowledgement
       option
       (e.g., they will not attempt to add this to their Route Cache as
       a link).  By choosing MAX_SALVAGE_COUNT as the nonzero value to
       which be the node initializes this field, nodes furthermore will not
       attempt to salvage IP Destination Address of this packet.

    -  Transmit the new packet (set
       above to be the next-hop node on the new source route
       in IP address of the packet, using previous-hop node).

    -  Send the forwarding procedure packet as described in Section 6.1.5.

6.2.4. Originating 8.1.1.

   Packets containing an Acknowledgement option SHOULD NOT be placed in
   the Maintenance Buffer.

   When a Route Reply

   A node originates a Route Reply in order to reply to receives a received and
   processed Route Request, according to the procedures described in
   Sections 6.2.2 packet with both an Acknowledgement option
   and 6.2.3.  The Route Reply an Acknowledgement Request option, if that node is returned in a Route
   Reply not the
   destination of the Acknowledgement option (Section 5.3).  The Route Reply (the IP Destination Address
   of the packet), then the Acknowledgement Request option MAY MUST
   be returned
   to ignored.  Otherwise (that node is the initiator destination of the Route
   Acknowledgement option), that node MUST process the Acknowledgement
   Request in option by returning an Acknowledgement option according to
   the following sequence of steps:

    -  Create a separate packet and set the IP packet, used
   only Protocol field to carry this Route Reply option, or it MAY be included in any
   other the protocol
       number assigned for a DSR Options header (TBA???).

    -  Set the IP Source Address field in this packet being sent to the IP address
       of this address.

   The node, copied from the source route in the DSR Source
       Route Reply option MUST be included in that packet (or from the IP Destination Address
       field of the packet, if the packet does not contain a DSR header in Source
       Route option).

    -  Set the IP Destination Address field in this packet
   returned to the initiator.  To initialize the Route Reply option, IP
       address of the node performs originating the following sequence of steps: Acknowledgement option.

    -  The Option Type in  Add a DSR Options header to the option MUST be packet, and set to the value 3.

    -  The Opt Data Len DSR Options
       header's Next Header field in to the "No Next Header" value.

    -  Add an Acknowledgement option MUST be set to the value
       (n * 4) + 3, where n is the number of addresses in the source
       route being returned (excluding the Route Discovery initiator
       node's address).

    -  The Last Hop External (L) bit DSR Options header in this
       packet; set the option MUST be
       initialized to 0.

    -  The Reserved Acknowledgement option's Option Type field in to 6
       and the option MUST be initialized Opt Data Len field to 0. 10.

    -  The Route Request Identifier MUST be initialized to  Copy the
       Identifier Identification field of from the Route received Acknowledgement
       Request that this reply is sent in
       response to.

    -  The sequence of hop addresses in the source route are copied option into the Address[i] fields of Identification field in the
       Acknowledgement option.  Address[1] MUST be set to
       the first-hop address of the route after

    -  Set the initiator of ACK Source Address field in the
       Route Discovery, Address[n] MUST be set option to be the last-hop address
       of the source route (the address IP
       Source Address of the target node), and each
       other Address[i] MUST be set this new packet (set above to be the next IP address in sequence in
       of this node).

    -  Set the source route being returned.

   The ACK Destination Address field in the option to be the IP header
       Destination Address of the this new packet carrying
   the Route Reply option MUST be set (set above to be the IP
       address of the initiator
   of node originating the Route Discovery (i.e., for a Route Reply being returned in
   response Acknowledgement option.)

    -  Send the packet directly to some Route Request, the destination.  The IP Source
       Destination Address of the Route
   Request).

   After creating and initializing MUST be treated as a direct neighbor node:
       the transmission to that node MUST be done in a single IP
       forwarding hop, without Route Reply option Discovery and the IP
   packet containing it, send without searching
       the Route Reply. Cache.  In sending the Route
   Reply from this node (but not from nodes forwarding the Route Reply), addition, this node SHOULD delay the Reply by packet MUST NOT contain a small jitter period chosen
   randomly between 0
       DSR Acknowledgement Request, MUST NOT be retransmitted for Route
       Maintenance, and BroadcastJitter. MUST NOT expect a link-layer acknowledgement or
       passive acknowledgement.

   When returning any using network-layer acknowledgements for Route Reply in the case in which the MAC protocol
   in Maintenance,
   a node SHOULD use an adaptive algorithm in determining the network is not capable of transmitting unicast packets
   over unidirectional links, the source route used
   retransmission timeout for routing the
   Route Reply packet MUST be obtained by reversing the sequence each transmission attempt of hops in the Route Request packet (the source route that is
   then returned an
   acknowledgement request.  For example, a node SHOULD maintain a
   separate round-trip time (RTT) estimate for each to which it has
   recently attempted to transmit packets, and it SHOULD use this RTT
   estimate in setting the timeout for each retransmission attempt
   for Route Reply).  This restriction on returning Maintenance.  The TCP RTT estimation algorithm has been
   shown to work well for this purpose in implementation and testbed
   experiments with DSR [22, 24].

8.3.4. Originating a Route Reply enables the Route Reply Error

   When a node is unable to test this sequence verify reachability of
   hops for bidirectionality, preventing the Route Reply from being
   received by the initiator a next-hop node after
   reaching a maximum number of the retransmission attempts, a node SHOULD
   send a Route Discovery unless each of
   the hops over which Error to the Route Reply is returned (and thus each IP Source Address of the hops in the source route being returned in the Reply) is
   bidirectional.

   If packet.  When
   sending a Route Reply to the initiator of the Error for a packet containing either a Route Request
   requires performing Error
   option or an Acknowledgement option, a node SHOULD add these existing
   options to its Route Discovery, Error, subject to the limit described below.

   A node transmitting a Route Reply Option Error MUST
   be piggybacked on perform the following steps:

    -  Create an IP packet that contains and set the Route Request.  This
   piggybacking prevents a loop wherein Source Address field in this
       packet's IP header to the target address of this node.

    -  If the new Salvage field in the DSR Source Route
   Request (which was itself option in the initiator of
       packet triggering the original Route
   Request) must do another Error is zero, then copy the
       Source Address field of the packet triggering the Route Request Error
       into the Destination Address field in order to return its
   Route Reply.

   If sending the Route Reply to new packet's IP
       header; otherwise, copy the Address[1] field from the initiator DSR Source
       Route option of the packet triggering the Route Request
   does not require performing a Route Discovery, a node SHOULD send a
   unicast Route Reply Error into the
       Destination Address field in response to every Route Request it receives
   for which it is the target node.

6.2.5. Processing new packet's IP header

    -  Insert a DSR Options header into the new packet.

    -  Add a Received Route Reply Error Option

   Section 6.1.4 describes to the general processing for a received new packet,
   including setting the addition of routing information from options in Error
       Type to NODE_UNREACHABLE, the
   packet's DSR header Salvage value to the receiving node's Route Cache.

   If Salvage
       value from the received packet contains a DSR Source Route Reply, no additional special
   processing option of the packet triggering
       the Route Reply option is required beyond what is
   described there.  As described in Section 4.1 anytime a node adds
   new information Error, and the Unreachable Node Address field to its Route Cache (including
       the information added
   from this Route Reply option), address of the next-hop node SHOULD check each packet in
   its own Send Buffer (Section 4.2) from the original source
       route.  Set the Error Source Address field to determine whether a route this node's IP
       address, and the Error Destination field to
   that the new packet's IP
       Destination Address now exists in Address.

    -  If the packet triggering the node's Route
   Cache (including Error contains any Route Error
       or Acknowledgement options, the information just added node MAY append to its Route
       Error each of these options, with the Cache).  If so,
   the packet SHOULD then be sent using that route and removed following constraints:

        o  The node MUST NOT include any Route Error option from the
   Send Buffer.  This general procedure handles all processing required
   for a received
           packet triggering the new Route Reply option.

   When a MAC protocol requires bidirectional links Error, for unicast
   transmission, a unidirectional link may be discovered by which the
   propagation total
           salvage count (Section 6.4) of that included Route Error
           would be greater than MAX_SALVAGE_COUNT in the new packet.

        o  If any Route Request.  When Error option from the packet triggering the new
           Route Reply Error is sent over not included in the reverse path, a forwarding node may discover that packet, the next-hop is
   unreachable.  In this case, it node MUST add the next-hop address to its
   blacklist.

6.3. Route Maintenance Processing NOT
           include any following Route Maintenance is Error or Acknowledgement options
           from the mechanism by which a source node S is able
   to detect, while using a source route to some destination node D,
   if packet triggering the network topology has changed such that it can no longer use
   its route to D because a link along new Route Error.

        o  Any appended options from the packet triggering the route no longer works.  When Route Maintenance indicates that a source route is broken, S can
   attempt to use any other route it happens to know to D, or can invoke
           Error MUST follow the new Route Discovery again Error in the packet.

        o  In appending these options to find a the new route for subsequent packets
   to D. Route Maintenance for this route is used only when S is
   actually sending packets to D.

   Specifically, when forwarding Error, the order
           of these options from the packet triggering the Route Error
           MUST be preserved.

    -  Send the packet as described in Section 8.1.1.

8.3.5. Processing a packet, Received Route Error Option

   When a node receives a packet containing a Route Error option, that
   node MUST attempt
   to confirm the reachability of the next-hop node, unless such
   confirmation had been received in process the last MaintHoldoffTime.
   Individual implementations MAY choose Route Error option according to bypass such confirmation
   for some limited number of packets, as long as those packets
   all fall within MaintHoldoffTime within the last confirmation.
   If no confirmation is received after the retransmission following
   sequence of
   MaxMaintRexmt acknowledgment requests, after steps:

    -  The node MUST remove from its Route Cache the initial transmission
   of link from the packet, and conceptually including all retransmissions
   provided
       node identified by the MAC layer, Error Source Address field to the node determines that
       identified by the link
   for Unreachable Node Address field (if this next-hop node of the source route link is "broken".  This
   confirmation from
       present in its Route Cache).  If the next-hop node for implements its Route Maintenance can be
   implemented using a link-layer acknowledgment (Section 6.3.1),
   using a "passive acknowledgment" (Section 6.3.2), or using
       Cache as a
   network-layer acknowledgment (Section 6.3.3); the particular strategy
   for retransmission timing depends on link cache, as described in Section 4.1, only this
       single link is removed; if the type of acknowledgment
   mechanism used.  When passive acknowledgments node implements its Route Cache as
       a path cache, however, all routes (paths) that use this link are being used, each
   retransmitted acknowledgment request SHOULD be explicit software
   acknowledgment requests.
       removed.

    -  If no acknowledgment the option following the Route Error is received after
   MaxMaintRexmt retransmissions (if necessary), an Acknowledgement
       or Route Error option sent by this node (that is, with
       Acknowledgement or Error Source Address equal to this node's
       address), copy the node SHOULD
   originate a DSR options following the current Route
       Error into a new packet with IP Source Address equal to this
       node's own IP address and IP Destination Address equal to the original sender of the packet,
       Acknowledgement or Error Destination Address.  Transmit this
       packet as described in Section 6.3.4.

   In deciding whether or not to send a Route Error 8.1.1, with the salvage count
       in response to
   attempting the DSR Source Route option set to forward a packet from some sender over a broken link,
   a node MUST limit the number Salvage value of consecutive packets from a single
   sender that the node attempts to forward over this same broken
   link for which
       Route Error.

   In addition, after processing the node chooses not to return a Route Error; this
   requirement Error as described above,
   the node MAY be satisfied by returning initiate a new Route Error Discovery for each
   packet that the any destination node attempts to forward over a broken link.

6.3.1. Using Link-Layer Acknowledgments

   If the MAC protocol
   for which it then has no route in use provides feedback its Route Cache as to the successful
   delivery a result of
   processing this Route Error, if the node has indication that a data packet (such as route
   to that destination is provided by needed.  For example, if the link-layer
   acknowledgment frame defined by IEEE 802.11 [11]), node has an open
   TCP connection to some destination node, then if the use
   of the DSR Acknowledgment Request and Acknowledgment options
   is not necessary.  If such link-layer feedback is available, it
   SHOULD be used instead processing of any other acknowledgment mechanism for
   this Route Maintenance, and Error removed the node SHOULD NOT use either passive
   acknowledgments or network-layer acknowledgments for only route to that destination from this
   node's Route
   Maintenance.

   When using link-layer acknowledgments for Cache, then this node MAY initiate a new Route Maintenance, the
   retransmission timing and Discovery
   for that destination node.  Any node, however, MUST limit the timing rate at
   which retransmission attempts
   are scheduled are generally controlled by the particular link layer
   implementation in use in the network.  For example, it initiates new Route Discoveries for any single destination
   address, and any new Route Discovery initiated in IEEE 802.11,
   the link-layer acknowledgment is returned after the data packet this way as
   a part of
   processing this Route Error MUST conform to this limit.

8.3.6. Salvaging a Packet

   When an intermediate node forwarding a packet detects through Route
   Maintenance that the basic access method of of the IEEE 802.11 Distributed
   Coordination Function (DCF) MAC protocol; the time at which next-hop link along the
   acknowledgment route for that packet is expected to arrive and
   broken (Section 8.3), if the time at which node has another route to the next
   retransmission attempt (if necessary) will occur are controlled by packet's
   IP Destination Address in its Route Cache, the MAC protocol implementation.

   When a node receives a link-layer acknowledgment for any SHOULD "salvage"
   the packet rather than discarding it.  To do so using the route found
   in its Maintenance Buffer, that Route Cache, this node SHOULD remove that packet, as well processes the packet as any other packets follows:

    -  If the MAC protocol in use in its Maintenance Buffer with the same next-hop
   destination, from its Maintenance Buffer.

6.3.2. Using Passive Acknowledgments

   When link-layer acknowledgments are network is not available, but passive
   acknowledgments [16] are available, passive acknowledgments SHOULD be
   used for Route Maintenance when originating or forwarding capable of
       transmitting unicast packets over unidirectional links, as
       discussed in Section 3.3.1, then if this packet contains a Route
       Reply option, remove and discard the Route Reply option in the
       packet; if the DSR Options header in the packet
   along any hop other than then contains no
       DSR options, remove the last hop (the hop leading to DSR Options header from the packet.  If
       the resulting packet then contains only an IP
   Destination Address header, the node of
       SHOULD NOT salvage the packet).  In particular, passive
   acknowledgments packet and instead SHOULD be used for discard the
       entire packet.

       When returning any Route Maintenance Reply in such cases if the node can place its network interface into "promiscuous" receive
   mode, and network links used for data packets generally operate
   bidirectionally.

   A node MUST NOT attempt to case in which the MAC
       protocol in use passive acknowledgments for Route
   Maintenance for a packet originated or forwarded over its last hop
   (the hop leading to in the IP Destination Address node network is not capable of transmitting
       unicast packets over unidirectional links, the packet),
   since the receiving node will not be forwarding source route
       used for routing the Route Reply packet and thus
   no passive acknowledgment will be available to MUST be heard obtained by this node.
   Beyond this restriction, a node MAY utilize a variety
       reversing the sequence of strategies hops in using passive acknowledgments for the Route Maintenance of a Request packet (the
       source route that it originates or forwards.  For example, is then returned in the following two
   strategies are possible:

    -  Each time a node receives a packet to be forwarded to Route Reply).  This
       restriction on returning a node
       other than the final destination (the IP Destination Address of
       the packet), Route Reply and on salvaging a packet
       that node sends contains a Route Reply option enables the original transmission Route Reply to
       test this sequence of that
       packet without requesting a network-layer acknowledgment hops for it.
       If no passive acknowledgment is bidirectionality, preventing the
       Route Reply from being received within PassiveAckTimeout
       after this transmission, by the node retransmits initiator of the packet, again
       without requesting a network-layer acknowledgment for it; Route
       Discovery unless each of the
       same PassiveAckTimeout timeout value hops over which the Route Reply is used for
       returned (and thus each such
       attempt.  If no acknowledgment has been received after a total
       of TryPassiveAcks retransmissions of the packet, network-layer
       acknowledgments (as described hops in Section 6.3.3) are used for all
       remaining attempts for that packet. the source route being
       returned in the Reply) is bidirectional.

    -  Each node keeps a table of possible next-hop destination nodes,
       noting whether or not passive acknowledgments can typically
       be expected from transmission to that node, and  Modify the existing DSR Source Route option in the expected
       latency and jitter of a passive acknowledgment from that node.
       Each time a node receives a packet to be forwarded to a node
       other than so
       that the Address[i] fields represent the source route found in
       this node's Route Cache to this packet's IP Destination Address, Address.
       Specifically, the node checks its table copies the hop addresses of next-hop destination nodes to determine whether to use a
       passive acknowledgment or a network-layer acknowledgment for
       that transmission to that node.  The timeout the source
       route into sequential Address[i] fields in the DSR Source Route
       option, for this packet
       can also be derived i = 1, 2, ..., n.  Address[1] here is the address
       of the salvaging node itself (the first address in the source
       route found from this table.  A node using this method
       SHOULD prefer using passive acknowledgments to network-layer
       acknowledgments.

   In using passive acknowledgments for a packet that it originates or
   forwards, a node considers the later receipt IP Destination Address of a new packet (e.g.,
   with promiscuous receive mode enabled on its network interface) to be
   an acknowledgment the
       packet).  The value n here is the number of hop addresses in this first packet if both
       source route, excluding the destination of the following two
   tests succeed:

    -  The Source Address, packet (which is
       instead already represented in the Destination Address, Protocol,
       Identification, and Fragment Offset fields Address field in
       the packet's IP header
       of header).

    -  Initialize the two packets MUST match [27], and Segments Left field in the DSR Source Route option
       to n as defined above.

    -  If either packet contains a  The First Hop External (F) bit in the DSR Source Route header, both packets
       MUST contain one, and option is
       copied from the value External bit flagging the first hop in the Segments Left field source
       route for the packet, as indicated in the Route Cache.

    -  The Last Hop External (L) bit in the DSR Source Route header of option is
       copied from the new packet MUST be less than that External bit flagging the last hop in the first packet.

   When a node hears such a passive acknowledgment source
       route for any packet in its
   Maintenance Buffer, that node SHOULD remove that the packet, as well as
   any other packets indicated in its Maintenance Buffer with the same next-hop
   destination, from its Maintenance Buffer.

6.3.3. Using Network-Layer Acknowledgments

   When a node originates or forwards a Route Cache.

    -  The Salvage field in the DSR Source Route option is set to 1 plus
       the value of the Salvage field in the DSR Source Route option of
       the packet that caused the error.

    -  Transmit the packet and has no other
   mechanism of acknowledgment available to determine reachability of the next-hop node in on the new source route for Route Maintenance, that
       in the packet, using the forwarding procedure described in
       Section 8.1.5.

   As described in Section 8.3.4, the node in this case also SHOULD request
   return a network-layer acknowledgment from that next-hop
   node.  To do so, Route Error to the original sender of the packet.  If the
   node inserts an Acknowledgment Request option
   in chooses to salvage the DSR header in packet, it SHOULD do so after originating
   the packet.  The Identification field Route Error.

8.4. Multiple Interface Support

   A node in DSR MAY have multiple network interfaces that
   Acknowledgment Request option support
   ad hoc network routing.  This section describes special packet
   processing at such nodes.

   A node with multiple network interfaces MUST be set to a value unique over all have some policy for
   determining which Request packets transmitted by this are forwarded out which network
   interfaces.  For example, a node MAY choose to the same next-hop forward all Requests
   out all network interfaces.

   When a node that are
   either unacknowledged with multiple network interfaces propagates a Route
   Request on an network interface other than the one it received the
   Request on, it MUST modify the address list between receipt and
   re-propagation as follows:

    -  Append the address of the incoming interface

    -  If the incoming interface and outgoing interface differ in
       whether or not they require bidirectionality for unicast
       transmission, append the address 127.0.0.1

    -  If the incoming interface and outgoing interface differ in
       whether or recently acknowledged. not unidirectional links are common, append the
       address 127.0.0.2

    -  Append the address of the outgoing interface

   When a node receives forwards a packet containing an Acknowledgment Request
   option, then a source route, it MUST
   assume that node performs the following tests next hop is reachable on the packet:

    -  If incoming interface,
   unless the next hop is the indicated next-hop node address for this packet does not
       match any of one of this node's own IP addresses, then interfaces,
   in which case this node MUST
       NOT process the Acknowledgment Request option.  The indicated
       next-hop node address is the next Address[i] field in the DSR
       Source Route option packet in the DSR header in same way as if
   the packet, or node had just received it from that interface.

   If a node which previously had multiple network interfaces receives a
   packet sent with a source route specifying an interface change to an
   interface that is no longer available, it MAY send a Route Error to
   the IP
       Destination Address in source of the packet if without attempting to forward the packet does not contain
       a DSR Source Route option or on
   the Segments Left there is zero.

    -  If incoming interface, unless the packet contains network uses an Acknowledgment option, then this autoconfiguration
   mechanism that may have allowed another node
       MUST NOT process to acquire the Acknowledgment Request option.

   If neither now
   unused address of the tests above fails, then this node unavailable interface.

   Source routes MUST process the
   Acknowledgment Request option by sending an Acknowledgment option
   to the previous-hop node; to do so, never contain the special addresses 127.0.0.1 and
   127.0.0.2.

8.5. Fragmentation and Reassembly

   When a node performs using DSR wishes to fragment a packet that contains a DSR
   header not containing a Route Request option, it MUST perform the
   following sequence of steps:

    -  Create a packet and set the IP Protocol field to  Remove the protocol
       number assigned for a DSR Options header (TBA???).

    -  Set the IP Source Address field in this packet to the IP address
       of this node, copied from the source route in packet.

    -  Fragment the packet.

    -  IP-in-IP encapsulate each fragment.

    -  Add the DSR Options header to each fragment.  If a Source Route option
       header is present in that packet (or from the IP Destination Address
       field of the packet, if DSR Options header, increment the packet does not contain
       Salvage field.

   When a DSR Source
       Route option).

    -  Set node using the IP Destination Address field in this DSR protocol receives an IP-in-IP encapsulated
   packet destined to itself, it SHOULD decapsulate the IP
       address of the previous-hop node, copied from the source route packet and
   reassemble any fragments contained inside, in accordance with
   RFC 791 [30].

8.6. Flow State Processing

   A node implementing the optional DSR Source Route option in that packet (or from the IP
       Source Address field of the packet, if the flow state extension MUST follow
   these additional processing steps.

8.6.1. Originating a Packet

   When originating any packet does not
       contain to be routed using flow state, a node
   using DSR Source Route option). flow state MUST:

    -  Add  If the route to be used for this packet has never had a DSR header to the packet, and set
       flow state established along it (or the existing flow state has
       expired):

        o  Generate a 16-bit Flow ID larger than any unexpired Flow IDs
           used for this destination.  Odd Flow IDs MUST be chosen for
           "default" flows; even Flow IDs MUST be chosen for non-default
           flows.

        o  Add a DSR header's
       Next Header field to the "No Next Header" value.

    - Options header, as described in Section 8.1.2.

        o  Add an Acknowledgment option to the a DSR header Flow State header, as described in Section 8.6.2.

        o  Initialize the packet;
       set the Acknowledgment option's Option Type Hop Count field to 6 and in the
       Opt Data Len field DSR Flow State header
           to 10.

    -  Copy the Identification field from the received Acknowledgment
       Request option into 0.

        o  Set the Identification Flow ID field in the
       Acknowledgment option.

    -  Set DSR Flow State header to the ACK Source Address field
           Flow ID generated in the Acknowledgment first step.

        o  Add a Timeout option to
       be the IP DSR Options header.

        o  Add a Source Address of this new packet (set above to be the
       IP address of this node).

    -  Set the ACK Destination Address field in the Acknowledgment Route option to be after the IP Destination Address of this new packet (set
       above Timeout option.  with the
           route to be the IP address of the previous-hop node).

    -  Send the packet used, as described in Section 6.1.1.

   Packets containing an Acknowledgment option 8.1.3.

        o  The source SHOULD NOT be placed record this flow in
   the Maintenance Buffer.

   When a node receives a packet with both an Acknowledgment option and
   an Acknowledgment Request option, if that node its Flow Table.

        o  If this flow is not the destination
   of the Acknowledgment option (the IP Destination Address of recorded in the
   packet), then Flow Table, the Acknowledgment Request option TTL MUST be ignored.
   Otherwise (that node is the destination of the Acknowledgment
   option), that node MUST process the Acknowledgment Request option
   by returning an Acknowledgment option according to the following
   sequence of steps:

    -  Create a packet and
           set the IP Protocol field to be the protocol
       number assigned for a DSR header (TBA???).

    -  Set TTL of the IP Source Address field flow establishment packet.

        o  If this flow is recorded in this packet to the IP address
       of this node, copied from Flow Table, the source route in timeout MUST
           be set to a value no less than the DSR Source
       Route option value specified in that packet (or from the IP Destination Address
       field of the packet, if
           Timeout option.

    -  If the route to be used for this packet does has had DSR flow state
       established along it, but has not contain been established end-to-end:

        o  Add a DSR Source
       Route option).

    -  Set Options header, as described in Section 8.1.2.

        o  Add a DSR Flow State header, as described in Section 8.6.2.

        o  Initialize the IP Destination Address Hop Count field in this packet to the IP
       address of the node originating the Acknowledgment option.

    -  Add a DSR Flow State header
           to the packet, and set 0.

        o  The Flow ID field of the DSR header's
       Next Header field to Flow State header SHOULD be the "No Next Header" value.

    -
           Flow ID previously used for this route.  If it is not, the
           steps for sending packets along never before established
           routes MUST be followed in place of these.

        o  Add an Acknowledgment a Timeout option to the DSR header in this packet;
       set Options header, setting the Acknowledgment option's Option Type field
           Timeout to 6 and a value not greater than the
       Opt Data Len field to 10.

    -  Copy timeout remaining for
           this flow in the Identification field from Flow Table.

        o  Add a Source Route option after the received Acknowledgment
       Request Timeout option into with the Identification field
           route to be used, as described in Section 8.1.3

        o  If the IP TTL is not equal to the TTL specified in the
       Acknowledgment option. Flow
           Table, the source MUST set a flag to indicate that this flow
           cannot be used as default.

    -  Set  If the ACK Source Address field in route the option node wishes to be the IP
       Source Address of use for this new packet (set above to be has been
       established end-to-end and is not the IP address
       of this node).

    -  Set default flow:

        o  Add a DSR Flow State header, as described in Section 8.6.2.

        o  Initialize the ACK Destination Address Hop Count field in the option to be the IP
       Destination Address of this new packet (set above DSR Flow State header
           to be the IP
       address 0.

        o  The Flow ID field of the node originating the Acknowledgment option.)

    -  Send DSR Flow State header SHOULD be the packet directly to
           Flow ID previously used for this route.  If it is not, the destination.  The IP
       Destination Address
           steps for sending packets along never before established
           routes MUST be treated followed in place of these.

        o  If the next hop requires a Hop-by-Hop acknowledgement,
           add a DSR Options header, as described in Section 8.1.2,
           and an Acknowledgement Request option, as described in
           Section 8.3.3.

        o  A DSR Options header SHOULD NOT be added to a direct neighbor node:
       the transmission packet, unless
           it is added to that node MUST be done carry an Acknowledgement Request option, in a single IP
       forwarding hop, without
           which case:

            +  A Source Route Discovery and without searching option in the Route Cache.  In addition, this packet MUST NOT contain a DSR Acknowledgment Request, MUST Options header SHOULD
               NOT be retransmitted for Route
       Maintenance, and MUST NOT expect added.

            +  If a link-layer acknowledgment or
       passive acknowledgment.

   When using network-layer acknowledgments for Source Route Maintenance,
   a node SHOULD use an adaptive algorithm option in determining the
   retransmission timeout DSR Options header is
               added, the steps for each transmission attempt sending packets along routes not
               yet established end-to-end MUST be followed in place of an
   acknowledgment request.  For example, a node
               these.

            +  A Timeout option SHOULD maintain NOT be added.

            +  If a
   separate round-trip time (RTT) estimate for each to which it has
   recently attempted to transmit packets, and Timeout option is added, it SHOULD use this RTT
   estimate in setting MUST specify a timeout
               not greater than the timeout remaining for each retransmission attempt this flow in
               the Flow Table.

    -  If the route the node wishes to use for Route Maintenance.  The TCP RTT estimation algorithm this packet has been
   shown
       established end-to-end and is the current default flow:

        o  If the IP TTL is not equal to work well for this purpose the TTL specified in implementation and testbed
   experiments with DSR [20, 22].

6.3.4. Originating the Flow
           Table, the source MUST follow the steps for sending a Route Error

   When packet
           along a node is unable to verify reachability non-default flow that has been established end-to-end
           in place of these steps.

        o  If the next hop requires a next-hop Hop-by-Hop acknowledgement,
           the sending node after
   reaching a maximum number of retransmission attempts, MUST add a DSR Options header and
           an Acknowledgement Request option, as described in
           Section 8.3.3.  The sending node MUST NOT add any additional
           options to this header.

        o  A DSR Options header SHOULD
   send NOT be added, except as specified
           in the previous step.  If one is added in a Route Error to way inconsistent
           with the IP Source Address of previous step, the packet.  When
   sending a Route Error source MUST follow the steps
           for sending a packet containing either along a Route Error
   option or an Acknowledgment option, non-default flow that has been
           established end-to-end in place of these steps.

8.6.2. Inserting a DSR Flow State Header

   A node SHOULD add these existing
   options originating a packet adds a DSR Flow State header to its Route Error, subject the
   packet, if necessary, to carry information needed by the limit described below. routing
   protocol.  Only one DSR Flow State header may be in any packet.
   A node transmitting DSR Flow State header is added to a Route Error MUST perform packet by performing the
   following sequence of steps:

    -  Create an  Insert a DSR Flow State header after the IP packet header and set any
       Hop-by-Hop Options header that may already be in the Source Address packet, but
       before any other header that may be present.

    -  Set the Next Header field in this
       packet's IP of the DSR Flow State header to the address
       Next Header field of this node. the previous header (either an IP header or
       a Hop-by-Hop Options header).

    -  If  Set the Salvage Next Header field in of the previous header to the Protocol
       number assigned to DSR Source Route option in Options headers.

8.6.3. Receiving a Packet

   This section describes processing only for packets that are sent to
   the
       packet triggering processing node as the Route Error next-hop node; that is, when the MAC-layer
   destination address is zero, then copy the
       Source Address field MAC address of this node.  Otherwise, the
   process described in Sections 8.6.5 should be followed.

   The flow along which a packet triggering is being sent is considered to be in
   the Route Error
       into Flow Table if the triple (IP Source Address, IP Destination Address field
   Address, Flow ID) has an unexpired entry in the new packet's IP
       header; otherwise, copy Flow Table.

   When a node using DSR flow state receives a packet, it MUST follow
   the Address[1] field from following steps for processing:

    -  If a DSR Flow State header is present, increment the Hop Count
       field.

    -  In addition, if a DSR Flow State header is present, then if the DSR
       triple (IP Source Address, IP Destination Address, Flow ID) is
       in this node's Automatic Route option of Shortening Table and the packet triggering the Route Error into the
       Destination Address field
       is listed in the new packet's IP header

    -  Insert a DSR header into entry, then the new packet.

    -  Add node MAY send a gratuitous
       Route Error Option Reply as described in Section 4.4, subject to the new packet, setting rate
       limiting specified in Section 4.4.  This gratuitous Route Reply
       gives the Error
       Type to NODE_UNREACHABLE, route by which the Salvage value to packet originally reached this
       node.  Specifically, the Salvage
       value from node sending the DSR Source gratuitous Route option of Reply
       constructs the packet triggering route to return in the Route Error, and the Unreachable Node Address field to Reply as follows:

        o  Let k = (packet Hop Count) - (table Hop Count), where
           packet Hop Count is the address value of the next-hop node from the original source
       route.  Set the Error Source Address Hop Count field to in this node's IP
       address,
           received packet, and table Hop Count is the Error Destination field to the new packet's IP
       Destination Address.

    -  If the Hop Count value
           stored for this packet triggering in the corresponding entry in this
           node's Automatic Route Error contains any Route Error
       or Acknowledgment options, Shortening Table.

        o  Copy the node MAY append to its Route Error
       each of these options, with complete source route for this flow from the following constraints:
           corresponding entry in the node's Flow Table.

        o  The  Remove from this route the k hops immediately preceding this
           node MUST NOT include any in the route, since these are the hops "skipped over"
           by the packet as recorded in the Automatic Route Error option from Shortening
           Table entry.

    -  Process each of the
           packet triggering DSR options within the new DSR Options header in
       order:

        o  On receiving a Pad1 or PadN option, skip over the option

        o  On receiving a Route Error, Request for which this node is the total
           salvage count (Section 5.4) of that included
           destination, remove the option and return a Route Error
           would be greater than MAX_SALVAGE_COUNT Reply as
           specified in the new packet. Section 8.2.2.

        o  If any Route Error option from the packet triggering the new  On receiving a broadcast Route Error Request that this node has not
           previously seen for which this node is not included in the packet, destination,
           append this node's incoming interface address to the node MUST NOT
           include any following Route Error or Acknowledgment options
           from the packet triggering
           Request, continue propagating the new Route Error.

        o  Any appended options from Request as specified
           in Section 8.2.2, send the packet triggering payload, if any, to the network
           layer, and stop processing.

        o  On receiving a Route
           Error MUST follow Request that this node has not
           previously seen for which this node is not the new Route Error in destination,
           discard the packet. packet and stop processing.

        o  In appending these options  On receiving any Route Request, add appropriate links to the new
           cache, as specified in Section 8.2.2.

        o  On receiving a Route Error, Reply that this node is the order
           of these options Requester
           for, remove the Route Reply from the packet triggering the and process it as
           specified in Section 8.2.5.

        o  On receiving any Route Error
           MUST be preserved.

    -  Send Reply, add appropriate links to the packet
           cache, as described specified in Section 6.1.1.

6.3.5. Processing a Received 8.2.5.

        o  On receiving any Route Error Option

   When a node receives a packet containing of type NODE_UNREACHABLE,
           remove appropriate links to the cache, as specified in
           Section 8.3.5.

        o  On receiving a Route Error option, of type NODE_UNREACHABLE that
           this node MUST process is the Error Destination Address of, remove the
           Route Error option according to from the following
   sequence of steps:

    -  The node packet and process it as specified
           in Section 8.3.5.  It also MUST stop originating packets
           along any flows using the link from Error Source Address to
           Unreachable Node, and it MAY remove from its Route Cache Flow Table any
           flows using the link from the
       node identified by the Error Source Address field to the node
       identified by the Unreachable Node Address field (if
           Node.

        o  On receiving a Route Error of type UNKNOWN_FLOW that this link
           node is
       present in its Route Cache).  If not the Error Destination Address of, the node implements its Route
       Cache as a link cache, as described in Section 4.1, only this
       single link is removed; checks
           if the node implements its Route Cache as Error corresponds to a path cache, however, all routes (paths) that use this link are
       removed.

    - flow in its Flow Table.
           If it does not, the option following node silently discards the Route Error is an Acknowledgment
       or Route Error option sent by this node (that is, with
       Acknowledgment or Error Source Address equal Error;
           otherwise, it forwards the packet to this node's
       address), copy the DSR options following expected previous
           hop of the current corresponding flow.  If Route Error
       into a new packet with IP Source Address equal to this node's own
       IP address and IP Destination Address equal to Maintenance cannot
           confirm the reachability of the previous hop, the node checks
           if the network interface requires bidirectional links for
           operation.  If it does, the node silently discards the Error;
           otherwise, it sends the Acknowledgment
       or Error Destination Address.  Transmit this packet as if it were originating it,
           as described in Section 6.1.1, with the salvage count in the DSR Source 8.1.1.

        o  On receiving a Route
       option set to the Salvage value Error of type UNKNOWN_FLOW that this
           node is the Route Error.

   In addition, after processing Error Destination Address of, remove the Route
           Error as described above, from the node MAY initiate a new Route Discovery for any destination node
   for which it then has no route in its Route Cache packet and mark the flow specified by the
           triple (Error Destination Address, Original IP Destination
           Address, Flow ID) as not having been established end-to-end.

        o  On receiving a result Route Error of
   processing type DEFAULT_FLOW_UNKNOWN
           that this Route Error, if the node has indication that a route
   to that destination is needed.  For example, if not the Error Destination Address of, the
           node has an open
   TCP connection to some destination node, then checks if the processing of
   this Route Error removed corresponds to a flow in
           its Default Flow Table.  If it does not, the only route node silently
           discards the Route Error; otherwise, it forwards the packet
           to that destination from this
   node's the expected previous hop of the corresponding flow.
           If Route Cache, then this Maintenance cannot confirm the reachability of
           the previous hop, the node MAY initiate a new Route Discovery checks if the network interface
           requires bidirectional links for that destination node.  Any node, however, MUST limit operation.  If it does,
           the rate at
   which node silently discards the Error; otherwise, it initiates new Route Discoveries for any single destination
   address, and any new Route Discovery initiated in this way as part of
   processing this Route sends
           the Error MUST conform to this limit.

6.3.6. Salvaging a Packet

   When an intermediate node forwarding as if it were originating it, as described in
           Section 8.1.1.

        o  On receiving a packet detects through Route
   Maintenance Error of type DEFAULT_FLOW_UNKNOWN that
           this node is the next-hop link along Error Destination Address of, remove the
           Route Error from the route for that packet is
   broken (Section 6.3), if and mark the node has another route to default flow between
           the packet's Error Destination Address and the Original IP Destination
           Address in its Route Cache, as not having been established end-to-end.

        o  On receiving a Acknowledgement Request option, the receiving
           node SHOULD "salvage"
   the packet rather than discarding it.  To do so using removes the route found
   in its Route Cache, this node processes Acknowledgement Request option and replies
           to the packet as follows:

    - previous hop with a Acknowledgement option.  If the MAC protocol in use in
           previous hop cannot be determined, the network Acknowledgement
           Request option is not capable of
       transmitting unicast packets over unidirectional links, discarded, and processing continues.

        o  On receiving a Acknowledgement option, the receiving node
           removes the Acknowledgement option and processes it.

        o  On receiving any Acknowledgement option, add the appropriate
           link to the cache, as
       discussed specified in Section 3.3.1, then if this packet contains a 8.1.4

        o  On receiving any Source Route
       Reply option, remove and discard add appropriate links
           to the cache, as specified in Section 8.1.4.

        o  On receiving a Source Route Reply option in the
       packet; if the and either no DSR Flow
           State header in is present, the flow this packet then contains is being sent
           along is in the Flow Table, or no DSR
       options, remove Timeout option preceded the
           Source Route option in this DSR header from the packet.  If the resulting
       packet then contains only an IP Options header, process it
           as specified in Section 8.1.4.  Stop processing this packet
           unless the node SHOULD NOT
       salvage last address in the Source Route option is an
           address of this node.

        o  On receiving a Source Route option in a packet with a DSR
           Flow State header, and instead SHOULD discard the entire packet.

       When returning any Route Reply Flow ID specified in the case DSR Flow
           State header is not in which the MAC
       protocol in use in Flow Table, add the network is flow to the
           Flow Table, setting the Timeout value to a value not capable greater
           than the Timeout field of transmitting
       unicast packets over unidirectional links, the source route
       used for routing Timeout option in this header.
           If no Timeout option preceded the Source Route Reply packet option in this
           header, the flow MUST NOT be obtained by
       reversing added to the sequence of hops Flow Table.

           If the Flow ID is odd and larger than any unexpired, odd
           Flow IDs, it is set to be default in the Default Flow ID
           Table.

           Then process the Route Request option as specified in Section 8.1.4.
           Stop processing this packet (the
       source route that is then returned unless the last address in the
           Source Route Reply).  This
       restriction on returning a Route Reply and on salvaging option is an address of this node.

        o  On receiving a Timeout option, check if this packet
       that contains
           a Route Reply option enables the Route Reply to
       test DSR Flow State header.  If this sequence of hops for bidirectionality, preventing packet does not contain a
           DSR Flow State header, discard the
       Route Reply from being received by DSR option.  Otherwise,
           record the initiator of Timeout value in the Route
       Discovery unless each of option for future reference.
           The value recorded SHOULD be discarded when the hops over which node has
           finished processing this DSR Options header.  If the Route Reply flow
           that this packet is being sent along is
       returned (and thus each of the hops in the source route being
       returned Flow Table, it
           MAY set the flow to time out no more than Timeout seconds in
           the Reply) is bidirectional.

    -  Modify future.

        o  On receiving a Destination and Flow ID option, if the existing DSR Source Route option in
           IP Destination Address is not an address of this node,
           forward the packet so
       that the Address[i] fields represent according to the source route found Flow ID, as described in
           Section 8.6.4, and stop processing this node's Route Cache to this packet's IP packet.

        o  On receiving a Destination Address.
       Specifically, the node copies and Flow ID option, if the hop addresses IP
           Destination Address is an address of this node, set the source
       route into sequential Address[i] fields
           IP Destination Address to the New IP Destination Address
           specified in the DSR Source Route option, for i = 1, 2, ..., n.  Address[1] here is and set the address
       of Flow ID to the salvaging node itself (the first address in New
           Flow Identifier.  Then remove the source
       route found DSR option from this node to the packet
           and continue processing.

    -  If the IP Destination Address of the
       packet).  The value n here is the number an address of hop addresses in this
       source route, excluding node, remove
       the destination of DSR Options header, if any, and pass the packet (which up the
       network stack and stop processing.

    -  If there is
       instead already represented still a DSR Options header containing no options,
       remove the DSR Options header.

    -  If there is still a DSR Flow State header, forward the packet
       according to the Flow ID, as described in Section 8.6.4.

    -  If there is neither a DSR Options header nor a DSR Flow State
       header, but there is an entry in the Default Flow Table for the
       (IP Source Address, IP Destination Address field in Address) pair:

        o  If the packet's IP header).

    -  Initialize TTL is not equal to the Segments Left field TTL expected in the Flow
           Table, insert a DSR Source Route option Flow State header, setting Hop Count
           equal to n as defined above.

    -  The First the Hop External (F) bit in Count of this node, and the DSR Source Route option is
       copied from Flow ID equal
           to the External bit flagging default Flow ID found in the first hop table, and forward
           this packet according to the Flow ID, as described in
           Section 8.6.4.

        o  Otherwise, follow the source
       route steps for forwarding the packet, as indicated packet using
           Flow IDs described in Section 8.6.4, but taking the Route Cache.

    -  The Last Hop External (L) bit Flow ID
           to be the default Flow ID found in the DSR Source Route option table.

    -  If there is
       copied from the External bit flagging no DSR Options header, no DSR Flow State header, and
       no default flow can be found, the last hop in node returns a Route Error of
       type Default Flow Unknown to the source
       route for IP Source Address, specifying
       the packet, IP Destination Address as indicated in the Route Cache.

    -  The Salvage field Original IP Destination in the DSR Source Route option is set to 1 plus
       type-specific field.

8.6.4. Forwarding a Packet Using Flow IDs

   To forward a packet using Flow IDs, a node MUST follow the value following
   sequence of steps:

    -  If the Salvage field triple (IP Source Address, IP Destination Address,
       Flow ID) is not in the DSR Source Flow Table, return a Route option Error of
       the packet that caused the error. type
       Unknown Flow.

    -  Transmit  If a hop-by-hop acknowledgement is required for the packet to next hop, the next-hop
       node on the new source route MUST include an Acknowledegment Request option as specified
       in Section 8.3.3.  If no DSR Options header is in the packet, using packet for
       the forwarding procedure described in
       Section 6.1.5.

   As Acknowledgement Request option to be attached to, it MUST be
       included, as described in Section 6.3.4, 8.1.2, except that it MUST be
       added after the node in this case also SHOULD
   return a Route Error DSR Flow State header, if one is present.

    -  Attempt to the original sender of the packet.  If the
   node chooses transmit this packet to salvage the packet, it SHOULD do so after originating next hop as specified in
       the Flow Table, performing Route Error.

7. Multiple Interface Support

   A node in DSR MAY have multiple network interfaces that support
   ad hoc network routing. Maintenance to detect broken
       routes.

8.6.5. Promiscuously Receiving a Packet

   This section describes special packet processing at such nodes.

   A node with multiple network interfaces MUST have some policy only for
   determining which Request packets are forwarded out which network
   interfaces.  For example, a node MAY choose to forward all Requests
   out all network interfaces.

   When a node with multiple network interfaces propagates a Route
   Request on an network interface that have MAC
   destinations other than the one it received the
   Request on, it MUST modify the address list between receipt and
   re-propagation as follows:

    -  Append the address of the incoming interface

    -  If the incoming interface and outgoing interface differ in
       whether or not they require bidirectionality for unicast
       transmission, append the address 127.0.0.1

    -  If processing node.  Otherwise, the incoming interface and outgoing interface differ process
   described in
       whether or not unidirectional links are common, append the
       address 127.0.0.2

    -  Append the address of the outgoing interface Section 8.6.3 should be followed.

   When a node forwards using DSR flow state promiscuously overhears a packet, it
   SHOULD follow the following steps for processing:

    -  If the packet containing contains a source route, it MUST
   assume that DSR Flow State header, and if the next hop triple
       (IP Source Address, IP Destination Address, Flow ID) is reachable on in the incoming interface,
   unless
       Flow Table and the next hop Hop Count is less than the address of one of this node's interfaces, Hop Count in which case this the
       flow's entry, the node MUST process MAY retain the packet in the same way as if
   the node had just received Automatic
       Route Shortening Table.  If it from can be determined that interface. this
       Flow ID has been recently used, it SHOULD retain the packet in
       the Automatic Route Shortening Table.

    -  If a node which previously had multiple network interfaces receives a the packet sent with contains neither a source route specifying an interface change to an
   interface that is no longer available, it MAY send DSR Flow State header nor a
       Source Route Error to
   the source of the packet without attempting to forward option, and a Default Flow ID can be found in
       the packet on Default Flow Table for (IP Source Address, IP Destination
       Address), and the incoming interface, unless IP TTL is greater than the network uses an autoconfiguration
   mechanism that may have allowed another node to acquire TTL in the now
   unused address of table
       for the unavailable interface.

   Source routes MUST never contain default flow, the special addresses 127.0.0.1 and
   127.0.0.2.

8. Fragmentation and Reassembly

   When a node using DSR wishes to fragment a MAY retain the packet that contains a DSR
   header not containing a in the
       Automatic Route Request option, Shortening Table.  If it MUST perform can be determined that
       this Flow ID has been used recently, the
   following sequence of steps:

    -  Remove node SHOULD retain the DSR header from
       packet in the packet.

    -  Fragment Automatic Route Shortening Table.

8.6.6. Operation where the packet.

    -  IP-in-IP encapsulate each fragment.

    -  Add Layer below DSR Decreases
       the IP TTL Non-Uniformly

   Some nodes may use an IP tunnel as a DSR header to each fragment. hop.  If different packets
   sent along this IP tunnel can take different routes, the reduction
   in IP TTL across this link may be different for different packets.
   This prevents the Automatic Route Shortening and Loop Detection
   functionality from working properly when used in conjunction with
   default routes.

   Nodes forwarding packets without a Source Route option onto a link
   with unpredictable TTL changes MUST ensure that a DSR Flow State
   header is
       present in present, indicating the correct Hop Count and Flow ID.

8.6.7. Salvage Interactions with DSR

   Nodes salvaging packets MUST remove the DSR Flow State header, increment if
   present.

   Any time this document refers to the Salvage field.

   When a node using field in the DSR protocol receives an IP-in-IP encapsulated
   packet destined Source
   Route option, packets without a Source Route option are considered to itself, it SHOULD decapsulate
   have the packet and
   reassemble any fragments contained inside, value zero in accordance with
   RFC 791 [27]. the Salvage field.

9. Protocol Constants and Configuration Variables

   Any DSR implementation MUST support the following configuration
   variables and MUST support a mechanism enabling the value of these
   variables to be modified by system management.  The specific variable
   names are used for demonstration purposes only, and an implementation
   is not required to use these names for the configuration variables,
   so long as the external behavior of the implementation is consistent
   with that described in this document.

   For each configuration variable below, the default value is specified
   to simplify configuration.  In particular, the default values given
   below are chosen for a DSR network running over 2 Mbps IEEE 802.11
   network interfaces using the Distributed Coordination Function (DCF)
   MAC with RTS and CTS [11, [13, 5].

       BroadcastJitter                     10   milliseconds

       RouteCacheTimeout                  300   seconds

       SendBufferTimeout                   30   seconds

       RequestTableSize                    64   nodes
       RequestTableIds                     16   identifiers
       MaxRequestRexmt                     16   retransmissions
       MaxRequestPeriod                    10   seconds
       RequestPeriod                      500   milliseconds
       NonpropRequestTimeout               30   milliseconds

       RexmtBufferSize                     50   packets

       MaintHoldoffTime                   250   milliseconds

       MaxMaintRexmt                        2   retransmissions

       TryPassiveAcks                       1   attempt
       PassiveAckTimeout                  100   milliseconds

       GratReplyHoldoff                     1   second

   In addition, the following protocol constant MUST be supported by any
   implementation of the DSR protocol:

       MAX_SALVAGE_COUNT                   15   salvages

10. IANA Considerations

   This document proposes specifies the DSR Options header, which requires an IP
   Protocol number.

   This document also specifies the use of a DSR Flow State header, which
   requires an IP Protocol number.

   In addition, this document proposes use of the value "No Next Header"
   (originally defined for use for use in IPv6) within an IPv4 packet, to
   indicate that no further header follows a DSR Options header.

   Finally, this document introduces a number of DSR options for use in
   the DSR Options header, and additional new DSR options may be defined
   in the future.  Each of these options requires a unique Option Type
   value, with the most significant 3 bits (that is, Option Type & 0xE0)
   encoded as defined in IPv6) within an IPv4 packet, to
   indicate Section 6.1.  It is necessary only that no further header follows a DSR header. each
   Option Type value be unique, not that they be unique in the remaining
   5 bits of the value after these 3 most significant bits.

11. Security Considerations

   This document does not specifically address security concerns.  This
   document does assume that all nodes participating in the DSR protocol
   do so in good faith and without malicious intent to corrupt the
   routing ability of the network.  In mission-oriented environments

   Depending on the threat model, a number of different mechanisms can
   be used to secure DSR.  For example, in an environment where node
   compromise is unrealistic and where where all the nodes participating
   in the DSR protocol share a common goal that motivates their
   participation in the protocol, the communications between the nodes
   can be encrypted at the physical channel or link layer to prevent
   attack by outsiders.  Cryptographic approaches, such as that provided
   by Ariadne [12] or SRP [26], can resist stronger attacks.

Appendix A. Link-MaxLife Cache Description

   As guidance to implementors of DSR, the description below outlines
   the operation of a possible implementation of a Route Cache for DSR
   that has been shown to outperform other other caches studied in
   detailed simulations.  Use of this design for the Route Cache is
   recommended in implementations of DSR.

   This cache, called "Link-MaxLife" [9], [10], is a link cache, in that each
   individual link (hop) in the routes returned in Route Reply packets
   (or otherwise learned from the header of overhead packets) is added
   to a unified graph data structure of this node's current view of the
   network topology, as described in Section 4.1.  To search for a route
   in this cache to some destination node, the sending node uses a graph
   search algorithm, such as the well-known Dijkstra's shortest-path
   algorithm, to find the current best path through the graph to the
   destination node.

   The Link-MaxLife form of link cache is adaptive in that each link in
   the cache has a timeout that is determined dynamically by the caching
   node according to its observed past behavior of the two nodes at the
   ends of the link; in addition, when selecting a route for a packet
   being sent to some destination, among cached routes of equal length
   (number of hops) to that destination, Link-MaxLife selects the route
   with the longest expected lifetime (highest minimum timeout of any
   link in the route).

   Specifically, in Link-MaxLife, a link's timeout in the Route Cache
   is chosen according to a "Stability Table" maintained by the caching
   node.  Each entry in a node's Stability Table records the address of
   another node and a factor representing the perceived "stability" of
   this node.  The stability of each other node in a node's Stability
   Table is initialized to InitStability.  When a link from the Route
   Cache is used in routing a packet originated or salvaged by that
   node, the stability metric for each of the two endpoint nodes of that
   link is incremented by the amount of time since that link was last
   used, multiplied by StabilityIncrFactor (StabilityIncrFactor >= 1);
   when a link is observed to break and the link is thus removed
   from the Route Cache, the stability metric for each of the two
   endpoint nodes of that link is multiplied by StabilityDecrFactor
   (StabilityDecrFactor < 1).

   When a node adds a new link to its Route Cache, the node assigns a
   lifetime for that link in the Cache equal to the stability of the
   less "stable" of the two endpoint nodes for the link, except that a
   link is not allowed to be given a lifetime less than MinLifetime.
   When a link is used in a route chosen for a packet originated or
   salvaged by this node, the link's lifetime is set to be at least
   UseExtends into the future; if the lifetime of that link in the
   Route Cache is already further into the future, the lifetime remains
   unchanged.

   When a node using Link-MaxLife selects a route from its Route Cache
   for a packet being originated or salvaged by this node, it selects
   the shortest-length route that has the longest expected lifetime
   (highest minimum timeout of any link in the route), as opposed to
   simply selecting an arbitrary route of shortest length.

   The following configuration variables are used in the description
   of Link-MaxLife above.  The specific variable names are used for
   demonstration purposes only, and an implementation is not required
   to use these names for these configuration variables.  For each
   configuration variable below, the default value is specified to
   simplify configuration.  In particular, the default values given
   below are chosen for a DSR network where nodes move at relative
   velocities between 12 and 25 seconds per transmission radius.

       InitStability                       25   seconds
       StabilityIncrFactor                  4
       StabilityDecrFactor                  2

       MinLifetime                          1   second
       UseExtends                         120   seconds

Appendix B. Location of DSR in the ISO Network Reference Model

   When designing DSR, we had to determine at what layer within
   the protocol hierarchy to implement ad hoc network routing.  We
   considered two different options:  routing at the link layer (ISO
   layer 2) and routing at the network layer (ISO layer 3).  Originally,
   we 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 between IPv4 [27], [30], IPv6 [6], [7], and IPX [32] [35] nodes.

    -  Historically [13, 14], [15, 16], DSR grew from our contemplation of
       a multi-hop propagating version of the Internet's Address
       Resolution Protocol (ARP) [25], [28], as well as from the routing
       mechanism used in IEEE 802 source routing bridges [24]. [27].  These
       are layer 2 protocols.

    -  Technically, we designed DSR to be simple enough that it could
       be implemented directly in the firmware inside wireless network
       interface cards [13, 14], [15, 16], well below the layer 3 software within
       a mobile node.  We see 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, we decided to specify and to implement [20] [22]
   DSR as a layer 3 protocol, since this is the only layer at which we
   could realistically support nodes with multiple network interfaces of
   different types forming an ad hoc network.

Appendix C. Implementation and Evaluation Status

   The initial design of the DSR protocol, including DSR's basic Route
   Discovery and Route Maintenance mechanisms, was first published in
   December 1994 [13], [15], with significant additional design details and
   initial simulation results published in early 1996 [14]. [16].

   The DSR protocol has been extensively studied since then through
   additional detailed simulations.  In particular, we have implemented
   DSR in the ns-2 network simulator [23, [25, 5] and performed extensive
   simulations of DSR using ns-2 (e.g., [5, 19]). 21]).  We have also
   conducted evaluations of the different caching strategies documented in this draft [9].
   document [10].

   We have also implemented the DSR protocol under the FreeBSD 2.2.7
   operating system running on Intel x86 platforms.  FreeBSD [8] [9] is
   based on a variety of free software, including 4.4 BSD Lite from the
   University of California, Berkeley.  For the environments in which
   we used it, this implementation is functionally equivalent to the
   version of the DSR protocol specified in this draft. document.

   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, in an actively
   mobile ad hoc network under realistic communication workloads.  The
   last week of February and the first week of March of 1999 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 [20]. [22].

   We have since ported this implementation of DSR to FreeBSD 3.3, and
   we have also added a preliminary version of Quality of Service (QoS)
   support for DSR.  A demonstration of this modified version of DSR was
   presented in July 2000.  These QoS features are not included in this
   draft,
   document, and will be added later in a separate draft document on top of
   the base protocol specified here.

   DSR has also been implemented under Linux by Alex Song at the
   University of Queensland, Australia [31]. [34].  This implementation
   supports the Intel x86 PC platform and the Compaq iPAQ.

   The Network and Telecommunications Research Group at Trinity College
   Dublin have implemented a version of DSR on Windows CE.

   Microsoft Research has implemented a version of DSR on Windows XP,
   and has used it in testbeds of over 15 nodes.  Several machines use
   this implementation as their primary means of accessing the Internet.

   Several other independent groups have also used DSR as a platform for
   their own research, or and as a basis of comparison between ad hoc
   network routing protocols.

   A preliminary version of the optional DSR flow state extension was
   implemented in FreeBSD 3.3.  A demonstration of this modified version
   of DSR was presented in July 2000.  The DSR flow state extension has
   also been extensively evaluated using simulation [11].

Changes from Previous Version of the Draft

   This appendix briefly lists some of the major changes in this
   draft relative to the previous version of this same draft,
   draft-ietf-manet-dsr-06.txt:

    -  Added this same draft,
   draft-ietf-manet-dsr-07.txt:

    -  Integrated the specification of the DSR flow state extension into
       the main DSR draft.  Previously, these had been specified in a
       separate draft.

    -  Included processing directions for unknown Option Types.

    -  Changed the name of the DSR header to DSR Options header, to
       clarify it as a separate header type from the DSR Flow State
       header.

    -  Slightly changed the format of the DSR Options header and the DSR
       Flow State header to allow the same IP protocol number to be used
       for both.  The new Flow State Header (F) bit in the two headers
       indicates which type of header is being used (the bit is clear in
       a blacklist mechanism for handling unidirectional links
       when the network interface requires bidirectionality.

    -  Added language describing multiple interface support.

    -  Described fragmentation and reassembly processing.

    -  Updated the implementation DSR Options header and evaluation list. set in a DSR Flow State header).

Acknowledgements

   The protocol described in this draft document has been designed and
   developed within the Monarch Project, a research project at Rice
   University (previously at Carnegie Mellon University) that is
   developing adaptive networking protocols and protocol interfaces to
   allow truly seamless wireless and mobile node networking [15, 30]. [17, 33].

   The authors would like to acknowledge the substantial contributions
   of Josh Broch in helping to design, simulate, and implement the DSR
   protocol.  Josh is currently on leave of absence from Carnegie Mellon
   University at AON Networks.  We thank him for his contributions to earlier versions of
   this draft. document.

   We would also like to acknowledge the assistance of Robert V. Barron
   at Carnegie Mellon University.  Bob ported our DSR implementation
   from FreeBSD 2.2.7 into FreeBSD 3.3.

   Many valuable suggestions came from participants in the IETF process.
   We would particularly like to acknowledge Fred Baker, who provided
   extensive feedback on our a previous draft, version of this document, as well as
   the working group chairs, for their suggestions of previous versions
   of the draft. document.

References

    [1] David F. Bantz and Frederic J. Bauchot.  Wireless LAN Design
        Alternatives.  IEEE Network, 8(2):43--53, March/April 1994.

    [2] Vaduvur Bharghavan, Alan Demers, Scott Shenker, and Lixia
        Zhang.  MACAW: A Media Access Protocol for Wireless LAN's.  In
        Proceedings of the ACM SIGCOMM '94 Conference, pages 212--225,
        August 1994.

    [3] Robert T. Braden, editor.  Requirements for Internet
        Hosts---Communication Layers.  RFC 1122, October 1989.

    [4] Scott Bradner.  Key words for use in RFCs to Indicate
        Requirement Levels.  RFC 2119, March 1997.

    [5] Josh Broch, David A. Maltz, David B. Johnson, Yih-Chun Hu,
        and Jorjeta Jetcheva.  A Performance Comparison of Multi-Hop
        Wireless Ad Hoc Network Routing Protocols.  In Proceedings of
        the Fourth Annual ACM/IEEE International Conference on Mobile
        Computing and Networking, pages 85--97, October 1998.

    [6] David D. Clark.  The Design Philosophy of the DARPA Internet
        Protocols.  In Proceedings of the ACM SIGCOMM '88 Conference,
        pages 106--114, August 1988.

    [7] Stephen E. Deering and Robert M. Hinden.  Internet Protocol
        Version 6 (IPv6) Specification.  RFC 2460, December 1998.

    [7]

    [8] Ralph Droms.  Dynamic Host Configuration Protocol.  RFC 2131,
        March 1997.

    [8]

    [9] The FreeBSD Project.  Project web page available at
        http://www.freebsd.org/.

    [9]

   [10] Yih-Chun Hu and David B. Johnson.  Caching Strategies in
        On-Demand Routing Protocols for Wireless Ad Hoc Networks.  In
        Proceedings of the Sixth Annual ACM International Conference on
        Mobile Computing and Networking, August 2000.

   [10]

   [11] Yih-Chun Hu, David B. Johnson, Hu and David A. Maltz.  Flow
        State B. Johnson.  Implicit Source Routing
        in On-Demand Ad Hoc Network Routing.  In Proceedings of the Dynamic Source
        Second Symposium on Mobile Ad Hoc Networking and Computing
        (MobiHoc 2001), pages 1--10, October 2001.

   [12] Yih-Chun Hu, Adrian Perrig, and David B. Johnson.  Ariadne:
        A Secure On-Demand Routing Protocol for Mobile Ad Hoc Networks.  Internet-Draft, draft-ietf-manet-dsrflow-00.txt,
        February 2001.  Work in progress.

   [11]  In
        Proceedings of the Eighth Annual International Conference on
        Mobile Computing and Networking (MobiCom 2002), pages 12--23,
        September 2002.

   [13] 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.

   [12]

   [14] Per Johansson, Tony Larsson, Nicklas Hedman, Bartosz Mielczarek,
        and Mikael Degermark.  Scenario-based Performance Analysis of
        Routing Protocols for Mobile Ad-hoc Networks.  In Proceedings
        of the Fifth Annual ACM/IEEE International Conference on Mobile
        Computing and Networking, pages 195--206, August 1999.

   [13]

   [15] 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, December 1994.

   [14]

   [16] David B. Johnson and David A. Maltz.  Dynamic Source Routing in
        Ad Hoc Wireless Networks.  In Mobile Computing, edited by Tomasz
        Imielinski and Hank Korth, chapter 5, pages 153--181. Kluwer
        Academic Publishers, 1996.

   [15]

   [17] David B. Johnson and David A. Maltz.  Protocols for Adaptive
        Wireless and Mobile Networking.  IEEE Personal Communications,
        3(1):34--42, February 1996.

   [16]

   [18] John Jubin and Janet D. Tornow.  The DARPA Packet Radio Network
        Protocols.  Proceedings of the IEEE, 75(1):21--32, January 1987.

   [17]

   [19] Phil Karn.  MACA---A New Channel Access Method for Packet Radio.
        In ARRL/CRRL Amateur Radio 9th Computer Networking Conference,
        pages 134--140, September 1990.

   [18]

   [20] Gregory S. Lauer.  Packet-Radio Routing.  In Routing in
        Communications Networks, edited by Martha E. Steenstrup,
        chapter 11, pages 351--396. Prentice-Hall, Englewood Cliffs,
        New Jersey, 1995.

   [19]

   [21] David A. Maltz, Josh Broch, Jorjeta Jetcheva, and David B.
        Johnson.  The Effects of On-Demand Behavior in Routing Protocols
        for Multi-Hop Wireless Ad Hoc Networks.  IEEE Journal on
        Selected Areas of Communications, 17(8):1439--1453, August 1999.

   [20]

   [22] David A. Maltz, Josh Broch, and David B. Johnson.  Experiences
        Designing and Building a Multi-Hop Wireless Ad Hoc Network
        Testbed.  Technical Report CMU-CS-99-116, School of Computer
        Science, Carnegie Mellon University, Pittsburgh, Pennsylvania,
        March 1999.

   [21]

   [23] David A. Maltz, Josh Broch, and David B. Johnson.  Quantitative
        Lessons From a Full-Scale Multi-Hop Wireless Ad Hoc Network
        Testbed.  In Proceedings of the IEEE Wireless Communications and
        Networking Conference, September 2000.

   [22]

   [24] David A. Maltz, Josh Broch, and David B. Johnson.  Lessons From
        a Full-Scale MultiHop Wireless Ad Hoc Network Testbed.  IEEE
        Personal Communications, 8(1):8--15, February 2001.

   [23]

   [25] The Network Simulator -- ns-2.  Project web page available at
        http://www.isi.edu/nsnam/ns/.

   [24]

   [26] Panagiotis Papadimitratos and Zygmunt J. Haas.  Secure Routing
        for Mobile Ad Hoc Networks.  In SCS Communication Networks and
        Distributed Systems Modeling and Simulation Conference (CNDS
        2002), January 2002.

   [27] Radia Perlman.  Interconnections:  Bridges and Routers.
        Addison-Wesley, Reading, Massachusetts, 1992.

   [25]

   [28] David C. Plummer.  An Ethernet Address Resolution Protocol:
        Or Converting Network Protocol Addresses to 48.bit Ethernet
        Addresses for Transmission on Ethernet Hardware.  RFC 826,
        November 1982.

   [26]

   [29] J. B. Postel, editor.  Internet Control Message Protocol.
        RFC 792, September 1981.

   [27]

   [30] J. B. Postel, editor.  Internet Protocol.  RFC 791, September
        1981.

   [28]

   [31] J. B. Postel, editor.  Transmission Control Protocol.  RFC 793,
        September 1981.

   [29]

   [32] Joyce K. Reynolds and Jon Postel.  Assigned Numbers.  RFC 1700,
        October 1994.  See also http://www.iana.org/numbers.html.

   [30]

   [33] Rice University Monarch Project.  Monarch Project Home Page.
        Available at http://www.monarch.cs.rice.edu/.

   [31]

   [34] Alex Song.  picoNet II: A Wireless Ad Hoc Network for Mobile
        Handheld Devices.  Submitted for the degree of Bachelor of
        Engineering (Honours) in the division of Electrical Engineering,
        Department of Information Technology and Electrical Engineering,
        University of Queensland, Australia, October 2001.  Available at
        http://student.uq.edu.au/~s369677/main.html.

   [32]

   [35] Paul Turner.  NetWare Communications Processes.  NetWare
        Application Notes, Novell Research, pages 25--91, September
        1990.

   [33]

   [36] Gary R. Wright and W. Richard Stevens.  TCP/IP Illustrated,
        Volume 2:  The Implementation.  Addison-Wesley, Reading,
        Massachusetts, 1995.

Chair's Address

   The MANET Working Group can be contacted via its current chairs:

   M. Scott Corson                        Phone: +1 908 947-7033
   Flarion Technologies, Inc.             Email: corson@flarion.com
   Bedminster One
   135 Route 202/206 South
   Bedminster, NJ  07921
   USA

   Joseph Macker                          Phone: +1 202 767-2001
   Information Technology Division        Email: macker@itd.nrl.navy.mil
   Naval Research Laboratory
   Washington, DC  20375
   USA

Authors' Addresses

   Questions about this document can also be directed to the authors:

   David B. Johnson                       Phone: +1 713 348-3063
   Rice University                        Fax:   +1 713 348-5930
   Computer Science Department, MS 132    Email: dbj@cs.rice.edu
   6100 Main Street
   Houston, TX 77005-1892
   USA

   David A. Maltz                         Phone: +1 650 688-3128
   AON Networks 412 268-5329
   Carnegie Mellon University             Fax:   +1 650 688-3119
   3045 Park Blvd. 412 268-5576
   Computer Science Department            Email: dmaltz@cs.cmu.edu
   Palo Alto, CA 94306
   5000 Forbes Avenue
   Pittsburgh, PA 15213
   USA

   Yih-Chun Hu                            Phone: +1 412 268-3075
   Rice University                        Fax:   +1 412 268-5576
   Computer Science Department, MS 132    Email: yihchun@cs.cmu.edu
   6100 Main Street
   Houston, TX 77005-1892
   USA

   Jorjeta G. Jetcheva                    Phone: +1 412 268-3053
   Carnegie Mellon University             Fax:   +1 412 268-5576
   Computer Science Department            Email: jorjeta@cs.cmu.edu
   5000 Forbes Avenue
   Pittsburgh, PA  15213-3891
   USA