AODV路由协议RFC3561中文版

Network Working Group C. Perkins Request for Comments: 3561 Nokia Research Center Category: Experimental E. Belding-Royer University of California, Santa Barbara S. Das University of Cincinnati July 2003 Ad hoc On-Demand Distance Vector (AODV) RoutingStatus of this MemoThis memo defines an Experimental Protocol for the Internetcommunity. It does not specify an Internet standard of any kind.Discussion and suggestions for improvement are requested.Distribution of this memo is unlimited.Copyright NoticeCopyright (C) The Internet Society (2003). All Rights Reserved.AbstractThe Ad hoc On-Demand Distance Vector (AODV) routing protocol isintended for use by mobile nodes in an ad hoc network. It offersquick adaptation to dynamic link conditions, low processing andmemory overhead, low network utilization, and determines unicastroutes to destinations within the ad hoc network. It usesdestination sequence numbers to ensure loop freedom at all times(even in the face of anomalous delivery of routing control messages), avoiding problems (such as "counting to infinity") associated withclassical distance vector protocols.Table of Contents1. Introduction (2)2. Overview (3)3. AODV Terminology (4)4. Applicability Statement (6)5. Message Formats (7)5.1. Route Request (RREQ) Message Format (7)5.2. Route Reply (RREP) Message Format (8)5.3. Route Error (RERR) Message Format (10)5.4. Route Reply Acknowledgment (RREP-ACK) Message Format .. 116. AODV Operation (11)6.1. Maintaining Sequence Numbers (11)6.2. Route Table Entries and Precursor Lists (13)Perkins, et. al. Experimental [Page 1]6.3. Generating Route Requests (14)6.4. Controlling Dissemination of Route Request Messages (15)6.5. Processing and Forwarding Route Requests (16)6.6. Generating Route Replies (18)6.6.1. Route Reply Generation by the Destination (18)6.6.2. Route Reply Generation by an IntermediateNode (19)6.6.3. Generating Gratuitous RREPs (19)6.7. Receiving and Forwarding Route Replies (20)6.8. Operation over Unidirectional Links (21)6.9. Hello Messages (22)6.10 Maintaining Local Connectivity (23)6.11 Route Error (RERR) Messages, Route Expiry and RouteDeletion (24)6.12 Local Repair (26)6.13 Actions After Reboot (27)6.14 Interfaces (28)7. AODV and Aggregated Networks (28)8. Using AODV with Other Networks (29)9. Extensions (30)9.1. Hello Interval Extension Format (30)10. Configuration Parameters (31)11. Security Considerations (33)12. IANA Considerations (34)13. IPv6 Considerations (34)14. Acknowledgments (34)15. Normative References (35)16. Informative References (35)17. Authors’ Addresses (36)18. Full Copyright Statement (37)1. IntroductionThe Ad hoc On-Demand Distance Vector (AODV) algorithm enablesdynamic, self-starting, multihop routing between participating mobile nodes wishing to establish and maintain an ad hoc network. AODVallows mobile nodes to obtain routes quickly for new destinations,and does not require nodes to maintain routes to destinations thatare not in active communication. AODV allows mobile nodes to respond to link breakages and changes in network topology in a timely manner. The operation of AODV is loop-free, and by avoiding the Bellman-Ford "counting to infinity" problem offers quick convergence when the adhoc network topology changes (typically, when a node moves in thenetwork). When links break, AODV causes the affected set of nodes to be notified so that they are able to invalidate the routes using the lost link.Perkins, et. al. Experimental [Page 2]One distinguishing feature of AODV is its use of a destinationsequence number for each route entry. The destination sequencenumber is created by the destination to be included along with anyroute information it sends to requesting nodes. Using destinationsequence numbers ensures loop freedom and is simple to program.Given the choice between two routes to a destination, a requestingnode is required to select the one with the greatest sequence number.2. OverviewRoute Requests (RREQs), Route Replies (RREPs), and Route Errors(RERRs) are the message types defined by AODV. These message typesare received via UDP, and normal IP header processing applies. So,for instance, the requesting node is expected to use its IP addressas the Originator IP address for the messages. For broadcastmessages, the IP limited broadcast address (255.255.255.255) is used. This means that such messages are not blindly forwarded. However,AODV operation does require certain messages (e.g., RREQ) to bedisseminated widely, perhaps throughout the ad hoc network. Therange of dissemination of such RREQs is indicated by the TTL in theIP header. Fragmentation is typically not required.As long as the endpoints of a communication connection have validroutes to each other, AODV does not play any role. When a route to a new destination is needed, the node broadcasts a RREQ to find a route to the destination. A route can be determined when the RREQ reaches either the destination itself, or an intermediate node with a ’fresh enough’ route to the destination. A ’fresh enough’ route is a valid route entry for the destination whose associated sequence number isat least as great as that contained in the RREQ. The route is madeavailable by unicasting a RREP back to the origination of the RREQ.Each node receiving the request caches a route back to the originator of the request, so that the RREP can be unicast from the destination along a path to that originator, or likewise from any intermediatenode that is able to satisfy the request.Nodes monitor the link status of next hops in active routes. When a link break in an active route is detected, a RERR message is used to notify other nodes that the loss of that link has occurred. The RERR message indicates those destinations (possibly subnets) which are no longer reachable by way of the broken link. In order to enable this reporting mechanism, each node keeps a "precursor list", containingthe IP address for each its neighbors that are likely to use it as a next hop towards each destination. The information in the precursor lists is most easily acquired during the processing for generation of a RREP message, which by definition has to be sent to a node in aprecursor list (see section 6.6). If the RREP has a nonzero prefix Perkins, et. al. Experimental [Page 3]length, then the originator of the RREQ which solicited the RREPinformation is included among the precursors for the subnet route(not specifically for the particular destination).A RREQ may also be received for a multicast IP address. In thisdocument, full processing for such messages is not specified. Forexample, the originator of such a RREQ for a multicast IP address may have to follow special rules. However, it is important to enablecorrect multicast operation by intermediate nodes that are notenabled as originating or destination nodes for IP multicastaddresses, and likewise are not equipped for any special multicastprotocol processing. For such multicast-unaware nodes, processingfor a multicast IP address as a destination IP address MUST becarried out in the same way as for any other destination IP address. AODV is a routing protocol, and it deals with route table management. Route table information must be kept even for short-lived routes,such as are created to temporarily store reverse paths towards nodes originating RREQs. AODV uses the following fields with each routetable entry:- Destination IP Address- Destination Sequence Number- Valid Destination Sequence Number flag- Other state and routing flags (e.g., valid, invalid, repairable,being repaired)- Network Interface- Hop Count (number of hops needed to reach destination)- Next Hop- List of Precursors (described in Section 6.2)- Lifetime (expiration or deletion time of the route)Managing the sequence number is crucial to avoiding routing loops,even when links break and a node is no longer reachable to supply its own information about its sequence number. A destination becomesunreachable when a link breaks or is deactivated. When theseconditions occur, the route is invalidated by operations involvingthe sequence number and marking the route table entry state asinvalid. See section 6.1 for details.3. AODV TerminologyThis protocol specification uses conventional meanings [1] forcapitalized words such as MUST, SHOULD, etc., to indicate requirement levels for various protocol features. This section defines otherterminology used with AODV that is not already defined in [3]. Perkins, et. al. Experimental [Page 4]active routeA route towards a destination that has a routing table entrythat is marked as valid. Only active routes can be used toforward data packets.broadcastBroadcasting means transmitting to the IP Limited Broadcastaddress, 255.255.255.255. A broadcast packet may not beblindly forwarded, but broadcasting is useful to enabledissemination of AODV messages throughout the ad hoc network.destinationAn IP address to which data packets are to be transmitted.Same as "destination node". A node knows it is the destination node for a typical data packet when its address appears in the appropriate field of the IP header. Routes for destinationnodes are supplied by action of the AODV protocol, whichcarries the IP address of the desired destination node in route discovery messages.forwarding nodeA node that agrees to forward packets destined for anothernode, by retransmitting them to a next hop that is closer tothe unicast destination along a path that has been set up using routing control messages.forward routeA route set up to send data packets from a node originating aRoute Discovery operation towards its desired destination.invalid routeA route that has expired, denoted by a state of invalid in the routing table entry. An invalid route is used to storepreviously valid route information for an extended period oftime. An invalid route cannot be used to forward data packets, but it can provide information useful for route repairs, andalso for future RREQ messages.Perkins, et. al. Experimental [Page 5]originating nodeA node that initiates an AODV route discovery message to beprocessed and possibly retransmitted by other nodes in the adhoc network. For instance, the node initiating a RouteDiscovery process and broadcasting the RREQ message is calledthe originating node of the RREQ message.reverse routeA route set up to forward a reply (RREP) packet back to theoriginator from the destination or from an intermediate nodehaving a route to the destination.sequence numberA monotonically increasing number maintained by eachoriginating node. In AODV routing protocol messages, it isused by other nodes to determine the freshness of theinformation contained from the originating node.valid routeSee active route.4. Applicability StatementThe AODV routing protocol is designed for mobile ad hoc networks with populations of tens to thousands of mobile nodes. AODV can handlelow, moderate, and relatively high mobility rates, as well as avariety of data traffic levels. AODV is designed for use in networks where the nodes can all trust each other, either by use ofpreconfigured keys, or because it is known that there are nomalicious intruder nodes. AODV has been designed to reduce thedissemination of control traffic and eliminate overhead on datatraffic, in order to improve scalability and performance.Perkins, et. al. Experimental [Page 6]5. Message Formats5.1. Route Request (RREQ) Message Format0 1 2 30 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type |J|R|G|D|U| Reserved | Hop Count |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| RREQ ID |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Destination IP Address |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Destination Sequence Number |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Originator IP Address |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Originator Sequence Number |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The format of the Route Request message is illustrated above, andcontains the following fields:Type 1J Join flag; reserved for multicast.R Repair flag; reserved for multicast.G Gratuitous RREP flag; indicates whether agratuitous RREP should be unicast to the nodespecified in the Destination IP Address field (see sections 6.3, 6.6.3).D Destination only flag; indicates only thedestination may respond to this RREQ (seesection 6.5).U Unknown sequence number; indicates the destination sequence number is unknown (see section 6.3).Reserved Sent as 0; ignored on reception.Hop Count The number of hops from the Originator IP Addressto the node handling the request.Perkins, et. al. Experimental [Page 7]RREQ ID A sequence number uniquely identifying theparticular RREQ when taken in conjunction with the originating node’s IP address.Destination IP AddressThe IP address of the destination for which a route is desired.Destination Sequence NumberThe latest sequence number received in the pastby the originator for any route towards thedestination.Originator IP AddressThe IP address of the node which originated theRoute Request.Originator Sequence NumberThe current sequence number to be used in the route entry pointing towards the originator of the route request.5.2. Route Reply (RREP) Message Format0 1 2 30 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type |R|A| Reserved |Prefix Sz| Hop Count |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Destination IP address |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Destination Sequence Number |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Originator IP address |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Lifetime |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The format of the Route Reply message is illustrated above, andcontains the following fields:Type 2R Repair flag; used for multicast.A Acknowledgment required; see sections 5.4 and 6.7.Reserved Sent as 0; ignored on reception.Perkins, et. al. Experimental [Page 8]Prefix Size If nonzero, the 5-bit Prefix Size specifies that the indicated next hop may be used for any nodes withthe same routing prefix (as defined by the PrefixSize) as the requested destination.Hop Count The number of hops from the Originator IP Addressto the Destination IP Address. For multicast route requests this indicates the number of hops to themulticast tree member sending the RREP.Destination IP AddressThe IP address of the destination for which a route is supplied.Destination Sequence NumberThe destination sequence number associated to theroute.Originator IP AddressThe IP address of the node which originated the RREQ for which the route is supplied.Lifetime The time in milliseconds for which nodes receivingthe RREP consider the route to be valid.Note that the Prefix Size allows a subnet router to supply a routefor every host in the subnet defined by the routing prefix, which is determined by the IP address of the subnet router and the PrefixSize. In order to make use of this feature, the subnet router has to guarantee reachability to all the hosts sharing the indicated subnet prefix. See section 7 for details. When the prefix size is nonzero, any routing information (and precursor data) MUST be kept withrespect to the subnet route, not the individual destination IPaddress on that subnet.The ’A’ bit is used when the link over which the RREP message is sent may be unreliable or unidirectional. When the RREP message contains the ’A’ bit set, the receiver of the RREP is expected to return aRREP-ACK message. See section 6.8.Perkins, et. al. Experimental [Page 9]5.3. Route Error (RERR) Message Format0 1 2 30 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type |N| Reserved | DestCount |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Unreachable Destination IP Address (1) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Unreachable Destination Sequence Number (1) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|| Additional Unreachable Destination IP Addresses (if needed) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Additional Unreachable Destination Sequence Numbers (if needed)|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The format of the Route Error message is illustrated above, andcontains the following fields:Type 3N No delete flag; set when a node has performed a local repair of a link, and upstream nodes should not delete the route.Reserved Sent as 0; ignored on reception.DestCount The number of unreachable destinations included in the message; MUST be at least 1.Unreachable Destination IP AddressThe IP address of the destination that has becomeunreachable due to a link break.Unreachable Destination Sequence NumberThe sequence number in the route table entry forthe destination listed in the previous UnreachableDestination IP Address field.The RERR message is sent whenever a link break causes one or moredestinations to become unreachable from some of the node’s neighbors. See section 6.2 for information about how to maintain the appropriate records for this determination, and section 6.11 for specificationabout how to create the list of destinations.Perkins, et. al. Experimental [Page 10]5.4. Route Reply Acknowledgment (RREP-ACK) Message FormatThe Route Reply Acknowledgment (RREP-ACK) message MUST be sent inresponse to a RREP message with the ’A’ bit set (see section 5.2).This is typically done when there is danger of unidirectional linkspreventing the completion of a Route Discovery cycle (see section6.8).0 10 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type | Reserved |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type 4Reserved Sent as 0; ignored on reception.6. AODV OperationThis section describes the scenarios under which nodes generate Route Request (RREQ), Route Reply (RREP) and Route Error (RERR) messagesfor unicast communication towards a destination, and how the message data are handled. In order to process the messages correctly,certain state information has to be maintained in the route tableentries for the destinations of interest.All AODV messages are sent to port 654 using UDP.6.1. Maintaining Sequence NumbersEvery route table entry at every node MUST include the latestinformation available about the sequence number for the IP address of the destination node for which the route table entry is maintained.This sequence number is called the "destination sequence number". It is updated whenever a node receives new (i.e., not stale) information about the sequence number from RREQ, RREP, or RERR messages that may be received related to that destination. AODV depends on each nodein the network to own and maintain its destination sequence number to guarantee the loop-freedom of all routes towards that node. Adestination node increments its own sequence number in twocircumstances:- Immediately before a node originates a route discovery, it MUSTincrement its own sequence number. This prevents conflicts withpreviously established reverse routes towards the originator of a RREQ.Perkins, et. al. Experimental [Page 11]- Immediately before a destination node originates a RREP inresponse to a RREQ, it MUST update its own sequence number to the maximum of its current sequence number and the destinationsequence number in the RREQ packet.When the destination increments its sequence number, it MUST do so by treating the sequence number value as if it were an unsigned number. To accomplish sequence number rollover, if the sequence number hasalready been assigned to be the largest possible number representable as a 32-bit unsigned integer (i.e., 4294967295), then when it isincremented it will then have a value of zero (0). On the otherhand, if the sequence number currently has the value 2147483647,which is the largest possible positive integer if 2’s complementarithmetic is in use with 32-bit integers, the next value will be2147483648, which is the most negative possible integer in the samenumbering system. The representation of negative numbers is notrelevant to the increment of AODV sequence numbers. This is incontrast to the manner in which the result of comparing two AODVsequence numbers is to be treated (see below).In order to ascertain that information about a destination is notstale, the node compares its current numerical value for the sequence number with that obtained from the incoming AODV message. Thiscomparison MUST be done using signed 32-bit arithmetic, this isnecessary to accomplish sequence number rollover. If the result ofsubtracting the currently stored sequence number from the value ofthe incoming sequence number is less than zero, then the information related to that destination in the AODV message MUST be discarded,since that information is stale compared to the node’s currentlystored information.The only other circumstance in which a node may change thedestination sequence number in one of its route table entries is inresponse to a lost or expired link to the next hop towards thatdestination. The node determines which destinations use a particular next hop by consulting its routing table. In this case, for eachdestination that uses the next hop, the node increments the sequence number and marks the route as invalid (see also sections 6.11, 6.12). Whenever any fresh enough (i.e., containing a sequence number atleast equal to the recorded sequence number) routing information for an affected destination is received by a node that has marked thatroute table entry as invalid, the node SHOULD update its route table information according to the information contained in the update. Perkins, et. al. Experimental [Page 12]A node may change the sequence number in the routing table entry of a destination only if:- it is itself the destination node, and offers a new route toitself, or- it receives an AODV message with new information about thesequence number for a destination node, or- the path towards the destination node expires or breaks.6.2. Route Table Entries and Precursor ListsWhen a node receives an AODV control packet from a neighbor, orcreates or updates a route for a particular destination or subnet, it checks its route table for an entry for the destination. In theevent that there is no corresponding entry for that destination, anentry is created. The sequence number is either determined from the information contained in the control packet, or else the validsequence number field is set to false. The route is only updated if the new sequence number is either(i) higher than the destination sequence number in the routetable, or(ii) the sequence numbers are equal, but the hop count (of thenew information) plus one, is smaller than the existing hop count in the routing table, or(iii) the sequence number is unknown.The Lifetime field of the routing table entry is either determinedfrom the control packet, or it is initialized toACTIVE_ROUTE_TIMEOUT. This route may now be used to send any queued data packets and fulfills any outstanding route requests.Each time a route is used to forward a data packet, its Active Route Lifetime field of the source, destination and the next hop on thepath to the destination is updated to be no less than the currenttime plus ACTIVE_ROUTE_TIMEOUT. Since the route between eachoriginator and destination pair is expected to be symmetric, theActive Route Lifetime for the previous hop, along the reverse pathback to the IP source, is also updated to be no less than the current time plus ACTIVE_ROUTE_TIMEOUT. The lifetime for an Active Route is updated each time the route is used regardless of whether thedestination is a single node or a subnet.Perkins, et. al. Experimental [Page 13]For each valid route maintained by a node as a routing table entry,the node also maintains a list of precursors that may be forwardingpackets on this route. These precursors will receive notificationsfrom the node in the event of detection of the loss of the next hoplink. The list of precursors in a routing table entry contains those neighboring nodes to which a route reply was generated or forwarded.6.3. Generating Route RequestsA node disseminates a RREQ when it determines that it needs a routeto a destination and does not have one available. This can happen if the destination is previously unknown to the node, or if a previously valid route to the destination expires or is marked as invalid. The Destination Sequence Number field in the RREQ message is the lastknown destination sequence number for this destination and is copied from the Destination Sequence Number field in the routing table. If no sequence number is known, the unknown sequence number flag MUST be set. The Originator Sequence Number in the RREQ message is thenode’s own sequence number, which is incremented prior to insertionin a RREQ. The RREQ ID field is incremented by one from the lastRREQ ID used by the current node. Each node maintains only one RREQ ID. The Hop Count field is set to zero.Before broadcasting the RREQ, the originating node buffers the RREQID and the Originator IP address (its own address) of the RREQ forPATH_DISCOVERY_TIME. In this way, when the node receives the packet again from its neighbors, it will not reprocess and re-forward thepacket.An originating node often expects to have bidirectionalcommunications with a destination node. In such cases, it is notsufficient for the originating node to have a route to thedestination node; the destination must also have a route back to the originating node. In order for this to happen as efficiently aspossible, any generation of a RREP by an intermediate node (as insection 6.6) for delivery to the originating node SHOULD beaccompanied by some action that notifies the destination about aroute back to the originating node. The originating node selectsthis mode of operation in the intermediate nodes by setting the ’G’flag. See section 6.6.3 for details about actions taken by theintermediate node in response to a RREQ with the ’G’ flag set.A node SHOULD NOT originate more than RREQ_RATELIMIT RREQ messagesper second. After broadcasting a RREQ, a node waits for a RREP (orother control message with current information regarding a route tothe appropriate destination). If a route is not received withinNET_TRAVERSAL_TIME milliseconds, the node MAY try again to discover a route by broadcasting another RREQ, up to a maximum of RREQ_RETRIES Perkins, et. al. Experimental [Page 14]。

#3节点仿真Ad hoc AODV的例子# 环境设定set val(chan) Channel/WirelessChannel ;#信道类型set val(prop) Propagation/TwoRayGround ;#无线传输模块类型set val(netif) Phy/WirelessPhy ;#网络接口类型set val(mac) Mac/802_11 ;# MAC类型set val(ifq) Queue/DropTail/PriQueue ;#接口队列类型set val(ll) LL ;#链路层类型set val(ant) Antenna/OmniAntenna ;#天线类型set val(ifqlen) 50 ;#IFQ中最大报文数set val(nn) 3 ;# 移动节点数目set val(rp) AODV ;# 路由协议set val(x) 500 ;# 场景长xset val(y) 400 ;# 场景宽yset val(stop) 150 ;# 仿真结束时间set ns [new Simulator]#创建一个模拟对象set tracefd [open aodv.tr w]#打开一个trace file记录数据包的传送过程$ns trace-all $tracefdset windowVsTime2 [open win.tr w]set namtrace[open aodv.nam w] #创建.nam文件记录nam的trace数据$ns namtrace-all-wireless $namtrace $val(x) $val(y)set topo[new Topography]#建立一个Topography对象在拓扑边界范围内运动$topoload_flatgrid $val(x) $val(y)#设定场景的长宽尺寸#创建nn移动节点[$ val(nn)] 并将它们附加到信道。

ietfrfc3551—2003
RFC 3551是实时传输协议（RTP）的标准，它定义了互联网音频和视频传输的标准格式。

该标准主要应用于实时传输数据，例如音频、视频或仿真数据。

RTP本身不提供服务质量保证（QoS），也不提供资源预留功能，但可以通过一个控制协议（RTCP）进行扩展，对数据传输进行监测和控制。

RTCP 可以升级到大型的多点传送（多播）网络，并提供最小限度的控制和鉴别功能。

RTP和RTCP被设计成与下面的传输层和网络层无关，这意味着它们可以与不同的传输层协议（如TCP或UDP）和不同的网络层协议（如IPv4或IPv6）一起使用。

此外，RTP标准还支持RTP标准的转换器和混合器的使用。

以上内容仅供参考，如需了解更多信息，建议查阅RFC 3551的官方文档或咨询专业技术人员。

AODV总结1 信源和信宿的定义在AODV协议[1]中，序列号的分析。

图1：RREQ的消息格式在图1中，信源序列号（Originator Sequence Number）由信源节点维护，表示到信源的反向路由的新旧；也就是当中间节点收到信源发来的RREQ后，其路由表中到信源的路由表项的新旧程度。

信宿序列号（Destination Sequence Number）表示信源可接受的到信宿的前向路由的新旧，等于过去接收到的有关信宿的最大序列号，信源应维护到每个信宿的最大序列号。

2 序列号的维护每个节点中的每个路由表项都必须维护目的节点有关序列号的最新信息，该序列号称为“目的序列号”。

当节点收到RREQ、RREP、RERR信息后，如果能从中得到关于目的节点序列号的新信息后，就会更新路由表。

AODV通过节点维护目的序列号来保证到某个节点的所有路由不会出现环路。

目的节点增加其序列号主要包括下列两种方式：（1）在节点发起一次路由请求之前，需增加源序列号，这就避免了和以前建立的到RREQ的发送节点的反向路由相冲突。

（2）当节点为了响应RREQ而发起RREP之前，需增加序列号，必须将起序列号更新为其源序列号和RREQ中目的序列号的最大值。

当该节点增加其源序列号时，必须将该序列号作为一个无符号数，为了实现序列号的翻滚，当序列号已经设置为32比特无符号数的最大值时，也就是4294967295。

如果增加序列号，就变成0。

另一方面，如果当前序列值为2147483647，是32比特整数补码符号数的最大值，则下一个值为2147483648，是32比特补码的最小值。

负值的表示和AODV序列号的增加并不关联。

为了确保关于一个信宿的信息是最新的，节点应该对序列号的当前值和到达的AODV 信息的序列号进行比较，这种比较采用了有符号32bit算法，有必要完成序列号的翻转。

如果到达分组的序列号减去当前序列号的值小于零，则和AODV信宿相关的信息必须删除，因为该信息相对于节点当前保存信息是过期的。

网络组诺基亚研发中心C. PerkinsRFC：3561 加州大学圣芭芭拉分校E. Belding-Royer类别：试验版辛辛那提大学S. Das2003年7月Ad hoc网络中基于距离数组的按需(AODV)路由协议本备忘状态本备忘定义的只是一个试验性质的网络社区协议而已，它不是任何一种类型的网络标准。

我们非常需要各种讨论和建议用于改进这个协议。

本备忘录的分发不受任何限制。

版权声明复制权属于整个因特网社区，保留所有权利。

摘要本协议用于特定网络中的可移动节点。

它能在动态变化的点对点网络中确定一条到目的地的路由，并且具有接入速度快，计算量小，内存占用低，网络负荷轻等特点。

它采用目的序列号来确保在任何时候都不会出现回环（甚至在路由控制信息出现异常的时候也是如此），避免了传统的距离数组协议中会出现的很多问题（比如无穷计数问题）。

目录1.导言AODV算法旨在多个移动节点中建立和维护一个动态的，自启动的，多跳路由的专属网络。

AODV使得移动节点能快速获得通向新的目的节点的路由，并且节点仅需要维护通向它信号所及范围内的节点的路由，更远的节点的路由信息则不需要维护。

网络中连接的断开和异动会使得网络拓扑结构发生变化，AODV使得移动节点能适时对这种变化做出响应。

AODV的操作是无自环的，并且由于解决了Bellman-Ford“无穷计数”的问题，使得该算法在网络拓扑变化时（比如一个节点在网络中移动）能够快速收敛。

当一个连接断开时，AODV会告知所有受到影响的节点，这些节点会让用到这个连接的路由失效。

AODV的一个显著特点是它在每个路由表项上使用了目的序列号。

目的序列号由目的节点创建，并且被包含在路由信息中，然后这些路由信息将被回发到所有向它发起请求的节点。

目的序列号的使用确保了无回环，并且易于编程。

如果到一个目的有两条路由可供选择，那么收到请求的节点将会选择序列号最大的那一条（由于目的节点每次收到新的请求都会将目的序列号加一，所以序列号最大表明该路由最新）。

MANET与WSN无线自组网的无中心、自组织、分布式、多跳转发等特点，使它具有无需网络基础设施、可快速临时组网、系统抗毁性强等突出优点，应用前景广阔。

移动自组网（Mobile Ad hoc Network）和无线传感器网络（WSN）是无线自组网的两个重要分支，面向不同应用。

移动自组网主要面向“人与人”之间的移动通信，最早源自军事移动通信，要求通信系统具备以下能力：网络快速展开与组织、抗毁性强、移动中通信、通信距离远等。

灾后救援是其又一应用领域。

发生地震、水灾、海啸或者大规模恐怖袭击后，通信基础设施可能无法正常工作，来自各方救援人员急需这种不依赖通信基础设施又能快速部署的通信技术。

在扩大蜂窝移动通信系统的覆盖范围、保障车辆通信等方面移动自组网技术具有得天独厚的条件。

Mobile Ad hoc Network节点是面向个人通信的无线终端，节点的自由移动（人员便携、车载、机载等）导致网络拓扑快速变化，如何适应网络拓扑动态变化是Mobile Ad hoc Network 设计的主要挑战。

无线传感器网络主要面向“物与物、人与物”之间的信息交互。

无线传感器网络具有快速部署、自组织、高容错性等特点，军事方面可用于敌军兵力监控、战场态势实时采集、目标定位、核生化攻击检测等；环境方面可用于监测河床水位和土壤水分，预测山洪、地震的可能性、监视野生动物等；医疗方面可用于监测人体生理数据，医院药物管理等；此外在智能家居、智能交通、仓库管理、自动化生产等众多领域都可能孕育出全新应用模式。

传感器节点多采用电池供电，节点数量众多，部署区域环境复杂，采用人工电池更换方式来补充能源是不现实的，电池能量耗尽是传感器节点失效的主要原因。

如何高效使用能量来最大化网络生命期是无线传感器网络设计面临的主要挑战。

发展历程：1、Mobile Ad hoc Network移动自组网（Mobile Ad hoc Network）分为两个阶段：1、二十世纪六十年代末到八十年代末期，是基于军事通信应用的初期发展阶段；2、二十世纪九十年代至今，是基于军事通信和民用通信应用的快速发展阶段。

Aodv路由协议报告本周主要工作是分析aodv协议代码的具体实现过程，根据代码总结出aodv中比较重要的知识一．Aodv数据结构路由表项{rt_dst:目的节点ip地址rt_seqno:目的节点序列号，目的节点有效序列号为偶数rt_hops:跳数rt_req_cnt:发rreq的次数，不得大于rreq_retries次rt_req_timeout:路由请求超时时间，只有超过此时间才能再次发出rreq的aodv消息.rt_req_last_ttl:上次请求生命期，即发送rreq时ip头中ttl的值rt_disc_latency[]:每次请求的延时rt_last_hop_count:上次使用的路由跳数rt_nexthop:下一跳ip地址rt_expire:路由寿命rt_flag:路由状态标志（RT_UP,RT_DOWN,RT_IN_PAIR)rt_prelist:路由前驱列表hist_index:本次发送的rreq次数}邻居列表{Expire：超时时间Id：邻居ip地址}广播列表{expire：过期时间id：广播iddst：广播源节点ip地址}二.节点定时器btimer:广播定时器，用来调用id_purge()函数，顺序查看广播表中的每个条目，比较过期时间是否大于当前时间，如果大于，则调用id_delete()函数删除此广播htimer:hello定时器，用来调用sendhello（）函数，发送hello消息ntimer:邻居列表定时器，用来调用nb_purge()函数，顺序查看邻居表中的每个条目，如果过期时间超过当前时间，则认为此邻居不可达，删除此邻居条目rtimer:路由缓存定时器，用来调用rt_purge()函数，顺序查看每条路由的是否过期，如果没过期且有效，则看是否缓存队列中是否有要发送到目的节点的分组，如果有则按路由转发，并将路由过期时间重置。

如果路由过期且有分组待转发，则发送rreq消息。