dsr_draft1.txt

来自「dsr路协议规范」· 文本 代码 · 共 1,527 行 · 第 1/5 页

   The Route Request Table on a node records the following information
   about nodes to which this node has initiated a Route Request:

    -  The time that this node last originated a Route Request for that
       target node.

    -  The number of consecutive Route Requests initiated for this
       target since receiving a valid Route Reply giving a route to that
       target node.

    -  The remaining amount of time before which this node MAY next
       attempt at a Route Discovery for that target node.

    -  The Time-to-Live (TTL) field used in the IP header of last Route
       Request initiated by this node for that target node.

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

    -  A FIFO cache of size REQUEST_TABLE_IDS 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 Table.

   The number of Identification values to retain in each Route Request
   Table entry, REQUEST_TABLE_IDS, MUST NOT be unlimited, since,
   in the worst case, when a node crashes and reboots, the first
   REQUEST_TABLE_IDS Route Discoveries it initiates after rebooting
   could appear to be duplicates to the other nodes in the network.
   In addition, a node SHOULD base its initial Identification value,
   used for 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 node SHOULD base its initial Identification value after
   rebooting on a random number.


4.3. 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 each such packet's destination.  Each packet in the Send
   Buffer is logically associated with the time that it was placed into
   the Buffer, and SHOULD be removed from the Send Buffer and silently
   discarded SEND_BUFFER_TIMEOUT seconds after initially being placed in




Johnson, et al            Expires 2 September 2001             [Page 18]
 
INTERNET-DRAFT     The Dynamic Source Routing Protocol      2 March 2001


   the 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 6.2, a Route
   Discovery SHOULD be initiated as often as possible for the
   destination address of any packets residing in the Send Buffer.


4.4. Retransmission Buffer

   The Retransmission Buffer of a node implementing DSR is a queue
   of packets sent by this node that are awaiting the receipt of an
   acknowledgment from the next hop in the source route (Section 5.7).
   For each packet in the Retransmission Buffer, a node maintains (1) a
   count of the number of retransmissions and (2) the time of the last
   retransmission.

   Packets are removed from the Retransmission Buffer when an
   acknowledgment is received or when the number of retransmissions
   exceeds DSR_MAXRXTSHIFT.  In the later case, the removal of the
   packet from the Retransmission Buffer SHOULD result in a Route Error
   being returned to the original source of the packet (Section 6.3).































Johnson, et al            Expires 2 September 2001             [Page 19]
 
INTERNET-DRAFT     The Dynamic Source Routing Protocol      2 March 2001


5. DSR Header Format

   The Dynamic Source Routing protocol makes use of a special header
   carrying control information that can be included in any existing IP
   packet.  This DSR header in a packet contains a small fixed-sized,
   4-octet portion, followed by a sequence of zero or more DSR options
   carrying optional information.  The end of the sequence of DSR
   options in the DSR header is implied by total length of the DSR
   header.

   The DSR header is inserted in the packet following the packet's IP
   header, before any following header such as a traditional (e.g., TCP
   or UDP) transport layer header.  Specifically, the Protocol field
   in the IP header is used to indicate that a DSR header follows the
   IP header, and the Next Header field in the DSR header is used to
   indicate the type of protocol header (such as a transport layer
   header) following the DSR header.

   The total length of the DSR header (and thus the total, combined
   length of all DSR options present) MUST be a multiple of 4 octets.
   This requirement preserves the alignment of any following headers in
   the packet.































Johnson, et al            Expires 2 September 2001             [Page 20]
 
INTERNET-DRAFT     The Dynamic Source Routing Protocol      2 March 2001


5.1. Fixed Portion of DSR Header

   The fixed portion of the DSR header is used to carry information that
   must be present in any DSR header.  This fixed portion of the 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 the DSR header.  Uses the same values as the IPv4
         Protocol field [26].

      Reserved

         Sent as 0; ignored on reception.

      Payload Length

         The length of the DSR header, excluding the 4-octet fixed
         portion.  The value of the Payload Length field defines the
         total length of all options carried in the DSR header.

      Options

         Variable-length field; the length of the Options field is
         specified by the Payload Length field in this DSR header.
         Contains one or more pieces of optional information (DSR
         options), encoded in type-length-value (TLV) format (with the
         exception of the Pad1 option, described in Section 5.8).

   The placement of DSR options following the fixed portion of the DSR
   header MAY be padded for alignment.  However, due to the typically
   limited available wireless bandwidth in ad hoc networks, this padding
   is not required, and receiving nodes MUST NOT expect options within
   a DSR header to be aligned.  A node inserting a DSR header into
   a packet MUST set the Don't Fragment (DF) bit in the packet's IP
   header.

   The following types of DSR options are defined in this document for
   use within a DSR header:



Johnson, et al            Expires 2 September 2001             [Page 21]
 
INTERNET-DRAFT     The Dynamic Source Routing Protocol      2 March 2001


    -  Route Request option (Section 5.2)

    -  Route Reply option (Section 5.3)

    -  Route Error option (Section 5.4)

    -  Acknowledgement Request option (Section 5.5)

    -  Acknowledgement option (Section 5.6)

    -  Source Route option (Section 5.7)

    -  Pad1 option (Section 5.8)

    -  PadN option (Section 5.9)






































Johnson, et al            Expires 2 September 2001             [Page 22]
 
INTERNET-DRAFT     The Dynamic Source Routing Protocol      2 March 2001


5.2. Route Request Option

   The Route Request DSR option 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                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-