The source node records this flow in its Flow Table for future use, setting the TTL in this Flow Table entry to the value used in the TTL field in the packet's IP header and setting the Lifetime in this entry to the lifetime specified in the Timeout option in the DSR Options header. The TTL field is used for Default Flow Forwarding, as described in Sections 3.5.3 and 3.5.4. Any further packets sent with this flow ID before the timeout that also contain a DSR Options header with a Source Route option MUST use this same source route in the Source Route option. Section 3.5.1, contain a DSR Options header with a Source Route option and are forwarded along the indicated route. A node implementing the DSR flow state extension, when receiving and forwarding such a DSR packet, also keeps some state in its own Flow Table to enable it to forward future packets that are sent along this flow with only the flow ID specified. Specifically, if the packet also contains a DSR Flow State header, this packet SHOULD cause an entry to be established for this flow in the Flow Table of each node along the packet's route. The Hop Count field of the DSR Flow State header is also stored in the Flow Table, as is the lifetime specified in the Timeout option specified in 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 this (IP Source Address, IP Destination Address) pair to the received Flow ID, and the TTL of the packet is recorded. The Flow ID option is removed before final delivery of the packet. Section 3.5.1, a packet is sent that establishes state in each node along the route. This state is soft; that is, the protocol contains mechanisms for recovering from the loss of this state. However, the use of these mechanisms may result in reduced performance for packets sent along flows with forgotten state. As a result, it is desirable to 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 flow's state to be "established end-to-end" if the Flow Tables of all nodes on the route contains forwarding information for that flow. While it is impossible to detect whether or not a flow's state has
been established end-to-end without sending packets, implementations may make reasonable assumptions about the retention of flow state and 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 is added to the packet. The source SHOULD set the Flow ID field of the DSR Flow State header either to the flow ID previously associated with this flow's route or to zero. If it sets the Flow ID field to any other value, it MUST follow the processing steps in Section 3.5.1 for establishing a new flow ID. If it sets the Flow ID field to a nonzero value, it MUST include a Timeout option with a value not greater than the timeout remaining in the node's Flow Table, and if its TTL is not equal to that specified in the Flow Table, the flow MUST NOT be used as a default flow in the future. Once flow state has been established end-to-end for non-default flows, a source adds a DSR Flow State header to each packet it wishes to send along that flow, setting the Flow ID field to the flow ID of that flow. A Source Route 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 packets with IP TTL equal to the TTL value in the local Flow Table entry for this flow then transmit the packet to the next hop. In this case, a DSR Flow State header SHOULD NOT be added to the packet and a DSR Options header likewise SHOULD NOT be added to the packet; though if one is, the steps for sending packets along non-default flows MUST be followed. If the IP TTL is not equal to the TTL value in the local Flow Table, then the steps for processing a non-default flow MUST be followed. Section 3.5.2. The Flow ID is 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 DSR Options header that indicates an unexpired flow in the node's Flow Table, it increments the Hop Count in the DSR Options header and forwards the packet to the next hop indicated in the Flow Table.
If a node receives a packet with a Flow ID that indicates a flow not currently in the node's Flow Table, it returns a Route Error of type UNKNOWN_FLOW with Error Destination and IP Destination addresses copied from the IP Source of the packet triggering the error. This error packet SHOULD be MAC-destined to the node from which the packet was received; if it cannot confirm reachability of the previous node using Route Maintenance, it MUST send the error as described in Section 8.1.1. The node sending the error SHOULD attempt to salvage the packet triggering the Route Error. If it does salvage the packet, it MUST zero the Flow ID in the packet. If a node receives a packet with no DSR Options header and no DSR Flow State header, it checks the Default Flow Table. If there is a matching entry, it forwards to the next hop indicated in the Flow Table for 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 Address of the packet triggering the error. This error packet SHOULD be MAC-destined to the node from which it was received; if this node cannot confirm reachability of the previous node using Route Maintenance, it MUST send the error as described in Section 8.1.1. The node sending the error SHOULD attempt to salvage the packet triggering the Route Error. If it does salvage the packet, it MUST zero the Flow ID in the packet. Section 5.1), the node assumes that the packet was sent by an upstream node and adds an entry for the packet to its Automatic Route Shortening Table, possibly evicting an earlier entry added to this table. When the packet is then sent to that node for
forwarding, the node finds that it has previously received the packet by checking its Automatic Route Shortening Table and returns a gratuitous Route Reply to the source of the packet. Section 8.6.7).
Section 5. Section 4.2) to determine whether a route to that packet's IP Destination Address now exists in the node's Route Cache (including the information just added to the Cache). If so, the packet SHOULD then be sent using that route and removed from the Send Buffer. It is possible to interface a DSR network with other networks, external to this DSR network. Such external networks may, for example, be the Internet or may be other ad hoc networks routed with a routing protocol other than DSR. Such external networks may also be other DSR networks that are treated as external networks in order to improve scalability. The complete handling of such external networks is beyond the scope of this document. However, this document specifies a minimal set of requirements and features
necessary to allow nodes only implementing 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 DSR Source Route option (Section 6.7) and a Route Reply option (Section 6.3) in a packet's DSR Options header (Section 6). 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 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 the Route Cache for a route to some destination node, the Route Cache is searched by destination node address. The following properties describe this searching function on a Route Cache: - Each implementation 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. For example, a node MAY choose to select the shortest route to the destination (the shortest sequence of hops), or it MAY use an alternate metric to select the route from the Cache. - However, if there are multiple cached routes to a destination, the selection of routes when searching the Route Cache SHOULD prefer routes that do not have the External flag set on any link. This preference will select routes that lead directly to the 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 selected when searching the Route Cache MUST NOT have the External bit set for 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 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 node's Route Cache: - Each implementation of DSR at each node MAY choose any appropriate policy for managing the entries in its Route Cache, such as when limited cache capacity requires a choice of which entries to retain in the Cache. For example, a node MAY chose a "least recently used" (LRU) cache replacement policy, in which the entry
last used longest ago is discarded from the cache if a decision needs to be made to allow space in the cache for some new entry being added. - However, 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 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 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 in any node. For example, the following two types of organization are possible: - In DSR, the route returned in each Route Reply that is received by the initiator of a Route Discovery (or that is learned from the header of overhead packets, as described in Section 8.1.4) represents a complete path (a sequence of links) leading to the 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 simple to implement and easily guarantees that 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 a route in a path cache data structure, the sending node can simply search its Route Cache for any path (or prefix of a path) that leads to the intended destination node. This type of organization for the Route Cache in DSR has been extensively studied through simulation [BROCH98, HU00, JOHANSSON99, MALTZ99a] and through implementation of DSR in a mobile outdoor testbed under significant workload [MALTZ99b, MALTZ00, MALTZ01]. - Alternatively, a "link cache" organization could be used for the Route Cache, in which 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. To search for a route in link cache, the sending node must use a more complex 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. Such an algorithm is more difficult to implement and may require significantly more CPU time to execute.
However, a link cache organization is more powerful than a path cache organization, in its ability to effectively utilize all of the potential information that a node might learn about the state of the network. In particular, links learned from different Route Discoveries or from the header of any overheard packets can be merged together to form new routes in the network, but this is not possible in a path cache due to the separation of each individual path in the cache. This type of organization for the Route Cache in DSR, including the effect of a range of implementation choices, has been studied through detailed simulation [HU00]. The choice of data structure organization to use for the Route Cache in any DSR implementation is a local matter for each node and affects only performance; any reasonable choice 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 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 the timeout for entries in the Route Cache. The configuration variable RouteCacheTimeout defined in Section 9 specifies the timeout to be applied to entries in the Route Cache, although it is also possible to instead use an adaptive policy in choosing timeout values rather than using a single timeout setting for all entries. For example, the Link-MaxLife cache design (below) uses an adaptive timeout algorithm and does not use the RouteCacheTimeout configuration variable. As guidance to implementers, Appendix A describes a type of link cache known as "Link-MaxLife" that has been shown to outperform other types of link caches and path caches studied in detailed simulation [HU00]. 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 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). Use of the Link-MaxLife design for the Route Cache is recommended in implementations of DSR.
Section 4.3, a Route Discovery SHOULD be initiated as often as allowed for the destination address of any packets residing in the Send Buffer. Section 3.3.3. - The time that this node last originated a Route Request for that target node. - The number of consecutive Route Discoveries 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. When the node initiates a new Route Discovery for this target node, this field in the Route Request Table entry for that target node is initialized to the timeout for that Route Discovery, after which the node MAY initiate a new Discovery for that target. Until a valid Route Reply is 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) value in the IP header of the Route 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 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 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 Table. The number of Identification values to retain in each Route Request Table entry, RequestTableIds, MUST NOT be unlimited, since, 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 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, if available, 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 a random number. Section 3.4.3, a node returns a gratuitous Route Reply when it overhears a packet transmitted by some node, for which the node overhearing the packet was not the intended next-hop node but was named later in the unexpended hops of the source route in that packet; the node overhearing the packet returns a gratuitous Route Reply to the original sender of the packet, listing the shorter route (not including the hops of the source route "skipped over" by this packet). A node uses its Gratuitous Route Reply Table to limit the rate at which it originates gratuitous Route Replies to the same original sender for the same node from which it overheard a packet to trigger the gratuitous Route Reply.
Each entry in the Gratuitous Route Reply Table of a node contains the following fields: - The address of the node to which this node originated a gratuitous Route Reply. - The address of the node from which this node overheard the packet triggering that gratuitous Route Reply. - The remaining time before which this entry in the Gratuitous Route Reply Table expires and SHOULD be deleted by the node. When a node creates a new entry in its Gratuitous Route Reply Table, the timeout value for that entry SHOULD be initialized to the value GratReplyHoldoff. When a node overhears a packet that would trigger a gratuitous Route Reply, if a corresponding entry already exists in the node's Gratuitous Route Reply Table, then the node SHOULD NOT send a gratuitous Route Reply for that packet. Otherwise (i.e., if no corresponding entry already exists), the node SHOULD create a new entry in its Gratuitous Route Reply Table to record that gratuitous Route Reply, with a timeout value of GratReplyHoldoff. IEEE80211]; the DSR protocol, as part of Route 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 implementing DSR is an output queue of packets from the network protocol stack waiting to be transmitted by the network interface; for example, in the 4.4BSD Unix network protocol stack implementation, this queue for a network interface is represented as a "struct ifqueue" [WRIGHT95]. This queue is used to hold packets while the network interface is in the process of transmitting another packet.
The Maintenance Buffer of a node implementing DSR is a queue of packets sent by this node that are awaiting next-hop reachability confirmation as part of Route Maintenance. For each packet in the Maintenance Buffer, a node maintains a count of the number of retransmissions and the time of the last retransmission. Packets are added to the Maintenance buffer after the first transmission attempt is made. The Maintenance Buffer MAY be of limited size; when adding a new packet to the Maintenance Buffer, if the buffer size is insufficient to hold the new packet, the new packet SHOULD be silently discarded. If, after MaxMaintRexmt attempts to confirm next-hop reachability 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, the node also SHOULD originate a Route Error for this packet to each original source of a packet 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 Cache. The definition of MaxMaintRexmt conceptually includes any retransmissions that might be attempted for a packet at the link layer or within the network interface hardware. The timeout value to use for each transmission attempt for an acknowledgement request depends on the type of acknowledgement mechanism used by Route Maintenance for that attempt, as described in Section 8.3.
A node MUST associate a state with each node listed in its blacklist, specifying whether the unidirectionality of the link to that node is "questionable" or "probable". Each time the unreachability is positively determined, the node SHOULD set the state to "probable". After the unreachability has not been positively determined for some amount of time, the state SHOULD revert to "questionable". A node MAY expire entries for nodes from its blacklist after a reasonable amount of time. Section 3.5.1. Each entry in the Flow Table contains the following fields: - The MAC address of the next-hop node along this flow. - An indication of the outgoing network interface on this node to be used in transmitting packets along this flow. - The MAC address of the previous-hop node along this flow. - An indication of the network interface on this node from which packets from that previous-hop node are received. - A timeout after which this entry in the Flow Table MUST be deleted. - The expected value of the Hop Count field in the DSR Flow State header for packets received for forwarding along this field (for use with packets containing a DSR Flow State header).
- An indication of whether or not this flow can be used as a default flow for packets originated by this node (the Flow ID of a default flow MUST be odd). - The entry SHOULD record the complete source route for the flow. (Nodes not recording the complete source route cannot participate in Automatic Route Shortening.) - The entry MAY contain a field recording the time this entry was last used. The entry MUST be deleted when its timeout expires.
flows in the table rather than about more packets listed in each entry in the table, as long as at least the listing of some small number of packets (e.g., 3) can be retained in each entry. RFC2460], becomes defined for IPv4, the DSR Options header MUST immediately follow the Hop-by-Hop Options extension header, if one is present in the packet, and MUST otherwise immediately follow the IP header.)
To add a DSR Options header to a packet, the DSR Options header is inserted 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 Options header follows the IP header, and the Next Header field in the DSR Options header is used to indicate the type of protocol header (such as a transport layer header) following the DSR Options header. If any headers follow the DSR Options header in a packet, the total length of the DSR Options 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 these following headers in the packet. RFC1700]. If no header follows, then Next Header MUST have the value 59, "No Next Header" [RFC2460]. Flow State Header (F) Flag bit. MUST be set to 0. This bit is set in a DSR Flow State header (Section 7.1) and clear in a DSR Options header. Reserved MUST be sent as 0 and ignored on reception.
Payload Length The length of the DSR Options 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 Options header. Options Variable-length field; the length of the Options field is specified by the Payload Length field in this DSR Options 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 6.8). The placement of DSR options following the fixed portion of the DSR Options 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 Options header to be aligned. Each DSR option is assigned a unique Option Type code. The most significant 3 bits (that is, Option Type & 0xE0) allow a node not implementing processing for this Option Type value to behave in the manner closest to correct for 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 (when the node does not implement processing for this Option Type) SHOULD respond to such a DSR option with a Route Error of type OPTION_NOT_SUPPORTED, except that such a Route Error SHOULD never be sent in response to a packet containing a Route Request option. - The two following bits in the Option Type value (that is, Option Type & 0x60) are a two-bit field indicating how such a node that does not support this Option Type MUST process the packet: 00 = Ignore Option 01 = Remove Option 10 = Mark Option 11 = Drop Packet When these 2 bits are 00 (that is, Option Type & 0x60 == 0), a node not implementing processing for that Option Type MUST use the Opt Data Len field to skip over the option and continue processing. When these 2 bits are 01 (that is, Option Type & 0x60 == 0x20), a node not implementing processing for that Option Type
MUST use the Opt Data Len field to remove the option from the packet and continue processing as if the option had not been included in the received packet. When these 2 bits are 10 (that is, Option Type & 0x60 == 0x40), a node not implementing processing for that Option Type MUST set the most significant bit following the Opt Data Len field, MUST ignore the contents of the option using the Opt Data Len field, and MUST continue processing the packet. Finally, when these 2 bits are 11 (that is, Option Type & 0x60 == 0x60), a node not implementing processing for that Option Type MUST drop the packet. The following types of DSR options are defined in this document for use within a DSR Options header: - Route 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) In addition, Section 7 specifies further DSR options for use with the optional DSR flow state extension.
Section 3.3.3). Route Request fields: Option Type 1. 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. MUST be set equal to (4 * n) + 6, where n is the number of addresses in the Route Request Option. Identification A unique value generated by the initiator (original sender) of the Route Request. Nodes initiating a Route Request generate a new Identification value for each Route Request, for example based on a sequence number counter of all Route Requests initiated by the node. This value allows a receiving node to determine whether it has recently seen a copy of this Route Request. If this Identification value (for this IP Source address and Target Address) is found by this receiving node in its Route Request Table (in the cache of Identification values in the entry there for this initiating node), this receiving node MUST discard the Route Request. When a Route Request is propagated, this field MUST be copied from the received copy of the Route Request being propagated. Target Address The address of the node that is the target of the Route Request. Address[1..n] Address[i] is the IPv4 address of the i-th node recorded in the Route Request option. The address given in the Source Address field in the IP header is the address of the initiator of the Route Discovery and MUST NOT be listed in the Address[i] fields; the address given in Address is thus the IPv4 address of 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 Route Request adds its own address to this list, increasing the Opt Data Len value by 4 octets. The Route Request option MUST NOT appear more than once within a DSR Options header.
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 the case of a gratuitous Route Reply, copied from the Source Address field of the data packet triggering the gratuitous Reply. Route Reply fields: Option Type 2. 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. MUST be set equal to (4 * n) + 1, where n is the number of addresses in the Route Reply Option. Last Hop External (L) Set to indicate that the last hop given by the Route Reply (the link from Address[n-1] to Address[n]) is actually an arbitrary path in a network external to the DSR network; the exact route outside the DSR network is not represented in the Route Reply. Nodes caching this hop in their Route Cache MUST flag the cached hop with the External flag. Such hops MUST NOT be returned in a cached Route Reply generated from this Route Cache entry, and selection of routes from the Route Cache to route a packet being sent SHOULD prefer routes that contain no hops flagged as External. Reserved MUST be sent as 0 and ignored on reception. Address[1..n] The source route being returned by the Route Reply. The route indicates a sequence of hops, originating at the source node specified in the Destination Address field of the IP header of the packet carrying the Route Reply, through each of the Address[i] nodes in the order listed in the Route Reply, ending at the node indicated by Address[n]. The number of addresses present in the Address[1..n] field is indicated by the Opt Data Len field in the option (n = (Opt Data Len - 1) / 4). A Route Reply option MAY appear one or more times within a DSR Options header.
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 the Salvage field in the DSR Source Route option of the packet triggering the Route Error. The "total salvage count" of the Route Error option is derived from the value in the Salvage field of this Route Error option and all preceding Route Error options in the packet as follows: the total salvage count is the sum of, for each such Route Error option, one plus the value in the Salvage field of that Route Error option. Error Source Address The address of the node originating the Route Error (e.g., the node that attempted to forward a packet and discovered the link failure). Error Destination Address The address of the node to which the Route Error must be delivered. For example, when the Error Type field is set to NODE_UNREACHABLE, this field will be set to the address of the node that generated the routing information claiming that the hop from the Error Source Address to Unreachable Node Address (specified in the Type-Specific Information) was a valid hop. Type-Specific Information Information specific to the Error Type of this Route Error message. A Route Error option MAY appear one or more times within a DSR Options header.
Option Type 160. Nodes not understanding this option will remove the option and return a Route Error. Opt Data Len 8-bit unsigned integer. Length of the option, in octets, excluding the Option Type and Opt Data Len fields. Identification The Identification field is set to a unique value and is copied into the Identification field of the Acknowledgement option when returned by the node receiving the packet over this hop. An Acknowledgement Request option MUST NOT appear more than once within a DSR Options header.
ACK Source Address The address of the node originating the acknowledgement. ACK Destination Address The address of the node to which the acknowledgement is to be delivered. An Acknowledgement option MAY appear one or more times within a DSR Options header.
network is not represented in the DSR Source Route option. Nodes caching this hop in their Route Cache MUST flag the cached hop with the External flag. Such hops MUST NOT be returned in a Route Reply generated from this Route Cache entry, and selection of routes from the Route Cache to route a packet being sent SHOULD prefer routes that contain no hops flagged as External. Last Hop External (L) Set to indicate that the last hop indicated by the DSR Source Route option is actually an arbitrary path in a network external to the DSR network; the exact route outside the DSR network is not represented in the DSR Source Route option. Nodes caching this hop in their Route Cache MUST flag the cached hop with the External flag. Such hops MUST NOT be returned in a Route Reply generated from this Route Cache entry, and selection of routes from the Route Cache to route a packet being sent SHOULD 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 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 source route. In routing and forwarding the packet, the source route is processed as described in Sections 8.1.3 and 8.1.5. The number of addresses present in the Address[1..n] field is indicated by the Opt Data Len field in the option (n = (Opt Data Len - 2) / 4). When forwarding a packet along a DSR source route using a DSR Source Route option in the packet's DSR Options header, the Destination Address field in the packet's IP header is always set to the address
of the packet's ultimate destination. A node receiving a packet containing a DSR Options header with a DSR Source Route option MUST examine the indicated source route to determine if it is the intended next-hop node for the packet and how to forward the packet, as defined in Sections 8.1.4 and 8.1.5.
Option Type 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. The size of the Option Data field. Option Data A number of zero-valued octets equal to the Opt Data Len. A PadN option MAY be included in the Options field of a DSR Options header in 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 header in a packet, the total length of a DSR Options header, indicated by the Payload Length field in the DSR Options header, MUST be a multiple of 4 octets. In this case, when building a DSR Options header in a packet, sufficient Pad1 or PadN options MUST be included in the Options field of the DSR Options header to make the total length a multiple of 4 octets.