Network Working Group D. Johnson
Request for Comments: 4728 Rice University
Category: Experimental Y. Hu
UIUC
D. Maltz
Microsoft Research
February 2007
Network Working Group D. Johnson
Request for Comments: 4728 Rice University
Category: Experimental Y. Hu
UIUC
D. Maltz
Microsoft Research
February 2007
The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4
IPv4移动adhoc网络的动态源路由协议（DSR）
Status of This Memo
关于下段备忘
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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 routes to arbitrary destinations in the ad hoc network. All aspects of the protocol operate entirely on demand, allowing the routing packet overhead of DSR to scale automatically to only what is needed to react to changes in the routes currently in use. The protocol allows multiple routes to any destination and allows each sender to select and control the 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, operation in 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 of up to about two hundred nodes and is designed to work well even with very high rates of mobility. This document specifies the operation of the DSR protocol for routing unicast IPv4 packets.
动态源路由协议（DSR）是一种简单高效的路由协议，专门设计用于移动节点的多跳无线自组织网络。DSR允许网络完全自组织和自配置，无需任何现有的网络基础设施或管理。该协议由“路由发现”和“路由维护”两种主要机制组成，这两种机制共同作用，允许节点发现和维护到adhoc网络中任意目的地的路由。协议的所有方面都完全按需运行，允许DSR的路由数据包开销自动扩展到只需要对当前使用的路由的变化做出反应。该协议允许到任何目的地的多条路由，并允许每个发送方选择和控制路由其数据包时使用的路由，例如，用于负载平衡或增强鲁棒性。DSR协议的其他优点包括易于保证的无环路路由、在包含单向链路的网络中运行、在路由中仅使用“软状态”，以及当网络中的路由发生变化时非常快速的恢复。DSR协议主要是为多达200个节点的移动自组织网络设计的，即使在移动速率非常高的情况下也能很好地工作。本文档指定了用于路由单播IPv4数据包的DSR协议的操作。
Table of Contents
目录
1. Introduction ....................................................5
2. Assumptions .....................................................7
3. DSR Protocol Overview ...........................................9
3.1. Basic DSR Route Discovery .................................10
3.2. Basic DSR Route Maintenance ...............................12
3.3. Additional Route Discovery Features .......................14
3.3.1. Caching Overheard Routing Information ..............14
3.3.2. Replying to Route Requests Using Cached Routes .....15
3.3.3. Route Request Hop Limits ...........................16
3.4. Additional Route Maintenance Features .....................17
3.4.1. Packet Salvaging ...................................17
3.4.2. Queued Packets Destined over a Broken Link .........18
3.4.3. Automatic Route Shortening .........................19
3.4.4. Increased Spreading of Route Error Messages ........20
3.5. Optional DSR Flow State Extension .........................20
3.5.1. Flow Establishment .................................21
3.5.2. Receiving and Forwarding Establishment Packets .....22
3.5.3. Sending Packets along Established Flows ............22
3.5.4. Receiving and Forwarding Packets Sent along
Established Flows ..................................23
3.5.5. Processing Route Errors ............................24
3.5.6. Interaction with Automatic Route Shortening ........24
3.5.7. Loop Detection .....................................25
3.5.8. Acknowledgement Destination ........................25
3.5.9. Crash Recovery .....................................25
3.5.10. Rate Limiting .....................................25
3.5.11. Interaction with Packet Salvaging .................26
4. Conceptual Data Structures .....................................26
4.1. Route Cache ...............................................26
4.2. Send Buffer ...............................................30
4.3. Route Request Table .......................................30
4.4. Gratuitous Route Reply Table ..............................31
4.5. Network Interface Queue and Maintenance Buffer ............32
4.6. Blacklist .................................................33
5. Additional Conceptual Data Structures for Flow State
Extension ......................................................34
5.1. Flow Table ................................................34
5.2. Automatic Route Shortening Table ..........................35
5.3. Default Flow ID Table .....................................36
6. DSR Options Header Format ......................................36
6.1. Fixed Portion of DSR Options Header .......................37
6.2. Route Request Option ......................................40
6.3. Route Reply Option ........................................42
1. Introduction ....................................................5
2. Assumptions .....................................................7
3. DSR Protocol Overview ...........................................9
3.1. Basic DSR Route Discovery .................................10
3.2. Basic DSR Route Maintenance ...............................12
3.3. Additional Route Discovery Features .......................14
3.3.1. Caching Overheard Routing Information ..............14
3.3.2. Replying to Route Requests Using Cached Routes .....15
3.3.3. Route Request Hop Limits ...........................16
3.4. Additional Route Maintenance Features .....................17
3.4.1. Packet Salvaging ...................................17
3.4.2. Queued Packets Destined over a Broken Link .........18
3.4.3. Automatic Route Shortening .........................19
3.4.4. Increased Spreading of Route Error Messages ........20
3.5. Optional DSR Flow State Extension .........................20
3.5.1. Flow Establishment .................................21
3.5.2. Receiving and Forwarding Establishment Packets .....22
3.5.3. Sending Packets along Established Flows ............22
3.5.4. Receiving and Forwarding Packets Sent along
Established Flows ..................................23
3.5.5. Processing Route Errors ............................24
3.5.6. Interaction with Automatic Route Shortening ........24
3.5.7. Loop Detection .....................................25
3.5.8. Acknowledgement Destination ........................25
3.5.9. Crash Recovery .....................................25
3.5.10. Rate Limiting .....................................25
3.5.11. Interaction with Packet Salvaging .................26
4. Conceptual Data Structures .....................................26
4.1. Route Cache ...............................................26
4.2. Send Buffer ...............................................30
4.3. Route Request Table .......................................30
4.4. Gratuitous Route Reply Table ..............................31
4.5. Network Interface Queue and Maintenance Buffer ............32
4.6. Blacklist .................................................33
5. Additional Conceptual Data Structures for Flow State
Extension ......................................................34
5.1. Flow Table ................................................34
5.2. Automatic Route Shortening Table ..........................35
5.3. Default Flow ID Table .....................................36
6. DSR Options Header Format ......................................36
6.1. Fixed Portion of DSR Options Header .......................37
6.2. Route Request Option ......................................40
6.3. Route Reply Option ........................................42
6.4. Route Error Option ........................................44
6.4.1. Node Unreachable Type-Specific Information .........46
6.4.2. Flow State Not Supported Type-Specific
Information ........................................46
6.4.3. Option Not Supported Type-Specific Information .....46
6.5. Acknowledgement Request Option ............................46
6.6. Acknowledgement Option ....................................47
6.7. DSR Source Route Option ...................................48
6.8. Pad1 Option ...............................................50
6.9. PadN Option ...............................................50
7. Additional Header Formats and Options for Flow State
Extension ......................................................51
7.1. DSR Flow State Header .....................................52
7.2. New Options and Extensions in DSR Options Header ..........52
7.2.1. Timeout Option .....................................52
7.2.2. Destination and Flow ID Option .....................53
7.3. New Error Types for Route Error Option ....................54
7.3.1. Unknown Flow Type-Specific Information .............54
7.3.2. Default Flow Unknown Type-Specific Information .....55
7.4. New Acknowledgement Request Option Extension ..............55
7.4.1. Previous Hop Address Extension .....................55
8. Detailed Operation .............................................56
8.1. General Packet Processing .................................56
8.1.1. Originating a Packet ...............................56
8.1.2. Adding a DSR Options Header to a Packet ............57
8.1.3. Adding a DSR Source Route Option to a Packet .......57
8.1.4. Processing a Received Packet .......................58
8.1.5. Processing a Received DSR Source Route Option ......60
8.1.6. Handling an Unknown DSR Option .....................63
8.2. Route Discovery Processing ................................64
8.2.1. Originating a Route Request ........................65
8.2.2. Processing a Received Route Request Option .........66
8.2.3. Generating a Route Reply Using the Route Cache .....68
8.2.4. Originating a Route Reply ..........................71
8.2.5. Preventing Route Reply Storms ......................72
8.2.6. Processing a Received Route Reply Option ...........74
8.3. Route Maintenance Processing ..............................74
8.3.1. Using Link-Layer Acknowledgements ..................75
8.3.2. Using Passive Acknowledgements .....................76
8.3.3. Using Network-Layer Acknowledgements ...............77
8.3.4. Originating a Route Error ..........................80
8.3.5. Processing a Received Route Error Option ...........81
8.3.6. Salvaging a Packet .................................82
8.4. Multiple Network Interface Support ........................84
8.5. IP Fragmentation and Reassembly ...........................84
8.6. Flow State Processing .....................................85
8.6.1. Originating a Packet ...............................85
8.6.2. Inserting a DSR Flow State Header ..................88
6.4. Route Error Option ........................................44
6.4.1. Node Unreachable Type-Specific Information .........46
6.4.2. Flow State Not Supported Type-Specific
Information ........................................46
6.4.3. Option Not Supported Type-Specific Information .....46
6.5. Acknowledgement Request Option ............................46
6.6. Acknowledgement Option ....................................47
6.7. DSR Source Route Option ...................................48
6.8. Pad1 Option ...............................................50
6.9. PadN Option ...............................................50
7. Additional Header Formats and Options for Flow State
Extension ......................................................51
7.1. DSR Flow State Header .....................................52
7.2. New Options and Extensions in DSR Options Header ..........52
7.2.1. Timeout Option .....................................52
7.2.2. Destination and Flow ID Option .....................53
7.3. New Error Types for Route Error Option ....................54
7.3.1. Unknown Flow Type-Specific Information .............54
7.3.2. Default Flow Unknown Type-Specific Information .....55
7.4. New Acknowledgement Request Option Extension ..............55
7.4.1. Previous Hop Address Extension .....................55
8. Detailed Operation .............................................56
8.1. General Packet Processing .................................56
8.1.1. Originating a Packet ...............................56
8.1.2. Adding a DSR Options Header to a Packet ............57
8.1.3. Adding a DSR Source Route Option to a Packet .......57
8.1.4. Processing a Received Packet .......................58
8.1.5. Processing a Received DSR Source Route Option ......60
8.1.6. Handling an Unknown DSR Option .....................63
8.2. Route Discovery Processing ................................64
8.2.1. Originating a Route Request ........................65
8.2.2. Processing a Received Route Request Option .........66
8.2.3. Generating a Route Reply Using the Route Cache .....68
8.2.4. Originating a Route Reply ..........................71
8.2.5. Preventing Route Reply Storms ......................72
8.2.6. Processing a Received Route Reply Option ...........74
8.3. Route Maintenance Processing ..............................74
8.3.1. Using Link-Layer Acknowledgements ..................75
8.3.2. Using Passive Acknowledgements .....................76
8.3.3. Using Network-Layer Acknowledgements ...............77
8.3.4. Originating a Route Error ..........................80
8.3.5. Processing a Received Route Error Option ...........81
8.3.6. Salvaging a Packet .................................82
8.4. Multiple Network Interface Support ........................84
8.5. IP Fragmentation and Reassembly ...........................84
8.6. Flow State Processing .....................................85
8.6.1. Originating a Packet ...............................85
8.6.2. Inserting a DSR Flow State Header ..................88
8.6.3. Receiving a Packet .................................88
8.6.4. Forwarding a Packet Using Flow IDs .................93
8.6.5. Promiscuously Receiving a Packet ...................93
8.6.6. Operation Where the Layer below DSR
Decreases the IP TTL ...............................94
8.6.7. Salvage Interactions with DSR ......................94
9. Protocol Constants and Configuration Variables .................95
10. IANA Considerations ...........................................96
11. Security Considerations .......................................96
Appendix A. Link-MaxLife Cache Description ........................97
Appendix B. Location of DSR in the ISO Network Reference Model ....99
Appendix C. Implementation and Evaluation Status .................100
Acknowledgements .................................................101
Normative References .............................................102
Informative References ...........................................102
8.6.3. Receiving a Packet .................................88
8.6.4. Forwarding a Packet Using Flow IDs .................93
8.6.5. Promiscuously Receiving a Packet ...................93
8.6.6. Operation Where the Layer below DSR
Decreases the IP TTL ...............................94
8.6.7. Salvage Interactions with DSR ......................94
9. Protocol Constants and Configuration Variables .................95
10. IANA Considerations ...........................................96
11. Security Considerations .......................................96
Appendix A. Link-MaxLife Cache Description ........................97
Appendix B. Location of DSR in the ISO Network Reference Model ....99
Appendix C. Implementation and Evaluation Status .................100
Acknowledgements .................................................101
Normative References .............................................102
Informative References ...........................................102
The Dynamic Source Routing protocol (DSR) [JOHNSON94, JOHNSON96a] 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.
动态源路由协议（DSR）[Johnson 94，Johnson 96a]是一种简单高效的路由协议，专门设计用于移动节点的多跳无线自组织网络。使用DSR，网络完全是自组织和自配置的，不需要现有的网络基础设施或管理。网络节点相互协作转发数据包，以允许不直接在彼此的无线传输范围内的节点之间通过多个“跳”进行通信。当网络中的节点移动或加入或离开网络时，当无线传输条件（如干扰源）发生变化时，所有路由都由DSR路由协议自动确定和维护。由于到达任何目的地所需的中间跃点的数量或序列可能随时发生变化，因此产生的网络拓扑可能非常丰富且变化迅速。
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.
在设计DSR时，我们试图创建一个路由协议，该协议具有非常低的开销，但能够对网络中的变化做出非常快速的反应。DSR协议提供高反应性服务，以帮助确保在节点移动或网络条件发生其他变化的情况下成功交付数据包。
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:
DSR协议由两个主要机制组成，这两个机制协同工作，以允许在自组织网络中发现和维护源路由：
- 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.
- 路由发现是一种机制，通过该机制，希望向目的地节点D发送数据包的节点S可获得到D的源路由。仅当S尝试向D发送数据包且不知道到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 it 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.
- 路由维护是一种机制，通过该机制，节点S在使用到D的源路由时，能够检测到网络拓扑是否发生了变化，从而无法再使用到D的路由，因为路由上的链路不再工作。当路由维护指示源路由已断开时，S可以尝试使用它碰巧知道的任何其他路由到D，或者它可以再次调用路由发现来为D的后续数据包找到新路由。仅当S实际向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
在DSR中，路由发现和路由维护都完全“按需”操作。特别是，与其他协议不同，DSR在网络中的任何层都不需要任何类型的周期性数据包。例如，DSR不使用任何周期性路由公告、链路状态感测或邻居检测分组，并且不依赖网络中任何底层协议的这些功能。这
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 what is 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.
完全按需行为和缺乏周期性活动允许DSR引起的开销数据包数量一直向下扩展到零，此时所有节点彼此几乎静止，并且当前通信所需的所有路由都已发现。当节点开始移动或通信模式发生变化时，DSR的路由数据包开销将自动扩展到仅跟踪当前使用的路由所需的开销。不影响当前正在使用的路由的网络拓扑更改将被忽略，不会引起协议的反应。
All state maintained by DSR is "soft state" [CLARK88], 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.
DSR维护的所有状态均为“软状态”[CLARK88]，因为任何状态的丢失都不会干扰协议的正确运行；根据需要发现所有状态，并且在发生故障后，如果需要，可以轻松快速地重新发现所有状态，而不会对协议造成重大影响。这种仅使用软状态的方式允许路由协议对诸如丢弃或延迟路由数据包或节点故障等问题具有非常强的鲁棒性。特别是，DSR中出现故障并重新启动的节点可以在重新启动后立即重新加入网络；如果故障节点作为一个或多个路由上的中间跃点参与了为其他节点转发数据包，则它也可以在重新启动后快速恢复此转发，而不会对路由协议造成任何中断或最小程度的中断。
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 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 transmit power levels or sources of interference.
DSR中的路由发现和路由维护操作旨在支持单向链路和非对称路由。特别地，如第2节中所述，在无线网络中，由于不同的发射功率电平或干扰源，两个节点之间的链路可能在两个方向上不能同样好地工作。
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
可以将DSR网络与此DSR网络外部的其他网络连接。例如，这种外部网络可以是因特网，或者可以是通过网络路由的其他自组织网络
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.
DSR以外的路由协议。这样的外部网络也可以是被视为外部网络以提高可伸缩性的其他DSR网络。此类外部网络的完整处理超出了本文件的范围。但是，本文档规定了一组最低限度的要求和功能，以允许仅实现本规范的节点与实现此类外部网络接口的节点正确地进行互操作。
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 [RFC2460], will be 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. As described in Appendix C, the design of DSR has been extensively studied through detailed simulations and testbed implementation and demonstration; this document encourages additional implementation and experimentation with the protocol.
本文档规定了在多跳无线自组织网络中路由单播IPv4数据包的DSR协议的操作。其他文档将介绍高级可选功能，如服务质量（QoS）支持和高效多播路由，以及DSR与IPv6的操作[RFC2460]。本文档中的DSR规范提供了一个兼容的基础，在此基础上可以单独添加这些功能，也可以通过与此处指定的DSR操作集成来添加这些功能。如附录C所述，DSR的设计已通过详细的模拟、试验台实施和演示进行了广泛的研究；本文件鼓励进一步实施和试验该协议。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
As described here, the DSR protocol is designed mainly for mobile ad hoc networks of up to about two hundred nodes and is designed to work well even with 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.
如本文所述，DSR协议主要设计用于多达200个节点的移动自组织网络，并且设计为即使在非常高的移动速率下也能很好地工作。允许DSR扩展到更大网络的其他协议功能和增强不在本文档范围内。
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.
在本文档中，我们假设所有希望与adhoc网络中的其他节点通信的节点都愿意完全参与网络的协议。特别地，参与adhoc网络的每个节点还应该愿意为网络中的其他节点转发分组。
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 it may often be greater than 1.
adhoc网络的直径是数据包从位于adhoc网络的一个极端边缘的任何节点到达另一个极端的节点所需的最小跳数。我们假设该直径通常较小（例如，可能为5或10跳），但通常可能大于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, such as through a standard link-layer checksum or Cyclic Redundancy Check (CRC), and discard the packet.
数据包在无线网络上传输时可能丢失或损坏。我们假设接收损坏数据包的节点可以检测错误，例如通过标准链路层校验和或循环冗余校验（CRC），并丢弃数据包。
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.
adhoc网络中的节点可以随时移动而不被通知，甚至可以连续移动，但是我们假设节点移动的速度相对于所使用的特定底层网络硬件的分组传输延迟和无线传输范围是中等的。特别是，DSR可以支持非常快速的任意节点移动速率，但我们假设节点不会持续快速移动，从而使每个单独数据包的泛洪成为唯一可能的路由协议。
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 and capacity are more the inherent limiting factors 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 [JOHNSON96a]. 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.
许多网络接口（包括用于广播媒体（如无线）的大多数当前LAN硬件）的一个共同特征是能够在“混杂”接收模式下操作网络接口。此模式使硬件将每个接收到的数据包发送到网络驱动程序软件，而不根据链路层目标地址进行过滤。虽然我们不需要这个工具，但是我们的一些优化可以利用它的可用性。使用混杂模式确实会增加CPU上的软件开销，但我们认为无线网络速度和容量更是当前和未来系统性能的固有限制因素；我们还认为，协议的某些部分适合直接在可编程网络接口单元内实现，以避免CPU上的这种开销[Johnson 96a]。根据接收器硬件的设计，混杂模式的使用也可能增加网络接口硬件的功耗，在这种情况下，DSR可以很容易地使用，而无需依赖混杂接收模式的优化，或者可以编程为仅周期性地将接口切换到混杂模式。使用混杂接收模式是完全可选的。
Wireless communication ability between any pair of nodes may at times not work equally well in both directions, due, for example, to transmit power levels or sources of interference around the two nodes [BANTZ94, LAUER95]. 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. Some Medium Access Control (MAC) protocols, however, such as MACA [KARN90], MACAW [BHARGHAVAN94], or IEEE 802.11 [IEEE80211], limit unicast data packet transmission to bidirectional links, due to the required bidirectional exchange of request to send (RTS) and clear to send (CTS) packets in these protocols and to the link-layer acknowledgement feature in IEEE 802.11. When used on top of MAC
任何一对节点之间的无线通信能力有时可能在两个方向上都不能同样好地工作，例如，由于在两个节点周围发射功率电平或干扰源[BANTZ94，LAUER95]。也就是说，在许多情况下，每对节点之间的无线通信将能够双向操作，但是有时两个节点之间的无线链路可能只是单向的，允许一个节点成功地向另一个节点发送分组，而不可能在相反方向上进行通信。然而，一些媒体访问控制（MAC）协议，如MACA[KARN90]、MACAW[BHARGHAVAN94]或IEEE 802.11[IEEE80211]，由于所需的双向发送请求交换（RTS）和清除发送（CTS），将单播数据包传输限制为双向链路这些协议中的数据包和IEEE 802.11中的链路层确认功能。在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.
像这样的协议，DSR可以利用额外的优化，例如反转源路由以获得返回原始路由的路由的能力。
The IP address used by a node using the DSR protocol MAY be assigned by any mechanism (e.g., static assignment or use of Dynamic Host Configuration Protocol (DHCP) for dynamic assignment [RFC2131]), although the method of such assignment is outside the scope of this specification.
使用DSR协议的节点使用的IP地址可以通过任何机制分配（例如，静态分配或使用动态主机配置协议（DHCP）进行动态分配[RFC2131]），尽管这种分配的方法不在本规范的范围内。
A routing protocol such as DSR chooses a next-hop for each packet and provides the IP address of that next-hop. When the packet is transmitted, however, the lower-layer protocol often has a separate, MAC-layer address for the next-hop node. DSR uses the Address Resolution Protocol (ARP) [RFC826] to translate from next-hop IP addresses to next-hop MAC addresses. In addition, a node MAY add an entry to its ARP cache based on any received packet, when the IP address and MAC address of the transmitting node are available in the packet; for example, the IP address of the transmitting node is present in a Route Request option (in the Address list being accumulated) and any packets containing a source route. Adding entries to the ARP cache in this way avoids the overhead of ARP in most cases.
DSR等路由协议为每个数据包选择下一跳，并提供下一跳的IP地址。然而，当分组被传输时，较低层协议通常为下一跳节点具有单独的MAC层地址。DSR使用地址解析协议（ARP）[RFC826]将下一跳IP地址转换为下一跳MAC地址。此外，当发送节点的IP地址和MAC地址在分组中可用时，节点可以基于任何接收到的分组向其ARP高速缓存添加条目；例如，发送节点的IP地址存在于路由请求选项（在正在累积的地址列表中）和包含源路由的任何分组中。在大多数情况下，以这种方式向ARP缓存添加条目可以避免ARP的开销。
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 the fundamental properties of DSR's operation are preserved.
本节概述DSR协议的操作。DSR的基本版本使用显式的“源路由”，其中发送的每个数据包在其报头中都包含完整的、有序的节点列表，数据包将通过这些节点。这种显式源路由的使用允许发送方选择和控制用于其自身数据包的路由，支持使用到任何目的地的多个路由（例如，用于负载平衡），并允许简单地保证使用的路由是无环路的。通过将该源路由包括在每个数据分组的报头中，转发或偷听这些分组中的任何一个的其他节点也可以容易地缓存该路由信息以供将来使用。第3.1节描述了路由发现的基本操作，第3.2节描述了基本路由维护，第3.3节和第3.4节描述了DSR操作这两部分的附加功能。然后，第3.5节描述了DSR的可选兼容扩展，称为“流状态”，该扩展允许在数据包中无显式源路由头的情况下路由大多数数据包，同时保留DSR操作的基本属性。
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正试图发现到节点E的路由。在本例中，节点a发起的路由发现将按如下方式进行：
^ "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
^ "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.
为了发起路由发现，节点A将“路由请求”作为单个本地广播分组发送，该本地广播分组由（大约）当前在A的无线传输范围内的所有节点（包括本示例中的节点B）接收。每个路由请求标识路由发现的发起方和目标，还包含由请求发起方确定的唯一请求标识（本例中为2）。每个路由请求还包含一条记录，其中列出了每个中间节点的地址，路由请求的特定副本是通过该中间节点转发的。路由发现的发起人将此路由记录初始化为空列表。在本例中，路由记录最初仅列出节点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.
当另一个节点接收到该路由请求时（如本例中的节点B），如果它是路由发现的目标，则它向路由发现的发起方返回“路由应答”，给出来自路由请求的累积路由记录的副本；当启动器收到此路由应答时，它将此路由缓存在其路由缓存中，以用于将后续数据包发送到此目的地。
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. (A node considers a Request recently seen if it still has information about that Request in its Route Request Table, which is described in Section 4.3.) 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 receipt of a copy of the Request by node E.
否则，如果接收路由请求的此节点最近看到来自此启动器的另一个路由请求消息具有相同的请求标识和目标地址，或者如果此节点自己的地址已列在路由请求的路由记录中，则此节点丢弃该请求。（如果一个节点在其路由请求表中仍然有关于该请求的信息（如第4.3节所述），则该节点会考虑最近看到的请求。）否则，该节点会将其自己的地址附加到路由请求中的路由记录中，并通过将其作为本地广播包（具有相同的请求标识）进行传输来传播。在该示例中，节点B广播由节点C接收的路由请求；节点C和D各自也依次广播该请求，导致节点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 one is 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 in this case 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 [RFC793], on a Route Request using this same mechanism.
在将路由应答返回给路由发现的发起方时，例如在本示例中，节点E回复回节点A，节点E通常将检查其自身的路由缓存以寻找返回到A的路由，并且如果找到了路由缓存，则将其用于源路由以传递包含路由应答的分组。否则，E应该为目标节点A执行自己的路由发现，但为了避免可能的无限递归路由发现，在这种情况下，E必须在包含其自身对A的路由请求的数据包上搭载该路由应答。也可以搭载其他小数据包，例如TCP SYN数据包[RFC793]，在路由请求上使用相同的机制。
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 for unicast packets as part of the MAC protocol [IEEE80211], the discovered source route MUST be reversed in this way to return the Route Reply, since this route reversal tests the discovered route to ensure that 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.
相反，节点E可以简单地反转它试图在路由应答中发送的路由记录中的跳序列，并将其用作承载路由应答本身的分组上的源路由。对于MAC协议，如IEEE 802.11，作为MAC协议[IEEE80211]的一部分，需要对单播数据包进行双向帧交换，发现的源路由必须以这种方式反转以返回路由应答，因为此路由反转会在路由发现启动器开始使用路由之前测试已发现的路由，以确保它是双向的。此路由反转还避免了可能的第二个路由发现的开销。
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 SendBufferTimeout; 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.
当启动路由发现时，发送节点将原始数据包（触发发现的数据包）的副本保存在称为“发送缓冲区”的本地缓冲区中。发送缓冲区包含此节点无法传输的每个数据包的副本，因为它还没有到数据包目的地的源路由。发送缓冲区中的每个数据包在逻辑上与它被放入发送缓冲区的时间相关联，并且在发送缓冲区中驻留一段超时时间后丢弃SendBufferTimeout；如果有必要防止发送缓冲区溢出，FIFO或其他替换策略也可用于在数据包过期之前逐出数据包。
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 (as described in Section 4.3), 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 common.
当数据包保留在发送缓冲区中时，节点应偶尔为数据包的目的地地址启动新的路由发现。但是，节点必须限制为相同地址启动此类新路由发现的速率（如第4.3节所述），因为目标节点当前可能无法到达。具体地，由于有限的无线传输范围和网络中节点的移动，网络有时可能被划分，这意味着当前没有节点序列，分组可以通过这些节点被转发到目的地。根据网络中节点的移动模式和密度，此类网络分区可能很少或常见。
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 [RFC1122].
如果为这种分区网络中的节点发送的每个数据包启动了新的路由发现，那么大量非生产性路由请求数据包将传播到可从该节点到达的adhoc网络的整个子集。为了减少此类路由发现的开销，节点应使用指数退避算法来限制其为同一目标启动新路由发现的速率，将为同一目标启动的每个后续发现之间的超时时间增加一倍。如果节点尝试向同一目的地节点发送额外数据包的频率高于此限制，则后续数据包应缓冲在发送缓冲区中，直到收到路由回复，给出到该目的地的路由，但是，在达到此目标的新路由发现之间的最小允许间隔之前，节点不得启动新路由发现。对同一目标的最大路由发现速率的限制类似于Internet节点所需的机制，以限制针对任何单个目标IP地址发送ARP请求的速率[RFC1122]。
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发起分组：
+-----+ +-----+ +-----+ +-----+ +-----+
| A |---->| B |---->| C |-->? | D | | E |
+-----+ +-----+ +-----+ +-----+ +-----+
+-----+ +-----+ +-----+ +-----+ +-----+
| 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, and node D is responsible for the link from D to E.
在这种情况下，节点A负责从A到B的链路，节点B负责从B到C的链路，节点C负责从C到D的链路，节点D负责从D到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 [IEEE80211]), or by a "passive acknowledgement" [JUBIN87] (in which, for example, B confirms receipt at C by overhearing C transmit the packet when forwarding it on to D).
确认可以提供链路能够承载数据的确认，并且在无线网络中，通常免费提供确认，或者作为使用中的MAC协议的现有标准部分（例如由IEEE 802.11[IEEE80211]定义的链路层确认帧），或者通过“被动确认”[JUBIN87]（例如，在这种情况下，B通过在将数据包转发给D时偷听C发送数据包来确认在C的接收）。
If a built-in acknowledgement mechanism is not available, the node transmitting the packet can explicitly request that 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 (Section 4.6), this software acknowledgement could travel over a different, multi-hop path.
如果内置确认机制不可用，则发送分组的节点可以明确请求由路由上的下一节点返回DSR特定软件确认；该软件确认通常将直接发送到发送节点，但如果这两个节点之间的链路是单向的（第4.6节），则该软件确认可以通过不同的多跳路径传输。
After an acknowledgement has been received from some neighbor, a node MAY choose not to 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
在确认请求被重传最大次数之后，如果没有收到确认，则发送方将到该下一跳目的地的链路视为当前“断开”。它应该从其路由缓存中删除此链接，并且应该向自上次收到确认后通过该链接发送数据包的每个节点返回“路由错误”。例如，在上面所示的情况下，如果C在一些请求之后没有从D接收到确认，它将向a以及自C上次从D接收到确认以来可能已经使用了从C到D的链路的任何其他节点返回路由错误。然后，节点a将该断开的链路从其缓存中移除；如有必要，可通过任何原始TCP协议的上层进行重传。为了将这样的重传或其他分组发送到此同一目的地E，如果a在其路由缓存中具有到E的另一路由（例如，来自其先前路由发现的额外路由应答，或者来自无意中听到来自其他分组的足够路由信息），则其可以
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.1节中描述的退避）。
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 on the MAC protocol being used. Specifically, three distinct cases are possible:
转发或偷听任何数据包的节点应将该数据包中的所有可用路由信息添加到其自身的路由缓存中。分组中路由信息的有用性取决于物理介质的方向性特征（第2节），以及所使用的MAC协议。具体而言，有三种不同的情况：
- 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.
- 网络中的链路通常能够仅单向地（而不是双向地）操作，并且网络中使用的MAC协议能够通过单向链路传输单播分组。
- 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.
- 网络中的链路偶尔只能单向（而不是双向）运行，但对任何链路的这种单向限制并不持久；几乎所有链路在物理上都是双向的，并且网络中使用的MAC协议能够通过单向链路传输单播数据包。
- 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 [IEEE80211] 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.
- 网络中使用的MAC协议不能通过单向链路传输单播分组；MAC协议只能使用双向链路来传输单播数据包。例如，IEEE 802.11分布式协调功能（DCF）MAC协议[IEEE80211]能够仅通过双向链路发送单播分组，由于MAC协议要求从接收机返回链路级确认分组，并且还可选地要求在发射机和接收机节点之间双向交换RTS和CTS分组。
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.
在上面的第一种情况下，例如，数据分组中使用的源路由、路由请求中的累积路由记录或路由应答中返回的路由都应由“向前”方向上的任何节点缓存。任何节点都应从接收到的任何此类数据包中缓存该信息，无论该数据包是寻址到此节点、发送到广播（或多播）MAC地址，还是在节点的网络接口处于混杂模式时被偷听。然而，在这样的包头中标识的链路的“反向”方向不应该被缓存。
For example, in the situation shown below, node A is using a source route to communicate with node E:
例如，在如下所示的情况下，节点A使用源路由与节点E通信：
+-----+ +-----+ +-----+ +-----+ +-----+
| A |---->| B |---->| C |---->| D |---->| 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.
当节点C沿着从a到E的路由转发数据包时，它应将其从这些包的报头、从自身到D以及从D到E所学到的“正向”链路的存在添加到其缓存中。在这种情况下，节点C不应缓存这些包报头中标识的链路的“反向”方向，从自身返回到B，从B到A，因为这些链接可能是单向的。
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.
在上面的第二种情况下，链路偶尔可以单向操作，上面描述的链路应该在两个方向上高速缓存。此外，在这种情况下，如果节点X偷听（例如，通过混杂模式）由节点C发送的使用从节点a到e的源路由的分组，则节点X也应缓存所有这些链路，还包括其偷听分组的从C到X的链路。
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. However, the links not yet traversed in this route SHOULD NOT be cached.
在MAC协议要求单播操作具有物理双向性的最后一种情况下，应在两个方向上缓存来自源路由的链路，除非数据包还包含路由应答，在这种情况下，应仅缓存该源路由中已通过的链路。但是，此路由中尚未遍历的链接不应缓存。
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 it is found, the node generally returns a Route Reply to the initiator itself rather than forward 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:
但是，在以这种方式传输使用其路由缓存中的信息生成的路由应答数据包之前，节点必须验证在此连接之后，路由应答中返回的结果路由是否包含路由记录中列出的重复节点。例如，下图说明了一种情况，其中节点F已经接收到针对目标E的路由请求，并且节点F的路由缓存中已经有一条从自身到E的路由：
+-----+ +-----+ +-----+ +-----+
| A |---->| B |- >| D |---->| E |
+-----+ +-----+ \ / +-----+ +-----+
\ /
\ +-----+ /
>| C |-
+-----+
| ^
v |
Route Request +-----+
Route: A - B - C - F | F | Cache: C - D - 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.
来自路由请求的累积路由记录和来自F的路由缓存的缓存路由的串联将包括从C传递到F并返回到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, due to this restriction on returning a Route Reply based on information from its Route Cache, node F does not return such a Route Reply, it propagates the Route Request normally.
在这种情况下，节点F可以尝试编辑路由以消除重复，从而产生从a到B到C到D再到E的路由，但在这种情况下，节点F将不在其自己的路由应答中返回的路由上。DSR路由发现禁止节点F从其缓存返回这样的路由应答；这种禁止增加了结果路由有效的概率，因为在这种情况下，如果路由先前停止工作，节点F应该已经接收到路由错误。此外，该禁止意味着，将来穿越该路由的路由错误很可能通过发送该路由的路由应答的任何节点（包括节点F），这有助于确保及时地从缓存（例如在F处）移除过时数据；否则，由A启动的下一个路由发现也可能被来自F的包含相同陈旧路由的路由应答所污染。如果由于对基于来自其路由缓存的信息返回路由应答的限制，节点F不返回这样的路由应答，则它正常地传播路由请求。
Each Route Request message contains a "hop limit" that may be used to limit the number of intermediate nodes allowed to forward that copy of the Route Request. This hop limit is implemented using the Time-to-Live (TTL) field in the IP header of the packet carrying the Route Request. As the Request is forwarded, this limit is decremented, and the Request packet is discarded if the limit reaches zero before finding the target. This Route Request hop limit can be used to implement a variety of algorithms for controlling the spread of a Route Request during a Route Discovery attempt.
每个路由请求消息都包含一个“跃点限制”，可用于限制允许转发该路由请求副本的中间节点数。此跃点限制是使用承载路由请求的数据包的IP报头中的生存时间（TTL）字段实现的。当请求被转发时，该限制将减小，如果在找到目标之前限制达到零，则请求数据包将被丢弃。此路由请求跃点限制可用于实现各种算法，用于在路由发现尝试期间控制路由请求的传播。
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 using this technique sends its first Route Request attempt for some target node using a hop limit of 1, such that any node receiving the initial transmission of the Route Request will 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 the target is currently a neighbor of the initiator or if a neighbor node has a route to the target cached (effectively using the neighbors' Route Caches as an extension of the initiator's own Route Cache). If no Route Reply is received after a short timeout, then the node sends a "propagating" Route Request for the target node (i.e., with hop limit as defined by the value of the DiscoveryHopLimit configuration variable).
例如，节点可以使用该跃点限制来实现“非传播”路由请求，作为路由发现的初始阶段。使用此技术的节点使用跳数限制1向某个目标节点发送其第一次路由请求尝试，这样接收路由请求初始传输的任何节点都不会通过重新广播将请求转发给其他节点。这种形式的路由请求称为“非传播”路由请求；它提供了一种廉价的方法，用于确定目标当前是否是启动器的邻居，或者邻居节点是否缓存了到目标的路由（有效地使用邻居的路由缓存作为启动器自身路由缓存的扩展）。如果在短时间超时后未收到路由应答，则节点向目标节点发送“传播”路由请求（即，具有由DiscoveryHopLimit配置变量的值定义的跳数限制）。
As another example, a node MAY use this hop limit to implement an "expanding ring" search for the target [JOHNSON96a]. A node using this technique sends an initial non-propagating Route Request as described above; if no Route Reply is received for it, the node originates another Route Request with a hop limit of 2. For each Route Request originated, if no Route Reply is received for it, the node doubles the hop limit used on the previous attempt, to progressively explore for the target node without allowing the Route Request to propagate over the entire network. However, this expanding ring search approach could increase the average latency of Route Discovery, since multiple Discovery attempts and timeouts may be needed before discovering a route to the target node.
作为另一个示例，节点可以使用该跳数限制来实现对目标的“扩展环”搜索[Johnson 96a]。如上所述，使用该技术的节点发送初始非传播路由请求；如果没有收到路由应答，则节点发起另一个跃点限制为2的路由请求。对于每个发起的路由请求，如果没有收到路由回复，则节点会将上一次尝试中使用的跃点限制加倍，以逐步探索目标节点，而不允许路由请求在整个网络上传播。然而，这种扩展环搜索方法可能会增加路由发现的平均延迟，因为在发现到目标节点的路由之前，可能需要多次发现尝试和超时。
When an intermediate node forwarding a packet detects through Route Maintenance that the next hop along the route for that packet is broken, if the node has another route to the packet's destination in its Route Cache, the node SHOULD "salvage" the packet rather than discard it. To salvage a packet, the node replaces the original source route on the packet with a route from its Route Cache. The node then forwards the packet to the next node indicated along this source route. 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 the original route in the packet with this new route from its own Route Cache rather than discarding the packet.
当转发数据包的中间节点通过路由维护检测到该数据包的路由上的下一跳中断时，如果该节点在其路由缓存中有另一条到该数据包目的地的路由，则该节点应“挽救”该数据包，而不是丢弃该数据包。为了挽救数据包，节点将数据包上的原始源路由替换为来自其路由缓存的路由。然后，该节点将数据包转发到沿着该源路由指示的下一个节点。例如，在第3.2节的示例中所示的情况下，如果节点C缓存了另一条路由到节点E，则它可以通过从其自身的路由缓存中将该包中的原始路由替换为该新路由来挽救该包，而不是丢弃该包。
When salvaging a packet, 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, since the TTL is
在回收数据包时，数据包中保留其被回收次数的计数，以防止单个数据包被无休止地回收。否则，因为TTL是
decremented only once by each node, a single node could salvage a packet an unbounded number of times. Even if we chose to require the TTL to be decremented on each salvage attempt, packet salvaging is an expensive operation, so it is desirable to bound the maximum number of times a packet can be salvaged independently of the maximum number of hops a packet can traverse.
每个节点只减少一次，单个节点可以挽救一个数据包无数次。即使我们选择在每次补救尝试时要求减少TTL，数据包补救也是一项昂贵的操作，因此，最好将数据包可被补救的最大次数与数据包可穿越的最大跳数分开。
As described in Section 3.2, an intermediate node, such as in this case, that detects through Route Maintenance that the next hop along the route for a 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 the packet could not be forwarded. If the node sends this Route Error, it SHOULD originate the Route Error before salvaging the packet.
如第3.2节所述，中间节点（例如在本例中）通过路由维护检测到其转发的数据包沿路由的下一跳中断，该节点还应将路由错误返回给数据包的原始发送方，以识别无法转发数据包的链路。如果节点发送此路由错误，则应在回收数据包之前发起路由错误。
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 handling that packet as 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 new broken link. For each such packet currently queued at this node, the node SHOULD process that packet as follows:
当转发数据包的中间节点通过路由维护检测到该数据包的路由上的下一跳链路断开时，除了按照为路由维护定义的方式处理该数据包外，该节点还应以类似的方式处理其排队的、目的地在该新断开链路上的任何未决数据包。具体地说，节点应搜索其网络接口队列和维护缓冲区（第4.5节），以查找下一跳链路是该新断开链路的数据包。对于当前在该节点排队的每个此类数据包，该节点应按如下方式处理该数据包：
- Remove the packet from the node's Network Interface Queue and Maintenance Buffer.
- 从节点的网络接口队列和维护缓冲区中删除数据包。
- Originate a Route Error for this packet to the original sender of the packet, using the procedure described in Section 8.3.4, as if the node had already reached the maximum number of retransmission attempts for that packet for Route Maintenance. However, in sending such Route Errors for queued packets in response to detection of a single, new broken link, the node SHOULD send no more than one Route Error to each original sender of any of these packets.
- 使用第8.3.4节中描述的程序，为该数据包向该数据包的原始发送方发起一个路由错误，就好像节点已经达到该数据包用于路由维护的最大重传尝试次数一样。然而，在响应于检测到单个新的断开链路而为排队的分组发送此类路由错误时，节点应向这些分组中任何一个的每个原始发送者发送不超过一个路由错误。
- If the node has another route to the packet's IP Destination Address in its Route Cache, the node SHOULD salvage the packet as described in Section 8.3.6. Otherwise, the node SHOULD discard the packet.
- 如果节点在其路由缓存中有到数据包IP目的地地址的另一条路由，则该节点应按照第8.3.6节所述修复数据包。否则，节点应丢弃该数据包。
Source routes in use MAY be automatically shortened if one or more intermediate nodes in the route become no longer necessary. This mechanism of automatically shortening routes in use is somewhat similar to the use of passive acknowledgements [JUBIN87]. In particular, if a node is able to overhear a packet carrying a source route (e.g., by operating its network interface in promiscuous receive mode), then this node examines the unexpended portion of that source route. If this node is not the intended next-hop destination for the packet but is named in the later unexpended portion of the packet's source route, then it can infer that the intermediate nodes before itself in the source route are no longer needed in the route. For example, the figure below illustrates an example in which node D has overheard a data packet being transmitted from B to C, for later forwarding to D and to E:
如果不再需要路由中的一个或多个中间节点，则使用中的源路由可能会自动缩短。这种自动缩短使用中的路由的机制与被动应答的使用有些相似[JUBIN87]。特别地，如果节点能够无意中听到携带源路由的分组（例如，通过在混杂接收模式下操作其网络接口），则该节点检查该源路由的未使用部分。如果该节点不是分组的预期下一跳目的地，而是在分组的源路由的稍后未使用部分中命名的，则可以推断源路由中在其之前的中间节点在路由中不再需要。例如，下图说明了一个示例，其中节点D无意中听到数据包从B发送到C，以便稍后转发到D和E：
+-----+ +-----+ +-----+ +-----+ +-----+
| A |---->| B |---->| C | | D | | E |
+-----+ +-----+ +-----+ +-----+ +-----+
\ ^
\ /
---------------------
+-----+ +-----+ +-----+ +-----+ +-----+
| A |---->| B |---->| C | | D | | E |
+-----+ +-----+ +-----+ +-----+ +-----+
\ ^
\ /
---------------------
In this case, this node (node D) SHOULD return a "gratuitous" Route Reply to the 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 suffix of the original source route beginning with the node returning the gratuitous Route Reply (node D). In this example, the route returned in the gratuitous Route Reply message sent from D to A gives the new route as the sequence of hops from A to B to D to E.
在这种情况下，该节点（节点D）应向数据包的原始发送方（节点a）返回“免费”路由应答。路由应答给出较短的路由，作为原始源路由的一部分通过发送偷听分组的节点（节点B）向上的级联，加上原始源路由的后缀，该后缀从返回免费路由应答的节点（节点D）开始。在本例中，从D发送到A的免费路由应答消息中返回的路由将新路由作为从A到B到D到E的跳跃序列。
When deciding whether to return a gratuitous Route Reply in this way, a node MAY factor in additional information beyond the fact that it was able to overhear the packet. For example, the node MAY decide to return the gratuitous Route Reply only when the overheard packet is received with a signal strength or signal-to-noise ratio above some specific threshold. In addition, each node maintains a Gratuitous Route Reply Table, as described in Section 4.4, to limit the rate at which it originates gratuitous Route Replies for the same returned route.
当决定是否以这种方式返回免费路由应答时，节点可能会考虑额外的信息，而不仅仅是它能够无意中听到数据包。例如，节点可以仅当接收到信号强度或信噪比高于某个特定阈值的偷听分组时，才决定返回免费路由应答。此外，如第4.4节所述，每个节点维护一个免费路由应答表，以限制其为相同返回路由发起免费路由应答的速率。
When a source node receives a Route Error for a data packet that it originated, this source node propagates this Route Error to its neighbors by piggybacking it on its next Route Request. In this way, stale information in the caches of nodes around this source node will not generate Route Replies that contain the same invalid link for which this source node received the Route Error.
当源节点接收到其发起的数据包的路由错误时，该源节点通过在其下一个路由请求上搭载该路由错误，将该路由错误传播给其邻居。这样，此源节点周围的节点缓存中的过时信息将不会生成包含此源节点收到路由错误的相同无效链接的路由回复。
For example, in the situation shown in the example of Section 3.2, node A learns from the 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 its Route Cache). On the Route Request packet initiating this Route Discovery, node A piggybacks a copy of this Route Error, ensuring that the Route Error spreads well to other nodes, and guaranteeing that any Route Reply that it receives (including those from other node's Route Caches) in response to this Route Request does not contain a route that assumes the existence of this broken link.
例如，在第3.2节示例中所示的情况下，节点A从来自C的路由错误消息中得知，从C到D的链路当前已断开。因此，它将从自己的路由缓存中删除此链接，并启动新的路由发现（如果在其路由缓存中没有其他要查找的路由）。在发起该路由发现的路由请求数据包上，节点A携带该路由错误的副本，确保路由错误很好地传播到其他节点，并确保其接收到的任何路由回复（包括来自其他节点的路由缓存的路由回复）响应此路由请求时，不包含假定存在此断开链路的路由。
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 the packet. The DSR flow state extension further reduces the overhead of the protocol yet still preserves the fundamental properties of DSR's operation. Once a sending node has discovered a source route such as through DSR's Route Discovery mechanism, the flow state mechanism allows the sending node to establish hop-by-hop forwarding state within the network, based on this source route, to enable each node along the route to forward the packet to the next hop based on the node's own local knowledge of the flow along which this packet is being routed. Flow state is dynamically initialized by the first packet using a source route and is then able to route subsequent packets along the same flow without use of a source route header in the packet. The state established at each hop along a flow is "soft state" and thus automatically expires when no longer needed and can be quickly recreated as necessary. Extending DSR's basic operation based on an explicit source route in the header of each packet routed, the flow state extension operates as a form of "implicit source routing" by preserving DSR's basic operation but removing the explicit source route from packets.
本节描述了DSR协议的可选兼容扩展，称为“流状态”，该扩展允许在数据包中没有显式源路由头的情况下路由大多数数据包。DSR操作的基本流保留器的开销进一步减少。一旦发送节点发现源路由（如通过DSR的路由发现机制），流状态机制允许发送节点基于该源路由在网络内建立逐跳转发状态，使路由上的每个节点能够基于该节点自身对该数据包路由所沿的流的本地知识将该数据包转发到下一跳。流状态由使用源路由的第一个分组动态初始化，然后能够沿着相同的流路由后续分组，而不使用分组中的源路由报头。在流的每个跃点处建立的状态是“软状态”，因此在不再需要时自动过期，并且可以根据需要快速重新创建。基于每个分组路由的报头中的显式源路由扩展DSR的基本操作，流状态扩展通过保留DSR的基本操作但从分组中删除显式源路由，以“隐式源路由”的形式运行。
A source node sending packets to some destination node MAY use the DSR flow state extension described here to establish a route to that destination as a flow. A "flow" is a route from the source to the destination represented by hop-by-hop forwarding state within the nodes along the route. Each flow is uniquely identified by a combination of the source node address, the destination node address, and a flow identifier (flow ID) chosen by the source node.
向某个目的地节点发送分组的源节点可以使用这里描述的DSR流状态扩展来建立作为流的到该目的地的路由。“流”是从源到目的地的路由，由沿路由的节点内的逐跳转发状态表示。每个流由源节点地址、目标节点地址和源节点选择的流标识符（流ID）的组合唯一标识。
Each flow ID is a 16-bit unsigned integer. Comparison between different flow IDs MUST be performed modulo 2**16. For example, using an implementation in the C programming language, a flow ID value (a) is greater than another flow ID value (b) if ((short)((a) - (b)) > 0), if a C language "short" data type is implemented as a 16-bit signed integer.
每个流ID是一个16位无符号整数。不同流ID之间的比较必须以2**16的模进行。例如，使用C编程语言中的实现，如果（（short）（（a）-（b））>0，如果C语言“short”数据类型实现为16位有符号整数，则流ID值（a）大于另一个流ID值（b）。
A DSR Flow State header in a packet identifies the flow ID to be followed in forwarding that packet. From a given source 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. One of these flows MAY be considered the "default" flow from that source to that destination. If a node receives a packet with neither a DSR Options header specifying the route to be taken (with a Source Route option in the DSR Options header) nor a DSR Flow State header specifying the flow ID to be followed, it is forwarded along the default flow for the source and destination addresses specified in the packet's IP header.
数据包中的DSR流状态报头标识转发该数据包时要遵循的流ID。从一个给定的源到某个目的地，可能存在任意数量的不同流，并且正在使用，例如，跟随不同的跳序列到达目的地。其中一个流可以被视为从该源到该目的地的“默认”流。如果节点接收到的数据包既没有指定要采取的路由的DSR Options报头（DSR Options报头中有Source route选项），也没有指定要遵循的流ID的DSR Flow State报头，则它将沿着数据包IP报头中指定的源地址和目标地址的默认流转发。
In establishing a new flow, the source node generates a nonzero 16-bit flow ID greater than any unexpired flow IDs for this (source, destination) pair. If the source wishes for this flow to become the default flow, the low bit of the flow ID MUST be set (the flow ID is an odd number); otherwise, the low bit MUST NOT be set (the flow ID is an even number).
在建立新流时，源节点生成一个非零的16位流ID，该ID大于此（源、目标）对的任何未过期流ID。如果源希望此流成为默认流，则必须设置流ID的低位（流ID为奇数）；否则，不得设置低位（流ID为偶数）。
The source node establishing the new flow then transmits a packet containing a DSR Options header with a Source Route option. To establish the flow, the source node also MUST include in the packet a DSR Flow State header, with the Flow ID field set to the chosen flow ID for the new flow, and MUST include a Timeout option in the 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 destination (for example, the first packet sent after discovering the new route) but is also treated as a "flow establishment" packet.
然后，建立新流的源节点发送包含带有源路由选项的DSR Options报头的数据包。要建立流，源节点还必须在数据包中包含一个DSR流状态标头，其中流ID字段设置为新流的所选流ID，并且必须在DSR选项标头中包含一个超时选项，给出有关此流的状态信息将在该期限后过期的生存期。该分组通常是从该发送者发送到目的地的正常数据分组（例如，发现新路由后发送的第一个分组），但也被视为“流建立”分组。
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.
源节点在其流表中记录此流以备将来使用，将此流表条目中的TTL设置为数据包IP报头中TTL字段中使用的值，并将此条目中的生存期设置为DSR Options报头中超时选项中指定的生存期。TTL字段用于默认流转发，如第3.5.3节和第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.
在超时之前使用此流ID发送的任何其他数据包，如果还包含带有源路由选项的DSR Options标头，则必须在源路由选项中使用相同的源路由。
Packets intended to establish a flow, as described in 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.
如第3.5.1节所述，用于建立流的数据包包含带有源路由选项的DSR Options报头，并沿指示的路由转发。实现DSR流状态扩展的节点在接收和转发这样的DSR数据包时，也在其自己的流表中保持一些状态，以使其能够转发仅使用指定的流ID沿着该流发送的未来数据包。具体地说，如果该分组还包含DSR流状态报头，则该分组应导致在沿着分组的路由的每个节点的流表中为该流建立条目。
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.
DSR流状态标头的跃点计数字段也存储在流表中，DSR选项标头中指定的超时选项中指定的生存期也是如此。
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.
如果流ID为奇数，并且流表中没有流ID大于接收到的流ID的流，则将此（IP源地址、IP目标地址）对的默认流ID设置为接收到的流ID，并记录数据包的TTL。
The Flow ID option is removed before final delivery of the packet.
在数据包最终交付之前，将删除Flow ID选项。
When a flow is established as described in 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
当如第3.5.1节所述建立流时，发送一个数据包，该数据包在路由上的每个节点中建立状态。这种状态是软的；也就是说，协议包含从该状态丢失中恢复的机制。然而，这些机制的使用可能会导致随着具有遗忘状态的流发送的数据包的性能降低。结果，期望基于发送方是否合理地确定流状态存在于沿路由的每个节点上来区分行为。如果路由上所有节点的流表包含该流的转发信息，我们将该流的状态定义为“已建立的端到端”。而不可能检测到流的状态是否已更改
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.
希望沿着已建立的流发送分组的源确定流状态是否已端到端建立。如果没有，则数据包中会添加一个DSR Options头，其中包含源路由选项和此流的路由。源应将DSR Flow State标头的Flow ID字段设置为以前与此流的路由关联的流ID或设置为零。如果将Flow ID字段设置为任何其他值，则必须按照第3.5.1节中的处理步骤建立新的Flow ID。如果将Flow ID字段设置为非零值，则必须包含一个超时选项，该选项的值不得大于节点流表中剩余的超时值，如果其TTL不等于流表中指定的TTL，则该流将来不得用作默认流。
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.
一旦为非默认流建立了端到端的流状态，源向它希望沿着该流发送的每个数据包添加一个DSR流状态头，将流ID字段设置为该流的流ID。不应将源路由选项添加到数据包中，但如果是，则必须遵循处理未建立端到端的流的步骤。
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.
一旦为默认流建立了端到端的流状态，发送IP TTL等于该流本地流表条目中TTL值的数据包的源，然后将数据包传输到下一跳。在这种情况下，不应将DSR流状态报头添加到分组，同样，也不应将DSR选项报头添加到分组；如果是，则必须遵循沿非默认流发送数据包的步骤。如果IP TTL不等于本地流表中的TTL值，则必须遵循处理非默认流的步骤。
The handling of packets containing a DSR Options header with both a nonzero Flow ID and a Source Route option is described in 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.
第3.5.2节描述了对包含DSR Options报头且具有非零流ID和源路由选项的数据包的处理。流量ID等于零时将被忽略。本节仅描述不带源路由选项的数据包处理。
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.
如果节点接收到一个数据包，该数据包在DSR Options报头中的流ID指示节点流表中的未过期流，则它会增加DSR Options报头中的跃点计数，并将该数据包转发到流表中指示的下一个跃点。
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.
如果节点接收到一个具有流ID的数据包，该流ID指示当前不在节点的流表中的流，则它返回一个类型为UNKNOWN\u Flow的路由错误，错误目的地和IP目的地地址是从触发错误的数据包的IP源复制的。这个错误包应该是发送到接收包的节点的MAC；如果无法使用路由维护确认前一节点的可达性，则必须发送第8.1.1节所述的错误。发送错误的节点应尝试挽救触发路由错误的数据包。如果它确实挽救了数据包，则必须将数据包中的流ID归零。
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.
如果节点接收到一个没有DSR选项头和DSR流状态头的数据包，它将检查默认流表。如果有匹配的条目，它将转发到默认流的流表中指示的下一个跃点。否则，它返回类型为DEFAULT_FLOW_UNKNOWN的路由错误，错误目的地和IP目的地地址是从触发错误的数据包的IP源地址复制的。这个错误包应该是发送到接收它的节点的MAC；如果该节点无法使用路由维护确认前一节点的可达性，则必须发送第8.1.1节所述的错误。发送错误的节点应尝试挽救触发路由错误的数据包。如果它确实挽救了数据包，则必须将数据包中的流ID归零。
When a node receives a Route Error of type UNKNOWN_FLOW, it marks the flow to indicate that it has not been established end-to-end. When a node receives a Route Error of type DEFAULT_FLOW_UNKNOWN, it marks the default flow to indicate that it has not been established end-to-end.
当节点接收到类型为UNKNOWN_FLOW的路由错误时，它会标记该流以指示尚未端到端建立该流。当节点接收到类型为DEFAULT\u FLOW\u UNKNOWN的路由错误时，它会标记默认流，以指示尚未建立端到端的路由错误。
Because a full source route is not carried in every packet, an alternative method for performing automatic route shortening is necessary for packets using the flow state extension. Instead, nodes promiscuously listen to packets, and if a node receives a packet with (IP Source, IP Destination, Flow ID) found in the Flow Table but the MAC-layer (next hop) destination address of the packet is not this node, the node determines whether the packet was sent by an upstream or downstream node by examining the Hop Count field in the DSR Flow State header. If the Hop Count field is less than the expected Hop Count at this node (that is, the expected Hop Count field in the Flow Table described in 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
因为没有在每个分组中携带完整的源路由，所以对于使用流状态扩展的分组，需要执行自动路由缩短的替代方法。相反，节点杂乱地侦听数据包，如果节点接收到一个数据包（IP源、IP目的地、流ID）位于流表中，但数据包的MAC层（下一跳）目的地地址不是该节点，该节点通过检查DSR流状态报头中的跃点计数字段来确定数据包是由上游节点还是下游节点发送的。如果该节点的跃点计数字段小于预期的跃点计数（即，第5.1节中描述的流表中的预期跃点计数字段），则该节点假定该数据包是由上游节点发送的，并将该数据包的条目添加到其自动路由缩短表中，可能会删除添加到此表中的较早条目。当数据包随后被发送到该节点进行
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.
转发时，节点通过检查其自动路由缩短表发现它以前已收到该数据包，并向该数据包的源返回免费路由回复。
If a node receives a packet for forwarding with TTL lower than expected and default flow forwarding is being used, it sends a Route Error of type DEFAULT_FLOW_UNKNOWN back to the IP source. It can attempt delivery of the packet by normal salvaging (subject to constraints described in Section 8.6.7).
如果一个节点接收到一个TTL低于预期的用于转发的数据包，并且正在使用默认流转发，那么它会将类型为default\u flow\u UNKNOWN的路由错误发送回IP源。它可以尝试通过正常打捞方式交付数据包（受第8.6.7节所述约束）。
In packets sent using Flow State, the previous hop is not necessarily known. In order to allow nodes that have lost flow state to determine the previous hop, the address of the previous hop can optionally be stored in the Acknowledgement Request. This extension SHOULD NOT be used when a Source Route option is present, MAY be used when flow state routing is used without a Source Route option, and SHOULD be used before Route Maintenance determines that the next-hop destination is unreachable.
在使用流状态发送的数据包中，前一跳不一定是已知的。为了允许丢失流状态的节点确定前一跳，可以选择将前一跳的地址存储在确认请求中。当存在源路由选项时，不应使用此扩展，当使用流状态路由而不使用源路由选项时，可以使用此扩展，并且应在路由维护确定无法到达下一跳目的地之前使用此扩展。
Each node has a maximum Timeout value that it can possibly generate. This can be based on the largest number that can be set in a timeout option (2**16 - 1 seconds) or may be less than this, set in system software. When a node crashes, it does not establish new flows for a period equal to this maximum Timeout value, in order to avoid colliding with its old Flow IDs.
每个节点都有可能生成的最大超时值。这可以基于超时选项（2**16-1秒）中可设置的最大值，也可以小于系统软件中设置的最大值。当节点崩溃时，它不会在等于此最大超时值的时间段内建立新流，以避免与其旧流ID冲突。
Flow IDs can be assigned with a counter. More specifically, the "Current Flow ID" is kept. When a new default Flow ID needs to be assigned, if 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.
可以使用计数器分配流ID。更具体地说，保留“当前流ID”。当需要分配新的默认流ID时，如果当前流ID为奇数，则将当前流ID分配为流ID，并将当前流ID递增1；如果当前流ID为偶数，则一加上当前流ID将被指定为流ID，并且当前流ID将增加两。
If Flow IDs are assigned in this way, one algorithm for avoiding duplicate, unexpired Flow IDs is to 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 be averaged over any period not exceeding the maximum Timeout value.
如果以这种方式分配流ID，一种避免重复的、未过期的流ID的算法是将新流ID的速率限制为每秒n个分配的平均速率，其中n是2**15除以最大超时值。这可以在不超过最大超时值的任何时间段内平均。
Salvaging is modified to zero the Flow ID field in the packet. Also, anytime this document refers to the Salvage field in the Source Route option in a DSR Options header, packets without a Source Route option are considered to have the value zero in the Salvage field.
打捞被修改为使数据包中的流ID字段为零。此外，每当本文档引用DSR Options报头中源路由选项中的补救字段时，不带源路由选项的数据包被认为在补救字段中的值为零。
This document describes the operation of the 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 protocol. In an implementation of the protocol, these data structures MUST be implemented in a manner consistent with the external behavior described in this document, but the choice of implementation used is otherwise unconstrained. Additional conceptual data structures are required for the optional flow state extensions to DSR; these data structures are described in Section 5.
本文档描述了DSR协议在许多概念数据结构方面的操作。本节介绍每种数据结构，并概述其在协议中的使用。在协议的实现中，这些数据结构必须以与本文档中描述的外部行为一致的方式实现，但所用实现的选择不受限制。DSR的可选流状态扩展需要额外的概念数据结构；第5节描述了这些数据结构。
Each node implementing DSR MUST maintain a Route Cache, containing routing information needed by the node. A node adds information to its Route Cache as it learns of new links between nodes in the ad hoc network; for example, a node may learn of new links when it receives 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 in the ad hoc network have broken. For example, a node may learn of a broken link when it receives a packet carrying a Route Error or through the link-layer retransmission mechanism reporting a failure in forwarding a packet to its next-hop destination.
实现DSR的每个节点都必须维护一个路由缓存，其中包含节点所需的路由信息。节点在获悉自组织网络中节点之间的新链路时向其路由缓存添加信息；例如，当节点接收到携带路由请求、路由应答或DSR源路由的分组时，节点可以学习新链路。类似地，节点在得知自组织网络中的现有链路已断开时，会从其路由缓存中删除信息。例如，当节点接收到携带路由错误的分组或通过链路层重传机制报告将分组转发到其下一跳目的地的失败时，节点可以获知断开的链路。
Anytime a node adds new information to its Route Cache, the node SHOULD check each packet in its own Send Buffer (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.
每当节点向其路由缓存添加新信息时，该节点应检查其自身发送缓冲区（第4.2节）中的每个数据包，以确定到该数据包的IP目的地地址的路由现在是否存在于节点的路由缓存中（包括刚刚添加到缓存中的信息）。如果是这样，则应使用该路由发送数据包，并将其从发送缓冲区中删除。
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
可以将DSR网络与此DSR网络外部的其他网络连接。例如，这种外部网络可以是因特网，或者可以是使用除DSR之外的路由协议路由的其他自组织网络。这样的外部网络也可以是被视为外部网络以提高可伸缩性的其他DSR网络。此类外部网络的完整处理超出了本文件的范围。但是，本文件规定了最低限度的要求和功能
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.
必须允许仅实现此规范的节点与实现此类外部网络接口的节点正确互操作。此最低要求和功能集涉及DSR源路由选项（第6.7节）中的第一跳外部（F）和最后一跳外部（L）位，以及数据包DSR选项报头（第6节）中的路由应答选项（第6.3节）。这些要求还包括添加外部标志位，标记路由缓存中的每个链路，从DSR源路由选项或路由应答选项中的第一跳外部（F）和最后一跳外部（L）位复制，从中学习该链路。
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.
- 任何节点上的DSR的每个实现都可以选择任何适当的策略和算法来搜索其路由缓存，并从找到的路由中选择到目的地的“最佳”路由。例如，节点可以选择到目的地的最短路由（最短的跳跃序列），或者可以使用备用度量从缓存中选择路由。
- 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.
- 但是，如果有多个缓存的路由到一个目的地，则在搜索路由缓存时选择的路由应优先选择未在任何链接上设置外部标志的路由。此首选项将选择直接通向目标节点的路由，而不是尝试通过连接到DSR自组织网络的任何外部网络到达目标的路由。
- 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
- 每个节点上的DSR的每个实现可以选择任何适当的策略来管理其路由缓存中的条目，例如当有限的缓存容量要求选择要保留在缓存中的条目时。例如，节点可以选择“最近使用最少”（LRU）缓存替换策略，其中条目
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.
如果需要决定在缓存中为添加的某些新条目留出空间，则会从缓存中丢弃上次使用的最长时间ago。
- 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.
- 在DSR中，路由发现的发起人接收到的每个路由应答中返回的路由（或从开销数据包的报头中学习的路由，如第8.1.4节所述）表示通向目标节点的完整路径（链路序列）。通过分别缓存这些路径中的每一个，可以形成路由缓存的“路径缓存”组织。路径缓存实现起来非常简单，并且很容易保证所有路由都是无循环的，因为来自路由应答或路由请求或在数据包中使用的每个单独路由都是无循环的。要在路径缓存数据结构中搜索路由，发送节点只需在其路由缓存中搜索指向目标节点的任何路径（或路径前缀）。
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].
通过模拟[BROCH98、HU00、JOHANSSON99、MALTZ99a]和在移动室外试验台上在大量工作负载下实施DSR[MALTZ99b、MALTZ00、MALTZ01]，已经对DSR中的路由缓存的这种类型的组织进行了广泛的研究。
- 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.
- 或者，“链路缓存”组织可用于路由缓存，其中在路由应答分组（或从开销分组的报头学习的）中返回的路由中的每个单独链路（跃点）被添加到该节点的当前网络拓扑视图的统一图数据结构中。要在链路缓存中搜索路由，发送节点必须使用更复杂的图搜索算法，如著名的Dijkstra最短路径算法，以找到通过图到目标节点的当前最佳路径。这种算法更难实现，可能需要更多的CPU时间来执行。
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].
DSR中路由缓存的这种类型的组织，包括一系列实现选择的影响，已经通过详细模拟[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.
在任何DSR实现中，用于路由缓存的数据结构组织的选择对于每个节点来说都是一个局部问题，并且只影响性能；路由缓存组织的任何合理选择都不会影响正确性或互操作性。
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.
路由缓存中的每个条目都应该有一个与之相关联的超时，以允许在一段时间内不使用该条目时删除该条目。在为路由缓存中的条目选择超时时，应考虑用于实现路由缓存的算法和数据结构的特定选择。第9节中定义的配置变量RouteCacheTimeout指定要应用于路由缓存中条目的超时，尽管也可以使用自适应策略来选择超时值，而不是对所有条目使用单个超时设置。例如，链路MaxLife缓存设计（以下）使用自适应超时算法，而不使用RouteCacheTimeout配置变量。
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.
作为对实施者的指导，附录A描述了一种称为“链路MaxLife”的链路缓存类型，该类型的缓存性能优于详细模拟[HU00]中研究的其他类型的链路缓存和路径缓存。链路MaxLife是一种自适应链路缓存，其中缓存中的每个链路都有一个超时，该超时由缓存节点根据其在链路末端观察到的两个节点的过去行为动态确定。此外，当为发送到某个目的地的数据包选择路由时，在到该目的地的等长缓存路由（跳数）中，Link MaxLife选择预期寿命最长（路由中任何链路的最高最小超时）的路由。在DSR的实现中，建议对路由缓存使用链路MaxLife设计。
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 after a period of SendBufferTimeout after initially being placed in the buffer. If necessary, a FIFO strategy SHOULD be used to evict packets before they time out to prevent the buffer from overflowing.
实现DSR的节点的发送缓冲区是该节点无法发送的数据包队列，因为它还没有到每个数据包目的地的源路由。发送缓冲区中的每个数据包都与放入缓冲区的时间有逻辑关联，应该从发送缓冲区中删除，并在最初放入缓冲区后经过一段SendBufferTimeout后自动丢弃。如有必要，应使用FIFO策略在数据包超时之前逐出数据包，以防止缓冲区溢出。
Subject to the rate limiting defined in 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.
根据第4.3节中定义的速率限制，应尽可能频繁地针对驻留在发送缓冲区中的任何数据包的目标地址启动路由发现。
The Route Request Table of a node implementing DSR records information about Route Requests that have been recently originated or forwarded by this node. The table is indexed by IP address.
实现DSR的节点的路由请求表记录有关该节点最近发起或转发的路由请求的信息。该表按IP地址编制索引。
The Route Request Table on a node records the following information about nodes to which this node has initiated a Route Request:
节点上的路由请求表记录有关该节点已向其发起路由请求的节点的以下信息：
- The Time-to-Live (TTL) field used in the IP header of the Route Request for the last Route Discovery initiated by this node for that target node. This value allows the node to implement a variety of 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.3.
- 此节点为该目标节点启动的最后一个路由发现的路由请求的IP报头中使用的生存时间（TTL）字段。该值允许节点实现各种算法，以控制其路由请求在为目标启动的每个路由发现上的传播。作为示例，第3.3.3节描述了使用TTL字段的两种可能算法。
- 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.
使用路由请求数据包IP报头中的相同生存时间（TTL）值为此目标启动的每个后续路由发现的值。此类连续路由发现启动之间的超时应通过在每次新启动时加倍超时值来增加。
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.
- size RequestTableIds项的FIFO缓存，包含该节点从该发起方节点接收的最新路由请求的标识值和目标地址。
Nodes SHOULD use an LRU policy to manage the entries in their Route Request Table.
节点应使用LRU策略来管理其路由请求表中的条目。
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.
每个路由请求表条目RequestTableId中保留的标识值的数量不能是无限的，因为在最坏的情况下，当节点崩溃并重新启动时，它在重新启动后启动的第一个RequestTableId路由发现可能与网络中的其他节点重复。此外，节点应根据电池备份时钟或其他持久性存储设备（如果可用）在重启后用于路由发现的初始标识值，以帮助避免在重启后成功发现新路由时出现任何可能的此类延迟；如果没有此类初始标识值来源，则重新启动后的节点应将其初始标识值基于随机数。
The Gratuitous Route Reply Table of a node implementing DSR records information about "gratuitous" Route Replies sent by this node as part of automatic route shortening. As described in 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.
实现DSR的节点的免费路由应答表记录有关此节点作为自动路由缩短的一部分发送的“免费”路由应答的信息。如第3.4.3节所述，当某个节点无意中听到某个节点发送的数据包时，该节点返回一个免费的路由应答，对于该数据包，无意中听到该数据包的节点不是预期的下一跳节点，而是在该数据包中源路由的未使用的跳数中被命名的；偷听数据包的节点向数据包的原始发送方返回一个免费的路由回复，列出较短的路由（不包括该数据包“跳过”的源路由的跳数）。节点使用其免费路由应答表来限制其向同一节点的同一原始发送方发起免费路由应答的速率，该节点从中无意中听到数据包以触发免费路由应答。
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.
- 免费路由回复表中此条目过期并应由节点删除之前的剩余时间。当节点在其免费路由应答表中创建新条目时，该条目的超时值应初始化为值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.
当节点无意中听到将触发免费路由应答的数据包时，如果节点的免费路由应答表中已经存在相应的条目，则该节点不应为该数据包发送免费路由应答。否则（即，如果没有相应的条目已存在），节点应在其免费路由应答表中创建一个新条目，以记录该免费路由应答，超时值为GratReplyHoldoff。
Depending on factors such as the structure and organization of the operating system, protocol stack implementation, network interface device driver, and network interface hardware, a packet being transmitted could be queued in a variety of ways. For example, outgoing packets from the network protocol stack might be queued at the operating system or link layer, before transmission by the network interface. The network interface might also provide a retransmission mechanism for packets, such as occurs in IEEE 802.11 [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.
根据操作系统的结构和组织、协议栈实现、网络接口设备驱动程序和网络接口硬件等因素，正在传输的数据包可以以多种方式排队。例如，在通过网络接口传输之前，来自网络协议栈的传出数据包可能在操作系统或链路层排队。网络接口还可以为分组提供重传机制，例如在IEEE 802.11[IEEE80211]中发生的情况；作为路由维护的一部分，DSR协议要求对已经传输的数据包进行有限的缓冲，下一跳目的地的可达性尚未确定。DSR的操作在这里是根据两个概念数据结构定义的，这两个数据结构结合在一起，包含了这种排队行为。
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.
实现DSR的节点的网络接口队列是来自等待由网络接口发送的网络协议栈的分组的输出队列；例如，在4.4BSD Unix网络协议栈实现中，网络接口的此队列表示为“struct ifqueue”[WRIGHT95]。此队列用于在网络接口传输另一个数据包的过程中保存数据包。
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.
实现DSR的节点的维护缓冲区是该节点发送的等待下一跳可达性确认（作为路由维护的一部分）的数据包队列。对于维护缓冲器中的每个分组，节点维护重传次数和最后一次重传时间的计数。在进行第一次传输尝试后，数据包被添加到维护缓冲区。维护缓冲区的大小可能有限；在向维护缓冲区添加新数据包时，如果缓冲区大小不足以容纳新数据包，则应悄悄丢弃新数据包。如果在MaxMaintRexmt尝试确认某个节点的下一跳可达性后，未收到任何确认，则该节点的维护缓冲区中具有该下一跳目的地的所有数据包都应从维护缓冲区中删除。在这种情况下，该节点还应为此数据包向以这种方式移除的数据包的每个原始源发起路由错误（第8.3节），并且如果其路由缓存中有到该数据包的IP目的地地址的另一条路由，则应补救以这种方式移除的每个数据包（第8.3.6节）。MaxMaintRexmt的定义在概念上包括可能在链路层或网络接口硬件内对数据包尝试的任何重传。用于确认请求的每次传输尝试的超时值取决于路由维护用于该尝试的确认机制的类型，如第8.3节所述。
When a node using the DSR protocol is connected through a network interface that requires physically bidirectional links for unicast transmission, the node MUST maintain a blacklist. The blacklist is a table, indexed by neighbor node address, that indicates that the link between this node and the specified neighbor node may not be bidirectional. A node places another node's address in this list when it believes that broadcast packets from that other node reach this node, but that unicast transmission between the two nodes is not possible. For example, if a node forwarding a Route Reply discovers that the next hop is unreachable, it places that next hop in the node's blacklist.
当使用DSR协议的节点通过需要物理双向链路进行单播传输的网络接口连接时，该节点必须保持黑名单。黑名单是一个表，由邻居节点地址索引，表示此节点和指定邻居节点之间的链路可能不是双向的。当一个节点认为来自另一个节点的广播数据包到达该节点，但两个节点之间不可能进行单播传输时，该节点将另一个节点的地址放入该列表中。例如，如果转发路由应答的节点发现下一个跃点不可访问，它会将该下一个跃点放入节点的黑名单中。
Once a node discovers that it can communicate bidirectionally with one of the nodes listed in the blacklist, it SHOULD remove that node from the blacklist. For example, if node A has node B listed in its blacklist, but after transmitting a Route Request, node A hears B forward the Route Request with a route record indicating that the broadcast from A to B was successful, then A SHOULD remove the entry for node B from its blacklist.
一旦节点发现它可以与黑名单中列出的一个节点进行双向通信，它应该将该节点从黑名单中删除。例如，如果节点A将节点B列在其黑名单中，但在发送路由请求后，节点A听到B转发路由请求，并带有指示从A到B的广播成功的路由记录，则A应从其黑名单中删除节点B的条目。
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.
节点必须将状态与其黑名单中列出的每个节点相关联，指定指向该节点的链接的单向性是“可疑”还是“可能”。每次确定不可达性时，节点应将状态设置为“可能”。在一段时间内未确定不可达性后，状态应恢复为“可疑”。一个节点可能会在一段合理的时间后使其黑名单中节点的条目过期。
This section defines additional conceptual data structures used by the optional "flow state" extension to DSR. In an implementation of the protocol, these data structures MUST be implemented in a manner consistent with the external behavior described in this document, but the choice of implementation used is otherwise unconstrained.
本节定义了DSR的可选“流状态”扩展所使用的其他概念数据结构。在协议的实现中，这些数据结构必须以与本文档中描述的外部行为一致的方式实现，但所用实现的选择不受限制。
A node implementing the flow state extension MUST implement a Flow Table or other data structure consistent with the external behavior described in this section. A node not implementing the flow state extension SHOULD NOT implement a Flow Table.
实现流状态扩展的节点必须实现与本节中描述的外部行为一致的流表或其他数据结构。未实现流状态扩展的节点不应实现流表。
The 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 number assigned by the source as described in Section 3.5.1. Each entry in the Flow Table contains the following fields:
流表记录有关此节点最近发送或转发数据包的流的信息。该表由三元组（IP源地址、IP目标地址、流ID）索引，其中流ID是由第3.5.1节所述源分配的16位数字。流量表中的每个条目都包含以下字段：
- The MAC address of the next-hop node along this flow.
- 沿此流的下一跳节点的MAC地址。
- 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.
- 沿此流的上一跳节点的MAC地址。
- 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).
- DSR流状态标头中接收的数据包的跃点计数字段的预期值，用于沿此字段转发（用于包含DSR流状态标头的数据包）。
- 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).
- 指示此流是否可以用作此节点发起的数据包的默认流（默认流的流ID必须为奇数）。
- 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.
该条目超时后必须删除。
A node implementing the flow state extension SHOULD implement an Automatic Route Shortening Table or other data structure consistent with the external behavior described in this section. A node not implementing the flow state extension SHOULD NOT implement an Automatic Route Shortening Table.
实现流状态扩展的节点应实现一个自动路由缩短表或与本节所述外部行为一致的其他数据结构。未实现流状态扩展的节点不应实现自动路由缩短表。
The Automatic Route 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 Automatic Route Shortening Table contains a list of (packet identifier, Hop Count) pairs for that flow. The packet identifier in the list may be any unique identifier for the received packet; for example, for IPv4 packets, the combination of the following fields from the packet's IP header MAY be used as a unique identifier for the packet: Source Address, Destination Address, Identification, Protocol, Fragment Offset, and Total Length. The Hop Count in the list in the entry is copied from the Hop Count field in the DSR Flow State header of the received packet for which this table entry was created. Any packet identifier SHOULD appear at most once in an entry's list, and this list item SHOULD record the minimum Hop Count value received for that packet (if the wireless signal strength or signal-to-noise ratio at which a packet is received is available to the DSR implementation in a node, the node MAY, for example, remember instead in this list the minimum Hop Count value for which the received packet's signal strength or signal-to-noise ratio exceeded some threshold).
自动路由缩短表记录关于接收的分组的信息，对于这些分组，可以进行自动路由缩短。该表由三元组（IP源地址、IP目标地址、流ID）索引。自动路由缩短表中的每个条目都包含该流的（数据包标识符、跳数）对列表。列表中的分组标识符可以是所接收分组的任何唯一标识符；例如，对于IPv4分组，来自分组的IP报头的以下字段的组合可用作分组的唯一标识符：源地址、目的地地址、标识、协议、片段偏移和总长度。条目列表中的跃点计数是从为其创建此表条目的接收数据包的DSR Flow State标头中的跃点计数字段复制的。任何数据包标识符在条目列表中最多应出现一次，此列表项应记录该数据包收到的最小跃点计数值（如果接收分组时的无线信号强度或信噪比可用于节点中的DSR实现，则该节点例如可以在该列表中记住接收分组的信号强度或信噪比超过某个阈值的最小跳数计数值）。
Space in the Automatic Route Shortening Table of a node MAY be dynamically managed by any local algorithm at the node. For example, in order to limit the amount of memory used to store the table, any existing entry MAY be deleted at any time, and the number of packets listed in each entry MAY be limited. However, when reclaiming space in the table, nodes SHOULD favor retaining information about more
节点的自动路由缩短表中的空间可由节点处的任何本地算法动态管理。例如，为了限制用于存储表的内存量，可以随时删除任何现有条目，并且可以限制每个条目中列出的分组的数量。但是，在回收表中的空间时，节点应该倾向于保留更多信息
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.
流在表中，而不是在表中的每个条目中列出更多的数据包，只要在每个条目中至少可以保留一些少量数据包（例如，3）的列表。
A node implementing the flow state extension MUST implement a Default Flow Table or other data structure consistent with the external behavior described in this section. A node not implementing the flow state extension SHOULD NOT implement a Default Flow Table.
实现流状态扩展的节点必须实现与本节中描述的外部行为一致的默认流表或其他数据结构。未实现流状态扩展的节点不应实现默认流表。
For each (IP Source Address, IP Destination Address) pair for which a node forwards packets, the node MUST record:
对于节点转发数据包的每个（IP源地址、IP目标地址）对，节点必须记录：
- The largest odd Flow ID value seen.
- 看到的最大奇数流ID值。
- The time at which all the corresponding flows that are forwarded by this node expire.
- 此节点转发的所有相应流过期的时间。
- The current default Flow ID.
- 当前默认流ID。
- A flag indicating whether or not the current default Flow ID is valid.
- 指示当前默认流ID是否有效的标志。
If a node deletes this record for an (IP Source Address, IP Destination Address) pair, it MUST also delete all Flow Table entries for that pair. Nodes MUST delete table entries if all of this (IP Source Address, IP Destination Address) pair's flows that are forwarded by this node expire.
如果节点删除（IP源地址、IP目标地址）对的此记录，则还必须删除该对的所有流表条目。如果此节点转发的所有（IP源地址、IP目标地址）对流过期，则节点必须删除表项。
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 Options 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 Options header is implied by the total length of the DSR Options header.
动态源路由协议利用携带控制信息的特殊报头，该控制信息可包含在任何现有IP数据包中。数据包中的这个DSR选项报头包含一个固定大小的4个八位字节的小部分，后面是一系列零个或多个DSR选项，其中包含可选信息。DSR选项标头中DSR选项序列的结尾由DSR选项标头的总长度表示。
For IPv4, the DSR Options header MUST immediately follow the IP header in the packet. (If a Hop-by-Hop Options extension header, as defined in IPv6 [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.)
对于IPv4，DSR Options报头必须紧跟在数据包中的IP报头之后。（如果IPv6[RFC2460]中定义的逐跳选项扩展报头为IPv4定义，则DSR选项报头必须紧跟在逐跳选项扩展报头之后（如果数据包中存在），否则必须紧跟在IP报头之后。）
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.
要向数据包添加DSR Options报头，DSR Options报头将插入数据包的IP报头之后，插入任何后续报头之前，如传统（如TCP或UDP）传输层报头。具体而言，IP报头中的协议字段用于指示IP报头之后是DSR Options报头，DSR Options报头中的下一个报头字段用于指示DSR Options报头之后的协议报头类型（例如传输层报头）。
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.
如果数据包中有任何头跟随DSR Options头，则DSR Options头的总长度（以及所有DSR选项的总长度）必须是4个八位字节的倍数。此要求保留数据包中以下报头的对齐。
The fixed portion of the DSR Options header is used to carry information that must be present in any DSR Options header. This fixed portion of the DSR Options header has the following format:
DSR选项标题的固定部分用于承载任何DSR选项标题中必须存在的信息。DSR选项标题的此固定部分具有以下格式：
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 .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Options header. Uses the same values as the IPv4 Protocol field [RFC1700]. If no header follows, then Next Header MUST have the value 59, "No Next Header" [RFC2460].
8位选择器。标识紧接DSR选项标头之后的标头类型。使用与IPv4协议字段[RFC1700]相同的值。如果后面没有标头，则下一个标头的值必须为59，“无下一个标头”[RFC2460]。
Flow State Header (F)
流量状态集管（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.
标志位。必须设置为0。该位在DSR流量状态标头（第7.1节）中设置，并在DSR选项标头中清除。
Reserved
含蓄的
MUST be sent as 0 and ignored on reception.
必须作为0发送，并在接收时忽略。
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.
DSR选项标头的长度，不包括4个八位字节的固定部分。有效负载长度字段的值定义DSR options标头中携带的所有选项的总长度。
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).
可变长度字段；选项字段的长度由此DSR选项标头中的有效负载长度字段指定。包含一条或多条可选信息（DSR选项），以类型长度值（TLV）格式编码（第6.8节中描述的Pad1选项除外）。
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.
DSR选项标题固定部分之后的DSR选项位置可以填充以对齐。然而，由于adhoc网络中的可用无线带宽通常有限，因此不需要这种填充，并且接收节点不得期望DSR options报头中的选项对齐。
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:
每个DSR选项都分配了一个唯一的选项类型代码。最高有效3位（即选项类型&0xE0）允许未执行此选项类型值处理的节点以最接近该类型的正确方式运行：
- 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.
- 选项类型值（即选项类型&0x80）中的最高有效位表示接收此选项类型的节点（当该节点未实现对此选项类型的处理时）是否应响应此DSR选项，且不支持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:
- 选项类型值（即选项类型&0x60）中的以下两位是两位字段，指示不支持此选项类型的节点必须如何处理数据包：
00 = Ignore Option 01 = Remove Option 10 = Mark Option 11 = Drop Packet
00=忽略选项01=删除选项10=标记选项11=丢弃数据包
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
当这2位为00（即选项类型&0x60==0）时，未对该选项类型执行处理的节点必须使用Opt Data Len字段跳过该选项并继续处理。当这2位为01（即选项类型&0x60==0x20）时，一个节点不执行对该选项类型的处理
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.
必须使用Opt Data Len字段从数据包中删除该选项，并继续处理，就像该选项未包含在接收的数据包中一样。当这2位为10（即，选项类型&0x60==0x40）时，未对该选项类型执行处理的节点必须在Opt Data Len字段后设置最高有效位，必须使用Opt Data Len字段忽略选项的内容，并且必须继续处理数据包。最后，当这2位为11（即选项类型&0x60==0x60）时，未对该选项类型执行处理的节点必须丢弃该数据包。
The following types of DSR options are defined in this document for use within a DSR Options header:
本文档中定义了以下类型的DSR选项，以便在DSR选项标题中使用：
- Route Request option (Section 6.2)
- 路由请求选项（第6.2节）
- Route Reply option (Section 6.3)
- 路线回复选项（第6.3节）
- Route Error option (Section 6.4)
- 路由错误选项（第6.4节）
- Acknowledgement Request option (Section 6.5)
- 确认请求选项（第6.5节）
- Acknowledgement option (Section 6.6)
- 确认选项（第6.6节）
- DSR Source Route option (Section 6.7)
- DSR源路由选项（第6.7节）
- Pad1 option (Section 6.8)
- Pad1选项（第6.8节）
- PadN option (Section 6.9)
- PadN选项（第6.9节）
In addition, Section 7 specifies further DSR options for use with the optional DSR flow state extension.
此外，第7节规定了与可选DSR流状态扩展一起使用的其他DSR选项。
The Route Request option in a DSR Options header is encoded as follows:
DSR选项标头中的路由请求选项编码如下：
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] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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:
IP字段：
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).
必须设置为IP限制广播地址（255.255.255.255）。
Hop Limit (TTL)
跃点限制（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.3).
例如，可在1到255之间变化，以实现非传播路由请求和路由请求扩展环搜索（第3.3.3节）。
Route Request fields:
路由请求字段：
Option Type
选项类型
1. Nodes not understanding this option will ignore this option.
1. 不了解此选项的节点将忽略此选项。
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.
8位无符号整数。选项的长度，以八位字节为单位，不包括选项类型和Opt Data Len字段。必须设置为（4*n）+6，其中n是路由请求选项中的地址数。
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.
此值允许接收节点确定其最近是否看到此路由请求的副本。如果该接收节点在其路由请求表（在该发起节点条目中的标识值缓存中）中找到该标识值（用于该IP源地址和目标地址），则该接收节点必须放弃路由请求。传播路由请求时，必须从接收到的正在传播的路由请求副本复制此字段。
Target Address
目标地址
The address of the node that is the target of the Route Request.
作为路由请求目标的节点的地址。
Address[1..n]
地址[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[1] 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.
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[1] 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.
路由请求选项在DSR选项标题中不得出现多次。
The Route Reply option in a DSR Options header is encoded as follows:
DSR选项报头中的路由应答选项编码如下：
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] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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:
IP字段：
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.
设置为发送路由应答的节点的地址。在节点从其路由缓存（第3.3.2节）发送应答或发送免费路由应答（第3.4.3节）的情况下，该地址可能不同于作为路由发现目标的地址。
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.
2. 不了解此选项的节点将忽略此选项。
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.
8位无符号整数。选项的长度，以八位字节为单位，不包括选项类型和Opt Data Len字段。必须设置为等于（4*n）+1，其中n是路由回复选项中的地址数。
Last Hop External (L)
最后一跳外部（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.
设置为指示路由应答给出的最后一跳（从地址[n-1]到地址[n]的链路）实际上是DSR网络外部网络中的任意路径；DSR网络外的确切路由未在路由应答中表示。在路由缓存中缓存此跃点的节点必须使用外部标志来标记缓存的跃点。此类跃点不得在此路由缓存项生成的缓存路由应答中返回，并且从路由缓存选择路由以路由正在发送的数据包应首选不包含标记为外部跃点的路由。
Reserved
含蓄的
MUST be sent as 0 and ignored on reception.
必须作为0发送，并在接收时忽略。
Address[1..n]
地址[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).
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.
路由回复选项可能在DSR选项标头中出现一次或多次。
The Route Error option in a DSR Options header is encoded as follows:
DSR选项标头中的路由错误选项编码如下：
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 .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
选项类型
3. Nodes not understanding this option will ignore this option.
3. 不了解此选项的节点将忽略此选项。
Opt Data Len
选项数据长度
8-bit unsigned integer. Length of the option, in octets, excluding the Option Type and Opt Data Len fields.
8位无符号整数。选项的长度，以八位字节为单位，不包括选项类型和Opt Data Len字段。
For the current definition of the Route Error option, this field MUST be set to 10, plus the size of any Type-Specific Information present in the Route Error. Further extensions to the Route Error option format may also be included after the Type-Specific Information portion of the Route Error option specified above. The presence of such extensions will be indicated by the Opt Data Len field. When the Opt Data Len is greater than that required for the fixed portion of the Route Error plus the necessary Type-Specific Information as indicated by the Option Type value in the option, the remaining octets are interpreted as extensions. Currently, no such further extensions have been defined.
对于路由错误选项的当前定义，此字段必须设置为10，加上路由错误中存在的任何类型特定信息的大小。在上面指定的路由错误选项的类型特定信息部分之后，还可以包括路由错误选项格式的进一步扩展。此类扩展的存在将由Opt Data Len字段指示。当Opt Data Len大于路由错误的固定部分所需的长度加上由选项中的选项类型值指示的必要类型特定信息时，剩余的八位字节被解释为扩展。目前，尚未定义此类进一步的扩展。
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
1=节点不可访问2=流状态不受支持3=选项不受支持
Other values of the Error Type field are reserved for future use.
错误类型字段的其他值保留供将来使用。
Reservd
储备
Reserved. MUST be sent as 0 and ignored on reception.
保留的。必须作为0发送，并在接收时忽略。
Salvage
打捞
A 4-bit unsigned integer. Copied from the Salvage field in the DSR Source Route option of the packet triggering the Route Error.
4位无符号整数。从触发路由错误的数据包的DSR源路由选项中的补救字段复制。
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.
路由错误必须传递到的节点的地址。例如，当错误类型字段设置为NODE_UNREACHABLE时，该字段将设置为生成路由信息的节点的地址，该路由信息声称从错误源地址到不可访问节点地址（在类型特定信息中指定）的跃点是有效的跃点。
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.
路由错误选项可能在DSR选项标题中出现一次或多次。
When the Route Error is of type NODE_UNREACHABLE, the Type-Specific Information field is defined as follows:
当路由错误类型为NODE_UNREACHABLE时，类型特定信息字段定义如下：
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 IP address of the node that was found to be unreachable (the next-hop neighbor to which the node with address Error Source Address was attempting to transmit the packet).
发现无法访问的节点的IP地址（具有地址错误源地址的节点尝试向其发送数据包的下一跳邻居）。
When the Route Error is of type FLOW_STATE_NOT_SUPPORTED, the Type-Specific Information field is empty.
当路由错误的类型为FLOW_STATE_NOT_SUPPORTED时，特定于类型的信息字段为空。
When the Route Error is of type OPTION_NOT_SUPPORTED, the Type-Specific Information field is defined as follows:
当路由错误的类型为OPTION_NOT_SUPPORTED时，类型特定信息字段定义如下：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Unsupported Opt|
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Unsupported Opt|
+-+-+-+-+-+-+-+-+
Unsupported Opt
不支持的选项
The Option Type of option triggering the Route Error.
触发路由错误的选项的选项类型。
The Acknowledgement Request option in a DSR Options header is encoded as follows:
DSR选项报头中的确认请求选项编码如下：
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 option and return a Route Error.
160不理解此选项的节点将删除该选项并返回路由错误。
Opt Data Len
选项数据长度
8-bit unsigned integer. Length of the option, in octets, excluding the Option Type and Opt Data Len fields.
8位无符号整数。选项的长度，以八位字节为单位，不包括选项类型和Opt Data Len字段。
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.
确认请求选项在DSR选项标头中不得出现多次。
The Acknowledgement option in a DSR Options header is encoded as follows:
DSR选项报头中的确认选项编码如下：
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 option will remove the option.
32. 不理解此选项的节点将删除该选项。
Opt Data Len
选项数据长度
8-bit unsigned integer. Length of the option, in octets, excluding the Option Type and Opt Data Len fields.
8位无符号整数。选项的长度，以八位字节为单位，不包括选项类型和Opt Data Len字段。
Identification
识别
Copied from the Identification field of the Acknowledgement Request option of the packet being acknowledged.
从正在确认的数据包的确认请求选项的标识字段复制。
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.
确认选项可能在DSR选项报头中出现一次或多次。
The DSR Source Route option in a DSR Options header is encoded as follows:
DSR选项标头中的DSR源路由选项编码如下：
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] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 option will drop the packet.
96. 不理解此选项的节点将丢弃数据包。
Opt Data Len
选项数据长度
8-bit unsigned integer. Length of the option, in octets, excluding the Option Type and Opt Data Len fields. For the format of the DSR Source Route option defined here, this field MUST be set to the value (n * 4) + 2, where n is the number of addresses present in the Address[i] fields.
8位无符号整数。选项的长度，以八位字节为单位，不包括选项类型和Opt Data Len字段。对于此处定义的DSR源路由选项的格式，此字段必须设置为值（n*4）+2，其中n是地址[i]字段中存在的地址数。
First Hop External (F)
第一跳外部（F）
Set to indicate that the first 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
设置为指示DSR源路由选项指示的第一跳实际上是DSR网络外部网络中的任意路径；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.
DSR源路由选项中未表示网络。在路由缓存中缓存此跃点的节点必须使用外部标志来标记缓存的跃点。从该路由缓存项生成的路由回复中不得返回此类跃点，并且从路由缓存选择路由以路由发送的数据包应首选不包含标记为外部跃点的路由。
Last Hop External (L)
最后一跳外部（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.
设置为指示DSR源路由选项指示的最后一个跃点实际上是DSR网络外部网络中的任意路径；DSR源路由选项中不表示DSR网络外部的确切路由。在路由缓存中缓存此跃点的节点必须使用外部标志来标记缓存的跃点。从该路由缓存项生成的路由回复中不得返回此类跃点，并且从路由缓存选择路由以路由发送的数据包应首选不包含标记为外部跃点的路由。
Reserved
含蓄的
MUST be sent as 0 and ignored on reception.
必须作为0发送，并在接收时忽略。
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).
4位无符号整数。此数据包作为DSR路由的一部分被回收的次数（第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]
地址[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).
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
当使用数据包的DSR选项报头中的DSR源路由选项沿DSR源路由转发数据包时，数据包IP报头中的目标地址字段始终设置为
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.
数据包的最终目的地。根据第8.1.4节和第8.1.5节的定义，接收包含DSR选项报头和DSR源路由选项的数据包的节点必须检查指示的源路由，以确定它是否是该数据包的预期下一跳节点，以及如何转发该数据包。
The Pad1 option in a DSR Options header is encoded as follows:
DSR选项标头中的Pad1选项编码如下：
+-+-+-+-+-+-+-+-+
| Option Type |
+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
| Option Type |
+-+-+-+-+-+-+-+-+
Option Type
选项类型
224. Nodes not understanding this option will drop the packet and return a Route Error.
224不理解此选项的节点将丢弃数据包并返回路由错误。
A Pad1 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.
为了对齐后续的DSR选项，可以在DSR选项报头的选项字段中包括Pad1选项，但接收包含DSR选项报头的数据包的节点不需要且不应期望这种对齐。
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.
如果数据包中的DSR Options报头后面有任何报头，则DSR Options报头的总长度（由DSR Options报头中的有效负载长度字段指示）必须是4个八位字节的倍数。在这种情况下，在数据包中构建DSR Options报头时，DSR Options报头的Options字段中必须包含足够的Pad1或PadN选项，以使总长度为4个八位字节的倍数。
If more than one consecutive octet of padding is being inserted in the Options field of a DSR Options header, the PadN option described next, SHOULD be used, rather than multiple Pad1 options.
如果在DSR选项标头的选项字段中插入多个连续八位字节的填充，则应使用下面描述的PadN选项，而不是多个Pad1选项。
Note that the format of the Pad1 option is a special case; it does not have an Opt Data Len or Option Data field.
请注意，Pad1选项的格式是一种特殊情况；它没有Opt Data Len或Option Data字段。
The PadN option in a DSR Options header is encoded as follows:
DSR选项标头中的PadN选项编码如下：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| Option Type | Opt Data Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| Option Type | Opt Data Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
Option Type
选项类型
0. Nodes not understanding this option will ignore this option.
0. 不了解此选项的节点将忽略此选项。
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.
8位无符号整数。选项的长度，以八位字节为单位，不包括选项类型和Opt Data Len字段。选项数据字段的大小。
Option Data
期权数据
A number of zero-valued octets equal to the Opt Data Len.
等于Opt数据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.
为了对齐后续DSR选项，可以在DSR选项报头的选项字段中包括PadN选项，但接收包含DSR选项报头的数据包的节点不需要且不应期望这种对齐。
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.
如果数据包中的DSR Options报头后面有任何报头，则DSR Options报头的总长度（由DSR Options报头中的有效负载长度字段指示）必须是4个八位字节的倍数。在这种情况下，在数据包中构建DSR Options报头时，DSR Options报头的Options字段中必须包含足够的Pad1或PadN选项，以使总长度为4个八位字节的倍数。
The optional DSR flow state extension requires a new header type, the DSR Flow State header.
可选的DSR流状态扩展需要新的标头类型，即DSR流状态标头。
In addition, the DSR flow state extension adds the following options for the DSR Options header defined in Section 6:
此外，DSR流状态扩展为第6节中定义的DSR选项标头添加了以下选项：
- Timeout option (Section 7.2.1)
- 超时选项（第7.2.1节）
- Destination and Flow ID option (Section 7.2.2)
- 目的地和流量ID选项（第7.2.2节）
Two new Error Type values are also defined for use in the Route Error option in a DSR Options header:
还定义了两个新的错误类型值，用于DSR选项标头中的路由错误选项：
- UNKNOWN_FLOW
- 未知流量
- DEFAULT_FLOW_UNKNOWN
- 默认\u流量\u未知
Finally, an extension to the Acknowledgement Request option in a DSR Options header is also defined:
最后，还定义了DSR选项标头中确认请求选项的扩展：
- Previous Hop Address
- 前一跳地址
This section defines each of these new header, option, or extension formats.
本节定义了每种新的标题、选项或扩展格式。
The DSR Flow State header is a small 4-byte header optionally used to carry the flow ID and hop count for a packet being sent along a DSR flow. It is distinguished from the fixed DSR Options header (Section 6.1) in that the Flow State Header (F) bit is set in the DSR Flow State header and is clear in the fixed DSR Options header.
DSR流状态报头是一个小的4字节报头，可选地用于携带沿着DSR流发送的数据包的流ID和跳数。它与固定DSR选项标题（第6.1节）的区别在于，流状态标题（F）位在DSR流状态标题中设置，在固定DSR选项标题中清除。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 DSR Flow State header. Uses the same values as the IPv4 Protocol field [RFC1700].
8位选择器。标识紧接DSR流状态标头之后的标头类型。使用与IPv4协议字段[RFC1700]相同的值。
Flow State Header (F)
流量状态集管（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).
标志位。必须设置为1。该位在DSR流量状态标题中设置，并在DSR选项标题中清除（第6.1节）。
Hop Count
跳数
7-bit unsigned integer. The number of hops through which this packet has been forwarded.
7位无符号整数。转发此数据包所经过的跃点数。
Flow Identification
流量识别
The flow ID for this flow, as described in Section 3.5.1.
该流量的流量ID，如第3.5.1节所述。
The Timeout option is defined for use in a DSR Options header to indicate the amount of time before the expiration of the flow ID along which the packet is being sent.
超时选项定义为在DSR Options报头中使用，以指示发送数据包的流ID过期之前的时间量。
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 | Timeout |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Timeout |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
选项类型
128. Nodes not understanding this option will ignore the option and return a Route Error.
128不理解此选项的节点将忽略该选项并返回路由错误。
Opt Data Len
选项数据长度
8-bit unsigned integer. Length of the option, in octets, excluding the Option Type and Opt Data Len fields.
8位无符号整数。选项的长度，以八位字节为单位，不包括选项类型和Opt Data Len字段。
When no extensions are present, the Opt Data Len of a Timeout option is 2. Further extensions to DSR may include additional data in a Timeout option. The presence of such extensions is indicated by an Opt Data Len greater than 2. Currently, no such extensions have been defined.
当不存在扩展时，超时选项的Opt Data Len为2。DSR的进一步扩展可能包括超时选项中的附加数据。此类扩展的存在由大于2的Opt数据Len表示。目前，尚未定义此类扩展。
Timeout
超时
The number of seconds for which this flow remains valid.
此流保持有效的秒数。
The Timeout option MUST NOT appear more than once within a DSR Options header.
超时选项在DSR选项标题中不得出现多次。
The Destination and Flow ID option is defined for use in a DSR Options header 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.
Destination and Flow ID选项定义为在DSR Options报头中使用，以沿一个流向中间主机发送数据包，以便最终沿不同的流转发到最终目的地。此选项允许聚合多个流的状态。
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 | New Flow Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New IP Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | New Flow Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New IP Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
选项类型
129. Nodes not understanding this option will ignore the option and return a Route Error.
129不理解此选项的节点将忽略该选项并返回路由错误。
Opt Data Len
选项数据长度
8-bit unsigned integer. Length of the option, in octets, excluding the Option Type and Opt Data Len fields.
8位无符号整数。选项的长度，以八位字节为单位，不包括选项类型和Opt Data Len字段。
When no extensions are present, the Opt Data Len of a Destination and Flow ID option is 6. Further extensions to DSR may include additional data in a Destination and Flow ID option. The presence of such extensions is indicated by an Opt Data Len greater than 6. Currently, no such extensions have been defined.
当不存在扩展时，目标和流ID选项的Opt Data Len为6。DSR的进一步扩展可以包括目的地和流ID选项中的附加数据。此类扩展的存在由大于6的Opt数据Len表示。目前，尚未定义此类扩展。
New Flow Identifier
新流标识符
Indicates the next identifier to store in the Flow ID field of the DSR Options header.
指示要存储在DSR选项标头的Flow ID字段中的下一个标识符。
New IP Destination Address
新IP目标地址
Indicates the next address to store in the Destination Address field of the IP header.
指示要存储在IP标头的目标地址字段中的下一个地址。
The Destination and Flow ID option MAY appear one or more times within a DSR Options header.
目标和流ID选项可能在DSR选项标题中出现一次或多次。
A new Error Type value of 129 (UNKNOWN_FLOW) is defined for use in a Route Error option in a DSR Options header. The Type-Specific Information for errors of this type is encoded as follows:
定义了一个新的错误类型值129（未知_流），用于DSR选项标头中的路由错误选项。此类型错误的类型特定信息编码如下：
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
原始IP目标地址
The IP Destination Address of the packet that caused the error.
导致错误的数据包的IP目标地址。
Flow ID
流量ID
The Flow ID contained in the DSR Flow ID option that caused the error.
导致错误的DSR Flow ID选项中包含的流ID。
A new Error Type value of 130 (DEFAULT_FLOW_UNKNOWN) is defined for use in a Route Error option in a DSR Options header. The Type-Specific Information for errors of this type is encoded as follows:
定义了一个新的错误类型值130（默认\u FLOW\u UNKNOWN），用于DSR选项标头中的路由错误选项。此类型错误的类型特定信息编码如下：
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Original IP Destination Address
原始IP目标地址
The IP Destination Address of the packet that caused the error.
导致错误的数据包的IP目标地址。
When the Opt Data Len field of an Acknowledgement Request option in a DSR Options header is greater than or equal to 6, the ACK Request Source Address field is present. The option is then formatted as follows:
当DSR Options报头中确认请求选项的Opt Data Len字段大于或等于6时，ACK请求源地址字段存在。然后，该选项的格式如下所示：
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 | Packet Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACK Request Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Packet Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACK Request Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
选项类型
160. Nodes not understanding this option will remove the option and return a Route Error.
160不理解此选项的节点将删除该选项并返回路由错误。
Opt Data Len
选项数据长度
8-bit unsigned integer. Length of the option, in octets, excluding the Option Type and Opt Data Len fields.
8位无符号整数。选项的长度，以八位字节为单位，不包括选项类型和Opt Data Len字段。
When no extensions are presents, the Opt Data Len of an Acknowledgement Request option is 2. Further extensions to DSR may include additional data in an Acknowledgement Request option. The presence of such extensions is indicated by an Opt Data Len greater than 2.
当不存在扩展时，确认请求选项的Opt Data Len为2。DSR的进一步扩展可包括确认请求选项中的附加数据。此类扩展的存在由大于2的Opt数据Len表示。
Currently, one such extension has been defined. If the Opt Data Len is at least 6, then an ACK Request Source Address is present.
目前，已经定义了一个这样的扩展。如果Opt Data Len至少为6，则存在ACK请求源地址。
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.
数据包标识符字段被设置为一个唯一的数字，并在通过该跳接收数据包的节点返回时复制到DSR确认选项的标识字段中。
ACK Request Source Address
确认请求源地址
The address of the node requesting the DSR Acknowledgement.
请求DSR确认的节点的地址。
When originating any packet, a node using DSR routing MUST perform the following sequence of steps:
发起任何数据包时，使用DSR路由的节点必须执行以下一系列步骤：
- Search the node's Route Cache for a route to the address given in the IP Destination Address field in the packet's header.
- 在节点的路由缓存中搜索到数据包头中IP Destination address字段中给定地址的路由。
- If no such route is found in the Route Cache, then perform Route Discovery for the Destination Address, as described in Section 8.2. Initiating a Route Discovery for this target node address results in the node adding a Route Request option in a DSR Options header in this existing packet, or saving this existing packet to its Send Buffer and initiating the Route Discovery by sending a separate packet containing such a Route Request option. If the node chooses to initiate the Route Discovery by adding the Route Request option to this existing packet, it will replace the IP Destination Address field with the IP "limited broadcast" address
- 如果在路由缓存中未找到此类路由，则按照第8.2节所述，对目标地址执行路由发现。为此目标节点地址启动路由发现会导致节点在此现有数据包的DSR Options报头中添加路由请求选项，或将此现有数据包保存到其发送缓冲区，并通过发送包含此路由请求选项的单独数据包来启动路由发现。如果节点选择通过将路由请求选项添加到此现有数据包来启动路由发现，它将用IP“受限广播”地址替换IP目的地地址字段
(255.255.255.255) [RFC1122], copying the original IP Destination Address to the Target Address field of the new Route Request option added to the packet, as described in Section 8.2.1.
（255.255.255.255）[RFC1122]，将原始IP目标地址复制到添加到数据包的新路由请求选项的目标地址字段，如第8.2.1节所述。
- If the packet now does not contain a Route Request option, then this node must have a route to the Destination Address of the packet; if the node has more than one route to this Destination Address, the node selects one to use for this packet. If the length of this route is greater than 1 hop, or if the node determines to request a DSR network-layer acknowledgement from the first-hop node in that route, then insert a DSR Options header into the packet, as described in Section 8.1.2, and insert a DSR Source Route option, as described in Section 8.1.3. The source route in the packet is initialized from the selected route to the Destination Address of the packet.
- 如果包现在不包含路由请求选项，则该节点必须具有到包的目的地地址的路由；如果节点有多条到该目的地地址的路由，则节点选择一条用于该数据包。如果该路由的长度大于1跳，或者如果节点决定从该路由中的第一跳节点请求DSR网络层确认，则按照第8.1.2节所述，将DSR选项头插入数据包，并按照第8.1.3节所述，插入DSR源路由选项。数据包中的源路由从所选路由初始化到数据包的目标地址。
- Transmit the packet to the first-hop node address given in selected source route, using Route Maintenance to determine the reachability of the next hop, as described in Section 8.3.
- 如第8.3节所述，使用路由维护来确定下一跳的可达性，将数据包发送到选定源路由中给定的第一跳节点地址。
A node originating a packet adds a DSR Options header to the packet, if necessary, to carry information needed by the routing protocol. A packet MUST NOT contain more than one DSR Options header. A DSR Options header is added to a packet by performing the following sequence of steps (these steps assume that the packet contains no other headers that MUST be located in the packet before the DSR Options header):
发起数据包的节点在必要时向数据包添加DSR Options报头，以承载路由协议所需的信息。数据包不能包含多个DSR选项标头。通过执行以下一系列步骤，将DSR Options报头添加到数据包中（这些步骤假定数据包不包含必须位于DSR Options报头之前的数据包中的其他报头）：
- Insert a DSR Options header after the IP header but before any other header that may be present.
- 在IP头之后但在可能存在的任何其他头之前插入DSR选项头。
- Set the Next Header field of the DSR Options header to the Protocol number field of the packet's IP header.
- 将DSR选项报头的下一个报头字段设置为数据包IP报头的协议编号字段。
- Set the Protocol field of the packet's IP header to the protocol number assigned for DSR (48).
- 将数据包IP报头的协议字段设置为为DSR分配的协议号（48）。
A node originating a packet adds a DSR Source Route option to the packet, if necessary, in order to carry the source route from this originating node to the final destination address of the packet. Specifically, the node adding the DSR Source Route option constructs the DSR Source Route option and modifies the IP packet according to the following sequence of steps:
发起数据包的节点在必要时向数据包添加DSR源路由选项，以便将源路由从该发起节点传送到数据包的最终目的地地址。具体而言，添加DSR源路由选项的节点构造DSR源路由选项，并根据以下步骤序列修改IP分组：
- The node creates a DSR Source Route option, as described in Section 6.7, and appends it to the DSR Options header in the packet. (A DSR Options header is added, as described in Section 8.1.2, if not already present.)
- 节点创建一个DSR源路由选项，如第6.7节所述，并将其附加到数据包中的DSR选项头中。（如第8.1.2节所述，如果尚未出现，则添加DSR选项标题。）
- The number of Address[i] fields to include in the DSR Source Route option (n) is the number of intermediate nodes in the source route for the packet (i.e., excluding the address of the originating node and the final destination address of the packet). The Segments Left field in the DSR Source Route option is initialized equal to n.
- 要包括在DSR源路由选项（n）中的地址[i]字段的数目是分组的源路由中的中间节点的数目（即，不包括发起节点的地址和分组的最终目的地地址）。DSR源路由选项中的Segments Left字段初始化为n。
- The addresses within the source route for the packet are copied into sequential Address[i] fields in the DSR Source Route option, for i = 1, 2, ..., n.
- 数据包的源路由内的地址被复制到DSR源路由选项中的顺序地址[i]字段中，i=1，2，…，n。
- The First Hop External (F) bit in the DSR Source Route option is copied from the External bit flagging the first hop in the source route for the packet, as indicated in the Route Cache.
- DSR源路由选项中的第一跳外部（F）位从标记数据包源路由中第一跳的外部位复制，如路由缓存中所示。
- The Last Hop External (L) bit in the DSR Source Route option is copied from the External bit flagging the last hop in the source route for the packet, as indicated in the Route Cache.
- DSR源路由选项中的最后一跳外部（L）位从标记数据包源路由中最后一跳的外部位复制，如路由缓存中所示。
- The Salvage field in the DSR Source Route option is initialized to 0.
- DSR源路由选项中的补救字段初始化为0。
When a node receives any packet (whether for forwarding, overheard, or 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:
当一个节点收到任何数据包（无论是转发、窃听还是数据包的最终目的地）时，如果该数据包包含DSR Options报头，则该节点必须按照其中包含的顺序处理该DSR Options报头中包含的任何选项。明确地：
- If the DSR Options header contains a Route Request option, the node SHOULD extract the source route from the Route Request and add this routing information to its Route Cache, subject to the conditions identified in Section 3.3.1. The routing information from the Route Request is the sequence of hop addresses
- 如果DSR Options报头包含路由请求选项，则节点应根据第3.3.1节中确定的条件，从路由请求中提取源路由，并将此路由信息添加到其路由缓存中。路由请求中的路由信息是跃点地址序列
initiator, Address[1], Address[2], ..., Address[n]
发起人，地址[1]，地址[2]，…，地址[n]
where initiator is the value of the Source Address field in the IP header of the packet carrying the Route Request (the address of the initiator of the Route Discovery), and each Address[i] is a node through which this Route Request has passed, in turn, during
其中，initiator是承载路由请求的分组的IP报头中的源地址字段的值（路由发现的启动器的地址），并且每个地址[i]是一个节点，该路由请求在发送过程中依次通过该节点
this Route Discovery. The value n, here, is the number of addresses recorded in the Route Request option, or (Opt Data Len - 6) / 4.
这条路线被发现了。这里的值n是路由请求选项中记录的地址数，或（Opt Data Len-6）/4。
After possibly updating the node's Route Cache in response to the routing information in the Route Request option, the node MUST then process the Route Request option as described in Section 8.2.2.
在可能更新节点的路由缓存以响应路由请求选项中的路由信息后，节点必须按照第8.2.2节所述处理路由请求选项。
- If the DSR Options header contains a Route Reply option, the node SHOULD extract the source route from the Route Reply and add this routing information to its Route Cache, subject to the conditions identified in Section 3.3.1. The source route from the Route Reply is the sequence of hop addresses
- 如果DSR Options报头包含路由应答选项，则节点应根据第3.3.1节中确定的条件，从路由应答中提取源路由，并将此路由信息添加到其路由缓存中。路由应答的源路由是跃点地址序列
initiator, Address[1], Address[2], ..., Address[n]
发起人，地址[1]，地址[2]，…，地址[n]
where initiator is the value of the Destination Address field in the IP header of the packet carrying the Route Reply (the address of the initiator of the Route Discovery), and each Address[i] is a node through which the source route passes, in turn, on the route to the target of the Route Discovery. Address[n] is the address of the target. If the Last Hop External (L) bit is set in the Route Reply, the node MUST flag the last hop from the Route Reply (the link from Address[n-1] to Address[n]) in its Route Cache as External. The value n here is the number of addresses in the source route being returned in the Route Reply option, or (Opt Data Len - 1) / 4.
其中启动器是承载路由应答的分组的IP报头中的目的地地址字段的值（路由发现的启动器的地址），并且每个地址[i]是一个节点，源路由依次通过该节点在路由上传递到路由发现的目标。地址[n]是目标的地址。如果在路由应答中设置了最后一个跃点外部（L）位，则节点必须将路由应答中的最后一个跃点（从地址[n-1]到地址[n]的链路）标记为外部。这里的值n是在路由应答选项中返回的源路由中的地址数，或（Opt Data Len-1）/4。
After possibly updating the node's Route Cache in response to the routing information in the Route Reply option, then if the packet's IP Destination Address matches one of this node's IP addresses, the node MUST then process the Route Reply option as described in Section 8.2.6.
在可能更新节点的路由缓存以响应路由应答选项中的路由信息后，如果数据包的IP目的地地址与该节点的IP地址之一匹配，则节点必须按照第8.2.6节中的描述处理路由应答选项。
- If the DSR Options header contains a Route Error option, the node MUST process the Route Error option as described in Section 8.3.5.
- 如果DSR Options标头包含路由错误选项，则节点必须按照第8.3.5节所述处理路由错误选项。
- If the DSR Options header contains an Acknowledgement Request option, the node MUST process the Acknowledgement Request option as described in Section 8.3.3.
- 如果DSR选项报头包含确认请求选项，则节点必须按照第8.3.3节所述处理确认请求选项。
- If the DSR Options header contains an Acknowledgement option, then subject to the conditions identified in Section 3.3.1, the node SHOULD add to its Route Cache the single link from the node identified by the ACK Source Address field to the node identified by the ACK Destination Address field.
- 如果DSR Options报头包含确认选项，则根据第3.3.1节中确定的条件，节点应将从ACK源地址字段标识的节点到ACK目的地地址字段标识的节点的单个链路添加到其路由缓存中。
After possibly updating the node's Route Cache in response to the routing information in the Acknowledgement option, the node MUST then process the Acknowledgement option as described in Section 8.3.3.
在可能更新节点的路由缓存以响应确认选项中的路由信息之后，节点必须按照第8.3.3节所述处理确认选项。
- If the DSR Options header contains a DSR Source Route option, the node SHOULD extract the source route from the DSR Source Route option and add this routing information to its Route Cache, subject to the conditions identified in Section 3.3.1. If the value of the Salvage field in the DSR Source Route option is zero, then the routing information from the DSR Source Route is the sequence of hop addresses
- 如果DSR选项标头包含DSR源路由选项，则节点应根据第3.3.1节中确定的条件，从DSR源路由选项中提取源路由，并将此路由信息添加到其路由缓存中。如果DSR源路由选项中的补救字段的值为零，则来自DSR源路由的路由信息为跃点地址序列
source, Address[1], Address[2], ..., Address[n], destination
来源，地址[1]，地址[2]，…，地址[n]，目的地
Otherwise (i.e., if Salvage is nonzero), the routing information from the DSR Source Route is the sequence of hop addresses
否则（即，如果补救为非零），来自DSR源路由的路由信息是跳地址序列
Address[1], Address[2], ..., Address[n], destination
地址[1]，地址[2]，…，地址[n]，目的地
where source is the value of the Source Address field in the IP header of the packet carrying the DSR Source Route option (the original sender of the packet), each Address[i] is the value in the Address[i] field in the DSR Source Route option, and destination is the value of the Destination Address field in the packet's IP header (the last-hop address of the source route). The value n here is the number of addresses in source route in the DSR Source Route option, or (Opt Data Len - 2) / 4.
其中，source是携带DSR源路由选项的分组的IP报头中的source Address字段的值（分组的原始发送方），每个地址[i]是DSR源路由选项中的Address[i]字段的值，destination是分组的IP报头中的destination Address字段的值（源路由的最后一个跃点地址）。此处的值n是DSR源路由选项中源路由中的地址数，或（Opt Data Len-2）/4。
After possibly updating the node's Route Cache in response to the routing information in the DSR Source Route option, the node MUST then process the DSR Source Route option as described in Section 8.1.5.
在可能更新节点的路由缓存以响应DSR源路由选项中的路由信息后，节点必须按照第8.1.5节所述处理DSR源路由选项。
- Any Pad1 or PadN options in the DSR Options header are ignored.
- DSR选项标题中的任何Pad1或PadN选项都将被忽略。
- Finally, if the Destination Address in the packet's IP header matches one of this receiving node's own IP address(es), remove the DSR Options header and all the included DSR options in the header, and pass the rest of the packet to the network layer.
- 最后，如果数据包IP报头中的目标地址与该接收节点自己的IP地址之一匹配，则删除DSR选项报头和报头中包含的所有DSR选项，并将数据包的其余部分传递给网络层。
When a node receives a packet containing a DSR Source Route option (whether for forwarding, overheard, or the final destination of the packet), that node SHOULD examine the packet 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
当节点接收到包含DSR源路由选项的数据包（无论是转发、窃听还是数据包的最终目的地）时，该节点应检查该数据包，以确定该数据包的接收是否表示自动路由缩短的机会，如第3.4.3节所述。具体来说，如果
node is not the intended next-hop destination for the packet but is named in the later unexpended portion of the source route in the packet's DSR Source Route option, then this packet indicates an opportunity for automatic route shortening: the intermediate nodes after the node from which this node overheard the packet and before this node itself are no longer necessary in the source route. In this case, this node SHOULD perform the following sequence of steps as part of automatic route shortening:
节点不是数据包的预期下一跳目的地，但在数据包的DSR源路由选项中的源路由的后未使用部分中命名，然后，此数据包表示自动路由缩短的机会：在源路由中，此节点无意中听到数据包的节点之后和节点本身之前的中间节点不再是必需的。在这种情况下，该节点应执行以下步骤序列，作为自动路线缩短的一部分：
- The node searches its Gratuitous Route Reply Table for an entry describing a gratuitous Route Reply earlier sent by this node, for which the original sender (of the packet triggering the gratuitous Route Reply) and the transmitting node (from which this node overheard that packet in order to trigger the gratuitous Route Reply) both match the respective node addresses for this new received packet. If such an entry is found in the node's Gratuitous Route 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 Reply Table. The timeout value for this new entry SHOULD be initialized to the value GratReplyHoldoff. After this timeout has expired, the node SHOULD delete this entry from its Gratuitous Route Reply Table.
- 否则，节点将在其免费路由应答表中为该偷听数据包创建一个条目。此新条目的超时值应初始化为值GratReplyHoldoff。此超时过期后，节点应从其免费路由应答表中删除此条目。
- 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 3.4.3.
- 在创建上述新的免费路由回复表条目后，节点发起对该偷听数据包的IP源地址的免费路由回复，如第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 Route Reply, the node MUST use a source route for routing the Route Reply packet that is obtained by reversing the sequence of hops over which the packet triggering the gratuitous Route Reply was routed in reaching and being overheard by this node. This reversing of the route uses the gratuitous Route Reply to test this sequence of hops for bidirectionality, preventing the gratuitous Route Reply from being received by the initiator of the Route Discovery unless each of the hops over which the gratuitous Route Reply is returned is bidirectional.
如第3.3.1节所述，如果网络中使用的MAC协议不能通过单向链路传输单播数据包，则在发起该路由应答时，该节点必须使用源路由来路由路由应答包，该路由应答包是通过反转触发免费路由应答的包在到达该节点并被该节点偷听时路由到的跳序列而获得的。该路由的反转使用免费路由应答来测试该跳序列的双向性，防止路由发现的发起方接收免费路由应答，除非返回免费路由应答的每个跳是双向的。
- Discard the overheard packet, since the packet has been received before its normal traversal of the packet's source route would have caused it to reach this receiving node. Another copy of the packet will normally arrive at this node as indicated in the
- 丢弃无意中听到的数据包，因为数据包在正常遍历数据包的源路由之前就已经被接收到，这将导致它到达这个接收节点。数据包的另一个副本通常会到达该节点，如
packet's source route; discarding this initial copy of the packet, which triggered the gratuitous Route Reply, will prevent the duplication of this packet that would otherwise occur.
包的源路由；丢弃触发免费路由应答的数据包初始副本将防止该数据包的复制，否则将发生这种复制。
If the packet is not discarded as part of automatic route shortening above, then the node MUST process the Source Route option according to the following sequence of steps:
如果包没有作为上述自动路由缩短的一部分被丢弃，则节点必须按照以下步骤顺序处理源路由选项：
- If the value of the Segments Left field in the DSR Source Route option equals 0, then remove the DSR Source Route option from the DSR Options header.
- 如果DSR源路由选项中Segments Left字段的值等于0，则从DSR Options标头中删除DSR源路由选项。
- Else, let n equal (Opt Data Len - 2) / 4. This is the number of addresses in the DSR Source Route option.
- 否则，让n等于（Opt Data Len-2）/4。这是DSR源路由选项中的地址数。
- If the value of the Segments Left field is greater than n, then send an ICMP Parameter Problem, Code 0, message [RFC792] to the IP Source Address, pointing to the Segments Left field, and discard the packet. Do not process the DSR Source Route option further.
- 如果Segments Left字段的值大于n，则向IP源地址发送ICMP参数问题代码0消息[RFC792]，指向Segments Left字段，并丢弃数据包。请勿进一步处理DSR源路由选项。
- Else, decrement the value of the Segments Left field by 1. Let i equal n minus Segments Left. This is the index of the next address to be visited in the Address vector.
- 否则，将Segments Left字段的值减1。让我等于n减去左边的线段。这是地址向量中要访问的下一个地址的索引。
- If Address[i] or the IP Destination Address is a multicast address, then discard the packet. Do not process the DSR Source Route option further.
- 如果地址[i]或IP目标地址是多播地址，则丢弃该数据包。请勿进一步处理DSR源路由选项。
- If this node has more than one network interface and if Address[i] is the address of one this node's network interfaces, then this indicates a change in the network interface to use in forwarding the packet, as described in Section 8.4. In this case, decrement the value of the Segments Left field by 1 to skip over this address (that indicated the change of network interface) and go to the first step above (checking the value of the Segments Left field) to continue processing this Source Route option; in further processing of this Source Route option, the indicated new network interface MUST be used in forwarding the packet.
- 如果该节点有多个网络接口，并且如果地址[i]是该节点的一个网络接口的地址，则这表示用于转发数据包的网络接口发生了变化，如第8.4节所述。在这种情况下，将Segments Left字段的值减1以跳过此地址（表示网络接口的更改），并转到上面的第一步（检查Segments Left字段的值）以继续处理此源路由选项；在进一步处理该源路由选项时，必须使用指示的新网络接口转发数据包。
- If the MTU of the link over which this node would transmit the packet to forward it to the node Address[i] is less than the size of the packet, the node MUST either discard the packet and send an ICMP Packet Too Big message to the packet's Source Address [RFC792] or fragment it as specified in Section 8.5.
- 如果该节点将通过其传输数据包以将其转发至节点地址[i]的链路的MTU小于数据包的大小，则该节点必须丢弃该数据包并向数据包的源地址[RFC792]发送一条ICMP数据包过大的消息，或者按照第8.5节的规定对其进行分段。
- Forward the packet to the IP address specified in the Address[i] field of the IP header, following normal IP forwarding procedures, including checking and decrementing the Time-to-Live (TTL) field
- 按照正常的IP转发过程，包括检查和减少生存时间（TTL）字段，将数据包转发到IP报头地址[i]字段中指定的IP地址
in the packet's IP header [RFC791, RFC1122]. In this forwarding of the packet, the next-hop node (identified by Address[i]) MUST be treated as a direct neighbor node: the transmission to that next node MUST be done in a single IP forwarding hop, without Route Discovery and without searching the Route Cache.
在数据包的IP报头中[RFC791，RFC1122]。在包的这种转发中，下一跳节点（由地址[i]标识）必须被视为直接邻居节点：到下一跳节点的传输必须在单个IP转发跳中完成，无需路由发现和搜索路由缓存。
- In forwarding the packet, perform Route Maintenance for the next hop of the packet, by verifying that the next-hop node is reachable, as described in Section 8.3.
- 在转发数据包时，通过验证下一跳节点是可到达的，为数据包的下一跳执行路由维护，如第8.3节所述。
Multicast addresses MUST NOT appear in a DSR Source Route option or in the IP Destination Address field of a packet carrying a DSR Source Route option in a DSR Options header.
多播地址不得出现在DSR源路由选项或DSR选项报头中承载DSR源路由选项的数据包的IP目标地址字段中。
Nodes implementing DSR MUST handle all options specified in this document, except those options pertaining to the optional flow state extension (Section 7). However, further extensions to DSR may include other option types that may not be understood by implementations conforming to this version of the DSR specification. In DSR, Option Type codes encode required behavior for nodes not implementing that type of option. These behaviors are included in the most significant 3 bits of the Option Type.
实现DSR的节点必须处理本文档中指定的所有选项，与可选流状态扩展相关的选项除外（第7节）。然而，DSR的进一步扩展可能包括符合此版本DSR规范的实现可能无法理解的其他选项类型。在DSR中，选项类型代码编码未实现该类型选项的节点所需的行为。这些行为包含在选项类型的最重要的3位中。
If the most significant bit of the 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 IP Source Address, following the steps described in Section 8.3.4, except that the Error Type MUST be set to OPTION_NOT_SUPPORTED and the Unsupported Opt field MUST be set to the Option Type triggering the Route Error.
如果设置了选项类型的最高有效位（即选项类型&0x80为非零），并且该数据包不包含路由请求选项，则节点应按照第8.3.4节中描述的步骤将路由错误返回到IP源地址，除了错误类型必须设置为选项\不受支持，且不受支持的选项字段必须设置为触发路由错误的选项类型之外。
Whether or not a Route Error is sent in response to this DSR option, as described above, the node also MUST examine the next 2 most significant bits (that is, Option Type & 0x60):
如上所述，无论是否发送路由错误以响应此DSR选项，节点还必须检查下两个最高有效位（即选项类型&0x60）：
- 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.
- 当这2位为00（即选项类型&0x60==0）时，未对该选项类型执行处理的节点必须使用Opt Data Len字段跳过该选项并继续处理。
- 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.
- 当这2位为01（即选项类型&0x60==0x20）时，未对该选项类型执行处理的节点必须使用Opt Data Len字段从数据包中删除该选项，并继续处理，就像该选项未包含在接收的数据包中一样。
- 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. In addition, the node MUST then ignore and skip over the contents of the option using the Opt Data Len field and MUST continue processing the packet.
- 当这2位为10（即选项类型&0x60==0x40）时，未对该选项类型执行处理的节点必须在Opt Data Len字段后设置最高有效位。此外，节点必须使用Opt Data Len字段忽略并跳过选项的内容，并且必须继续处理数据包。
- 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.
- 最后，当这2位为11（即选项类型&0x60==0x60）时，未对该选项类型执行处理的节点必须丢弃该数据包。
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 SHOULD be used only when S attempts to send a packet to D and does not already know a route to D. The node initiating a Route Discovery is known as the "initiator" of the Route Discovery, and the destination node for which the Route Discovery is initiated is known as the "target" of the Route Discovery.
路由发现是一种机制，通过该机制，希望将数据包发送到目的地节点D的节点S获得到D的源路由。只有当S尝试将数据包发送到D并且还不知道到D的路由时，才应使用路由发现。发起路由发现的节点称为路由发现的“发起方”，并且为其启动路由发现的目的地节点被称为路由发现的“目标”。
Route Discovery operates entirely on demand; a node initiates Route Discovery based on its own origination of new packets for some destination address to which it does not currently know a route. Route Discovery does not depend on any periodic or background exchange of routing information or neighbor node detection at any layer in the network protocol stack at any node.
路由发现完全按需运行；节点根据其自身对某些目的地地址的新数据包的发起来启动路由发现，该目的地地址当前不知道路由。路由发现不依赖于路由信息的任何定期或后台交换，也不依赖于任何节点的网络协议栈中任何层的邻居节点检测。
The Route Discovery procedure utilizes two types of messages, a Route Request (Section 6.2) and a Route Reply (Section 6.3), to actively search the ad hoc network for a route to the desired target destination. These DSR messages MAY be carried in any type of IP packet, through use of the DSR Options header as described in Section 6.
路由发现过程利用两种类型的消息，路由请求（第6.2节）和路由应答（第6.3节），主动搜索自组织网络，寻找到所需目标目的地的路由。如第6节所述，通过使用DSR选项报头，这些DSR消息可以在任何类型的IP数据包中承载。
Except as discussed in Section 8.3.5, a Route Discovery for a destination address SHOULD NOT be initiated unless the initiating node has a packet in its Send Buffer requiring delivery to that destination. A Route Discovery for a given target node MUST NOT be initiated unless permitted by the rate-limiting information contained in the 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 MaxRequestPeriod, until a valid Route Reply is received for this target.
除非第8.3.5节中讨论，否则不应启动目的地地址的路由发现，除非启动节点的发送缓冲区中有一个数据包需要发送到该目的地。除非路由请求表中包含的速率限制信息允许，否则不得启动给定目标节点的路由发现。在每次路由发现尝试之后，此目标的连续路由发现之间的间隔应加倍，最大为MaxRequestPeriod，直到收到此目标的有效路由回复为止。
A node initiating a Route Discovery for some target creates and initializes a Route Request option in a DSR Options header in some IP packet. This MAY be a separate IP packet, used only to carry this Route Request option, or the node MAY include the Route Request option in some existing packet that it needs to send to the target node (e.g., the IP packet originated by this node that caused the node to attempt Route Discovery for the destination address of the packet). The Route Request option MUST be included in a DSR Options header in the packet. To initialize the Route Request option, the node performs the following sequence of steps:
为某些目标启动路由发现的节点在某些IP数据包的DSR Options报头中创建并初始化路由请求选项。这可以是单独的IP分组，仅用于承载该路由请求选项，或者该节点可以在其需要发送到目标节点的某个现有分组中包括路由请求选项（例如，由该节点发起的IP分组，其导致该节点尝试对该分组的目的地地址进行路由发现）。路由请求选项必须包含在数据包的DSR选项标头中。要初始化路由请求选项，节点将执行以下步骤序列：
- The Option Type in the option MUST be set to the value 2.
- 选项中的选项类型必须设置为值2。
- The Opt Data Len field in the option MUST be set to the value 6. The total size of the Route Request option, when initiated, is 8 octets; the Opt Data Len field excludes the size of the Option Type and Opt Data Len fields themselves.
- 选项中的Opt Data Len字段必须设置为值6。路由请求选项在启动时的总大小为8个八位字节；Opt Data Len字段不包括选项类型的大小和Opt Data Len字段本身。
- The Identification field 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 a new Identification value for each Route Request it initiates.
- 选项中的标识字段必须设置为新值，不同于此节点最近为此相同目标地址启动的其他路由请求所使用的值。例如，每个节点可以维护单个计数器值，用于为其发起的每个路由请求生成新的标识值。
- The Target Address field in the option MUST be set to the IP address that is the target of this Route Discovery.
- 选项中的目标地址字段必须设置为此路由发现的目标IP地址。
The Source Address in the IP header of this packet MUST be the node's own IP address. The Destination Address in the IP header of this packet MUST be the IP "limited broadcast" address (255.255.255.255).
此数据包的IP报头中的源地址必须是节点自己的IP地址。此数据包的IP报头中的目标地址必须是IP“受限广播”地址（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, the node MUST use the information recorded in the Route Request Table entry for the target of that Route Request, and it MUST update that information in the table entry for use in the next Route Request initiated for this target. In particular:
节点必须在其路由请求表中维护有关其发起的路由请求的信息。启动新路由请求时，节点必须使用该路由请求目标的路由请求表条目中记录的信息，并且必须更新表条目中的信息，以便在为该目标启动的下一个路由请求中使用。特别地：
- The Route Request Table entry for a target node records the Time-to-Live (TTL) field used in the IP header of the Route Request for the last Route Discovery initiated by this node for that target node. This value allows the node to implement a variety of 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.3.
- 目标节点的路由请求表条目记录该节点为该目标节点发起的最后一次路由发现的路由请求的IP报头中使用的生存时间（TTL）字段。该值允许节点实现各种算法，以控制其路由请求在为目标启动的每个路由发现上的传播。作为示例，第3.3.3节描述了使用TTL字段的两种可能算法。
- The Route Request Table entry for a target node records the number of consecutive Route Requests initiated for this target since receiving a valid Route Reply giving a route to that target node, and the remaining amount of time before which this node MAY next attempt at a Route Discovery for that target node.
- 目标节点的路由请求表条目记录自接收到向该目标节点提供路由的有效路由应答以来为此目标启动的连续路由请求数，以及该节点下次尝试为该目标节点发现路由之前的剩余时间。
A node MUST use these values to implement a back-off algorithm to limit the rate at 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 this 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 with both a DSR Source Route option and a Route Request option is unspecified. Packets SHOULD NOT contain both a DSR Source Route option and a Route Request option.
未指定节点处理包含DSR Options报头的数据包的行为，其中包含DSR源路由选项和路由请求选项。数据包不应同时包含DSR源路由选项和路由请求选项。
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 logic described in this section.
包含路由请求选项的数据包不应包括确认请求选项，不应期望链路层确认或被动确认，并且不应重新传输。包含路由请求选项的数据包的重传仅由本节中描述的逻辑控制。
When a node receives a packet containing a Route Request option, that node MUST process the option according to the following sequence of steps:
当节点接收到包含路由请求选项的数据包时，该节点必须按照以下步骤顺序处理该选项：
- If the Target Address field in the Route Request matches this node's own IP address, then the node SHOULD return a Route Reply to the initiator of this Route Request (the Source Address in the IP header of the packet), as described in Section 8.2.4. The source route for this Reply is the sequence of hop addresses
- 如第8.2.4节所述，如果路由请求中的目标地址字段与该节点自己的IP地址匹配，则该节点应向该路由请求的发起方返回路由回复（数据包IP报头中的源地址）。此应答的源路由是跃点地址序列
initiator, Address[1], Address[2], ..., Address[n], target
发起者，地址[1]，地址[2]，…，地址[n]，目标
where initiator is the address of the initiator of this Route Request, each Address[i] is an address from the Route Request, and target is the target of the Route Request (the Target Address field in the Route Request). The value n here is the number of addresses recorded in the Route Request, or (Opt Data Len - 6) / 4.
其中启动器是该路由请求的启动器的地址，每个地址[i]是路由请求的地址，目标是路由请求的目标（路由请求中的目标地址字段）。这里的值n是路由请求中记录的地址数，或（Opt Data Len-6）/4。
The node then MUST replace the Destination Address field in the Route Request packet's IP header with the value in the Target Address field in the Route Request option, and continue processing the rest of the Route Request packet normally. The node MUST NOT process the Route Request option further and MUST NOT retransmit the Route Request to propagate it to other nodes as part of the Route Discovery.
然后，节点必须将路由请求包的IP报头中的目的地地址字段替换为路由请求选项中的目标地址字段中的值，并继续正常处理路由请求包的其余部分。节点不得进一步处理路由请求选项，也不得重新传输路由请求以将其传播到其他节点，作为路由发现的一部分。
- 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 node's own IP address already appears in this list of addresses. If so, the node MUST discard the entire packet carrying the Route Request option.
- 否则，节点必须检查路由请求选项（IP源地址字段和地址序列[i]字段）中记录的路由，以确定此节点自己的IP地址是否已出现在此地址列表中。如果是这样，节点必须丢弃携带路由请求选项的整个数据包。
- Else, if the Route Request was received through a network interface that requires physically bidirectional links for unicast transmission, the node MUST check if the Route Request was last forwarded by a node on its blacklist (Section 4.6). If such an entry is found in the blacklist, and the state of the unidirectional link is "probable", then the Request MUST be silently discarded.
- 否则，如果路由请求是通过需要物理双向链路进行单播传输的网络接口接收的，则节点必须检查路由请求是否最后由其黑名单上的节点转发（第4.6节）。如果在黑名单中找到这样一个条目，并且单向链路的状态为“可能”，则必须以静默方式放弃该请求。
- Else, if the Route Request was received through a network interface that requires physically bidirectional links for unicast transmission, the node MUST check if the Route Request was last forwarded by a node on its blacklist. If such an entry is found in the blacklist, and the state of the unidirectional link is "questionable", then the node MUST create and unicast a Route Request packet to that previous node, setting the IP Time-To-Live (TTL) to 1 to prevent the Request from being propagated. If the node receives a Route Reply in response to the new Request, it MUST remove the blacklist entry for that node, and SHOULD continue processing. If the node does not receive a Route Reply within some reasonable amount of time, the node MUST silently discard the Route Request packet.
- 否则，如果路由请求是通过需要物理双向链路进行单播传输的网络接口接收的，则节点必须检查路由请求是否最后由其黑名单上的节点转发。如果在黑名单中发现此类条目，且单向链路的状态为“可疑”，则该节点必须创建路由请求包并单播到该前一节点，将IP生存时间（TTL）设置为1以防止该请求被传播。如果节点收到响应新请求的路由应答，则必须删除该节点的黑名单条目，并应继续处理。如果节点在合理的时间内没有收到路由应答，则节点必须以静默方式丢弃路由请求数据包。
- Else, the node MUST search its Route Request Table for an entry for the initiator of this Route Request (the IP Source Address field). If such an entry is found in the table, the node MUST search the cache of Identification values of recently received Route Requests in that table entry, to determine if an entry is present in the cache matching the Identification value 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 Route Request Table, then the node MUST discard the entire packet carrying the Route Request option.
- 否则，节点必须在其路由请求表中搜索此路由请求的发起方的条目（IP源地址字段）。如果在表中找到此类条目，则节点必须搜索该表条目中最近接收的路由请求的标识值缓存，以确定缓存中是否存在与该路由请求中的标识值和目标节点地址匹配的条目。如果在路由请求表的该条目中的该缓存中找到这样一个（标识、目标地址）条目，则节点必须丢弃携带路由请求选项的整个数据包。
- Else, this node SHOULD further process the Route Request according to the following sequence of steps:
- 否则，该节点应按照以下步骤顺序进一步处理路由请求：
o Add an entry for this Route Request in its cache of (Identification, target address) values of recently received Route Requests.
o 在最近接收的路由请求的（标识、目标地址）值缓存中为此路由请求添加一个条目。
o Conceptually create a copy of this entire packet and perform the following steps on the copy of the packet.
o 从概念上创建整个数据包的副本，并对该数据包的副本执行以下步骤。
o Append this node's own IP address to the list of Address[i] values in the Route Request and increase the value of the Opt Data Len field in the Route Request by 4 (the size of an IP address). However, if the node has multiple network interfaces, this step MUST be modified by the special processing specified in Section 8.4.
o 将此节点自己的IP地址附加到路由请求中的地址[i]值列表中，并将路由请求中的Opt Data Len字段的值增加4（IP地址的大小）。但是，如果节点具有多个网络接口，则必须通过第8.4节中规定的特殊处理修改此步骤。
o This node SHOULD search its own Route Cache for a route (from itself, as if it were the source of a packet) to the target of this Route Request. If such a route is found in its Route Cache, then this node SHOULD follow the procedure outlined in Section 8.2.3 to return a "cached Route Reply" to the initiator of this Route Request, if permitted by the restrictions specified there.
o 该节点应在其自身的路由缓存中搜索（从其自身，好像它是数据包的源）到该路由请求目标的路由。如果在其路由缓存中找到此类路由，则该节点应遵循第8.2.3节中概述的程序，在此处指定的限制允许的情况下，向该路由请求的发起方返回“缓存路由回复”。
o If the node does not return a cached Route Reply, then this node SHOULD transmit this copy of the packet as a link-layer broadcast, with a short jitter delay before the broadcast is sent. The jitter period SHOULD be chosen as a random period, uniformly distributed between 0 and BroadcastJitter.
o 如果节点不返回缓存的路由应答，则该节点应将该数据包副本作为链路层广播发送，在发送广播之前有一个短的抖动延迟。抖动周期应选择为随机周期，均匀分布在0和0抖动之间。
As described in Section 3.3.2, it is possible for a node processing a received Route Request to avoid propagating the Route Request further toward the target of the 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 target of a Route Request is called a "cached Route Reply", and this mechanism can greatly reduce the overall overhead of Route Discovery on the network by reducing the flood of Route Requests. The general processing of a received Route Request is described in Section 8.2.2; this section specifies the additional requirements that MUST be met before a cached Route Reply may be generated and returned and specifies the procedure for returning such a cached Route Reply.
如第3.3.2节所述，处理接收到的路由请求的节点可以避免将路由请求进一步传播到请求的目标，前提是该节点的路由缓存中有一条从自身到该目标的路由。这种由节点从其自身缓存的路由到路由请求的目标生成的路由应答称为“缓存的路由应答”，该机制可以通过减少路由请求的泛滥，大大降低网络上路由发现的总体开销。第8.2.2节描述了接收到的路由请求的一般处理；本节规定了在生成和返回缓存路由回复之前必须满足的附加要求，并规定了返回此类缓存路由回复的过程。
While processing a received Route Request, for a node to possibly return a cached Route Reply, it MUST have in its Route Cache a route from itself to the target of this Route Request. However, before generating a cached Route Reply for this Route Request, the node MUST verify that there are no duplicate addresses listed in 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 Source Address of the packet containing the Route Request,
- 包含路由请求的数据包的IP源地址，
- The Address[i] fields in the Route Request, and
- 路由请求中的地址[i]字段，以及
- The nodes listed in the route obtained from this node's Route Cache, excluding the address of this node itself (this node itself is the common point between the route accumulated in the Route Request and the route obtained from the Route Cache).
- 从该节点的路由缓存获取的路由中列出的节点，不包括该节点本身的地址（该节点本身是路由请求中累积的路由与从路由缓存获取的路由之间的公共点）。
If any duplicates exist among these addresses, then the node MUST NOT send a cached Route Reply using this route from the Route Cache (it is possible that this node has another route in its Route Cache for which the above restriction on duplicate addresses is met, allowing the node to send a cached Route Reply based on that cached route, instead). The node SHOULD continue to process the Route Request as described in Section 8.2.2 if it does not send a cached Route Reply.
如果这些地址之间存在任何重复，则节点不得使用此路由从路由缓存发送缓存的路由回复（此节点的路由缓存中可能有另一个路由，满足上述对重复地址的限制，从而允许节点基于该缓存的路由发送缓存的路由回复）. 如果节点未发送缓存的路由回复，则应继续处理第8.2.2节所述的路由请求。
If the Route Request and the route from the Route Cache meet the restriction above, then the node SHOULD construct and return a cached Route Reply as follows:
如果路由请求和来自路由缓存的路由满足上述限制，则节点应按如下方式构造并返回缓存的路由应答：
- The source route for this Route Reply is the sequence of hop addresses
- 此路由应答的源路由是跃点地址序列
initiator, Address[1], Address[2], ..., Address[n], c-route
发起者，地址[1]，地址[2]，…，地址[n]，c-route
where initiator is the address of the initiator of this Route Request, each Address[i] is an address from the Route Request, and c-route is the sequence of hop addresses in the source route to this target node, obtained from the node's Route Cache. In appending this cached route to the source route for the reply, the address of this node itself MUST be excluded, since it is already listed as Address[n].
其中，启动器是该路由请求的启动器的地址，每个地址[i]是来自路由请求的地址，而c-Route是从节点的路由缓存获得的到该目标节点的源路由中的跃点地址序列。在将此缓存路由附加到应答的源路由时，必须排除此节点本身的地址，因为它已列为地址[n]。
- Send a Route Reply to the initiator of the Route Request, using the procedure defined in Section 8.2.4. The initiator of the Route Request is indicated in the Source Address field in the packet's IP header.
- 使用第8.2.4节中定义的程序向路由请求的发起人发送路由回复。路由请求的发起方在数据包IP报头的源地址字段中指示。
Before sending the cached Route Reply, however, the node MAY delay the Reply in order to help prevent a possible Route Reply "storm", as described in Section 8.2.5.
然而，在发送缓存的路由应答之前，节点可以延迟应答，以帮助防止可能的路由应答“风暴”，如第8.2.5节所述。
If the node returns a cached Route Reply as described above, then the node MUST NOT propagate the Route Request further (i.e., the node MUST NOT rebroadcast the Route 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 is not piggybacked on a TCP or UDP packet), then the node SHOULD simply discard the packet. Otherwise (if the packet contains other DSR options or contains any payload after the DSR Options header), the node SHOULD forward the packet along the cached route to the target of the Route Request. Specifically, if the node does so, it MUST use the following steps:
如果节点如上所述返回缓存的路由应答，则节点不得进一步传播路由请求（即，节点不得重新广播路由请求）。在这种情况下，相反，如果数据包不包含其他DSR选项，并且在DSR选项报头之后不包含有效负载（例如，路由请求没有搭载在TCP或UDP数据包上），则节点应该简单地丢弃该数据包。否则（如果数据包包含其他DSR选项或DSR选项报头之后包含任何有效负载），则节点应沿缓存的路由将数据包转发到路由请求的目标。具体而言，如果节点执行此操作，则必须使用以下步骤：
- Copy the Target Address from the Route Request option in the DSR Options header to the Destination Address field in the packet's IP header.
- 将目标地址从DSR选项标头中的路由请求选项复制到数据包IP标头中的目标地址字段。
- Remove the Route Request option from the DSR Options header in the packet, and add a DSR Source Route option to the packet's DSR Options header.
- 从数据包的DSR Options标头中删除路由请求选项，并将DSR源路由选项添加到数据包的DSR Options标头。
- In the DSR Source Route option, set the Address[i] fields to represent the source route found in this node's Route Cache to the original target of the Route Discovery (the new IP Destination Address of the packet). Specifically, the node copies the hop addresses of the source route into sequential Address[i] fields in the DSR Source Route option, for i = 1, 2, ..., n. Address[1], here, is the address of this node itself (the first address in the source route found from this node to the original target of the Route Discovery). The value n, here, is the number of hop addresses in this source route, excluding the destination of the packet (which is instead already represented in the Destination Address field in the packet's IP header).
- 在DSR源路由选项中，设置地址[i]字段，以表示在该节点的路由缓存中找到的源路由到路由发现的原始目标（数据包的新IP目标地址）。具体地说，对于i＝1，2，…，n，节点将源路由的跃点地址复制到DSR源路由选项中的顺序地址[i]字段中。这里的地址[1]是该节点本身的地址（从该节点到路由发现的原始目标的源路由中的第一个地址）。这里的值n是该源路由中的跃点地址数，不包括数据包的目的地（该目的地已在数据包的IP报头的目的地地址字段中表示）。
- Initialize the Segments Left field in the DSR Source Route option to n as defined above.
- 如上所述，将DSR源路由选项中的Segments Left字段初始化为n。
- The First Hop External (F) bit in the DSR Source Route option MUST be set to 0.
- DSR源路由选项中的第一跳外部（F）位必须设置为0。
- The Last Hop External (L) bit in the DSR Source Route option is copied from the External bit flagging the last hop in the source route for the packet, as indicated in the Route Cache.
- DSR源路由选项中的最后一跳外部（L）位从标记数据包源路由中最后一跳的外部位复制，如路由缓存中所示。
- The Salvage field in the DSR Source Route 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 this packet will not consider a link to exist between the IP Source Address of the packet and the Address[1] address in the DSR Source Route 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 the node initializes this field, nodes furthermore will not attempt to salvage this packet.
- DSR源路由选项中的补救字段必须初始化为某个非零值；使用的特定非零值应为最大残值计数。通过将该字段初始化为非零值，节点转发或监听该分组不会考虑在分组的IP源地址和DSR源路由选项中的地址（1）地址之间存在链接（例如，它们不会试图将其添加到其路由缓存中作为链路）。通过选择MAX_salvair_COUNT作为节点初始化此字段的非零值，节点将不会尝试挽救此数据包。
- Transmit the packet to the next-hop node on the new source route in the packet, using the forwarding procedure described in Section 8.1.5.
- 使用第8.1.5节中描述的转发程序，将数据包发送到数据包中新源路由上的下一跳节点。
A node originates a Route Reply in order to reply to a received and processed Route Request, according to the procedures described in Sections 8.2.2 and 8.2.3. The Route Reply is returned in a Route Reply option (Section 6.3). The Route Reply option MAY be returned to the initiator of the Route Request in a separate IP packet, used only to carry this Route Reply option, or it MAY be included in any other IP packet being sent to this address.
根据第8.2.2节和第8.2.3节中描述的程序，节点发起路由应答，以应答接收和处理的路由请求。路由回复在路由回复选项中返回（第6.3节）。路由应答选项可以在单独的IP分组中返回给路由请求的发起方，该IP分组仅用于携带该路由应答选项，或者它可以包括在发送到此地址的任何其他IP分组中。
The Route Reply option MUST be included in a DSR Options header in the packet returned to the initiator. To initialize the Route Reply option, the node performs the following sequence of steps:
路由回复选项必须包含在返回给启动器的数据包的DSR Options报头中。要初始化路由应答选项，节点将执行以下一系列步骤：
- The Option Type in the option MUST be set to the value 3.
- 选项中的选项类型必须设置为值3。
- The Opt Data Len field in the 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).
- 选项中的Opt Data Len字段必须设置为值（n*4）+3，其中n是返回的源路由中的地址数（不包括路由发现启动器节点的地址）。
- If this node is the target of the Route Request, the Last Hop External (L) bit in the option MUST be initialized to 0.
- 如果此节点是路由请求的目标，则必须将选项中的最后一个跃点外部（L）位初始化为0。
- The Reserved field in the option MUST be initialized to 0.
- 选项中的保留字段必须初始化为0。
- The Route Request Identifier MUST be initialized to the Identifier field of the Route Request to which this Route Reply is sent in response.
- 路由请求标识符必须初始化为发送此路由应答的路由请求的标识符字段。
- The sequence of hop addresses in the 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 the
- 源路由中的跃点地址序列被复制到选项的地址[i]字段中。地址[1]必须设置为路由发起方之后的路由第一跳地址
Route Discovery, Address[n] MUST be set to the last-hop address of the source route (the 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.
路由发现时，地址[n]必须设置为源路由的最后一个跃点地址（目标节点的地址），并且每个其他地址[i]必须按顺序设置为要返回的源路由中的下一个地址。
The Destination Address field in the IP header of the packet carrying the Route Reply option MUST be set to the address of the initiator of the Route Discovery (i.e., for a Route Reply being returned in response to some Route Request, the IP Source Address of the Route Request).
携带路由应答选项的数据包的IP报头中的目的地地址字段必须设置为路由发现发起方的地址（即，对于响应某个路由请求而返回的路由应答，路由请求的IP源地址）。
After creating and initializing the Route Reply option and the IP packet containing it, send the Route Reply. In sending the Route Reply from this node (but not from nodes forwarding the Route Reply), this node SHOULD delay the Reply by a small jitter period chosen randomly between 0 and BroadcastJitter.
创建并初始化路由应答选项和包含该选项的IP数据包后，发送路由应答。在从该节点（但不是从转发路由应答的节点）发送路由应答时，该节点应将应答延迟一个小的抖动周期，该抖动周期在0和0之间随机选择。
When returning any Route Reply in the case in which the 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 Reply packet MUST be obtained by reversing the sequence of hops in the Route Request packet (the source route that is then returned in the Route Reply). This restriction on returning a Route Reply enables the Route Reply to test this sequence of hops for bidirectionality, preventing the Route Reply from being received by the initiator of the Route Discovery unless each of the hops over which the Route Reply is returned (and thus each of the hops in the source route being returned in the Reply) is bidirectional.
当在网络中使用的MAC协议不能通过单向链路传输单播分组的情况下返回任何路由应答时，必须通过反转路由请求分组中的跳序列来获得用于路由应答分组的源路由（然后在路由应答中返回的源路由）。此对返回路由应答的限制使路由应答能够测试此跳序列的双向性，防止路由发现的发起方接收路由应答，除非返回路由应答的每个跳（因此，应答中返回的源路由中的每个跃点）是双向的。
If sending a Route Reply to the initiator of the Route Request requires performing a Route Discovery, the Route Reply option MUST be piggybacked on the packet that contains the Route Request. This piggybacking prevents a recursive dependency wherein the target of the new Route Request (which was itself the initiator of the original Route Request) must do another Route Request in order to return its Route Reply.
如果向路由请求的发起方发送路由应答需要执行路由发现，则必须在包含路由请求的数据包上搭载路由应答选项。这种搭载可以防止递归依赖，其中新路由请求的目标（它本身就是原始路由请求的发起方）必须执行另一个路由请求才能返回其路由应答。
If sending the Route Reply to the initiator of the Route Request does not require performing a Route Discovery, a node SHOULD send a unicast Route Reply in response to every Route Request it receives for which it is the target node.
如果向路由请求的发起方发送路由应答不需要执行路由发现，则节点应发送单播路由应答，以响应其作为目标节点接收的每个路由请求。
The ability for nodes to reply to a Route Request based on information in their Route Caches, as described in Sections 3.3.2 and 8.2.3, could result in a possible Route Reply "storm" in some cases. In particular, if a node broadcasts a Route Request for a target node
如第3.3.2节和第8.2.3节所述，节点根据其路由缓存中的信息回复路由请求的能力在某些情况下可能导致路由回复“风暴”。特别是，如果节点广播目标节点的路由请求
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:
例如，下图显示了节点B、C、D、E和F都接收到a对目标G的路由请求，并且每个节点都为该目标缓存了指示的路由的情况：
+-----+ +-----+
| 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
+-----+ +-----+
| 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 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 wireless network and may create packet collisions among some or all of these Replies if the MAC protocol 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.
通常，这些节点中的每一个都会尝试从自己的路由缓存中进行应答，因此它们都会在大约相同的时间发送它们的路由应答，因为它们都在大约相同的时间接收到广播路由请求。如果所使用的MAC协议没有为这些分组提供足够的冲突避免，则来自所有接收路由请求的不同节点的这种同时路由应答可能导致无线网络中的本地拥塞，并且可能在这些应答中的一些或全部之间创建分组冲突。此外，通常情况下，不同的回复将指示不同长度的路由，如本例所示。
In order to reduce these effects, if a node can put its network interface into promiscuous receive mode, it MAY delay sending its own Route Reply for 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)
d = H * (h - 1 + r)
where h is the length in number of network hops for the route to be returned in this node's Route Reply, r is a random floating point number between 0 and 1, and H is a small constant delay (at least twice the maximum wireless link propagation delay) to be introduced
其中h是该节点的路由应答中要返回的路由的网络跳数长度，r是介于0和1之间的随机浮点数，h是要引入的小恒定延迟（至少是最大无线链路传播延迟的两倍）
per hop. This delay effectively randomizes the time at which each node sends its Route Reply, with all nodes sending Route Replies giving routes of length less than h sending their Replies before this node, and all nodes sending Route Replies giving routes of length greater than h send their Replies after this node.
每跳。该延迟有效地随机化了每个节点发送其路由回复的时间，所有发送长度小于h的路由回复的节点在此节点之前发送回复，所有发送长度大于h的路由回复的节点在此节点之后发送回复。
Within the delay period, this node promiscuously receives all packets, looking for data packets from the initiator of this Route Discovery destined for the target of the Route Discovery. If such a data packet received by this node during the delay period uses a source route of length less than or equal to h, this node may infer that the 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 SHOULD NOT send its Route Reply for this Route Discovery.
在延迟期内，该节点杂乱地接收所有数据包，寻找来自该路由发现的发起方的数据包，该发起方的目的地是路由发现的目标。如果该节点在延迟期间接收的这样的数据分组使用长度小于或等于h的源路由，则该节点可以推断路由发现的发起方已经接收到给出同样好的或更好的路由的路由应答。在这种情况下，此节点应取消其延迟计时器，并且不应为此路由发现发送其路由回复。
Section 8.1.4 describes the general processing for a received packet, including the addition of routing information from options in the packet's DSR Options header to the receiving node's Route Cache.
第8.1.4节描述了接收到的数据包的一般处理，包括将来自数据包DSR options报头中的选项的路由信息添加到接收节点的路由缓存中。
If the received packet contains a Route Reply, no additional special processing of the Route Reply option is required beyond what is described there. As described in Section 4.1, anytime a node adds new information to its Route Cache (including the information added from this Route Reply option), the node SHOULD check each packet in its own Send Buffer (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. This general procedure handles all processing required for a received Route Reply option.
如果接收到的数据包包含路由应答，则除了此处所述之外，不需要对路由应答选项进行额外的特殊处理。如第4.1节所述，每当节点向其路由缓存添加新信息（包括从该路由应答选项添加的信息）时，节点应检查其自身发送缓冲区（第4.2节）中的每个数据包，以确定到该数据包的IP目的地地址的路由现在是否存在于节点的路由缓存中（包括刚刚添加到缓存中的信息）。如果是这样，则应使用该路由发送数据包，并将其从发送缓冲区中删除。此常规过程处理接收到的路由回复选项所需的所有处理。
When using a MAC protocol that requires bidirectional links for unicast transmission, a unidirectional link may be discovered by the propagation of the Route 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 add the next-hop address to its blacklist (Section 4.6).
当使用需要双向链路用于单播传输的MAC协议时，可通过路由请求的传播来发现单向链路。当路由应答通过反向路径发送时，转发节点可能会发现下一跳无法到达。在这种情况下，它必须将下一跳地址添加到其黑名单中（第4.6节）。
Route Maintenance is the mechanism by which a source node S is able to detect, while using a source route to some destination node 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 that a source route is broken, S can
路由维护是一种机制，通过该机制，源节点S在使用到某个目的地节点D的源路由时，能够检测到网络拓扑是否已发生变化，从而由于路由上的链路不再工作而无法再使用到目的地节点D的路由。当路由维护指示源路由已中断时，S可以
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.
尝试使用它碰巧知道的任何其他路由到D，或者可以再次调用路由发现来为到D的后续数据包找到新路由。仅当S实际向D发送数据包时，才使用此路由的路由维护。
Specifically, when forwarding a packet, a node MUST attempt to confirm the reachability of the next-hop node, unless such confirmation had been received in the last MaintHoldoffTime period. Individual implementations MAY choose to bypass such confirmation for some limited number of packets, as long as those packets all fall within MaintHoldoffTime since the last confirmation. If no confirmation is received after the retransmission of MaxMaintRexmt acknowledgement requests, after the initial transmission of the packet, and conceptually including all retransmissions provided by the MAC layer, the node determines that the link for this next-hop node of the source route is "broken". This confirmation from the next-hop node for Route Maintenance can be implemented using a link-layer acknowledgement (Section 8.3.1), a "passive acknowledgement" (Section 8.3.2), or a network-layer acknowledgement (Section 8.3.3); the particular strategy for retransmission timing depends on the type of acknowledgement mechanism used. When not using link-layer acknowledgements for Route Maintenance, nodes SHOULD use passive acknowledgements when possible but SHOULD try requesting a network-layer acknowledgement one or more times before deciding that the link has failed and originating a Route Error to the original sender of the packet, as described in Section 8.3.4.
具体地说，在转发数据包时，节点必须尝试确认下一跳节点的可达性，除非在最后一个maintholdoff时间段内收到了这样的确认。对于某些数量有限的数据包，只要这些数据包都在上次确认后的MainTholdOff时间内，个别实现可能会选择绕过此类确认。如果在重新传输MaxMaintRexmt确认请求之后、在分组的初始传输之后并且在概念上包括由MAC层提供的所有重新传输之后没有接收到确认，则该节点确定源路由的该下一跳节点的链路“断开”。可使用链路层确认（第8.3.1节）、“被动确认”（第8.3.2节）或网络层确认（第8.3.3节）来实现来自下一跳节点的路由维护确认；重传定时的特定策略取决于所使用的确认机制的类型。如第8.3.4节所述，当不使用链路层确认进行路由维护时，节点应尽可能使用被动确认，但应尝试请求网络层确认一次或多次，然后再确定链路已发生故障并向数据包的原始发送方发出路由错误。
In deciding whether or not to send a Route Error in response to attempting to forward a packet from some sender over a broken link, a node MUST limit the number of consecutive packets from a single sender that the node attempts to forward over this same broken link for which the node chooses not to return a Route Error. This requirement MAY be satisfied by returning a Route Error for each packet that the node attempts to forward over a broken link.
在决定是否发送路由错误以响应试图通过断开的链路转发来自某个发送方的数据包时，节点必须限制来自单个发送方的连续数据包的数量，该发送方试图通过该断开的链路转发该节点选择不返回路由错误的数据包。可以通过为节点试图通过断开的链路转发的每个分组返回路由错误来满足该要求。
If the MAC protocol in use provides feedback as to the successful delivery of a data packet (such as is provided for unicast packets by the link-layer acknowledgement frame defined by IEEE 802.11 [IEEE80211]), then the use of the 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 SHOULD NOT use either passive acknowledgements or network-layer acknowledgements for Route Maintenance.
如果使用中的MAC协议提供关于数据分组的成功递送的反馈（例如由IEEE 802.11[IEEE80211]定义的链路层确认帧为单播分组提供），则不需要使用DSR确认请求和确认选项。如果这种链路层反馈可用，则应使用它代替任何其他确认机制进行路由维护，并且节点不应使用被动确认或网络层确认进行路由维护。
When using link-layer acknowledgements for Route Maintenance, the retransmission timing and the timing at which retransmission attempts are scheduled are generally controlled by the particular link layer implementation in use in the network. For example, in IEEE 802.11, the link-layer acknowledgement is returned after a unicast packet as a part of the basic access method of the IEEE 802.11 Distributed Coordination Function (DCF) MAC protocol; the time at which the acknowledgement is expected to arrive and the time at which the next retransmission attempt (if necessary) will occur are controlled by the MAC protocol implementation.
当使用链路层确认进行路由维护时，重传定时和调度重传尝试的定时通常由网络中使用的特定链路层实现控制。例如，在IEEE 802.11中，作为IEEE 802.11分布式协调功能（DCF）MAC协议的基本接入方法的一部分，在单播分组之后返回链路层确认；确认预期到达的时间和下一次重传尝试（如有必要）将发生的时间由MAC协议实现控制。
When a node receives a link-layer acknowledgement for any packet in its Maintenance Buffer, that node SHOULD remove from its Maintenance Buffer that packet, as well as any other packets in its Maintenance Buffer with the same next-hop destination.
当节点接收到其维护缓冲区中任何数据包的链路层确认时，该节点应将该数据包以及其维护缓冲区中具有相同下一跳目的地的任何其他数据包从其维护缓冲区中移除。
When link-layer acknowledgements are not available, but passive acknowledgements [JUBIN87] are available, passive acknowledgements SHOULD be used for Route Maintenance when originating or forwarding a packet along any hop other than the last hop (the hop leading to the IP Destination Address node of the packet). In particular, passive acknowledgements SHOULD be used for Route Maintenance in such cases if the node can place its network interface into "promiscuous" receive mode, and if network links used for data packets generally operate bidirectionally.
当链路层确认不可用，但被动确认[JUBIN87]可用时，当沿着除最后一个跃点（通向数据包IP目的地地址节点的跃点）以外的任何跃点发起或转发数据包时，被动确认应用于路由维护。特别是，如果节点可以将其网络接口置于“混杂”接收模式，并且如果用于数据包的网络链路通常双向运行，则在这种情况下，应使用被动确认来维护路由。
A node MUST NOT attempt to use passive acknowledgements for Route Maintenance for a packet originated or forwarded over its last hop (the hop leading to the IP Destination Address node of the packet), since the receiving node will not be forwarding the packet and thus no passive acknowledgement will be available to be heard by this node. Beyond this restriction, a node MAY utilize a variety of strategies in using passive acknowledgements for Route Maintenance of a packet that it originates or forwards. For example, the following two strategies are possible:
节点不得尝试使用被动确认来维护在其最后一个跃点（通向数据包的IP目的地地址节点的跃点）上发起或转发的数据包的路由，因为接收节点不会转发数据包，因此该节点将无法听到被动确认。除此限制之外，节点可以利用各种策略来使用被动应答来维护其发起或转发的分组的路由。例如，以下两种策略是可能的：
- Each time a node receives a packet to be forwarded to a node other than the final destination (the IP Destination Address of the packet), that node sends the original transmission of that packet without requesting a network-layer acknowledgement for it. If no passive acknowledgement is received within PassiveAckTimeout after this transmission, the node retransmits the packet, again without requesting a network-layer acknowledgement for it; the same PassiveAckTimeout timeout value is used for each such attempt. If no acknowledgement has been received after a total of TryPassiveAcks retransmissions of the packet, network-layer
- 每当节点接收到要转发到除最终目的地（分组的IP目的地地址）以外的节点的分组时，该节点发送该分组的原始传输，而不请求对其进行网络层确认。如果在该传输之后的被动式应答时间内没有接收到被动式应答，则节点再次重新传输该分组，而不请求对其进行网络层应答；每次这样的尝试都使用相同的passiveEackTimeout超时值。如果在分组的TryPassiveAcks重新传输总数之后未收到确认，则网络层
acknowledgements (as described in Section 8.3.3) are requested for all remaining attempts for that packet.
对该数据包的所有剩余尝试请求确认（如第8.3.3节所述）。
- Each node maintains a table of possible next-hop destination nodes, noting whether or not passive acknowledgements can typically be expected from transmission to that node, and the expected latency and jitter of a passive acknowledgement from that node. Each time a node receives a packet to be forwarded to a node other than the IP Destination Address, the node checks its table of 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 packet can also be derived from this table. A node using this method SHOULD prefer using passive acknowledgements to network-layer acknowledgements.
- 每个节点维护一个可能的下一跳目的地节点的表，记录从传输到该节点是否通常可以预期被动确认，以及来自该节点的被动确认的预期延迟和抖动。每当节点接收到要转发到除IP目的地地址之外的节点的分组时，该节点检查其下一跳目的地节点的表，以确定是使用被动确认还是网络层确认来进行到该节点的传输。此数据包的超时时间也可以从此表中导出。与网络层确认相比，使用此方法的节点更喜欢使用被动确认。
In using passive acknowledgements for a packet that it originates or forwards, a node considers the later receipt of a new packet (e.g., with promiscuous receive mode enabled on its network interface) 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 IP header of the two packets MUST match [RFC791].
- 两个数据包的IP报头中的源地址、目标地址、协议、标识和片段偏移量字段必须匹配[RFC791]。
- If either packet contains a DSR Source Route header, both packets MUST contain one, and the value in the Segments Left field in the DSR Source Route header of the new packet MUST be less than that in the first packet.
- 如果任一数据包包含DSR源路由报头，则两个数据包都必须包含一个，并且新数据包的DSR源路由报头的Segments Left字段中的值必须小于第一个数据包中的值。
When a node hears such a passive acknowledgement for any packet in its Maintenance Buffer, that node SHOULD remove from its Maintenance Buffer that packet, as well as any other packets in its Maintenance Buffer with the same next-hop destination.
当节点听到对其维护缓冲器中的任何分组的这种被动确认时，该节点应将该分组以及其维护缓冲器中具有相同下一跳目的地的任何其他分组从其维护缓冲器中移除。
When a node originates or forwards a packet and has no other mechanism of acknowledgement available to determine reachability of the next-hop node in the source route for Route Maintenance, that node SHOULD request a network-layer acknowledgement from that next-hop node. To do so, the node inserts an Acknowledgement Request option in the DSR Options header in the packet. The Identification field in that Acknowledgement Request option MUST be set to a value unique over all packets recently transmitted by this node to the same next-hop node.
当一个节点发起或转发一个数据包，并且没有其他确认机制可用于确定源路由中下一跳节点的可达性以进行路由维护时，该节点应从该下一跳节点请求网络层确认。为此，节点在数据包的DSR Options报头中插入确认请求选项。该确认请求选项中的标识字段必须设置为该节点最近发送到同一下一跳节点的所有数据包上唯一的值。
When a node receives a packet containing an Acknowledgement Request option, that node performs the following tests on the packet:
当节点接收到包含确认请求选项的数据包时，该节点对该数据包执行以下测试：
- If the indicated next-hop node address for this packet does not match any of this node's own IP addresses, then this node MUST NOT process the Acknowledgement Request option. The indicated next-hop node address is the next Address[i] field in the DSR Source Route option in the DSR Options header in the packet, or the IP Destination Address in the packet if the packet does not contain a DSR Source Route option or the Segments Left there is zero.
- 如果指示的该数据包的下一跳节点地址与该节点自身的任何IP地址不匹配，则该节点不得处理确认请求选项。指示的下一跳节点地址是数据包中DSR选项报头中DSR源路由选项中的下一个地址[i]字段，如果数据包不包含DSR源路由选项或剩余的段为零，则是数据包中的IP目标地址。
- If the packet contains an Acknowledgement option, then this node MUST NOT process the Acknowledgement Request option.
- 如果数据包包含确认选项，则此节点不得处理确认请求选项。
If neither of the tests above fails, then this node MUST process the Acknowledgement Request option by sending an Acknowledgement option to the previous-hop node; to do so, the node performs the following sequence of steps:
如果上述测试均未失败，则该节点必须通过向前一跳节点发送确认选项来处理确认请求选项；为此，节点将执行以下一系列步骤：
- Create a packet and set the IP Protocol field to the protocol number assigned for DSR (48).
- 创建一个数据包，并将IP协议字段设置为为DSR分配的协议号（48）。
- Set the IP Source Address field in this packet to the IP address of this node, copied from the source route in the DSR Source Route option in that packet (or from the IP Destination Address field of the packet, if the packet does not contain a DSR Source Route option).
- 将此数据包中的IP源地址字段设置为此节点的IP地址，从该数据包中DSR源路由选项中的源路由复制（或者如果数据包不包含DSR源路由选项，则从数据包的IP目标地址字段复制）。
- Set the IP Destination Address field in this packet to the IP address of the previous-hop node, copied from the source route in the DSR Source Route option in that packet (or from the IP Source Address field of the packet, if the packet does not contain a DSR Source Route option).
- 将此数据包中的IP Destination Address（IP目的地地址）字段设置为上一跳节点的IP地址，从该数据包的DSR源路由选项中的源路由复制（如果数据包不包含DSR源路由选项，则从数据包的IP源地址字段复制）。
- Add a DSR Options header to the packet. Set the Next Header field in the DSR Options header to the value 59, "No Next Header" [RFC2460].
- 将DSR选项标头添加到数据包。将DSR选项标题中的下一个标题字段设置为值59，“无下一个标题”[RFC2460]。
- Add an Acknowledgement option to the DSR Options header in the packet; set the Acknowledgement option's Option Type field to 6 and the Opt Data Len field to 10.
- 向数据包中的DSR选项报头添加确认选项；将确认选项的选项类型字段设置为6，将Opt Data Len字段设置为10。
- Copy the Identification field from the received Acknowledgement Request option into the Identification field in the Acknowledgement option.
- 将接收到的确认请求选项中的标识字段复制到确认选项中的标识字段中。
- Set the ACK Source Address field in the Acknowledgement option to be the IP Source Address of this new packet (set above to be the IP address of this node).
- 将确认选项中的ACK Source Address字段设置为此新数据包的IP源地址（上面设置为此节点的IP地址）。
- Set the ACK Destination Address field in the Acknowledgement option to be the IP Destination Address of this new packet (set above to be the IP address of the previous-hop node).
- 将确认选项中的ACK Destination Address（确认目的地地址）字段设置为该新数据包的IP目的地地址（上面设置为前一跳节点的IP地址）。
- Send the packet as described in Section 8.1.1.
- 按照第8.1.1节所述发送数据包。
Packets containing an Acknowledgement option SHOULD NOT be placed in the Maintenance Buffer.
包含确认选项的数据包不应放在维护缓冲区中。
When a node receives a packet with both an Acknowledgement option and an Acknowledgement Request option, if that node is not the destination of the Acknowledgement option (the IP Destination Address of the packet), then the Acknowledgement Request option MUST be ignored. Otherwise (that node is the destination of the Acknowledgement option), that node MUST process the Acknowledgement Request option by returning an Acknowledgement option according to the following sequence of steps:
当节点接收到同时具有确认选项和确认请求选项的数据包时，如果该节点不是确认选项的目的地（数据包的IP目的地地址），则必须忽略确认请求选项。否则（该节点是确认选项的目的地），该节点必须通过按照以下步骤顺序返回确认选项来处理确认请求选项：
- Create a packet and set the IP Protocol field to the protocol number assigned for DSR (48).
- 创建一个数据包，并将IP协议字段设置为为DSR分配的协议号（48）。
- Set the IP Source Address field in this packet to the IP address of this node, copied from the source route in the DSR Source Route option in that packet (or from the IP Destination Address field of the packet, if the packet does not contain a DSR Source Route option).
- 将此数据包中的IP源地址字段设置为此节点的IP地址，从该数据包中DSR源路由选项中的源路由复制（或者如果数据包不包含DSR源路由选项，则从数据包的IP目标地址字段复制）。
- Set the IP Destination Address field in this packet to the IP address of the node originating the Acknowledgement option.
- 将此数据包中的IP Destination Address字段设置为发起确认选项的节点的IP地址。
- Add a DSR Options header to the packet, and set the DSR Options header's Next Header field to the value 59, "No Next Header" [RFC2460].
- 向数据包添加DSR选项标头，并将DSR选项标头的下一个标头字段设置为值59，“无下一个标头”[RFC2460]。
- Add an Acknowledgement option to the DSR Options header in this packet; set the Acknowledgement option's Option Type field to 6 and the Opt Data Len field to 10.
- 向该数据包中的DSR选项报头添加确认选项；将确认选项的选项类型字段设置为6，将Opt Data Len字段设置为10。
- Copy the Identification field from the received Acknowledgement Request option into the Identification field in the Acknowledgement option.
- 将接收到的确认请求选项中的标识字段复制到确认选项中的标识字段中。
- Set the ACK Source Address field in the option to the IP Source Address of this new packet (set above to be the IP address of this node).
- 将选项中的ACK Source Address字段设置为此新数据包的IP源地址（上面设置为此节点的IP地址）。
- Set the ACK Destination Address field in the option to the IP Destination Address of this new packet (set above to be the IP address of the node originating the Acknowledgement option).
- 将选项中的ACK Destination Address字段设置为此新数据包的IP目的地地址（上面设置为发起确认选项的节点的IP地址）。
- Send the packet directly to the destination. The IP Destination Address MUST be treated as a direct neighbor node: the transmission to that node MUST be done in a single IP forwarding hop, without Route Discovery and without searching the Route Cache. In addition, this packet MUST NOT contain a DSR Acknowledgement Request, MUST NOT be retransmitted for Route Maintenance, and MUST NOT expect a link-layer acknowledgement or passive acknowledgement.
- 将数据包直接发送到目的地。IP目标地址必须视为直接邻居节点：到该节点的传输必须在单个IP转发跃点中完成，无需路由发现和搜索路由缓存。此外，此数据包不得包含DSR确认请求，不得为路由维护而重新传输，且不得期望链路层确认或被动确认。
When using network-layer acknowledgements for Route Maintenance, a node SHOULD use an adaptive algorithm in determining the retransmission timeout for each transmission attempt of an acknowledgement request. For example, a node SHOULD maintain a separate round-trip time (RTT) estimate for each node 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 Maintenance. The TCP RTT estimation algorithm has been shown to work well for this purpose in implementation and testbed experiments with DSR [MALTZ99b, MALTZ01].
当使用网络层确认进行路由维护时，节点应使用自适应算法来确定确认请求的每次传输尝试的重传超时。例如，节点应为其最近尝试向其发送数据包的每个节点保持单独的往返时间（RTT）估计值，并且应使用该RTT估计值来设置用于路由维护的每次重传尝试的超时。在DSR[MALTZ99b，MALTZ01]的实现和试验台实验中，TCP RTT估计算法已被证明能够很好地实现这一目的。
When a node is unable to verify reachability of a next-hop node after reaching a maximum number of retransmission attempts, it SHOULD send a Route Error to the IP Source Address of the packet. When sending a Route Error for a packet containing either a Route Error option or an Acknowledgement option, a node SHOULD add these existing options to its Route Error, subject to the limit described below.
当节点在达到最大重传尝试次数后无法验证下一跳节点的可达性时，它应向数据包的IP源地址发送路由错误。当为包含路由错误选项或确认选项的数据包发送路由错误时，节点应将这些现有选项添加到其路由错误中，并遵守以下描述的限制。
A node transmitting a Route Error MUST perform the following steps:
发送路由错误的节点必须执行以下步骤：
- Create an IP packet and set the IP Protocol field to the protocol number assigned for DSR (48). Set the Source Address field in this packet's IP header to the address of this node.
- 创建IP数据包并将IP协议字段设置为为DSR分配的协议编号（48）。将此数据包IP头中的源地址字段设置为此节点的地址。
- If the Salvage field in the DSR Source Route option in the packet triggering the Route Error is zero, then copy the Source Address field of the packet triggering the Route Error into the Destination Address field in the new packet's IP header;
- 如果触发路由错误的分组中DSR源路由选项中的补救字段为零，则将触发路由错误的分组的源地址字段复制到新分组的IP报头中的目的地址字段中；
otherwise, copy the Address[1] field from the DSR Source Route option of the packet triggering the Route Error into the Destination Address field in the new packet's IP header
否则，将触发路由错误的数据包的DSR源路由选项中的地址[1]字段复制到新数据包IP报头中的目标地址字段中
- Insert a DSR Options header into the new packet.
- 将DSR选项标头插入新数据包。
- Add a Route Error Option to the new packet, setting the Error Type to NODE_UNREACHABLE, the Salvage value to the Salvage value from the DSR Source Route option of the packet triggering the Route Error, and the Unreachable Node Address field to the address of the next-hop node from the original source route. Set the Error Source Address field to this node's IP address, and the Error Destination field to the new packet's IP Destination Address.
- 向新数据包添加路由错误选项，将错误类型设置为NODE_UNREACHABLE，将残值设置为触发路由错误的数据包的DSR源路由选项的残值，将UNREACHABLE NODE Address字段设置为原始源路由的下一跳节点的地址。将错误源地址字段设置为此节点的IP地址，将错误目标字段设置为新数据包的IP目标地址。
- If the packet triggering the Route Error contains any Route Error or Acknowledgement options, the node MAY append to its Route Error each of these options, with the following constraints:
- 如果触发路由错误的分组包含任何路由错误或确认选项，则节点可将这些选项中的每一个附加到其路由错误，并具有以下约束：
o The node MUST NOT include any Route Error option from the packet triggering the new Route Error, for which the total Salvage count (Section 6.4) of that included Route Error would be greater than MAX_SALVAGE_COUNT in the new packet.
o 节点不得包括来自触发新路由错误的分组的任何路由错误选项，对于该选项，所包括的路由错误的总补救计数（第6.4节）将大于新分组中的最大补救计数。
o If any Route Error option from the packet triggering the new Route Error is not included in the packet, the node MUST NOT include any following Route Error or Acknowledgement options from the packet triggering the new Route Error.
o 如果来自触发新路由错误的分组的任何路由错误选项未包括在分组中，则节点不得包括来自触发新路由错误的分组的任何后续路由错误或确认选项。
o Any appended options from the packet triggering the Route Error MUST follow the new Route Error in the packet.
o 来自触发路由错误的数据包的任何附加选项必须位于数据包中的新路由错误之后。
o In appending these options to the new Route Error, the order of these options from the packet triggering the Route Error MUST be preserved.
o 在将这些选项附加到新路由错误时，必须保留这些选项在触发路由错误的数据包中的顺序。
- Send the packet as described in Section 8.1.1.
- 按照第8.1.1节所述发送数据包。
When a node receives a packet containing a Route Error option, that node MUST process the Route Error option according to the following sequence of steps:
当节点接收到包含路由错误选项的数据包时，该节点必须按照以下步骤顺序处理路由错误选项：
- The node MUST remove from its Route Cache the link from the node identified by the Error Source Address field to the node identified by the Unreachable Node Address field (if this link is present in its Route Cache). If the node implements its Route Cache as a link cache, as described in Section 4.1, only this
- 节点必须从其路由缓存中删除从“错误源地址”字段标识的节点到“无法访问的节点地址”字段标识的节点的链接（如果此链接存在于其路由缓存中）。如果节点将其路由缓存实现为链路缓存（如第4.1节所述），则仅此
single link is removed; if the node implements its Route Cache as a path cache, however, all routes (paths) that use this link are either truncated before the link or removed completely.
删除单个链接；但是，如果节点将其路由缓存实现为路径缓存，则使用此链接的所有路由（路径）要么在链接之前被截断，要么被完全删除。
- If the option following the Route Error is 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 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 Acknowledgement or Error Destination Address. Transmit this packet as described in Section 8.1.1, with the Salvage count in the DSR Source Route option set to the Salvage value of the Route Error.
- 如果路由错误后的选项是由该节点发送的确认或路由错误选项（即，确认或错误源地址等于该节点的地址），将当前路由错误后的DSR选项复制到一个新数据包中，该数据包的IP源地址等于此节点自己的IP地址，IP目标地址等于确认或错误目标地址。按照第8.1.1节所述传输此数据包，DSR源路由选项中的补救计数设置为路由错误的补救值。
In addition, after processing the Route Error as described above, the node MAY initiate a new Route Discovery for any destination node for which it then has no route in its Route Cache as a result of processing this Route Error, if the node has indication that a route to that destination is needed. For example, if the node has an open TCP connection to some destination node, then if the processing of this Route Error removed the only route to that destination from this node's Route Cache, then this node MAY initiate a new Route Discovery for that destination node. Any node, however, MUST limit the rate at which 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 Error MUST conform as a part of this limit.
此外，在如上所述处理路由错误之后，如果节点指示需要到该目的地的路由，则节点可以为其路由缓存中没有路由的任何目的地节点发起新路由发现，作为处理该路由错误的结果。例如，如果节点与某个目标节点有开放的TCP连接，则如果此路由错误的处理从该节点的路由缓存中删除了到该目标的唯一路由，则该节点可能会为该目标节点启动新的路由发现。但是，任何节点都必须限制其为任何单一目的地地址启动新路由发现的速率，并且作为处理此路由错误的一部分，以这种方式启动的任何新路由发现必须符合此限制的一部分。
When an intermediate node forwarding a packet detects through Route Maintenance that the next-hop link along the route for that packet is broken (Section 8.3), if the node has another route to the packet's IP Destination Address in its Route Cache, the node SHOULD "salvage" the packet rather than discard it. To do so using the route found in its Route Cache, this node processes the packet as follows:
当转发数据包的中间节点通过路由维护检测到该数据包的路由上的下一跳链路断开时（第8.3节），如果该节点在其路由缓存中有到该数据包的IP目的地地址的另一条路由，则该节点应“挽救”该数据包，而不是丢弃它。要使用在其路由缓存中找到的路由执行此操作，此节点按如下方式处理数据包：
- 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 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 then contains no DSR options or only a DSR Source Route Option, remove the DSR Options header from the packet. If the resulting packet then contains only an IP header (e.g., no transport layer header or payload), the node SHOULD NOT salvage the packet and instead SHOULD discard the entire packet.
- 如第3.3.1节所述，如果网络中使用的MAC协议不能通过单向链路传输单播数据包，则如果该数据包包含路由回复选项，则删除并丢弃数据包中的路由回复选项；如果数据包中的DSR选项报头不包含DSR选项或仅包含DSR源路由选项，请从数据包中删除DSR选项报头。如果生成的分组随后仅包含IP报头（例如，没有传输层报头或有效载荷），则节点不应挽救该分组，而是应丢弃整个分组。
- Modify the existing DSR Source Route option in the packet so that the Address[i] fields represent the source route found in this node's Route Cache to this packet's IP Destination Address. Specifically, the node copies the hop addresses of the source route into sequential Address[i] fields in the DSR Source Route option, for 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 node to the IP Destination Address of the packet). The value n, here, is the number of hop addresses in this source route, excluding the destination of the packet (which is instead already represented in the Destination Address field in the packet's IP header).
- 修改数据包中现有的DSR源路由选项，使地址[i]字段表示在该节点的路由缓存中找到的到该数据包IP目的地地址的源路由。具体地说，对于i＝1，2，…，n，节点将源路由的跃点地址复制到DSR源路由选项中的顺序地址[i]字段中。这里的地址[1]是回收节点本身的地址（从该节点到数据包的IP目标地址的源路由中的第一个地址）。这里的值n是该源路由中的跃点地址数，不包括数据包的目的地（该目的地已在数据包的IP报头的目的地地址字段中表示）。
- Initialize the Segments Left field in the DSR Source Route option to n as defined above.
- 如上所述，将DSR源路由选项中的Segments Left字段初始化为n。
- The First Hop External (F) bit in the DSR Source Route option MUST be set to 0.
- DSR源路由选项中的第一跳外部（F）位必须设置为0。
- The Last Hop External (L) bit in the DSR Source Route option is copied from the External bit flagging the last hop in the source route for the packet, as indicated in the Route Cache.
- DSR源路由选项中的最后一跳外部（L）位从标记数据包源路由中最后一跳的外部位复制，如路由缓存中所示。
- 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.
- DSR源路由选项中的补救字段设置为1加上导致错误的数据包的DSR源路由选项中的补救字段值。
- Transmit the packet to the next-hop node on the new source route in the packet, using the forwarding procedure described in Section 8.1.5.
- 使用第8.1.5节中描述的转发程序，将数据包发送到数据包中新源路由上的下一跳节点。
As described in Section 8.3.4, the node in this case also SHOULD return a Route Error to the original sender of the packet. If the node chooses to salvage the packet, it SHOULD do so after originating the Route Error.
如第8.3.4节所述，在这种情况下，节点还应向数据包的原始发送方返回路由错误。如果节点选择挽救数据包，那么它应该在发起路由错误后这样做。
When returning any Route Reply in the case in which the 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 Reply packet MUST be obtained by reversing the sequence of hops in the Route Request packet (the source route that is then returned in the Route Reply). This restriction on returning a Route Reply and on salvaging a packet that contains a Route Reply option enables the Route Reply to test this sequence of hops for bidirectionality, preventing the Route Reply from being received by the initiator of the Route Discovery unless each of the hops over which the Route Reply is returned (and thus each of the hops in the source route being returned in the Reply) is bidirectional.
当在网络中使用的MAC协议不能通过单向链路传输单播分组的情况下返回任何路由应答时，必须通过反转路由请求分组中的跳序列来获得用于路由应答分组的源路由（然后在路由应答中返回的源路由）。此对返回路由应答和回收包含路由应答选项的数据包的限制使路由应答能够测试此跳序列的双向性，防止路由发现的发起方接收路由应答，除非返回路由应答的每个跳（因此，应答中返回的源路由中的每个跃点）是双向的。
A node using DSR MAY have multiple network interfaces that support DSR ad hoc network routing. This section describes special packet processing at such nodes.
使用DSR的节点可能具有支持DSR自组织网络路由的多个网络接口。本节描述此类节点上的特殊数据包处理。
A node with multiple network interfaces that support DSR ad hoc network routing MUST have some policy for determining which Route Request packets are forwarded using which network interfaces. For example, a node MAY choose to forward all Route Requests over all network interfaces.
具有支持DSR自组织网络路由的多个网络接口的节点必须具有某些策略，用于确定使用哪些网络接口转发哪些路由请求数据包。例如，节点可以选择通过所有网络接口转发所有路由请求。
When a node with multiple network interfaces that support DSR propagates a Route Request on a network interface other than the one on which it received the Route Request, it MUST in this special case modify the Address list in the Route Request as follows:
当具有支持DSR的多个网络接口的节点在其接收路由请求的网络接口以外的网络接口上传播路由请求时，在这种特殊情况下，它必须修改路由请求中的地址列表，如下所示：
- Append the node's IP address for the incoming network interface.
- 为传入网络接口追加节点的IP地址。
- Append the node's IP address for the outgoing network interface.
- 为传出网络接口追加节点的IP地址。
When a node forwards a packet containing a source route, it MUST assume that the next-hop node is reachable on the incoming network interface, unless the next hop is the address of one of this node's network interfaces, in which case this node MUST skip over this address in the source route and process the packet in the same way as if it had just received it from that network interface, as described in Section 8.1.5.
当节点转发包含源路由的数据包时，它必须假设下一跳节点在传入网络接口上是可到达的，除非下一跳是该节点的一个网络接口的地址，在这种情况下，该节点必须跳过源路由中的该地址，并按照第8.1.5节所述，以与刚从该网络接口接收数据包相同的方式处理数据包。
If a node that previously had multiple network interfaces that support DSR receives a packet sent with a source route specifying a change to a network interface, as described above, that is no longer available, it MAY send a Route Error to the source of the packet without attempting to forward the packet on the incoming network interface, unless the network uses an autoconfiguration mechanism that may have allowed another node to acquire the now unused address of the unavailable network interface.
如果先前具有支持DSR的多个网络接口的节点接收到使用指定网络接口更改的源路由发送的不再可用的数据包（如上所述），则它可以向数据包的源发送路由错误，而不尝试在传入网络接口上转发数据包，除非网络使用自动配置机制，该机制可能允许另一个节点获取不可用网络接口的当前未使用地址。
When a node 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:
当使用DSR的节点希望对包含不包含路由请求选项的DSR报头的数据包进行分段时，它必须执行以下步骤序列：
- Remove the DSR Options header from the packet.
- 从数据包中删除DSR选项标头。
- Fragment the packet using normal IP fragmentation processing [RFC791]. However, when determining the size of each fragment to create from the original packet, the fragment size MUST be reduced by the size of the DSR Options header from the original packet.
- 使用正常的IP分段处理对数据包进行分段[RFC791]。但是，当确定从原始数据包创建的每个片段的大小时，片段大小必须减少原始数据包的DSR Options报头的大小。
- IP-in-IP encapsulate each fragment [RFC2003]. The IP Destination address of the outer (encapsulating) packet MUST be set equal to the IP Destination address of the original packet.
- IP中的IP封装每个片段[RFC2003]。外部（封装）数据包的IP目标地址必须设置为等于原始数据包的IP目标地址。
- Add the DSR Options header from the original packet to each resulting encapsulating packet. If a Source Route header is present in the DSR Options header, increment the Salvage field.
- 将原始数据包中的DSR选项标头添加到每个生成的封装数据包中。如果DSR选项标头中存在源路由标头，则增加补救字段。
When a node using the DSR protocol receives an IP-in-IP encapsulated packet destined to itself, it SHOULD decapsulate the packet [RFC2003] and then process the inner packet according to standard IP reassembly processing [RFC791].
当使用DSR协议的节点接收到目的地为其自身的IP-in-IP封装数据包时，它应解除数据包的封装[RFC2003]，然后根据标准IP重组处理[RFC791]处理内部数据包。
A node implementing the optional DSR flow state extension MUST follow these additional processing steps.
实现可选DSR流状态扩展的节点必须遵循这些附加处理步骤。
When originating any packet to be routed using flow state, a node using DSR flow state MUST do the following:
当使用流状态发起任何要路由的数据包时，使用DSR流状态的节点必须执行以下操作：
- If the route to be used for this packet has never had a DSR flow state established along it (or the existing flow state has expired):
- 如果用于此数据包的路由从未建立过DSR流状态（或现有流状态已过期）：
o Generate a 16-bit Flow ID larger than any unexpired Flow IDs used by this node for this destination. Odd Flow IDs MUST be chosen for "default" flows; even Flow IDs MUST be chosen for non-default flows.
o 生成一个大于此节点为此目标使用的任何未过期流ID的16位流ID。对于“默认”流，必须选择奇数流ID；对于非默认流，必须选择偶数流ID。
o Add a DSR Options header, as described in Section 8.1.2.
o 添加DSR选项标题，如第8.1.2节所述。
o Add a DSR Flow State header, as described in Section 8.6.2.
o 如第8.6.2节所述，添加DSR流量状态标头。
o Initialize the Hop Count field in the DSR Flow State header to 0.
o 将DSR流状态标头中的跃点计数字段初始化为0。
o Set the Flow ID field in the DSR Flow State header to the Flow ID generated in the first step.
o 将DSR Flow State标头中的Flow ID字段设置为第一步中生成的Flow ID。
o Add a Timeout option to the DSR Options header.
o 向DSR选项标题添加超时选项。
o Add a Source Route option after the Timeout option with the route to be used, as described in Section 8.1.3.
o 如第8.1.3节所述，在超时选项之后添加一个源路由选项，该选项包含要使用的路由。
o The source node SHOULD record this flow in its Flow Table.
o 源节点应在其流表中记录此流。
o If this flow is recorded in the Flow Table, the TTL in this Flow Table entry MUST be set to be the TTL of this flow establishment packet.
o 如果此流记录在流表中，则此流表条目中的TTL必须设置为此流建立数据包的TTL。
o If this flow is recorded in the Flow Table, the timeout in this Flow Table entry MUST be set to a value no less than the value specified in the Timeout option.
o 如果此流记录在流表中，则此流表条目中的超时值必须设置为不小于超时选项中指定的值。
- If the route to be used for this packet has had DSR flow state established along it, but has not been established end-to-end:
- 如果要用于此数据包的路由已沿其建立DSR流状态，但尚未建立端到端：
o Add a DSR Options header, as described in Section 8.1.2.
o 添加DSR选项标题，如第8.1.2节所述。
o Add a DSR Flow State header, as described in Section 8.6.2.
o 如第8.6.2节所述，添加DSR流量状态标头。
o Initialize the Hop Count field in the DSR Flow State header to 0.
o 将DSR流状态标头中的跃点计数字段初始化为0。
o The Flow ID field of the DSR Flow State header SHOULD be the Flow ID previously used for this route. If it is not, the steps for sending packets along never-before-established routes above MUST be followed in place of these.
o DSR Flow State标头的Flow ID字段应该是以前用于此路由的Flow ID。如果不是，则必须按照上述从未建立过的路由发送数据包的步骤来代替这些步骤。
o Add a Timeout option to the DSR Options header, setting the Timeout to a value not greater than the timeout remaining for this flow in the Flow Table.
o 向DSR Options标头添加超时选项，将超时设置为不大于流表中此流剩余超时的值。
o Add a Source Route option after the Timeout option with the route to be used, as described in Section 8.1.3.
o 如第8.1.3节所述，在超时选项之后添加一个源路由选项，该选项包含要使用的路由。
o If the IP TTL is not equal to the TTL specified in the Flow Table, the source node MUST set a flag to indicate that this flow cannot be used as default.
o 如果IP TTL不等于流表中指定的TTL，则源节点必须设置一个标志，指示此流不能用作默认值。
- If the route the node wishes to use for this packet has been established as a flow end-to-end and is not the default flow:
- 如果节点希望用于此数据包的路由已建立为端到端的流，并且不是默认流：
o Add a DSR Flow State header, as described in Section 8.6.2.
o 如第8.6.2节所述，添加DSR流量状态标头。
o Initialize the Hop Count field in the DSR Flow State header to 0.
o 将DSR流状态标头中的跃点计数字段初始化为0。
o The Flow ID field of the DSR Flow State header SHOULD be set to the Flow ID previously used for this route. If it is not, the steps for sending packets along never-before-established routes above MUST be followed in place of these.
o DSR Flow State标头的Flow ID字段应设置为以前用于此路由的Flow ID。如果不是，则必须按照上述从未建立过的路由发送数据包的步骤来代替这些步骤。
o If the next hop requires a network-layer acknowledgement for Route Maintenance, 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 如果下一跳需要网络层确认以进行路由维护，请添加DSR选项报头（如第8.1.2节所述）和确认请求选项（如第8.3.3节所述）。
o A DSR Options header SHOULD NOT be added to a packet, unless it is added to carry an Acknowledgement Request option, in which case:
o DSR Options报头不应添加到数据包中，除非添加它以携带确认请求选项，在这种情况下：
+ A Source Route option in the DSR Options header SHOULD NOT be added.
+ 不应在DSR选项标头中添加源路由选项。
+ If a Source Route option in the DSR Options header is added, the steps for sending packets along flows not yet established end-to-end MUST be followed in place of these.
+ 如果在DSR选项报头中添加了源路由选项，则必须遵循沿尚未建立端到端的流发送数据包的步骤来代替这些步骤。
+ A Timeout option SHOULD NOT be added.
+ 不应添加超时选项。
+ If a Timeout option is added, it MUST specify a timeout not greater than the timeout remaining for this flow in the Flow Table.
+ 如果添加了超时选项，则必须在流表中指定不大于此流剩余超时的超时。
- If the route the node wishes to use for this packet has been established as a flow end-to-end and is the current default flow:
- 如果节点希望用于此数据包的路由已建立为端到端的流，并且是当前默认流：
o If the IP TTL is not equal to the TTL specified in the Flow Table, the source node MUST follow the steps above for sending a packet along a non-default flow that has been established end-to-end in place of these steps.
o 如果IP TTL不等于流表中指定的TTL，则源节点必须遵循上述步骤，以沿已建立的端到端非默认流发送数据包，以代替这些步骤。
o If the next hop requires a network-layer acknowledgement for Route Maintenance, the sending node 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 如果下一跳需要网络层确认以进行路由维护，则发送节点必须添加DSR选项报头和确认请求选项，如第8.3.3节所述。发送节点不得向该标头添加任何其他选项。
o A DSR Options header SHOULD NOT be added, except as specified in the previous step. If one is added in a way inconsistent with the previous step, the source node MUST follow the steps above for sending a packet along a non-default flow that has been established end-to-end in place of these steps.
o 除非在上一步中指定，否则不应添加DSR选项标头。如果以与前一步骤不一致的方式添加了一个数据包，则源节点必须遵循上述步骤，以便沿着已建立的端到端的非默认流发送数据包，以代替这些步骤。
A node originating a packet adds a DSR Flow State header to the packet, if necessary, to carry information needed by the routing protocol. A packet MUST NOT contain more than one DSR Flow State header. A DSR Flow State header is added to a packet by performing the following sequence of steps:
发起分组的节点在必要时向分组添加DSR流状态报头，以承载路由协议所需的信息。一个数据包不能包含多个DSR流状态头。通过执行以下步骤序列，将DSR流状态报头添加到数据包中：
- Insert a DSR Flow State header after the IP header and any Hop-by-Hop Options header that may already be in the packet, but before any other header that may be present.
- 在IP报头和任何可能已经在数据包中的逐跳选项报头之后，但在可能存在的任何其他报头之前插入DSR流状态报头。
- Set the Next Header field of the DSR Flow State header to the Next Header field of the previous header (either an IP header or a Hop-by-Hop Options header).
- 将DSR流状态标头的下一个标头字段设置为上一个标头的下一个标头字段（IP标头或逐跳选项标头）。
- Set the Flow (F) bit in the DSR Flow State header to 1.
- 将DSR流状态标头中的流（F）位设置为1。
- Set the Protocol field of the IP header to the protocol number assigned for DSR (48).
- 将IP头的协议字段设置为为DSR分配的协议编号（48）。
This section describes processing only for packets that are sent to this processing node as the next-hop node; that is, when the MAC-layer destination address is the MAC address of this node. Otherwise, the process described in Sections 8.6.5 should be followed.
本节描述仅对发送到此处理节点作为下一跳节点的数据包的处理；即，当MAC层目的地址是该节点的MAC地址时。否则，应遵循第8.6.5节中描述的过程。
The flow along which a packet is being sent is considered to be in the Flow Table if the triple (IP Source Address, IP Destination Address, Flow ID) has an unexpired entry in this node's Flow Table.
如果三元组（IP源地址、IP目的地地址、流ID）在该节点的流表中有一个未过期的条目，则发送数据包的流被视为在流表中。
When a node using DSR flow state receives a packet, it MUST follow the following steps for processing:
当使用DSR流状态的节点接收到数据包时，必须遵循以下步骤进行处理：
- If a DSR Flow State header is present, increment the Hop Count field.
- 如果存在DSR流状态标头，则增加跃点计数字段。
- In addition, if a DSR Flow State header is present, then if the triple (IP Source Address, IP Destination Address, Flow ID) is in this node's Automatic Route Shortening Table and the packet is listed in the entry, then the node MAY send a gratuitous Route Reply as described in Section 4.4, subject to the rate limiting specified therein. This gratuitous Route Reply gives the route by which the packet originally reached this node. Specifically, the node sending the gratuitous Route Reply constructs the route to return in the Route Reply as follows:
- 此外，如果存在DSR流状态报头，则如果该三元组（IP源地址、IP目的地址、流ID）在该节点的自动路由缩短表中，并且该数据包列在条目中，则该节点可发送第4.4节所述的免费路由回复，但须遵守其中规定的速率限制。这个免费的路由应答给出了数据包最初到达这个节点的路由。具体而言，发送免费路由应答的节点在路由应答中构造要返回的路由，如下所示：
o Let k = (packet Hop Count) - (table Hop Count), where packet Hop Count is the value of the Hop Count field in this received packet, and table Hop Count is the Hop Count value stored for this packet in the corresponding entry in this node's Automatic Route Shortening Table.
o 设k=（数据包跃点计数）-（表跃点计数），其中数据包跃点计数是该接收数据包中跃点计数字段的值，表跃点计数是该节点的自动路由缩短表中相应条目中存储的该数据包的跃点计数值。
o Copy the complete source route for this flow from the corresponding entry in the node's Flow Table.
o 从节点流表中的相应条目复制此流的完整源路由。
o Remove from this route the k hops immediately preceding this node in the route, since these are the hops "skipped over" by the packet as recorded in the Automatic Route Shortening Table entry.
o 从该路由中删除路由中紧靠该节点前面的k个跃点，因为这些跃点是自动路由缩短表条目中记录的数据包“跳过”的跃点。
- Process each of the DSR options within the DSR Options header in order:
- 按顺序处理DSR选项标题中的每个DSR选项：
o On receiving a Pad1 or PadN option, skip over the option.
o 收到Pad1或PadN选项时，跳过该选项。
o On receiving a Route Request for which this node is the destination, remove the option and return a Route Reply as specified in Section 8.2.2.
o 在接收到此节点作为目的地的路由请求时，删除该选项并返回第8.2.2节中规定的路由回复。
o On receiving a broadcast Route Request that this node has not previously seen for which this node is not the destination, append this node's incoming interface address to the Route Request, continue propagating the Route Request as specified in Section 8.2.2, pass the payload, if any, to the network layer, and stop processing.
o 在接收到该节点之前未看到的广播路由请求（该节点不是目的地）时，将该节点的传入接口地址附加到路由请求，按照第8.2.2节的规定继续传播路由请求，将有效负载（如果有）传递到网络层，并停止处理。
o On receiving a Route Request that this node has previously seen for which this node is not the destination, discard the packet and stop processing.
o 在接收到该节点以前看到的路由请求（该节点不是目的地）时，丢弃该数据包并停止处理。
o On receiving any Route Request, add appropriate links to the Route Cache, as specified in Section 8.2.2.
o 收到任何路由请求后，按照第8.2.2节的规定，向路由缓存添加适当的链接。
o On receiving a Route Reply for which this node is the initiator, remove the Route Reply from the packet and process it as specified in Section 8.2.6.
o 在接收到此节点作为发起方的路由应答时，从数据包中删除路由应答，并按照第8.2.6节的规定对其进行处理。
o On receiving any Route Reply, add appropriate links to the Route Cache, as specified in Section 8.2.6.
o 收到任何路由回复后，按照第8.2.6节的规定，向路由缓存添加适当的链接。
o On receiving any Route Error of type NODE_UNREACHABLE, remove appropriate links to the Route Cache, as specified in Section 8.3.5.
o 根据第8.3.5节的规定，在收到任何类型为NODE_UNREACHABLE的路由错误时，删除到路由缓存的适当链接。
o On receiving a Route Error of type NODE_UNREACHABLE that this node is the Error Destination Address of, remove the Route Error from the 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 Flow Table any flows using the link from Error Source Address to Unreachable Node.
o 在接收到类型为NODE_UNREACHABLE的路由错误（该节点是其错误目的地地址）时，从数据包中移除路由错误，并按照第8.3.5节的规定进行处理。它还必须停止沿着使用从错误源地址到不可访问节点的链接的任何流发起数据包，并且它可以从其流表中删除使用从错误源地址到不可访问节点的链接的任何流。
o On receiving a Route Error of type UNKNOWN_FLOW that this node is not the Error Destination Address of, the node checks if the Route Error corresponds to a flow in its Flow Table. If it does not, the node silently discards the Route Error; otherwise, it forwards the packet to the expected previous hop of the corresponding flow. If Route 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 Route Error; otherwise, it sends the Error as if it were originating it, as described in Section 8.1.1.
o 当接收到此节点不是错误目标地址的类型为UNKNOWN_FLOW的路由错误时，节点将检查路由错误是否对应于其流表中的流。如果没有，则节点会自动放弃路由错误；否则，它将数据包转发到相应流的预期前一跳。如果路由维护无法确认前一跳的可达性，则节点检查网络接口是否需要双向链路进行操作。如果是这样，则节点会自动放弃路由错误；否则，按照第8.1.1节所述，它将发送错误，就像它是错误的始发者一样。
o On receiving a Route Error of type UNKNOWN_FLOW that this node is the Error Destination Address of, remove the Route Error from the 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 在接收到此节点是错误目的地地址的类型为UNKNOWN_FLOW的路由错误时，从数据包中删除路由错误，并将三元组（错误目的地地址、原始IP目的地地址、流ID）指定的流标记为未建立端到端。
o On receiving a Route Error of type DEFAULT_FLOW_UNKNOWN that this node is not the Error Destination Address of, the node checks if the Route Error corresponds to a flow in its Default Flow Table. If it does not, the node silently discards the Route Error; otherwise, it forwards the packet to the expected previous hop of the corresponding flow. If Route 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 Route Error; otherwise, it sends the Error as if it were originating it, as described in Section 8.1.1.
o 当接收到类型为DEFAULT_FLOW_UNKNOWN的路由错误（该节点不是的错误目标地址）时，节点将检查路由错误是否对应于其默认流表中的流。如果没有，则节点会自动放弃路由错误；否则，它将数据包转发到相应流的预期前一跳。如果路由维护无法确认前一跳的可达性，则节点检查网络接口是否需要双向链路进行操作。如果是这样，则节点会自动放弃路由错误；否则，按照第8.1.1节所述，它将发送错误，就像它是错误的始发者一样。
o On receiving a Route Error of type DEFAULT_FLOW_UNKNOWN that this node is the Error Destination Address of, remove the Route Error from the packet and mark the default flow between the Error Destination Address and the Original IP Destination Address as not having been established end-to-end.
o 在接收到类型为DEFAULT_FLOW_UNKNOWN的路由错误（该节点是的错误目标地址）时，从数据包中删除路由错误，并将错误目标地址和原始IP目标地址之间的默认流标记为未建立端到端。
o On receiving an Acknowledgement Request option, the receiving node removes the Acknowledgement Request option and replies to the previous hop with an Acknowledgement option. If the previous hop cannot be determined, the Acknowledgement Request option is discarded, and processing continues.
o 在接收到确认请求选项时，接收节点移除确认请求选项，并使用确认选项回复上一跳。如果无法确定上一个跃点，则放弃确认请求选项，并继续处理。
o On receiving an Acknowledgement option, the receiving node removes the Acknowledgement option and processes it.
o 在接收到确认选项时，接收节点移除确认选项并对其进行处理。
o On receiving any Acknowledgement option, add the appropriate link to the Route Cache, as specified in Section 8.1.4.
o 收到任何确认选项后，按照第8.1.4节的规定，向路由缓存添加适当的链接。
o On receiving any Source Route option, add appropriate links to the Route Cache, as specified in Section 8.1.4.
o 收到任何源路由选项后，按照第8.1.4节的规定，向路由缓存添加适当的链接。
o On receiving a Source Route option, if no DSR Flow State header is present, if the flow this packet is being sent along is in the Flow Table, or if no Timeout option preceded the Source Route option in this DSR Options header, process it as specified in Section 8.1.4. Stop processing this packet unless the last address in the Source Route option is an address of this node.
o 在接收到源路由选项时，如果不存在DSR流状态标头，如果此数据包所发送的流在流表中，或者如果此DSR选项标头中的源路由选项之前没有超时选项，则按照第8.1.4节中的规定对其进行处理。停止处理此数据包，除非源路由选项中的最后一个地址是此节点的地址。
o On receiving a Source Route option in a packet with a DSR Flow State header, if the Flow ID specified in the DSR Flow State header is not in the Flow Table, add the flow to the Flow Table, setting the Timeout value to a value not greater than the Timeout field of the Timeout option in this header. If no Timeout option preceded the Source Route option in this header, the flow MUST NOT be added to the Flow Table.
o 在接收到具有DSR流状态标头的数据包中的源路由选项时，如果DSR流状态标头中指定的流ID不在流表中，则将流添加到流表中，将超时值设置为不大于此标头中超时选项的超时字段的值。如果此标头中的源路由选项前面没有超时选项，则不能将流添加到流表中。
If the Flow ID is odd and larger than any unexpired, odd Flow IDs for this (IP Source Address, IP Destination Address), it is set to be default in the Default Flow ID Table.
如果流ID为奇数且大于此（IP源地址、IP目标地址）的任何未过期奇数流ID，则在默认流ID表中将其设置为默认值。
Then process the Route option as specified in Section 8.1.4. Stop processing this packet unless the last address in the Source Route option is an address of this node.
然后按照第8.1.4节的规定处理路线选项。停止处理此数据包，除非源路由选项中的最后一个地址是此节点的地址。
o On receiving a Timeout option, check if this packet contains a DSR Flow State header. If this packet does not contain a DSR Flow State header, discard the DSR option. Otherwise, record the Timeout value in the option for future reference. The value recorded SHOULD be discarded when the node has finished processing this DSR Options header. If the flow that this packet is being sent along is in the Flow Table, it MAY set the flow to time out no more than Timeout seconds in the future.
o 在收到超时选项时，检查此数据包是否包含DSR流状态标头。如果此数据包不包含DSR流状态标头，则放弃DSR选项。否则，请在选项中记录超时值以供将来参考。当节点完成处理此DSR Options标头时，应丢弃记录的值。如果发送此数据包的流在流表中，则它可能会将流设置为在未来超时不超过超时秒。
o On receiving a Destination and Flow ID option, if the IP Destination Address is not an address of this node, forward the packet according to the Flow ID, as described in Section 8.6.4, and stop processing this packet.
o 在接收到目的地和流ID选项时，如果IP目的地地址不是该节点的地址，则按照第8.6.4节所述，根据流ID转发数据包，并停止处理该数据包。
o On receiving a Destination and Flow ID option, if the IP Destination Address is an address of this node, set the IP Destination Address to the New IP Destination Address specified in the option and set the Flow ID to the New Flow Identifier. Then remove the Destination and Flow ID option from the packet and continue processing.
o 在接收到目的地和流ID选项时，如果IP目的地地址是此节点的地址，则将IP目的地地址设置为该选项中指定的新IP目的地地址，并将流ID设置为新的流标识符。然后从数据包中删除Destination和Flow ID选项并继续处理。
- If the IP Destination Address is an address of this node, remove the DSR Options header, if any, pass the packet up the network stack, and stop processing.
- 如果IP目标地址是此节点的地址，请删除DSR Options头（如果有），将数据包向上传递到网络堆栈，并停止处理。
- If there is still a DSR Options header containing no options, remove the DSR Options header.
- 如果DSR Options标头仍不包含任何选项，请删除DSR Options标头。
- If there is still a DSR Flow State header, forward the packet according to the Flow ID, as described in Section 8.6.4.
- 如果仍然存在DSR流状态报头，则根据流ID转发数据包，如第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) pair:
- 如果既没有DSR选项标头，也没有DSR流状态标头，但（IP源地址、IP目标地址）对的默认流表中有一个条目：
o If the IP TTL is not equal to the TTL expected in the Flow Table, insert a DSR Flow State header, setting the Hop Count equal to the Hop Count of this node, and the Flow ID equal to the default Flow ID found in the Default Flow Table, and forward this packet according to the Flow ID, as described in Section 8.6.4.
o 如果IP TTL不等于流表中预期的TTL，则插入DSR流状态标头，将跳数设置为该节点的跳数，流ID设置为默认流表中的默认流ID，并根据流ID转发该数据包，如第8.6.4节所述。
o Otherwise, follow the steps for forwarding the packet using Flow IDs described in Section 8.6.4, but taking the Flow ID to be the default Flow ID found in the Default Flow Table.
o 否则，请遵循使用第8.6.4节中描述的流ID转发数据包的步骤，但将流ID作为默认流表中的默认流ID。
- If there is no DSR Options header and no DSR Flow State header and no default flow can be found, the node returns a Route Error of type DEFAULT_FLOW_UNKNOWN to the IP Source Address, specifying the IP Destination Address as the Original IP Destination in the type-specific field.
- 如果没有DSR选项标头，也没有DSR流状态标头，并且找不到默认流，则节点将返回IP源地址未知的默认流类型的路由错误，并在特定类型字段中将IP目标地址指定为原始IP目标。
To forward a packet using Flow IDs, a node MUST follow the following sequence of steps:
要使用流ID转发数据包，节点必须遵循以下步骤顺序：
- If the triple (IP Source Address, IP Destination Address, Flow ID) is not in the Flow Table, return a Route Error of type UNKNOWN_FLOW.
- 如果三元组（IP源地址、IP目标地址、流ID）不在流表中，则返回类型为UNKNOWN\u Flow的路由错误。
- If a network-layer acknowledgement is required for Route Maintenance for the next hop, the node MUST include an Acknowledgement Request option as specified in Section 8.3.3. If no DSR Options header is in the packet in which the Acknowledgement Request option is to be added, it MUST be included, as described in Section 8.1.2, except that it MUST be added after the DSR Flow State header, if one is present.
- 如果下一跳的路由维护需要网络层确认，则节点必须包括第8.3.3节中规定的确认请求选项。如果要添加确认请求选项的数据包中没有DSR Options报头，则必须包括它，如第8.1.2节所述，除非它必须添加在DSR流状态报头之后（如果有）。
- Attempt to transmit this packet to the next hop as specified in the Flow Table, performing Route Maintenance to detect broken routes.
- 尝试将此数据包传输到流表中指定的下一跳，执行路由维护以检测断开的路由。
This section describes processing only for packets that have MAC destinations other than this processing node. Otherwise, the process described in Section 8.6.3 should be followed.
本节描述仅处理具有除此处理节点以外的MAC目的地的数据包。否则，应遵循第8.6.3节中描述的过程。
When a node using DSR flow state promiscuously overhears a packet, it SHOULD follow the following steps for processing:
当使用DSR流状态的节点无意中听到数据包时，应遵循以下步骤进行处理：
- If the packet contains a DSR Flow State header, and if the triple (IP Source Address, IP Destination Address, Flow ID) is in the Flow Table and the Hop Count is less than the Hop Count in the flow's entry, the node MAY retain the packet in the Automatic Route Shortening Table. If it can be determined that this Flow ID has been recently used, the node SHOULD retain the packet in the Automatic Route Shortening Table.
- 如果分组包含DSR流状态报头，并且如果三元组（IP源地址、IP目的地地址、流ID）在流表中并且跳数小于流条目中的跳数，则节点可以将分组保留在自动路由缩短表中。如果可以确定该流ID最近已被使用，则节点应在自动路由缩短表中保留该数据包。
- If the packet contains neither a DSR Flow State header nor a Source Route option and a Default Flow ID can be found in the Default Flow Table for the (IP Source Address, IP Destination Address), and if the IP TTL is greater than the TTL in the Flow Table for the default flow, the node MAY retain the packet in the Automatic Route Shortening Table. If it can be determined that this Flow ID has been used recently, the node SHOULD retain the packet in the Automatic Route Shortening Table.
- 如果数据包既不包含DSR流状态报头也不包含源路由选项，并且可以在（IP源地址、IP目的地地址）的默认流表中找到默认流ID，并且如果IP TTL大于默认流的流表中的TTL，则节点可以将数据包保留在自动路由缩短表中。如果可以确定该流ID最近已被使用，则节点应在自动路由缩短表中保留该数据包。
8.6.6. Operation Where the Layer below DSR Decreases the IP TTL Non-uniformly
8.6.6. DSR下面的层不均匀地降低IP TTL的操作
Some nodes may use an IP tunnel as a DSR 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.
一些节点可以使用IP隧道作为DSR跳。如果沿着此IP隧道发送的不同数据包可以采用不同的路由，则对于不同的数据包，此链路上IP TTL的减少可能不同。当与默认路由一起使用时，这会阻止自动路由缩短和环路检测功能正常工作。
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, indicating the correct Hop Count and Flow ID.
不使用源路由选项将数据包转发到具有不可预测TTL更改的链路上的节点必须确保存在DSR流状态头，指示正确的跃点计数和流ID。
Nodes salvaging packets MUST remove the DSR Flow State header, if present.
回收数据包的节点必须删除DSR流状态头（如果存在）。
Anytime this document refers to the Salvage field in the Source Route option, packets without a Source Route option are considered to have the value zero in the Salvage field.
每当本文档引用源路由选项中的补救字段时，不带源路由选项的数据包在补救字段中被视为值为零。
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.
任何DSR实现都必须支持以下配置变量，并且必须支持一种机制，使系统管理能够修改这些变量的值。特定变量名称仅用于演示目的，只要实现的外部行为与本文档中描述的一致，则不要求实现将这些名称用于配置变量。
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 protocol with RTS and CTS [IEEE80211, BROCH98].
对于下面的每个配置变量，将指定默认值以简化配置。具体而言，以下给出的默认值是为运行在2 Mbps IEEE 802.11网络接口上的DSR网络选择的，该网络使用带有RTS和CTS的分布式协调功能（DCF）MAC协议[IEEE80211，BROCH98]。
DiscoveryHopLimit 255 hops
发现人限制255跳
BroadcastJitter 10 milliseconds
广播抖动10毫秒
RouteCacheTimeout 300 seconds
RouteCache超时300秒
SendBufferTimeout 30 seconds
发送缓冲超时30秒
RequestTableSize 64 nodes RequestTableIds 16 identifiers MaxRequestRexmt 16 retransmissions MaxRequestPeriod 10 seconds RequestPeriod 500 milliseconds NonpropRequestTimeout 30 milliseconds
RequestTableSize 64个节点RequestTableIds 16个标识符MaxRequestRexmt 16重新传输MaxRequestPeriod 10秒RequestPeriod 500毫秒NonpropRequestTimeout 30毫秒
RexmtBufferSize 50 packets
RexmtBufferSize 50个数据包
MaintHoldoffTime 250 milliseconds
MaintHoldoffTime 250毫秒
MaxMaintRexmt 2 retransmissions
MaxMaintRexmt 2重传
TryPassiveAcks 1 attempt PassiveAckTimeout 100 milliseconds
TryPassiveAcks 1次尝试被动超时100毫秒
GratReplyHoldoff 1 second
GratReplyHoldoff 1秒
In addition, the following protocol constant MUST be supported by any implementation of the DSR protocol:
此外，DSR协议的任何实现都必须支持以下协议常量：
MAX_SALVAGE_COUNT 15 salvages
最多打捞次数15次
This document specifies the DSR Options header and DSR Flow State header, for which the IP protocol number 48 has been assigned. A single IP protocol number can be used for both header types, since they can be distinguished by the Flow State Header (F) bit in each header.
本文档指定了已分配IP协议编号48的DSR选项标头和DSR流状态标头。两种报头类型都可以使用一个IP协议号，因为它们可以通过每个报头中的流状态报头（F）位来区分。
In addition, this document proposes use of the value "No Next Header" (originally defined for use in IPv6 [RFC2460]) within an IPv4 packet, to indicate that no further header follows a DSR Options header.
此外，本文档建议在IPv4数据包内使用值“无下一个报头”（最初定义为在IPv6[RFC2460]中使用），以指示DSR选项报头后面没有其他报头。
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, the most significant 3 bits (that is, Option Type & 0xE0) encoded as defined in Section 6.1. It is necessary only that 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.
最后，本文档介绍了在DSR选项标题中使用的许多DSR选项，将来可能会定义其他新的DSR选项。每个选项都需要一个唯一的选项类型值，即按照第6.1节中的定义编码的最高有效3位（即选项类型&0xE0）。只需要每个选项类型值都是唯一的，而不是在这3个最高有效位之后的值的剩余5位中唯一。
Two registries (DSR Protocol Options and DSR Protocol Route Error Types) have been created and contain the initial registrations. Assignment of new values for DSR options will be by Expert Review [RFC2434], with the authors of this document serving as the Designated Experts.
已创建两个注册表（DSR协议选项和DSR协议路由错误类型），其中包含初始注册。DSR选项的新值分配将由专家评审[RFC2434]完成，本文件的作者将担任指定专家。
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.
本文件并未具体解决安全问题。本文档假定所有参与DSR协议的节点都是真诚地这样做的，并且没有恶意破坏网络路由能力的意图。
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 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 [HU02] or Secure Routing Protocol (SRP) [PAPADIMITRATOS02], can resist stronger attacks.
根据威胁模型，可以使用许多不同的机制来保护DSR。例如，在节点妥协是不现实的环境中，并且参与DSR协议的所有节点都有一个共同的目标来激励他们参与协议，节点之间的通信可以在物理信道或链路层加密，以防止外部攻击。加密方法，如Ariadne[HU02]或安全路由协议（SRP）[Papadimitatos02]提供的加密方法，可以抵抗更强的攻击。
As guidance to implementers 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 caches studied in detailed simulations. Use of this design for the Route Cache is recommended in implementations of DSR.
作为对DSR实现者的指导，以下描述概述了DSR路由缓存的可能实现的操作，该实现已被证明优于详细模拟中研究的其他缓存。在DSR的实现中，建议对路由缓存使用这种设计。
This cache, called "Link-MaxLife" [HU00], 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.
该缓存称为“链路MaxLife”[HU00]，是一个链路缓存，因为在路由应答数据包（或从开销数据包的报头中学习）中返回的路由中的每个单独链路（跃点）都被添加到该节点当前网络拓扑视图的统一图形数据结构中，如第4.1节所述。为了在缓存中搜索到某个目标节点的路由，发送节点使用图搜索算法（如著名的Dijkstra最短路径算法）来查找通过图到目标节点的当前最佳路径。
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).
链路缓存的链路MaxLife形式是自适应的，因为缓存中的每个链路都有一个超时，该超时由缓存节点根据其在链路末端观察到的两个节点的过去行为动态确定；此外，当为发送到某个目的地的数据包选择路由时，在到该目的地的等长缓存路由（跳数）中，Link MaxLife选择预期寿命最长（路由中任何链路的最高最小超时）的路由。
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).
具体而言，在Link MaxLife中，路由缓存中的链路超时是根据缓存节点维护的“稳定性表”选择的。节点稳定性表中的每个条目记录另一个节点的地址和表示该节点感知“稳定性”的因子。节点稳定性表中每个其他节点的稳定性初始化为InitStability。当路由缓存中的链路用于路由由该节点发起或回收的数据包时，该链路的两个端点节点中的每一个的稳定性度量增加自该链路上次使用以来的时间量，乘以StabilityIncrFactor（StabilityIncrFactor>=1）；当观察到一条链路断开，从而将该链路从路由缓存中删除时，该链路的两个端点节点的稳定性度量将乘以StabilityDecrafter（StabilityDecrafter<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
当节点将新链路添加到其路由缓存时，该节点在缓存中为该链路分配的生存期等于该链路的两个端点节点中较不“稳定”的一个节点的稳定性，但不允许为链路分配小于MinLifetime的生存期。当在为该节点发起或回收的数据包选择的路由中使用链路时，该链路的生存期至少设置为
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.
当使用Link MaxLife的节点从其路由缓存中为该节点发起或回收的数据包选择路由时，它会选择具有最长预期寿命（路由中任何链路的最高最小超时）的最短长度路由，而不是简单地选择长度最短的任意路由。
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 wireless transmission radius.
以下配置变量用于上述链接MaxLife的描述。特定的变量名仅用于演示目的，实现不需要为这些配置变量使用这些名称。对于下面的每个配置变量，将指定默认值以简化配置。特别是，下面给出的默认值是为DSR网络选择的，其中节点以每无线传输半径12到25秒之间的相对速度移动。
InitStability 25 seconds StabilityIncrFactor 4 StabilityDecrFactor 0.5
初始稳定性25秒稳定性增量因子4稳定性衰减因子0.5
MinLifetime 1 second UseExtends 120 seconds
最小使用寿命1秒延长120秒
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:
在设计DSR时，我们必须确定在协议层次结构中的哪一层实现adhoc网络路由。我们考虑了两种不同的选择：链路层（ISO层2）的路由和网络层（ISO层3）的路由。最初，出于以下几个原因，我们选择在链路层进行路由：
- 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 [RFC791], IPv6 [RFC2460], and IPX [TURNER90] nodes.
- 实际上，在链路层运行DSR协议可以最大限度地增加可参与ad hoc网络的移动节点数量。例如，该协议可以在IPv4[RFC791]、IPv6[RFC2460]和IPX[TURNER90]节点之间同样好地路由。
- Historically [JOHNSON94, JOHNSON96a], DSR grew from our contemplation of a multi-hop propagating version of the Internet's Address Resolution Protocol (ARP) [RFC826], as well as from the routing mechanism used in IEEE 802 source routing bridges [PERLMAN92]. These are layer 2 protocols.
- 从历史上看[Johnson 94，Johnson 96a]，DSR的发展源于我们对互联网地址解析协议（ARP）[RFC826]的多跳传播版本的设想，以及IEEE 802源路由桥[PERLMAN92]中使用的路由机制。这些是第二层协议。
- Technically, we designed DSR to be simple enough that it could be implemented directly in the firmware inside wireless network interface cards [JOHNSON94, JOHNSON96a], 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.
- 从技术上讲，我们设计的DSR足够简单，可以直接在无线网络接口卡[Johnson 94，Johnson 96A]内的固件中实现，远低于移动节点内的第3层软件。我们看到DSR在固定基站周围的移动节点云中运行的巨大潜力，DSR将透明地将覆盖范围扩展到这些节点。由于距离、衰落或本地干扰源等因素而无法与基站通信的移动节点随后可通过其对等方到达基站。
Ultimately, however, we decided to specify and to implement [MALTZ99b] 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.
然而，最终，我们决定将[MALTZ99b]DSR指定为第3层协议，并将其实现为第3层协议，因为这是我们能够实际支持具有不同类型的多个网络接口的节点形成一个自组织网络的唯一一层。
The initial design of the DSR protocol, including DSR's basic Route Discovery and Route Maintenance mechanisms, was first published in December 1994 [JOHNSON94]; significant additional design details and initial simulation results were published in early 1996 [JOHNSON96a].
DSR协议的初始设计，包括DSR的基本路由发现和路由维护机制，于1994年12月首次发布[Johnson 94]；重要的附加设计细节和初始模拟结果于1996年初发布[Johnson 96a]。
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 [NS-2, BROCH98] and performed extensive simulations of DSR using ns-2 (e.g., [BROCH98, MALTZ99a]). We have also conducted evaluations of the different caching strategies in this document [HU00].
从那时起，通过额外的详细模拟对DSR协议进行了广泛的研究。特别是，我们在ns-2网络模拟器[ns-2，BROCH98]中实现了DSR，并使用ns-2（例如[BROCH98，MALTZ99a]）对DSR进行了广泛的模拟。我们还在本文档[HU00]中对不同的缓存策略进行了评估。
We have also implemented the DSR protocol under the FreeBSD 2.2.7 operating system running on Intel x86 platforms. FreeBSD [FREEBSD] 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 document.
我们还在英特尔x86平台上运行的FreeBSD 2.2.7操作系统下实施了DSR协议。FreeBSD（FreeBSD）是基于各种免费软件，包括4.4个BSD Lite，来自加利福尼亚大学，伯克利。对于我们使用它的环境，此实现在功能上等同于本文档中指定的DSR协议版本。
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 the Defense Advanced Research Projects Agency (DARPA). A complete description of the testbed is available [MALTZ99b, MALTZ00, MALTZ01].
在1998年8月至1999年2月的7个月内，我们设计并实施了一个全面的物理测试平台，以便能够在实际通信负载下的主动移动adhoc网络中评估现场adhoc网络性能。1999年2月的最后一周和3月的第一周，包括向我们的许多赞助者和合作伙伴，包括朗讯科技公司、贝尔大西洋公司和国防高级研究计划局（DARPA），展示了这个试验台。可获得试验台的完整说明[MALTZ99b、MALTZ00、MALTZ01]。
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 document and will be added later in a separate document on top of the base protocol specified here.
此后，我们将DSR的这个实现移植到FreeBSD3.3中，并为DSR添加了服务质量（QoS）支持的初步版本。2000年7月演示了DSR的这一修改版本。这些QoS功能不包括在本文档中，稍后将在此处指定的基本协议之上的单独文档中添加。
DSR has also been implemented under Linux by Alex Song at the University of Queensland, Australia [SONG01]. This implementation supports the Intel x86 PC platform and the Compaq iPAQ.
DSR也已经在Linux下由澳大利亚昆士兰大学的Alex Song [SON01]实现。此实现支持Intel x86 PC平台和Compaq iPAQ。
The Network and Telecommunications Research Group at Trinity College, Dublin, have implemented a version of DSR on Windows CE.
都柏林三一学院的网络和电信研究小组已经在Windows CE上实现了DSR的一个版本。
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.
微软研究院已经在Windows XP上实现了DSR的一个版本，并在超过15个节点的试验台上使用了它。一些机器将此实现用作访问Internet的主要手段。
Several other independent groups have also used DSR as a platform for their own research, or as a basis of comparison between ad hoc network routing protocols.
其他几个独立的研究小组也将DSR作为自己研究的平台，或作为比较adhoc网络路由协议的基础。
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 [HU01].
FreeBSD 3.3中实现了可选DSR流状态扩展的初步版本。2000年7月演示了DSR的这一修改版本。DSR流动状态扩展也已通过模拟[HU01]进行了广泛评估。
Acknowledgements
致谢
The protocol described in this document has been designed and developed within the Monarch Project, a long-term 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 [JOHNSON96b, MONARCH].
本文件中描述的协议是在Monar项目中设计和开发的，该项目是莱斯大学（之前在卡内基梅隆大学）的一个长期研究项目，该项目正在开发自适应网络协议和协议接口，以实现真正无缝的无线和移动节点网络[Johnson 96B，Monar]。
The authors would like to acknowledge the substantial contributions of Josh Broch in helping to design, simulate, and implement the DSR protocol. We thank him for his contributions to earlier versions of this document.
作者要感谢Josh Broch在帮助设计、模拟和实现DSR协议方面做出的重大贡献。我们感谢他对本文件早期版本的贡献。
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.
我们还要感谢卡内基梅隆大学罗伯特·V·巴伦的帮助。Bob将我们的DSR实现从FreeBSD2.2.7移植到FreeBSD3.3。
Many valuable suggestions came from participants in the IETF process. We would particularly like to acknowledge Fred Baker, who provided extensive feedback on a previous version of this document, as well as the working group chairs, for their suggestions of previous versions of the document.
IETF过程的参与者提出了许多有价值的建议。我们要特别感谢弗雷德·贝克（Fred Baker），他就本文件的前一版本提供了广泛的反馈，并感谢工作组主席对本文件前一版本的建议。
Normative References
规范性引用文件
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]Postel，J.，“互联网协议”，标准5，RFC7911981年9月。
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC792]Postel，J.，“互联网控制消息协议”，STD 5，RFC 792，1981年9月。
[RFC826] Plummer, David C., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982.
[RFC826]Plummer，David C.，“以太网地址解析协议：或将网络协议地址转换为48位以太网地址，以便在以太网硬件上传输”，STD 37，RFC 826，1982年11月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，“互联网主机的要求-通信层”，标准3，RFC 1122，1989年10月。
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. See also http://www.iana.org/numbers.html.
[RFC1700]Reynolds，J.和J.Postel，“分配的数字”，标准2，RFC 1700，1994年10月。另见http://www.iana.org/numbers.html.
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. RFC 2003, October 1996.
[RFC2003]Perkins，C.，“IP内的IP封装”，RFC 2003，1996年10月。RFC 2003，1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
Informative References
资料性引用
[BANTZ94] David F. Bantz and Frederic J. Bauchot. Wireless LAN Design Alternatives. IEEE Network, 8(2):43-53, March/April 1994.
[BANTZ94]大卫·F·班茨和弗雷德里克·J·鲍肖特。无线局域网设计方案。IEEE网络，8（2）：43-531994年3月/4月。
[BHARGHAVAN94] 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. ACM, August 1994.
[Bharghavan 94]Vaduvur Bharghavan、Alan Demers、Scott Shenker和Lixia Zhang。MACAW：一种用于无线局域网的媒体访问协议。ACM SIGCOMM'94会议记录，第212-225页。ACM，1994年8月。
[BROCH98] 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. ACM/IEEE, October 1998.
[BROCH98]Josh Broch、David A.Maltz、David B.Johnson、Yih Chun Hu和Jorjeta Jetcheva。多跳无线adhoc网络路由协议的性能比较。第四届ACM/IEEE移动计算和网络国际年会论文集，第85-97页。ACM/IEEE，1998年10月。
[CLARK88] David D. Clark. The Design Philosophy of the DARPA Internet Protocols. In Proceedings of the ACM SIGCOMM '88 Conference, pages 106-114. ACM, August 1988.
大卫·D·克拉克。DARPA互联网协议的设计理念。《ACM SIGCOMM’88会议记录》，第106-114页。ACM，1988年8月。
[FREEBSD] The FreeBSD Project. Project web page available at http://www.freebsd.org/.
[FREEBSD]FREEBSD项目。项目网页可在http://www.freebsd.org/.
[HU00] 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. ACM, August 2000.
[HU00]胡怡君和大卫·B·约翰逊。无线adhoc网络按需路由协议中的缓存策略。第六届ACM移动计算和网络国际年会论文集。ACM，2000年8月。
[HU01] Yih-Chun Hu and David B. Johnson. Implicit Source Routing in On-Demand Ad Hoc Network Routing. In Proceedings of the Second Symposium on Mobile Ad Hoc Networking and Computing (MobiHoc 2001), pages 1-10, October 2001.
[HU01]胡怡君和大卫·B·约翰逊。按需adhoc网络路由中的隐式源路由。《第二届移动adhoc网络和计算研讨会论文集》（MobiHoc 2001），第1-10页，2001年10月。
[HU02] Yih-Chun Hu, Adrian Perrig, and David B. Johnson. Ariadne: A Secure On-Demand Routing Protocol for Ad Hoc Networks. In Proceedings of the Eighth Annual International Conference on Mobile Computing and Networking (MobiCom 2002), pages 12-23, September 2002.
[HU02]胡怡君、佩里格和大卫·B·约翰逊。Ariadne：一种用于adhoc网络的安全按需路由协议。《第八届移动计算和网络国际年会会议记录》（MobiCom 2002），第12-23页，2002年9月。
[IEEE80211] 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.
[IEEE80211]IEEE计算机协会局域网标准委员会。无线局域网介质访问控制（MAC）和物理层（PHY）规范，IEEE标准802.11-1997。电气和电子工程师学会，纽约，纽约，1997年。
[JOHANSSON99] 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. ACM/IEEE, August 1999.
[Johansson 99]佩尔·约翰逊、托尼·拉森、尼古拉斯·赫德曼、巴托斯·米尔查莱克和米凯尔·德格马克。基于场景的移动adhoc网络路由协议性能分析。第五届ACM/IEEE移动计算和网络国际年会论文集，第195-206页。ACM/IEEE，1999年8月。
[JOHNSON94] 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. IEEE Computer Society, December 1994.
大卫·B·约翰逊。移动主机自组织网络中的路由。IEEE移动计算系统和应用研讨会论文集，第158-163页。IEEE计算机学会，1994年12月。
[JOHNSON96a] 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.
大卫·B·约翰逊和大卫·A·马尔茨。adhoc无线网络中的动态源路由。《移动计算》由Tomasz Imielinski和Hank Korth编辑，第5章，第153-181页。Kluwer学术出版社，1996年。
[JOHNSON96b] David B. Johnson and David A. Maltz. Protocols for Adaptive Wireless and Mobile Networking. IEEE Personal Communications, 3(1):34-42, February 1996.
大卫·B·约翰逊和大卫·A·马尔茨。用于自适应无线和移动网络的协议。IEEE个人通信，3（1）：34-421996年2月。
[JUBIN87] John Jubin and Janet D. Tornow. The DARPA Packet Radio Network Protocols. Proceedings of the IEEE, 75(1):21-32, January 1987.
约翰·朱宾和珍妮特·托诺。DARPA分组无线网络协议。IEEE会议记录，75（1）：21-321987年1月。
[KARN90] Phil Karn. MACA---A New Channel Access Method for
Packet Radio. In ARRL/CRRL Amateur Radio 9th Computer
Networking Conference, pages 134-140. American Radio
Relay League, September 1990.
[KARN90] Phil Karn. MACA---A New Channel Access Method for
Packet Radio. In ARRL/CRRL Amateur Radio 9th Computer
Networking Conference, pages 134-140. American Radio
Relay League, September 1990.
[LAUER95] 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.
[LAUER95]Gregory S.Lauer。分组无线电路由。《通信网络中的路由》，Martha E.Steenstrup编辑，第11章，第351-396页。普伦蒂斯大厅，恩格尔伍德悬崖，新泽西州，1995年。
[MALTZ99a] 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.
[MALTZ99a]大卫·A·马尔茨、乔希·布罗克、约尔杰塔·耶切娃和大卫·B·约翰逊。多跳无线adhoc网络路由协议中随需应变行为的影响。IEEE选定通信领域杂志，17（8）：1439-1453，1999年8月。
[MALTZ99b] 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.
大卫·A·马尔茨、乔希·布罗克和大卫·B·约翰逊。设计和搭建多跳无线自组织网络试验台的经验。技术报告CMU-CS-99-116，卡内基梅隆大学计算机科学学院，宾夕法尼亚州匹兹堡，1999年3月。
[MALTZ00] 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. IEEE, September 2000.
[MALTZ00]大卫·A·马尔茨、乔希·布罗克和大卫·B·约翰逊。从一个完整的多跳无线自组织网络试验台上得到的定量经验教训。在IEEE无线通信和网络会议记录中。IEEE，2000年9月。
[MALTZ01] 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.
[MALTZ01]大卫·A·马尔茨、乔希·布罗克和大卫·B·约翰逊。从一个完整的多跳无线自组织网络试验台上得到的经验教训。IEEE个人通信，8（1）：8-15，2001年2月。
[MONARCH] Rice University Monarch Project. Monarch Project Home Page. Available at http://www.monarch.cs.rice.edu/.
[君主]莱斯大学君主项目。君主项目主页。可在http://www.monarch.cs.rice.edu/.
[NS-2] The Network Simulator -- ns-2. Project web page available at http://www.isi.edu/nsnam/ns/.
[NS-2]网络模拟器——NS-2。项目网页可在http://www.isi.edu/nsnam/ns/.
[PAPADIMITRATOS02] 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.
[Papadimitatos02]Papadimitatos和Zygmunt J.Haas。移动自组织网络的安全路由。SCS通信网络和分布式系统建模与仿真会议（CNDS 2002），2002年1月。
[PERLMAN92] Radia Perlman. Interconnections: Bridges and Routers. Addison-Wesley, Reading, Massachusetts, 1992.
[Perlman]Radia Perlman。互连：网桥和路由器。艾迪生·韦斯利，雷丁，马萨诸塞州，1992年。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[SONG01] 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://piconet.sourceforge.net/thesis/index.html.
[SONG01]亚历克斯·宋。微微网II：用于移动手持设备的无线自组织网络。2001年10月，澳大利亚昆士兰大学信息工程与电气工程系电气工程系荣誉学士学位。可在http://piconet.sourceforge.net/thesis/index.html.
[TURNER90] Paul Turner. NetWare Communications Processes. NetWare Application Notes, Novell Research, pages 25- 91, September 1990.
保罗·特纳。NetWare通信过程。NetWare应用说明，Novell Research，第25-91页，1990年9月。
[WRIGHT95] Gary R. Wright and W. Richard Stevens. TCP/IP Illustrated, Volume 2: The Implementation. Addison-Wesley, Reading, Massachusetts, 1995.
[WRIGHT95]加里·R·赖特和W·理查德·史蒂文斯。TCP/IP图解，第2卷：实现。艾迪生·韦斯利，雷丁，马萨诸塞州，1995年。
Authors' Addresses
作者地址
David B. Johnson Rice University Computer Science Department, MS 132 6100 Main Street Houston, TX 77005-1892 USA
David B.Johnson Rice大学计算机科学系，美国德克萨斯州休斯顿大街132号6100号，邮编77005-1892
Phone: +1 713 348-3063
Fax: +1 713 348-5930
EMail: dbj@cs.rice.edu
Phone: +1 713 348-3063
Fax: +1 713 348-5930
EMail: dbj@cs.rice.edu
David A. Maltz Microsoft Research One Microsoft Way Redmond, WA 98052 USA
David A.Maltz微软研究院微软路一号，华盛顿州雷德蒙，美国98052
Phone: +1 425 706-7785
Fax: +1 425 936-7329
EMail: dmaltz@microsoft.com
Phone: +1 425 706-7785
Fax: +1 425 936-7329
EMail: dmaltz@microsoft.com
Yih-Chun Hu University of Illinois at Urbana-Champaign Coordinated Science Lab 1308 West Main St, MC 228 Urbana, IL 61801 USA
胡春春伊利诺伊大学Urna ChanPaon协调科学实验室1308西门子ST，IL 228乌尔塔MC 61801美国
Phone: +1 217 333-4220
EMail: yihchun@uiuc.edu
Phone: +1 217 333-4220
EMail: yihchun@uiuc.edu
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。