idnits 2.17.1 draft-ietf-manet-aodvv2-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 18, 2016) is 3020 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Address' is mentioned on line 366, but not defined == Missing Reference: 'MetricType' is mentioned on line 2957, but not defined == Missing Reference: 'OrigAddr' is mentioned on line 2140, but not defined == Missing Reference: 'TargAddr' is mentioned on line 2125, but not defined == Missing Reference: 'TBD' is mentioned on line 3031, but not defined == Missing Reference: 'HopCount' is mentioned on line 2930, but not defined == Unused Reference: 'RFC4291' is defined on line 3256, but no explicit reference was found in the text == Unused Reference: 'RFC5082' is defined on line 3260, but no explicit reference was found in the text == Unused Reference: 'Perkins99' is defined on line 3310, but no explicit reference was found in the text == Unused Reference: 'RFC4861' is defined on line 3331, but no explicit reference was found in the text == Unused Reference: 'Sholander02' is defined on line 3346, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental RFC: RFC 3561 Summary: 1 error (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile Ad hoc Networks Working Group C. Perkins 3 Internet-Draft Futurewei 4 Intended status: Standards Track S. Ratliff 5 Expires: July 21, 2016 Idirect 6 J. Dowdell 7 Airbus Defence and Space 8 L. Steenbrink 9 HAW Hamburg, Dept. Informatik 10 V. Mercieca 11 Airbus Defence and Space 12 January 18, 2016 14 Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing 15 draft-ietf-manet-aodvv2-13 17 Abstract 19 The Ad Hoc On-demand Distance Vector Version 2 (AODVv2) routing 20 protocol is intended for use by mobile routers in wireless, multihop 21 networks. AODVv2 determines unicast routes among AODVv2 routers 22 within the network in an on-demand fashion. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on July 21, 2016. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 8 61 4. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 10 62 4.1. Interface List . . . . . . . . . . . . . . . . . . . . . 10 63 4.2. Router Client Table . . . . . . . . . . . . . . . . . . . 10 64 4.3. Neighbor Table . . . . . . . . . . . . . . . . . . . . . 11 65 4.4. Sequence Numbers . . . . . . . . . . . . . . . . . . . . 11 66 4.5. Local Route Set . . . . . . . . . . . . . . . . . . . . . 12 67 4.6. Multicast Route Message Table . . . . . . . . . . . . . . 15 68 5. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 69 6. AODVv2 Protocol Operations . . . . . . . . . . . . . . . . . 18 70 6.1. Initialization . . . . . . . . . . . . . . . . . . . . . 18 71 6.2. Next Hop Monitoring . . . . . . . . . . . . . . . . . . . 19 72 6.3. Neighbor Table Update . . . . . . . . . . . . . . . . . . 20 73 6.4. Interaction with the Forwarding Plane . . . . . . . . . . 21 74 6.5. Message Transmission . . . . . . . . . . . . . . . . . . 23 75 6.6. Route Discovery, Retries and Buffering . . . . . . . . . 24 76 6.7. Processing Received Route Information . . . . . . . . . . 25 77 6.7.1. Evaluating Route Information . . . . . . . . . . . . 26 78 6.7.2. Applying Route Updates . . . . . . . . . . . . . . . 28 79 6.8. Suppressing Redundant Messages Using the Multicast Route 80 Message Table . . . . . . . . . . . . . . . . . . . . . . 29 81 6.9. Local Route Set Maintenance . . . . . . . . . . . . . . . 32 82 6.9.1. Local Route State Changes . . . . . . . . . . . . . . 32 83 6.9.2. Reporting Invalid Routes . . . . . . . . . . . . . . 34 84 7. AODVv2 Protocol Messages . . . . . . . . . . . . . . . . . . 35 85 7.1. Route Request (RREQ) Message . . . . . . . . . . . . . . 35 86 7.1.1. RREQ Generation . . . . . . . . . . . . . . . . . . . 36 87 7.1.2. RREQ Reception . . . . . . . . . . . . . . . . . . . 38 88 7.1.3. RREQ Regeneration . . . . . . . . . . . . . . . . . . 39 89 7.2. Route Reply (RREP) Message . . . . . . . . . . . . . . . 40 90 7.2.1. RREP Generation . . . . . . . . . . . . . . . . . . . 41 91 7.2.2. RREP Reception . . . . . . . . . . . . . . . . . . . 43 92 7.2.3. RREP Regeneration . . . . . . . . . . . . . . . . . . 44 93 7.3. Route Reply Acknowledgement (RREP_Ack) Message . . . . . 46 94 7.3.1. RREP_Ack Generation . . . . . . . . . . . . . . . . . 46 95 7.3.2. RREP_Ack Reception . . . . . . . . . . . . . . . . . 46 96 7.4. Route Error (RERR) Message . . . . . . . . . . . . . . . 46 97 7.4.1. RERR Generation . . . . . . . . . . . . . . . . . . . 47 98 7.4.2. RERR Reception . . . . . . . . . . . . . . . . . . . 49 99 7.4.3. RERR Regeneration . . . . . . . . . . . . . . . . . . 51 100 8. RFC 5444 Representation . . . . . . . . . . . . . . . . . . . 51 101 8.1. Route Request Message Representation . . . . . . . . . . 53 102 8.1.1. Message Header . . . . . . . . . . . . . . . . . . . 53 103 8.1.2. Message TLV Block . . . . . . . . . . . . . . . . . . 53 104 8.1.3. Address Block . . . . . . . . . . . . . . . . . . . . 53 105 8.1.4. Address Block TLV Block . . . . . . . . . . . . . . . 53 106 8.2. Route Reply Message Representation . . . . . . . . . . . 54 107 8.2.1. Message Header . . . . . . . . . . . . . . . . . . . 54 108 8.2.2. Message TLV Block . . . . . . . . . . . . . . . . . . 55 109 8.2.3. Address Block . . . . . . . . . . . . . . . . . . . . 55 110 8.2.4. Address Block TLV Block . . . . . . . . . . . . . . . 55 111 8.3. Route Reply Acknowledgement Message Representation . . . 56 112 8.3.1. Message Header . . . . . . . . . . . . . . . . . . . 56 113 8.3.2. Message TLV Block . . . . . . . . . . . . . . . . . . 56 114 8.3.3. Address Block . . . . . . . . . . . . . . . . . . . . 56 115 8.3.4. Address Block TLV Block . . . . . . . . . . . . . . . 56 116 8.4. Route Error Message Representation . . . . . . . . . . . 57 117 8.4.1. Message Header . . . . . . . . . . . . . . . . . . . 57 118 8.4.2. Message TLV Block . . . . . . . . . . . . . . . . . . 57 119 8.4.3. Address Block . . . . . . . . . . . . . . . . . . . . 57 120 8.4.4. Address Block TLV Block . . . . . . . . . . . . . . . 58 121 9. Simple External Network Attachment . . . . . . . . . . . . . 58 122 10. Optional Features . . . . . . . . . . . . . . . . . . . . . . 59 123 10.1. Expanding Rings Multicast . . . . . . . . . . . . . . . 60 124 10.2. Precursor Lists . . . . . . . . . . . . . . . . . . . . 60 125 10.3. Intermediate RREP . . . . . . . . . . . . . . . . . . . 61 126 10.4. Message Aggregation Delay . . . . . . . . . . . . . . . 61 127 11. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 61 128 11.1. Timers . . . . . . . . . . . . . . . . . . . . . . . . . 62 129 11.2. Protocol Constants . . . . . . . . . . . . . . . . . . . 63 130 11.3. Local Settings . . . . . . . . . . . . . . . . . . . . . 64 131 11.4. Network-Wide Settings . . . . . . . . . . . . . . . . . 64 132 11.5. Optional Feature Settings . . . . . . . . . . . . . . . 64 133 11.6. MetricType Allocation . . . . . . . . . . . . . . . . . 65 134 11.7. AddressType Allocation . . . . . . . . . . . . . . . . . 65 135 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 66 136 12.1. RFC 5444 Message Types . . . . . . . . . . . . . . . . . 66 137 12.2. RFC 5444 Address Block TLV Types . . . . . . . . . . . . 66 138 13. Security Considerations . . . . . . . . . . . . . . . . . . . 66 139 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 69 140 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 69 141 15.1. Normative References . . . . . . . . . . . . . . . . . . 70 142 15.2. Informative References . . . . . . . . . . . . . . . . . 71 143 Appendix A. AODVv2 Draft Updates . . . . . . . . . . . . . . . . 72 144 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 73 146 1. Overview 148 The Ad Hoc On-demand Distance Vector Version 2 (AODVv2) routing 149 protocol (formerly named DYMO) enables on-demand, multihop unicast 150 routing among AODVv2 routers in mobile ad hoc networks (MANETs) 151 [RFC2501]. 153 Compared to AODV [RFC3561], AODVv2 makes some features optional, 154 notably intermediate route replies, expanding ring search, and 155 precursor lists. Hello messages and local repair have been removed. 156 AODVv2 provides a mechanism for the use of multiple metric types. 157 Message formats have been updated and made compliant with [RFC5444]. 159 AODVv2 control messages are defined as sets of data, which are mapped 160 to messages using the Generalized MANET Packet/Message Format defined 161 in [RFC5444] and sent using the parameters in [RFC5498]. 163 The basic operations of the AODVv2 protocol are route discovery and 164 route maintenance. 166 An AODVv2 router is configured to perform route discovery on behalf 167 of a configured set of IP addresses known as Router Clients. Route 168 discovery is performed when an AODVv2 router needs to forward an IP 169 packet from one of its Router Clients, but does not have a valid 170 route to the packet's destination. AODVv2 routers use Route Request 171 (RREQ) and Route Reply (RREP) messages to carry route information 172 between the originator of the route discovery and the target, 173 establishing a route to both endpoints on all intermediate routers. 174 A metric value is included to represent the cost of the route 175 contained within the message. AODVv2 uses sequence numbers to 176 identify stale routing information, and compares route metric values 177 to determine if advertised routes could form loops. 179 Route maintenance includes confirming bidirectionality of links to 180 next hop AODVv2 routers before considering discovered routes to be 181 valid, issuing Route Error (RERR) messages if link failures 182 invalidate routes, reacting to received Route Error messages, and 183 extending and enforcing route timeouts. 185 To enable the on-demand nature of AODVv2, signals are required to be 186 exchanged between AODVv2 and the forwarding plane, to indicate when a 187 packet is to be forwarded, in order to initiate route discovery, when 188 packet forwarding fails, in order to initiate route error reporting, 189 and when a packet is successfully forwarded, for route maintenance. 191 Security for authentication of AODVv2 routers and encryption of 192 control messages is accomplished using the TIMESTAMP and ICV TLVs 193 defined in [RFC7182]. 195 2. Terminology 197 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 198 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 199 "OPTIONAL" in this document are to be interpreted as described in 200 [RFC2119]. In addition, this document uses terminology from 201 [RFC5444], and defines the following terms: 203 AddressList 204 A list of IP addresses as used in AODVv2 messages. 206 AckReq 207 Used in a Route Reply message to indicate the IP address of the 208 router from which a Route Reply Acknowledgement is expected. 210 AdvRte 211 A route advertised in an incoming route message. 213 AODVv2 Router 214 An IP addressable device in the ad hoc network that performs the 215 AODVv2 protocol operations specified in this document. 217 CurrentTime 218 The current time as maintained by the AODVv2 router. 220 ENAR (External Network Access Router) 221 An AODVv2 router with an interface to an external, non-AODVv2 222 network. 224 Invalid route 225 A route that cannot be used for forwarding but still contains 226 useful sequence number information. 228 LocalRoute 229 An entry in the Local Route Set. 231 MANET 232 A Mobile Ad Hoc Network as defined in [RFC2501]. 234 MetricType 235 The metric type for a metric value included in a message. 237 MetricTypeList 238 A list of metric types associated with the addresses in the 239 AddressList of a Route Error message. 241 Neighbor 242 An AODVv2 router from which an RREQ or RREP message has been 243 received. Neighbors exchange routing information and verify 244 bidirectionality of the link to a neighbor before installing a 245 route via that neighbor into the Local Route Set. 247 OrigAddr 248 The source IP address of the IP packet triggering route discovery. 250 OrigMetric 251 The metric value associated with the route to OrigAddr (and any 252 other addresses included in the given prefix length). 254 OrigPrefixLen 255 The prefix length, in bits, configured in the Router Client entry 256 which includes OrigAddr. 258 OrigSeqNum 259 The sequence number of the AODVv2 router which originated the 260 Route Request on behalf of OrigAddr. 262 PktSource 263 The source address of the IP packet which triggered a Route Error 264 message. 266 PrefixLengthList 267 A list of routing prefix lengths associated with the addresses in 268 the AddressList of a message. 270 Reactive 271 Performed only in reaction to specific events. In AODVv2, routes 272 are requested only when data packets need to be forwarded. In 273 this document, "reactive" is synonymous with "on-demand". 275 RERR (Route Error) 276 The AODVv2 message type used to indicate that an AODVv2 router 277 does not have a valid LocalRoute toward one or more particular 278 destinations. 280 RERR_Gen (RERR Generating Router) 281 The AODVv2 router generating a Route Error message. 283 Routable Unicast IP Address 284 A routable unicast IP address is a unicast IP address that is 285 scoped sufficiently to be forwarded by a router. Globally-scoped 286 unicast IP addresses and Unique Local Addresses (ULAs) [RFC4193] 287 are examples of routable unicast IP addresses. 289 Router Client 290 An address or address range configured on an AODVv2 router, on 291 behalf of which that router will initiate and respond to route 292 discoveries, so that devices configured to use these addresses can 293 send and receive IP traffic to and from remote destinations. 294 These addresses may be used by the AODVv2 router itself or by non- 295 routing devices that are reachable without traversing another 296 AODVv2 router. 298 RREP (Route Reply) 299 The AODVv2 message type used to reply to a Route Request message. 301 RREP_Gen (RREP Generating Router) 302 The AODVv2 router that generates the Route Reply message, i.e., 303 the router configured with TargAddr as a Router Client. 305 RREQ (Route Request) 306 The AODVv2 message type used to discover a route to TargAddr and 307 distribute information about a route to OrigAddr. 309 RREQ_Gen (RREQ Generating Router) 310 The AODVv2 router that generates the Route Request message, i.e., 311 the router configured with OrigAddr as a Router Client. 313 RteMsg (Route Message) 314 A Route Request (RREQ) or Route Reply (RREP) message. 316 SeqNum 317 The sequence number maintained by an AODVv2 router to indicate 318 freshness of route information. 320 SeqNumList 321 A list of sequence numbers associated with the addresses in the 322 AddressList of a message. 324 TargAddr 325 The target address of a route request, i.e., the destination 326 address of the IP packet triggering route discovery. 328 TargMetric 329 The metric value associated with the route to TargAddr (and any 330 other addresses included in the given prefix length). 332 TargPrefixLen 333 The prefix length, in bits, configured in the Router Client entry 334 which includes TargAddr. 336 TargSeqNum 337 The sequence number of the AODVv2 router which originated the 338 Route Reply on behalf of TargAddr. 340 Valid route 341 A route that can be used for forwarding, which has been confirmed 342 as having a bidirectional link to the next hop, and has not timed 343 out or been made invalid by a route error. 345 Unreachable Address 346 An address reported in a Route Error message, either the address 347 on a LocalRoute which became Invalid, or the destination address 348 of an IP packet that could not be forwarded because a valid 349 LocalRoute to the destination is not known, and will not be 350 requested. 352 Upstream 353 In the direction from destination to source (from TargAddr to 354 OrigAddr). 356 ValidityTime 357 The length of time the route described by the message is offered. 359 This document uses the notational conventions in Table 1 to simplify 360 the text. 362 +-----------------------+------------------------------------+ 363 | Notation | Meaning | 364 +-----------------------+------------------------------------+ 365 | Route[Address] | A route toward Address | 366 | Route[Address].Field | A field in a route toward Address | 367 | RteMsg.Field | A field in either RREQ or RREP | 368 +-----------------------+------------------------------------+ 370 Table 1: Notational Conventions 372 3. Applicability Statement 374 The AODVv2 routing protocol is a reactive routing protocol. While 375 proactive routing protocols send frequent messages and determine 376 routes in advance of them being used, a reactive protocol only sends 377 messages to discover a route when there is data to send on that 378 route. Therefore, a reactive routing protocol requires certain 379 interactions with the forwarding plane, for example, to indicate when 380 a packet is to be forwarded, in order to initiate route discovery, 381 route error reporting, or route maintenance. The set of signals 382 exchanged between AODVv2 and the forwarding plane are discussed in 383 Section 6.4. 385 AODVv2 is designed for stub or disconnected mobile ad hoc networks, 386 i.e., non-transit networks or those not connected to the internet. 387 AODVv2 can, however, be configured to perform gateway functions when 388 attached to external networks, as discussed in Section 9. 390 AODVv2 handles a wide variety of mobility and traffic patterns by 391 determining routes on-demand. In networks with a large number of 392 routers, AODVv2 is best suited for relatively sparse traffic 393 scenarios where each router forwards IP packets to a small percentage 394 of other AODVv2 routers in the network. In this case fewer routes 395 are needed, and therefore less control traffic is produced. 397 Providing security for a reactive routing protocol can be difficult. 398 AODVv2 provides for message integrity and security against replay 399 attacks by using integrity check values, timestamps and sequence 400 numbers, as described in Section 13. If security associations can be 401 established, encryption can be used for AODVv2 messages to ensure 402 that only trusted routers participate in routing operations. 404 Since the route discovery process aims for a route to be established 405 in both directions along the same path, uni-directional links are not 406 suitable. AODVv2 will detect and exclude those links from route 407 discovery. The route discovered is optimised for the requesting 408 router, and the return path may not be the optimal route. 410 AODVv2 is applicable to memory constrained devices, since only a 411 little routing state is maintained in each AODVv2 router. In 412 contrast to proactive routing protocols, which maintain routing 413 information for all destinations within the MANET, AODVv2 routes that 414 are not needed for forwarding data do not need to be maintained. On 415 routers unable to store persistent AODVv2 state, recovery can impose 416 a performance penalty (e.g., in case of AODVv2 router reboot), since 417 if a router loses its sequence number, there is a delay before the 418 router can resume full operations. This is described in Section 6.1. 420 AODVv2 supports routers with multiple interfaces and multiple IP 421 addresses per interface. A router may also use the same IP address 422 on multiple interfaces. AODVv2 requires only that each interface 423 configured for AODVv2 has at least one unicast IP address. Address 424 assignment procedures are out of scope for AODVv2. 426 AODVv2 supports Router Clients with multiple interfaces, as long as 427 each interface is configured with its own unicast IP address. Multi- 428 homing of a Router Client IP address is not supported by AODVv2, and 429 therefore an IP address SHOULD NOT be configured as a Router Client 430 on more than one AODVv2 router at any one time. 432 Although AODVv2 is closely related to AODV [RFC3561], and shares some 433 features of DSR [RFC4728], AODVv2 is not interoperable with either of 434 those protocols. 436 The routing algorithm in AODVv2 MAY be operated at layers other than 437 the network layer, using layer-appropriate addresses. 439 4. Data Structures 441 4.1. Interface List 443 If multiple interfaces of the AODVv2 router are configured for use by 444 AODVv2, a list of the interfaces MUST be configured in the 445 AODVv2_INTERFACES list. 447 4.2. Router Client Table 449 An AODVv2 router provides route discovery services for its own local 450 applications and for other non-routing devices that are reachable 451 without traversing another AODVv2 router. The addresses used by 452 these devices, and the AODVv2 router itself, are configured in the 453 Router Client Table. An AODVv2 router will only originate Route 454 Request and Route Reply messages on behalf of configured Router 455 Clients. 457 Router Client Table entries MUST contain: 459 RouterClient.IPAddress 460 An IP address or the start of an address range that requires route 461 discovery services from the AODVv2 router. 463 RouterClient.PrefixLength 464 The length, in bits, of the routing prefix associated with the 465 RouterClient.IPAddress. If a prefix length is included, the 466 AODVv2 router MUST provide connectivity for all addresses within 467 that prefix. 469 RouterClient.Cost 470 The cost associated with reaching this Router Client. 472 The Router Client Table for an AODVv2 router is never empty, since an 473 AODVv2 router's interface addresses are always configured in Router 474 Client entries. 476 In the initial state, an AODVv2 router is not required to have 477 information about the Router Clients of any other AODVv2 router. 479 A Router Client address SHOULD NOT be served by more than one AODVv2 480 router at any one time. To shift responsibility for a Router Client 481 to a different AODVv2 router, correct AODVv2 routing behavior MUST be 482 observed. The AODVv2 router adding the Router Client MUST wait for 483 any existing routing information about this Router Client to be 484 purged from the network, i.e., at least MAX_SEQNUM_LIFETIME since the 485 last SeqNum update on the router which is removing this Router 486 Client. 488 4.3. Neighbor Table 490 A Neighbor Table MUST be maintained with information about 491 neighboring AODVv2 routers. Neighbor Table entries are stored when 492 AODVv2 messages are received. If the Neighbor is chosen as a next 493 hop on an installed route, the link to the Neighbor will be tested 494 for bidirectionality and the result stored in this table. A route 495 will only be considered valid when the link is confirmed to be 496 bidirectional. 498 Neighbor Table entries MUST contain: 500 Neighbor.IPAddress 501 An IP address of the neighboring router, learned from the source 502 IP address of a received route message. 504 Neighbor.State 505 Indicates whether the link to the neighbor is bidirectional. 506 There are three possible states: Confirmed, Unknown, and 507 Blacklisted. Unknown is the initial state. Confirmed indicates 508 that the link to the neighbor has been confirmed as bidirectional. 509 Blacklisted indicates that the link to the neighbor is uni- 510 directional. Section 6.2 discusses how to monitor link 511 bidirectionality. 513 Neighbor.ResetTime 514 When the value of Neighbor.State is Blacklisted, this indicates 515 the time at which the value of Neighbor.State will revert to 516 Unknown. By default this value is calculated at the time the 517 router is blacklisted and is equal to CurrentTime + 518 MAX_BLACKLIST_TIME. When the value of Neighbor.State is not 519 Blacklisted, this time is set to INFINITY_TIME. 521 4.4. Sequence Numbers 523 Sequence numbers enable AODVv2 routers to determine the temporal 524 order of route discovery messages, identifying stale routing 525 information so that it can be discarded. The sequence number 526 fulfills the same roles as the "Destination Sequence Number" of DSDV 527 [Perkins94], and the AODV Sequence Number in [RFC3561]. 529 Each AODVv2 router in the network MUST maintain its own sequence 530 number. All RREQ and RREP messages created by an AODVv2 router 531 include the router's sequence number, reported as a 16-bit unsigned 532 integer. Each AODVv2 router MUST ensure that its sequence number is 533 strictly increasing, and that it is incremented by one (1) whenever 534 an RREQ or RREP is created, except when the sequence number is 65,535 535 (the maximum value of a 16-bit unsigned integer), in which case it 536 MUST be reset to one (1). The value zero (0) is reserved to indicate 537 that the sequence number is unknown. 539 An AODVv2 router MUST only attach its own sequence number to 540 information about a route to one of its configured Router Clients. 541 All route messages regenerated by other routers retain the 542 originator's sequence number. Therefore, when two pieces of 543 information about a route are received, they both contain a sequence 544 number from the originating router. Comparing the sequence number 545 will identify which information is stale. The previously stored 546 sequence number is subtracted from the incoming sequence number. The 547 result of the subtraction is to be interpreted as a signed 16-bit 548 integer, and if less than zero, the information in the new AODVv2 549 message is stale and MUST be discarded. 551 This, along with the processes in Section 6.7.1, ensures loop 552 freedom. 554 An AODVv2 router SHOULD maintain its sequence number in persistent 555 storage. If the sequence number is lost, the router MUST follow the 556 procedure in Section 6.1 to safely resume routing operations with a 557 new sequence number. 559 4.5. Local Route Set 561 All AODVv2 routers MUST maintain a Local Route Set, containing 562 information about routes learned from AODVv2 route messages. 563 Implementations MAY choose to modify the Routing Information Base. 564 Alternatively, the Local Route Set is stored separately, and the 565 Routing Information Base is updated using information from the Local 566 Route Set. 568 Routes learned from AODVv2 route messages are referred to in this 569 document as LocalRoutes, and MUST contain the following information: 571 LocalRoute.Address 572 An address, which, when combined with LocalRoute.PrefixLength, 573 describes the set of destination addresses this route includes. 575 LocalRoute.PrefixLength 576 The prefix length, in bits, associated with LocalRoute.Address. 578 LocalRoute.SeqNum 579 The sequence number associated with LocalRoute.Address, obtained 580 from the last route message that successfully updated this entry. 582 LocalRoute.NextHop 583 The source IP address of the IP packet containing the AODVv2 584 message advertising the route to LocalRoute.Address, i.e. an IP 585 address of the AODVv2 router used for the next hop on the path 586 toward LocalRoute.Address. 588 LocalRoute.NextHopInterface 589 The interface used to send IP packets toward LocalRoute.Address. 591 LocalRoute.LastUsed 592 If this route is installed in the Routing Information Base, the 593 time it was last used to forward an IP packet. 595 LocalRoute.LastSeqNumUpdate 596 The time LocalRoute.SeqNum was last updated. 598 LocalRoute.ExpirationTime 599 The time at which this entry must be marked as Invalid. 601 LocalRoute.MetricType 602 The type of metric associated with this route. 604 LocalRoute.Metric 605 The cost of the route toward LocalRoute.Address expressed in units 606 consistent with LocalRoute.MetricType. 608 LocalRoute.State 609 The last known state (Unconfirmed, Idle, Active, or Invalid) of 610 the route. 612 LocalRoute.Precursors (optional feature) 613 A list of upstream neighbors using the route (see Section 10.2). 615 There are four possible states for a LocalRoute: 617 Unconfirmed 618 A route learned from a Route Request message, which has not yet 619 been confirmed as bidirectional. It is not able to be used for 620 forwarding IP packets, and therefore it is not referred to as a 621 valid route. 623 Idle 624 A route which has been learned from a route message, and has also 625 been confirmed, but has not been used in the last ACTIVE_INTERVAL. 626 It is able to be used for forwarding IP packets, and therefore it 627 is referred to as a valid route. 629 Active 630 A route which has been learned from a route message, and has also 631 been confirmed, and has been used in the last ACTIVE_INTERVAL. It 632 is able to be used for forwarding IP packets, and therefore it is 633 referred to as a valid route. 635 Invalid 636 A route which has expired or been lost. It is not able to be used 637 for forwarding IP packets, and therefore it is not referred to as 638 a valid route. Invalid routes contain sequence number information 639 which allows incoming information to be assessed for freshness. 641 When the Local Route State is stored separately from the Routing 642 Information Base, routes are added to the Routing Information Base 643 when LocalRoute.State is valid (set to Active or Idle), and removed 644 from the Routing Information Base LocalRoute.State becomes Invalid. 646 Changes to LocalRoute state are detailed in Section 6.9.1. 648 An AODVv2 router MAY offer a route for a limited time. In this case, 649 the route is referred to as a timed route. The length of time for 650 which the route is valid is referred to as validity time, and is 651 included in messages which advertise the route. The shortened 652 validity time is reflected in LocalRoute.ExpirationTime. If a route 653 is not timed, LocalRoute.ExpirationTime is INFINITY_TIME. 655 Note that multiple entries for the same address, prefix length and 656 metric type may exist in the Local Route Set, but only one will be a 657 valid entry. Any others will be Unconfirmed, but may offer 658 improvement to the existing valid route, if they can be confirmed as 659 valid routes (see Section 6.2). 661 Multiple valid routes for the same address and prefix length but for 662 different metric types may exist in the Local Route Set, but the 663 decision of which of these routes to install in the Routing 664 Information Base to use for forwarding is outside the scope of 665 AODVv2. 667 4.6. Multicast Route Message Table 669 A route message (RteMsg) is either a Route Request or Route Reply 670 message. RREQ messages are multicast by default and regenerated 671 multiple times, and RREP messages may be multicast when the link to 672 the next router is not known to be bidirectional. Multiple similar 673 route messages might be received by any one router during one route 674 discovery attempt. The AODVv2 router does not need to regenerate or 675 respond to every one of these messages. 677 The Multicast Route Message Table is a conceptual table which 678 contains information about previously received multicast route 679 messages, so that incoming route messages can be compared with 680 previously received messages to determine if the incoming information 681 is redundant, and the router can avoid sending redundant control 682 traffic. 684 Multicast Route Message Table entries MUST contain the following 685 information: 687 RteMsg.MessageType 688 Either RREQ or RREP. 690 RteMsg.OrigAddr 691 The source address of the IP packet triggering the route request. 693 RteMsg.OrigPrefixLen 694 The prefix length associated with RteMsg.OrigAddr, originally from 695 the Router Client entry on RREQ_Gen which includes 696 RteMsg.OrigAddr. 698 RteMsg.TargAddr 699 The destination address of the IP packet triggering the route 700 request. 702 RteMsg.TargPrefixLen 703 The prefix length associated with RteMsg.TargAddr, originally from 704 the Router Client entry on RREP_Gen which includes 705 RteMsg.TargAddr. 707 RteMsg.OrigSeqNum 708 The sequence number associated with the route to OrigAddr, if 709 RteMsg is an RREQ. 711 RteMsg.TargSeqNum 712 The sequence number associated with the route to TargAddr, if 713 present in the RteMsg. 715 RteMsg.MetricType 716 The metric type of the route requested. 718 RteMsg.Metric 719 The metric value received in the RteMsg. 721 RteMsg.Timestamp 722 The last time this Multicast Route Message Table entry was 723 updated. 725 RteMsg.RemoveTime 726 The time at which this entry MUST be removed from the Multicast 727 Route Message Table. This is set to CurrentTime + 728 MAX_SEQNUM_LIFETIME, whenever the sequence number of this entry 729 (RteMsg.OrigSeqNum for an RREQ, or RteMsg.TargSeqNum for an RREP) 730 is updated. 732 The Multicast Route Message Table is maintained so that no two 733 entries have the same MessageType, OrigAddr, TargAddr, and 734 MetricType. See Section 6.8 for details about updating this table. 736 5. Metrics 738 Metrics measure a cost or quality associated with a route or a link, 739 e.g., latency, delay, financial cost, energy, etc. Metric values are 740 reported in Route Request and Route Reply messages. 742 In Route Request messages, the metric describes the cost of the route 743 from OrigAddr (and any other addresses included in the prefix length 744 of RREQ_Gen's Router Client entry for OrigAddr) to the router sending 745 the Route Request. For RREQ_Gen, this is the cost associated with 746 the Router Client entry which includes OrigAddr. For routers which 747 regenerate the RREQ, this is the cost from OrigAddr to the 748 regenerating router, combining the metric value from the received 749 RREQ message with knowledge of the link cost from the sender to the 750 receiver, i.e., the incoming link cost. This updated route cost is 751 included when regenerating the Route Request message, and used to 752 install a route back toward OrigAddr. 754 Similarly, in Route Reply messages, the metric reflects the cost of 755 the route from TargAddr (and any other addresses included in the 756 prefix length of RREP_Gen's Router Client entry for TargAddr) to the 757 router sending the Route Reply. For RREP_Gen, this is the cost 758 associated with the Router Client entry which includes TargAddr. For 759 routers which regenerate the RREP, this is the cost from TargAddr to 760 the regenerating router, combining the metric value from the received 761 RREP message with knowledge of the link cost from the sender to the 762 receiver, i.e., the incoming link cost. This updated route cost is 763 included when regenerating the Route Reply message, and used to 764 install a route back toward TargAddr. 766 Assuming link metrics are symmetric, the cost of the routes installed 767 in the Local Route Set at each router will be correct. The route 768 discovered is optimised for the requesting router, and the return 769 path may not be the optimal route. 771 AODVv2 enables the use of multiple metric types. Each route 772 discovery attempt indicates the metric type which is requested for 773 the route. Only one metric type may be used in each route discovery 774 attempt. However, routes to a single destination might be requested 775 and created in the Local Route Set for multiple metric types. The 776 decision of which of these routes to install in the Routing 777 Information Base to use for forwarding is outside the scope of 778 AODVv2. 780 For each MetricType, AODVv2 requires: 782 o A MetricType number, to indicate the metric type of a route. 783 MetricType numbers allocated are detailed in Section 11.6. 785 o A maximum value, denoted MAX_METRIC[MetricType]. If the cost of a 786 route exceeds MAX_METRIC[MetricType], the route is ignored. 787 AODVv2 cannot store routes that cost more than 788 MAX_METRIC[MetricType]. 790 o A function for incoming link cost, denoted Cost(L). Using 791 incoming link costs means that the route learned has a path 792 optimized for the direction from OrigAddr to TargAddr. 794 o A function for route cost, denoted Cost(R). 796 o A function to analyze routes for potential loops based on metric 797 information, denoted LoopFree(R1, R2). LoopFree verifies that a 798 route R2 is not a sub-section of another route R1. An AODVv2 799 router invokes LoopFree() as part of the process in Section 6.7.1, 800 when an advertised route (R1) and an existing LocalRoute (R2) have 801 the same destination address, metric type, and sequence number. 802 LoopFree returns FALSE to indicate that an advertised route is not 803 to be used to update a stored LocalRoute, as it may cause a 804 routing loop. In the case where the existing LocalRoute is 805 Invalid, it is possible that the advertised route includes the 806 existing LocalRoute and came from a router which did not yet 807 receive notification of the route becoming Invalid, so the 808 advertised route should not be used to update the Local Route Set, 809 in case it forms a loop to a broken route. 811 AODVv2 currently supports cost metrics where Cost(R) is strictly 812 increasing, by defining: 814 o Cost(R) := Sum of Cost(L) of each link in the route 816 o LoopFree(R1, R2) := ( Cost(R1) <= Cost(R2) ) 818 Implementers MAY consider other metric types, but the definitions of 819 Cost and LoopFree functions for such types are undefined, and 820 interoperability issues need to be considered. 822 6. AODVv2 Protocol Operations 824 The AODVv2 protocol's operations include managing sequence numbers, 825 monitoring next hop AODVv2 routers on discovered routes and updating 826 the Neighbor Table, performing route discovery and dealing with 827 requests from other routers, processing incoming route information 828 and updating the Local Route Set, updating the Multicast Route 829 Message Table and suppressing redundant messages, and reporting 830 broken routes. These processes are discussed in detail in the 831 following sections. 833 6.1. Initialization 835 During initialization where an AODVv2 router does not have 836 information about its previous sequence number, or if its sequence 837 number is lost at any point, the router resets its sequence number to 838 one (1). However, other AODVv2 routers may still hold sequence 839 number information that this router previously issued. Since 840 sequence number information is removed if there has been no update to 841 the sequence number in MAX_SEQNUM_LIFETIME, the initializing router 842 must wait for MAX_SEQNUM_LIFETIME before it creates any messages 843 containing its new sequence number. It can then be sure that the 844 information it sends will not be considered stale. 846 Until MAX_SEQNUM_LIFETIME after its sequence number is reset, the 847 router SHOULD NOT create RREQ or RREP messages. 849 During this wait period, the router is permitted to do the following: 851 o Process information in a received RREQ or RREP message to learn a 852 route to the originator or target of that route discovery 854 o Regenerate a received RREQ or RREP 856 o Send an RREP_Ack 858 o Maintain valid routes in the Local Route Set 859 o Create, process and regenerate RERR messages 861 6.2. Next Hop Monitoring 863 AODVv2 routers MUST NOT establish routes over uni-directional links. 864 Consider the following. An RREQ is forwarded toward TargAddr, and 865 intermediate routers create a LocalRoute entry in the Local Route Set 866 for the addresses represented by OrigAddr and OrigPrefixLen. If, at 867 one of the intermediate routers, this route was used to forward data 868 traffic, but the link to the next hop toward OrigAddr was uni- 869 directional, the data packets would be lost. Further, an RREP sent 870 toward OrigAddr using this link would not reach the next hop, and 871 would therefore never reach RREQ_Gen, so end-to-end route 872 establishment will fail. 874 AODVv2 routers MUST verify that the link to the next hop router is 875 bidirectional before marking a route as valid in the Local Route Set. 876 If link bidirectionality cannot be verified, this link MUST be 877 excluded from the route discovery procedure. AODVv2 routers do not 878 need to monitor bidirectionality for links to neighboring routers 879 which are not used as next hops on routes in the Local Route Set. 881 o For the next hop router on the route toward OrigAddr, the approach 882 for testing bidirectional connectivity is to request 883 acknowledgement of Route Reply messages. Receipt of an 884 acknowledgement proves that bidirectional connectivity exists. 885 All AODVv2 routers MUST support this process, which is explained 886 in Section 7.2 and Section 7.3. A link to a neighbor is 887 determined to be unidirectional if a requested acknowledgement is 888 not received within RREP_Ack_SENT_TIMEOUT, or bidirectional if the 889 acknowledgement is received within the timeout. 891 o For the next hop router on the route toward TargAddr, receipt of 892 the Route Reply message containing the route to TargAddr is 893 confirmation of bidirectionality, since a Route Reply message is a 894 reply to a Route Request message which previously crossed the link 895 in the opposite direction. 897 To assist with next hop monitoring, a Neighbor Table (Section 4.3) is 898 maintained. When an RREQ or RREP is received from an IP address 899 which does not already have an entry in the Neighbor Table, a new 900 entry is created as described in Section 6.3. While the value of 901 Neighbor.State is Unknown, acknowledgement of RREP messages sent to 902 that neighbor MUST be requested. If an acknowledgement is not 903 received within the timeout period, the neighbor MUST have 904 Neighbor.State set to Blacklisted. If an acknowledgement is received 905 within the timeout period, Neighbor.State is set to Confirmed. While 906 the value of Neighbor.State is Confirmed, the request for an 907 acknowledgement of any other RREP message is unnecessary. 909 When routers perform other operations such as those from the list 910 below, these MAY be used as additional indications of connectivity: 912 o NHDP HELLO Messages [RFC6130] 914 o Route timeout 916 o Lower layer triggers, e.g. message reception or link status 917 notifications 919 o TCP timeouts 921 o Promiscuous listening 923 o Other monitoring mechanisms or heuristics 925 If such an external process signals that the link to a neighbor is 926 bidirectional, the AODVv2 router MAY update the matching Neighbor 927 Table entry by changing the value of Neighbor.State to Confirmed. If 928 an external process signals that a link is not bidirectional, the the 929 value of Neighbor.State MAY be changed to Blacklisted. If an 930 external process signals that the link might not be bidirectional, 931 and the value of Neighbor.State is currently Confirmed, it MAY be set 932 to Unknown. 934 For example, receipt of a Neighborhood Discovery Protocol HELLO 935 message with the receiving router listed as a neighbor is a signal of 936 bidirectional connectivity. The AODVv2 router MAY update the 937 matching Neighbor Table entry by changing the value of Neighbor.State 938 to Confirmed. 940 Similarly, if AODVv2 receives notification of a timeout, for example, 941 from TCP or some other protocol, this may be due to a disconnection. 942 The AODVv2 router MAY update the matching Neighbor Table entry by 943 setting the value of Neighbor.State to Unknown. 945 6.3. Neighbor Table Update 947 On receipt of an RREQ or RREP message, the Neighbor Table MUST be 948 checked for an entry with Neighbor.IPAddress which matches the source 949 IP address of the message. If no matching entry is found, a new 950 entry is created. 952 A new Neighbor Table entry is created as follows: 954 o Neighbor.IPAddress := Source IP address of the received route 955 message 957 o Neighbor.State := Unknown 959 o Neighbor.ResetTime := INFINITY_TIME 961 If the message is an RREP which answers a recently sent RREQ, or an 962 RREP_Ack which answers a recently sent RREP, the link to the neighbor 963 is bidirectional. When the link to the neighbor is determined to be 964 bidirectional, the Neighbor Table entry is updated as follows: 966 o Neighbor.State := Confirmed 968 o Neighbor.ResetTime := INFINITY_TIME 970 If an RREP_Ack is not received within the expected time, the link is 971 considered to be uni-directional. When the link to the neighbor is 972 determined to be uni-directional, the Neighbor Table entry is updated 973 as follows: 975 o Neighbor.State := Blacklisted 977 o Neighbor.ResetTime := CurrentTime + MAX_BLACKLIST_TIME 979 When the Neighbor.ResetTime is reached, the Neighbor Table entry is 980 updated as follows: 982 o Neighbor.State := Unknown 984 When a link to a neighbor is determined to be broken, the Neighbor 985 Table entry SHOULD be removed. 987 Route requests from neighbors with Neighbor.State set to Blacklisted 988 are ignored to avoid persistent IP packet loss or protocol failures. 989 However, Neighbor.ResetTime allows the neighbor to again be allowed 990 to participate in route discoveries after MAX_BLACKLIST_TIME, in case 991 the link between the routers has become bidirectional. 993 6.4. Interaction with the Forwarding Plane 995 A reactive routing protocol reacts when a route is needed, i.e., when 996 an application tries to send a packet and the forwarding plane has no 997 route to the destination of the packet. The fundamental concept of 998 reactive routing is to avoid creating routes that are not needed. 1000 AODVv2 requires signals from the forwarding plane: 1002 o A packet cannot be forwarded because a route is unavailable: 1003 AODVv2 needs to know the source and destination IP addresses of 1004 the packet, to determine if the source of the packet is configured 1005 as a Router Client, in which case the router should initiate route 1006 discovery. If it is not a Router Client, the router should create 1007 a Route Error message. 1009 o A packet is to be forwarded: AODVv2 needs to check the state of 1010 the route to deal with timeouts to ensure the route is still 1011 valid. 1013 o Packet forwarding succeeds: AODVv2 needs to update the record of 1014 when a route was last used to forward a packet. 1016 o Packet forwarding failure occurs: AODVv2 needs to create a Route 1017 Error message. 1019 AODVv2 needs to send signals to the forwarding plane: 1021 o A route discovery is in progress: buffering might be configured 1022 for packets requiring a route, while route discovery is attempted. 1024 o A route discovery failed: any buffered packets requiring that 1025 route should be discarded, and the source of the packet should be 1026 notified that the destination is unreachable (using an ICMP 1027 Destination Unreachable message). Route discovery fails if an 1028 RREQ cannot be generated because the control message generation 1029 limit has been reached, or if an RREP is not received within the 1030 expected time. 1032 o A route discovery is not permitted: any buffered packets requiring 1033 that route should be discarded. A route discovery will not be 1034 attempted if the source address of the packet needing a route is 1035 not configured as a Router Client. 1037 o A route discovery succeeded: install a corresponding route into 1038 the Routing Information Base and begin transmitting any buffered 1039 packets. 1041 o A route has been made invalid: remove the corresponding route from 1042 the Routing Information Base. 1044 o A route has been updated: update the corresponding route in the 1045 Routing Information Base. 1047 These are conceptual signals, and can be implemented in various ways. 1048 Conformant implementations of AODVv2 are not mandated to implement 1049 the forwarding plane separately from the control plane or data plane; 1050 these signals and interactions are identified simply as assistance 1051 for implementers who may find them useful. 1053 6.5. Message Transmission 1055 AODVv2 sends [RFC5444] formatted messages using the parameters for 1056 port number and IP protocol specified in [RFC5498]. Mapping of 1057 AODVv2 data to [RFC5444] messages is detailed in Section 8. AODVv2 1058 multicast messages are sent to the link-local multicast address LL- 1059 MANET-Routers [RFC5498]. All AODVv2 routers MUST subscribe to LL- 1060 MANET-Routers [RFC5498] to receive AODVv2 messages. Note that 1061 multicast messages MAY be sent via unicast. For example, this may 1062 occur for certain link-types (non-broadcast media), for manually 1063 configured router adjacencies, or in order to improve robustness. 1065 When multiple interfaces are available, an AODVv2 router transmitting 1066 a multicast message to LL-MANET-Routers MUST send the message on all 1067 interfaces that have been configured for AODVv2 operation, as given 1068 in the AODVv2_INTERFACES list (Section 4.1). Similarly, AODVv2 1069 routers MUST subscribe to LL-MANET-Routers on all their AODVv2 1070 interfaces. 1072 To avoid congestion, each AODVv2 router's rate of message generation 1073 SHOULD be limited (CONTROL_TRAFFIC_LIMIT) and administratively 1074 configurable. To prioritize transmission of AODVv2 control messages 1075 in order to respect the CONTROL_TRAFFIC_LIMIT: 1077 o Highest priority SHOULD be given to RREP_Ack messages. This 1078 allows links between routers to be confirmed as bidirectional and 1079 avoids undesirable blacklisting of next hop routers. 1081 o Second priority SHOULD be given to RERR messages for undeliverable 1082 IP packets, so that broken routes that are still in use by other 1083 AODVv2 routers can be reported to those routers, to avoid IP data 1084 packets being repeatedly forwarded to AODVv2 routers which cannot 1085 forward them to their destination. 1087 o Third priority SHOULD be given to RREP messages in order that 1088 RREQs do not time out. 1090 o RREQ messages SHOULD be given priority over RERR messages for 1091 newly invalidated routes, since the invalidated routes may not 1092 still be in use, and if there is an attempt to use the route, a 1093 new RERR message will be generated. 1095 o Lowest priority SHOULD be given to RERR messages generated in 1096 response to RREP messages which cannot be regenerated. In this 1097 case the route request will be retried at a later point. 1099 Messages may travel a maximum of MAX_HOPCOUNT hops. 1101 6.6. Route Discovery, Retries and Buffering 1103 AODVv2's RREQ and RREP messages are used for route discovery. RREQ 1104 messages are multicast to solicit an RREP, whereas RREP is unicast 1105 where possible. The constants used in this section are defined in 1106 Section 11. 1108 When an AODVv2 router needs to forward an IP packet (with source 1109 address OrigAddr and destination address TargAddr) from one of its 1110 Router Clients, it needs a route to TargAddr in its Routing 1111 Information Base. If no route exists, the AODVv2 router generates 1112 and multicasts a Route Request message (RREQ) containing OrigAddr and 1113 TargAddr. The procedure for this is described in Section 7.1.1. 1114 Each generated RREQ results in an increment to the router's sequence 1115 number. The AODVv2 router generating an RREQ is referred to as 1116 RREQ_Gen. 1118 Buffering might be configured for IP packets awaiting a route for 1119 forwarding by RREQ_Gen, if sufficient memory is available. Buffering 1120 of IP packets might have both positive and negative effects. Real- 1121 time traffic, voice, and scheduled delivery may suffer if packets are 1122 buffered and subjected to delays, but TCP connection establishment 1123 will benefit if packets are queued while route discovery is performed 1124 [Koodli01]. If packets are not queued, no notification should be 1125 sent to the source. Determining which packets to discard first when 1126 the buffer is full is a matter of policy at each AODVv2 router. 1128 RREQ_Gen awaits reception of a Route Reply message (RREP) containing 1129 a route toward TargAddr. If a valid route to TargAddr is not learned 1130 within RREQ_WAIT_TIME, RREQ_Gen will retry the route discovery. To 1131 reduce congestion in a network, repeated attempts at route discovery 1132 for a particular target address utilize a binary exponential backoff: 1133 for each additional attempt, the time to wait for receipt of the RREP 1134 is multiplied by 2. If the requested route is not learned within the 1135 wait period, another RREQ is sent, up to a total of 1136 DISCOVERY_ATTEMPTS_MAX. This is the same technique used in AODV 1137 [RFC3561]. 1139 The RREQ is received by neighboring AODVv2 routers, and processed and 1140 regenerated as described in Section 7.1. Routers learn a potential 1141 route to OrigAddr (and other addresses as indicated by OrigPrefixLen) 1142 from the RREQ and store it in the Local Route Set. The router 1143 responsible for TargAddr responds by generating a Route Reply message 1144 (RREP) and sends it back toward RREQ_Gen via the next hop on the 1145 potential route to OrigAddr. Each intermediate router learns the 1146 route to TargAddr (and other addresses as indicated by 1147 TargPrefixLen), regenerates the RREP and sends toward OrigAddr. 1149 Links which are not bidirectional cause problems. If a link is 1150 unavailable in the direction toward OrigAddr, an RREP is not received 1151 at the next hop, so cannot be regenerated, and it will never reach 1152 RREQ_Gen. However, since routers monitor bidirectionality to next 1153 hops (Section 6.2), the loss of the RREP will cause the last router 1154 which regenerated the RREP to blacklist the router which did not 1155 receive it. Later, a timeout occurs at RREQ_Gen, and a new RREQ is 1156 generated. If the new RREQ arrives via the blacklisted router, it 1157 will be ignored, enabling the RREQ, if also received from a different 1158 neighbor, to discover a different path toward TargAddr. 1160 Route discovery is considered to have failed after 1161 DISCOVERY_ATTEMPTS_MAX and the corresponding wait time for an RREP 1162 response to the final RREQ. After the attempted route discovery has 1163 failed, RREQ_Gen waits at least RREQ_HOLDDOWN_TIME before attempting 1164 another route discovery to the same destination, in order to avoid 1165 repeatedly generating control traffic that is unlikely to discover a 1166 route. Any IP packets buffered for TargAddr are also dropped and a 1167 Destination Unreachable ICMP message (Type 3) with a code of 1 (Host 1168 Unreachable Error) is delivered to the source of the packet, so that 1169 the application knows about the failure. The source might be an 1170 application on RREQ_Gen itself, or on a difference device. 1172 If RREQ_Gen does receive a route message containing a route to 1173 TargAddr within the timeout, it processes the message according to 1174 Section 7. When a valid LocalRoute entry is created in the Local 1175 Route Set, the route is also installed in the Routing Information 1176 Base, and the router will begin sending the buffered IP packets. Any 1177 retry timers for the corresponding RREQ are then cancelled. 1179 During route discovery, all routers on the path learn a route to both 1180 OrigAddr and TargAddr, so that routes are constructed in both 1181 directions. The route is optimized for the forward route, and the 1182 return route uses the same path in reverse. 1184 6.7. Processing Received Route Information 1186 All AODVv2 route messages contain a route. A Route Request (RREQ) 1187 contains a route toward OrigAddr (and other addresses as indicated by 1188 OrigPrefixLen), and a Route Reply (RREP) contains a route toward 1189 TargAddr (and other addresses as indicated by TargPrefixLen). All 1190 AODVv2 routers that receive a route message are able to store the 1191 route contained within it in their Local Route Set. Incoming 1192 information is first checked to verify that it is both safe to use 1193 and offers an improvement to existing information, as explained in 1194 Section 6.7.1. The Local Route Set MAY then be updated according to 1195 Section 6.7.2. 1197 In the processes below, RteMsg is used to denote the route message, 1198 AdvRte is used to denote the route contained within it, and 1199 LocalRoute denotes an existing entry in the Local Route Set which 1200 matches AdvRte on address, prefix length, and metric type. 1202 AdvRte has the following properties: 1204 o AdvRte.Address := network address given by combining 1205 RteMsg.OrigAddr and RteMsg.OrigPrefixLen (in RREQ) or 1206 RteMsg.TargAddr and RteMsg.TargPrefixLen (in RREP) 1208 o AdvRte.PrefixLength := RteMsg.OrigPrefixLen (in RREQ) or 1209 RteMsg.TargPrefixLen (in RREP). If no prefix length was included 1210 in RteMsg, prefix length is the address length, in bits, of 1211 RteMsg.OrigAddr (in RREQ) or RteMsg.TargAddr (in RREP) 1213 o AdvRte.SeqNum := RteMsg.OrigSeqNum (in RREQ) or RteMsg.TargSeqNum 1214 (in RREP) 1216 o AdvRte.NextHop := RteMsg.IPSourceAddress (an address of the router 1217 from which the RteMsg was received) 1219 o AdvRte.MetricType := RteMsg.MetricType 1221 o AdvRte.Metric := RteMsg.Metric 1223 o AdvRte.Cost := Cost(R) using the cost function associated with the 1224 route's metric type, i.e. Cost(R) = AdvRte.Metric + Cost(L), as 1225 described in Section 5, where L is the link from the advertising 1226 router 1228 o AdvRte.ValidityTime := RteMsg.ValidityTime, if included 1230 6.7.1. Evaluating Route Information 1232 An incoming advertised route (AdvRte) is compared to existing 1233 LocalRoutes to determine whether the advertised route is to be used 1234 to update the AODVv2 Local Route Set. The incoming route information 1235 MUST be processed as follows: 1237 1. Search for a LocalRoute in the Local Route Set matching AdvRte's 1238 address, prefix length and metric type 1240 * If no matching LocalRoute exists, AdvRte MUST be used to 1241 update the Local Route Set. 1243 * If a matching LocalRoute exists, continue to Step 2. 1245 2. Compare sequence numbers using the technique described in 1246 Section 4.4 1248 * If AdvRte is more recent, AdvRte MUST be used to update the 1249 Local Route Set. 1251 * If AdvRte is stale, AdvRte MUST NOT be used to update the 1252 Local Route Set. 1254 * If the sequence numbers are equal, continue to Step 3. 1256 3. Check that AdvRte is safe against routing loops (see Section 5) 1258 * If LoopFree(AdvRte, LocalRoute) returns FALSE, AdvRte MUST NOT 1259 be used to update the Local Route Set because using the 1260 incoming information might cause a routing loop. 1262 * If LoopFree(AdvRte, LocalRoute) returns TRUE, continue to Step 1263 4. 1265 4. Compare route costs 1267 * If AdvRte is better, it SHOULD be used to update the Local 1268 Route Set because it offers improvement. If it is not used to 1269 update the Local Route Set, the existing non-optimal 1270 LocalRoute will continue to be used, causing data traffic to 1271 use a non-optimal route. 1273 * If AdvRte is equal in cost and LocalRoute is valid, AdvRte MAY 1274 be used to update the Local Route Set but will offer no 1275 improvement. 1277 * If AdvRte is worse and LocalRoute is valid, AdvRte MUST NOT be 1278 used to update the Local Route Set because it does not offer 1279 any improvement. 1281 * If AdvRte is not better (i.e., it is worse or equal) but 1282 LocalRoute is Invalid or Unconfirmed, AdvRte SHOULD be used to 1283 update the Local Route Set because it can safely repair the 1284 existing Invalid LocalRoute or offer an alternative to the 1285 existing Unconfirmed route. 1287 If the advertised route is to be used to update the Local Route Set, 1288 the procedure in Section 6.7.2 MUST be followed. If not, non-optimal 1289 routes will remain in the Local Route Set. 1291 6.7.2. Applying Route Updates 1293 After determining that AdvRte is to be used to update the Local Route 1294 Set (as described in Section 6.7.1), the following procedure applies. 1296 If AdvRte is learned from an RREQ message, the link to the next hop 1297 neighbor may not be confirmed as bidirectional (see Section 4.3). 1298 The route will offer improvement to the Local Route Set if the 1299 neighbor can be confirmed. If there is no existing matching route, 1300 AdvRte allows a corresponding RREP to be sent. If a matching entry 1301 already exists, AdvRte offers potential improvement. 1303 The route update is applied as follows: 1305 1. If no existing entry in the Local Route Set matches AdvRte's 1306 address, prefix length and metric type, continue to Step 3 and 1307 create a new entry in the Local Route Set. 1309 2. If a matching entry (LocalRoute) exists in the Local Route Set: 1311 * If AdvRte has a different next hop to LocalRoute, and both 1312 AdvRte.NextHop's Neighbor.State is Unknown and 1313 LocalRoute.State is Active or Idle, the current route is valid 1314 but the advertised route may offer improvement, if the link to 1315 the next hop can be confirmed as bidirectional. AdvRte SHOULD 1316 be stored as an additional entry in the Local Route Set, with 1317 LocalRoute.State set to Unconfirmed. Continue processing from 1318 Step 3 to create a new LocalRoute. 1320 * If AdvRte.NextHop's Neighbor.State is Unknown and 1321 LocalRoute.State is Invalid, the advertised route can replace 1322 the existing LocalRoute. Continue processing from Step 4 to 1323 update the existing LocalRoute. 1325 * If AdvRte.NextHop's Neighbor.State is Confirmed, continue 1326 processing from Step 4 to update the existing LocalRoute. 1328 * If the existing LocalRoute.State is Unconfirmed, continue 1329 processing from Step 3 to create a new LocalRoute. 1331 3. Create an entry in the Local Route Set and initialize as follows: 1333 * LocalRoute.Address := AdvRte.Address 1335 * LocalRoute.PrefixLength := AdvRte.PrefixLength 1337 * LocalRoute.MetricType := AdvRte.MetricType 1339 4. Update the LocalRoute as follows: 1341 * LocalRoute.SeqNum := AdvRte.SeqNum 1343 * LocalRoute.NextHop := AdvRte.NextHop 1345 * LocalRoute.NextHopInterface := interface on which RteMsg was 1346 received 1348 * LocalRoute.Metric := AdvRte.Cost 1350 * LocalRoute.LastUsed := CurrentTime 1352 * LocalRoute.LastSeqNumUpdate := CurrentTime 1354 * LocalRoute.ExpirationTime := CurrentTime + AdvRte.ValidityTime 1355 if a validity time exists, otherwise INFINITY_TIME 1357 5. If a new LocalRoute was created, or if the existing 1358 LocalRoute.State is Invalid or Unconfirmed, update LocalRoute as 1359 follows: 1361 * LocalRoute.State := Unconfirmed (if the next hop's 1362 Neighbor.State is Unknown) or Idle (if the next hop's 1363 Neighbor.State is Confirmed) 1365 6. If an existing LocalRoute.State changed from Invalid or 1366 Unconfirmed to become Idle, any matching LocalRoute with worse 1367 metric value SHOULD be expunged. 1369 7. If this update results in LocalRoute.State of Active or Idle, 1370 which matches a route request which is still in progress, the 1371 associated route request retry timers can be cancelled. 1373 If this update to the Local Route Set results in multiple LocalRoutes 1374 to the same address, the best LocalRoute will be Unconfirmed. In 1375 order to improve the route used for forwarding, the router SHOULD try 1376 to determine if the link to the next hop of that LocalRoute is 1377 bidirectional, by using that LocalRoute to forward future RREPs and 1378 request acknowledgements (see Section 7.2.1). 1380 6.8. Suppressing Redundant Messages Using the Multicast Route Message 1381 Table 1383 When route messages are flooded in a MANET, an AODVv2 router may 1384 receive multiple similar messages. Regenerating every one of these 1385 gives little additional benefit, and generates unnecessary signaling 1386 traffic and might generate unnecessary interference. 1388 Each AODVv2 router stores information about recently received route 1389 messages in the AODVv2 Multicast Route Message Table (Section 4.6). 1391 To create a Multicast Route Message Table Entry: 1393 o RteMsg.MessageType := RREQ or RREP 1395 o RteMsg.OrigAddr := OrigAddr from the message 1397 o RteMsg.OrigPrefixLen := the prefix length associated with OrigAddr 1399 o RteMsg.TargAddr := TargAddr from the message 1401 o RteMsg.TargPrefixLen := the prefix length associated with TargAddr 1403 o RteMsg.OrigSeqNum := the sequence number associated with OrigAddr, 1404 if present in the message 1406 o RteMsg.TargSeqNum := the sequence number associated with TargAddr, 1407 if present in the message 1409 o RteMsg.MetricType := the metric type of the route requested 1411 o RteMsg.Metric := the metric value associated with OrigAddr in an 1412 RREQ or TargAddr in an RREP 1414 o RteMsg.Timestamp := CurrentTime 1416 o RteMsg.RemoveTime := CurrentTime + MAX_SEQNUM_LIFETIME 1418 Entries in the Multicast Route Message Table SHOULD be maintained for 1419 at least RteMsg_ENTRY_TIME after the last Timestamp update in order 1420 to account for long-lived RREQs traversing the network. An entry 1421 MUST be deleted when the sequence number is no longer valid, i.e., 1422 after MAX_SEQNUM_LIFETIME. Memory-constrained devices MAY remove the 1423 entry before this time. 1425 Received route messages are tested against previously received route 1426 messages, and if determined to be redundant, regeneration or response 1427 can be avoided. 1429 To determine if a received message is redundant: 1431 1. Search for an entry in the Multicast Route Message Table with the 1432 same MessageType, OrigAddr, TargAddr, and MetricType 1434 * If there is no entry, the message is not redundant. 1436 * If there is an entry, continue to Step 2. 1438 2. Compare sequence numbers using the technique described in 1439 Section 4.4 1441 * For RREQ messages, use OrigSeqNum of the entry for comparison. 1442 For RREP messages, use TargSeqNum of the entry for comparison. 1444 * If the entry has an older sequence number than the received 1445 message, the message is not redundant. 1447 * If the entry has a newer sequence number than the received 1448 message, the message is redundant. 1450 * If the entry has the same sequence number, continue to Step 3. 1452 3. Compare the metric values 1454 * If the entry has a Metric value that is worse than or equal to 1455 the metric in the received message, the message is redundant. 1457 * If the entry has a Metric value that is better than the metric 1458 in the received message, the message is not redundant. 1460 If the message is redundant, update the Timestamp and RemoveTime on 1461 the entry, since matching route messages are still traversing the 1462 network and this entry should be maintained. This message SHOULD NOT 1463 be regenerated or responded to. 1465 If the message is not redundant, create an entry or update the 1466 existing entry. 1468 To update a Multicast Route Message Table entry, set: 1470 o RteMsg.OrigSeqNum := the sequence number associated with OrigAddr, 1471 if present in the received message 1473 o RteMsg.TargSeqNum := the sequence number associated with TargAddr, 1474 if present in the received message 1476 o RteMsg.Metric := the metric value associated with OrigAddr in a 1477 received RREQ or TargAddr in a received RREP 1479 o RteMsg.Timestamp := CurrentTime 1481 o RteMsg.RemoveTime := CurrentTime + MAX_SEQNUM_LIFETIME 1482 Where the message is determined not redundant before Step 3, it MUST 1483 be regenerated or responded to. Where the message is determined not 1484 redundant in Step 3, it MAY be suppressed to avoid extra control 1485 traffic. However, since the processing of the message will result in 1486 an update to the Local Route Set, the message SHOULD be regenerated 1487 or responded to, to ensure other routers have up-to-date information 1488 and the best metrics. If not regenerated, the best route may not be 1489 found. Where necessary, regeneration or response is performed using 1490 the processes in Section 7. 1492 6.9. Local Route Set Maintenance 1494 Route maintenance involves monitoring LocalRoutes in the Local Route 1495 Set, updating LocalRoute.State to handle route timeouts and reporting 1496 routes that become Invalid. 1498 6.9.1. Local Route State Changes 1500 During normal operation, AODVv2 does not require any explicit 1501 timeouts to manage the lifetime of a route. At any time, any 1502 LocalRoute MAY be examined and updated according to the rules below. 1503 If timers are not used to prompt updates of LocalRoute.State, the 1504 LocalRoute.State MUST be checked before IP packet forwarding and 1505 before any operation based on LocalRoute.State. 1507 Route timeout behaviour is as follows: 1509 o An Unconfirmed route MUST be expunged at MAX_SEQNUM_LIFETIME after 1510 LocalRoute.LastSeqNumUpdate. 1512 o An Idle route MUST become Active when used to forward an IP 1513 packet. If the route is not used to forward an IP packet within 1514 MAX_IDLETIME, LocalRoute.State MUST become Invalid. 1516 o An Active route which is a timed route (i.e., with 1517 LocalRoute.ExpirationTime not equal to INFINITY_TIME) remains 1518 Active until LocalRoute.ExpirationTime, after which it MUST become 1519 Invalid. If it it not a timed route, it MUST become Idle if the 1520 route is not used to forward an IP packet within ACTIVE_INTERVAL. 1522 o An Invalid route SHOULD remain in the Local Route Set, since 1523 LocalRoute.SeqNum is used to classify future information about 1524 LocalRoute.Address as stale or fresh. 1526 o In all cases, if the time since LocalRoute.LastSeqNumUpdate 1527 exceeds MAX_SEQNUM_LIFETIME, LocalRoute.SeqNum must be set to 1528 zero. This is required to ensure that any AODVv2 routers 1529 following the initialization procedure can safely begin routing 1530 functions using a new sequence number, and that their messages 1531 will not be classified as stale and ignored. A LocalRoute with 1532 LocalRoute.State set to Active or Idle can remain in the Local 1533 Route Set after removing the sequence number, but if 1534 LocalRoute.State is Invalid, or later becomes Invalid, the 1535 LocalRoute MUST be expunged from the Local Route Set. 1537 LocalRoutes can become Invalid before a timeout occurs: 1539 o If a link breaks, all LocalRoutes using that link for 1540 LocalRoute.NextHop MUST immediately have LocalRoute.State set to 1541 Invalid. 1543 o If a Route Error (RERR) message containing the route is received, 1544 either from LocalRoute.NextHop, or with PktSource set to a Router 1545 Client address, LocalRoute.State MUST immediately be set to 1546 Invalid. 1548 LocalRoutes are also updated when Neighbor.State is updated: 1550 o While the value of Neighbor.State is set to Unknown, any routes in 1551 the Local Route Set using that neighbor as a next hop MUST have 1552 LocalRoute.State set to Unconfirmed. 1554 o When the value of Neighbor.State is set to Confirmed, the 1555 Unconfirmed routes in the Local Route Set using that neighbor as a 1556 next hop MUST have LocalRoute.State set to Idle. Any other 1557 matching LocalRoutes with metric values worse than 1558 LocalRoute.Metric MUST be expunged from the Local Route Set. 1560 o When the value of Neighbor.State is set to Blacklisted, any valid 1561 routes in the Local Route Set using that neighbor for their next 1562 hop MUST have LocalRoute.State set to Invalid. 1564 o When a Neighbor Table entry is removed, all routes in the Local 1565 Route Set using that neighbor as next hop MUST have 1566 LocalRoute.State set to Invalid. 1568 In some cases, by setting LocalRoute.State to Confirmed when 1569 Neighbor.State is set to Confirmed, an issue can occur if data 1570 packets are forwarded to LocalRoute.Address before the links that 1571 form the rest of the route are confirmed as bidirectional. 1572 Intermediate routers will not have a valid route to forward these 1573 data packets, and will generate a Route Error message. This in turn 1574 results in routes to that destination being removed from other 1575 routers. However, subsequent data packets will cause a new route 1576 discovery attempt to be initiated by the router with the source 1577 address of the data packet configured as a Router Client. 1579 Memory constrained devices MAY choose to expunge routes from the 1580 AODVv2 Local Route Set before LocalRoute.ExpirationTime, but MUST 1581 adhere to the following rules: 1583 o An Active route MUST NOT be expunged, as it is in use. If 1584 deleted, IP traffic forwarded to this router will prompt 1585 generation of a Route Error message, and it will be necessary for 1586 a Route Request to be generated by the originator's router to re- 1587 establish the route. 1589 o An Idle route SHOULD NOT be expunged, as it is still valid for 1590 forwarding IP traffic. If deleted, this could result in dropped 1591 IP packets and a Route Request could be generated to re-establish 1592 the route. 1594 o Any Invalid route MAY be expunged. Least recently used Invalid 1595 routes SHOULD be expunged first, since the sequence number 1596 information is less likely to be useful. 1598 o An Unconfirmed route MUST NOT be expunged if it was installed 1599 within the last RREQ_WAIT_TIME, because it may correspond to a 1600 route discovery in progress. A Route Reply message might be 1601 received which needs to use the LocalRoute.NextHop information. 1602 Otherwise, it MAY be expunged. 1604 6.9.2. Reporting Invalid Routes 1606 When LocalRoute.State changes from Active to Invalid as a result of a 1607 broken link or a received Route Error (RERR) message, other AODVv2 1608 routers MUST be informed by sending an RERR message containing 1609 details of the invalidated route. 1611 An RERR message MUST also be sent when an AODVv2 router receives an 1612 IP packet to forward on behalf of another router but does not have a 1613 valid route in its Routing Information Base for the destination of 1614 the packet. 1616 An RERR message MUST also be sent when an AODVv2 router receives an 1617 RREP message to regenerate, but the LocalRoute to the OrigAddr in the 1618 RREP has been lost or is marked as Invalid. 1620 The packet or message triggering the RERR MUST be discarded. 1622 Generation of an RERR message is described in Section 7.4.1. 1624 7. AODVv2 Protocol Messages 1626 AODVv2 defines four message types: Route Request (RREQ), Route Reply 1627 (RREP), Route Reply Acknowledgement (RREP_Ack), and Route Error 1628 (RERR). 1630 Each AODVv2 message is defined as a set of data. Rules for the 1631 generation, reception and regeneration of each message type are 1632 described in the following sections. Section 8 discusses how the 1633 data is mapped to [RFC5444] Message TLVs, Address Blocks, and Address 1634 TLVs. 1636 7.1. Route Request (RREQ) Message 1638 Route Request messages are used in route discovery operations to 1639 request a route to a specified target address. RREQ messages have 1640 the following contents: 1642 +-----------------------------------------------------------------+ 1643 | msg_hop_limit, (optional) msg_hop_count | 1644 +-----------------------------------------------------------------+ 1645 | AddressList | 1646 +-----------------------------------------------------------------+ 1647 | PrefixLengthList (optional) | 1648 +-----------------------------------------------------------------+ 1649 | OrigSeqNum, (optional) TargSeqNum | 1650 +-----------------------------------------------------------------+ 1651 | MetricType | 1652 +-----------------------------------------------------------------+ 1653 | OrigMetric | 1654 +-----------------------------------------------------------------+ 1655 | ValidityTime (optional) | 1656 +-----------------------------------------------------------------+ 1658 Figure 1: RREQ message contents 1660 msg_hop_limit 1661 The remaining number of hops allowed for dissemination of the RREQ 1662 message. 1664 msg_hop_count 1665 The number of hops already traversed during dissemination of the 1666 RREQ message. 1668 AddressList 1669 Contains OrigAddr and TargAddr, the source and destination 1670 addresses of the IP packet for which a route is requested. 1671 OrigAddr and TargAddr MUST be routable unicast addresses. 1673 PrefixLengthList 1674 Contains OrigPrefixLen, i.e., the length, in bits, of the prefix 1675 associated with the Router Client entry which includes OrigAddr. 1676 If omitted, the prefix length is equal to OrigAddr's address 1677 length in bits. 1679 OrigSeqNum 1680 The sequence number associated with OrigAddr. 1682 TargSeqNum 1683 A sequence number associated with an existing Invalid route to 1684 TargAddr. This MAY be included if available, and is useful for 1685 the optional Intermediate RREP feature (see Section 10.3). 1687 MetricType 1688 The metric type associated with OrigMetric. 1690 OrigMetric 1691 The metric value associated with the LocalRoute to OrigAddr (and 1692 to any other addresses included in the given prefix length), as 1693 seen from the sender of the message. 1695 ValidityTime 1696 The length of time that the message sender is willing to offer a 1697 route toward OrigAddr (and any other addresses included in the 1698 given prefix length). Omitted if no time limit is imposed. 1700 7.1.1. RREQ Generation 1702 An RREQ is generated when an IP packet needs to be forwarded for a 1703 Router Client, and no valid route currently exists for the packet's 1704 destination in the Routing Information Base. 1706 Before creating an RREQ, the router SHOULD check if an RREQ has 1707 recently been sent for the requested destination. If so, and the 1708 wait time for a reply has not yet been reached, the router SHOULD 1709 continue to await a response without generating a new RREQ. If the 1710 timeout has been reached, a new RREQ MAY be generated. If buffering 1711 is configured, incoming IP packets awaiting this route SHOULD be 1712 buffered until the route discovery is completed. 1714 If the limit for the rate of AODVv2 control message generation has 1715 been reached, no message SHOULD be generated. If approaching the 1716 limit, the message should be sent if the priorities in Section 6.5 1717 allow it. 1719 To generate the RREQ, the router (referred to as RREQ_Gen) follows 1720 this procedure: 1722 1. Set msg_hop_limit := MAX_HOPCOUNT 1724 2. Set msg_hop_count := 0, if including it 1726 3. Set AddressList := {OrigAddr, TargAddr} 1728 4. For the PrefixLengthList: 1730 * If OrigAddr is part of an address range configured as a Router 1731 Client, set PrefixLengthList := {RouterClient.PrefixLength, 1732 null}. This allows receiving routers to learn a route to all 1733 the addresses included by the prefix length, not only to 1734 OrigAddr. 1736 * Otherwise, omit PrefixLengthList. 1738 5. For OrigSeqNum: 1740 * Increment the router SeqNum as specified in Section 4.4. 1742 * Set OrigSeqNum := SeqNum. 1744 6. For TargSeqNum: 1746 * If an Invalid route exists in the Local Route Set matching 1747 TargAddr using longest prefix matching and has a valid 1748 sequence number, set TargSeqNum := LocalRoute.SeqNum. 1750 * If no Invalid route exists in the Local Route Set matching 1751 TargAddr, or the route doesn't have a sequence number, omit 1752 TargSeqNum. 1754 7. Include MetricType and set the type accordingly 1756 8. Set OrigMetric := RouterClient.Cost for the Router Client entry 1757 which includes OrigAddr 1759 9. Include ValidityTime if advertising that the route to OrigAddr 1760 (and any other addresses included in the given prefix length) via 1761 this router is offered for a limited time, and set ValidityTime 1762 accordingly 1764 This AODVv2 message is used to create a corresponding [RFC5444] 1765 message (see Section 8) which is multicast, by default, to LL-MANET- 1766 Routers on all interfaces configured for AODVv2 operation. 1768 7.1.2. RREQ Reception 1770 Upon receiving a Route Request, an AODVv2 router performs the 1771 following steps: 1773 1. Update the Neighbor Table according to Section 6.3 1775 * If the sender has Neighbor.State set to Blacklisted after the 1776 update, ignore this RREQ for further processing. 1778 2. Verify that the message hop count, if included, hasn't exceeded 1779 MAX_HOPCOUNT 1781 * If so, ignore this RREQ for further processing. 1783 3. Verify that the message contains the required data: 1784 msg_hop_limit, OrigAddr, TargAddr, OrigSeqNum, and OrigMetric, 1785 and that OrigAddr and TargAddr are valid addresses (routable and 1786 unicast) 1788 * If not, ignore this RREQ for further processing. 1790 4. Check that the MetricType is supported and configured for use 1792 * If not, ignore this RREQ for further processing. 1794 5. Verify that the cost of the advertised route will not exceed the 1795 maximum allowed metric value for the metric type (Metric <= 1796 MAX_METRIC[MetricType] - Cost(L)) 1798 * If it will, ignore this RREQ for further processing. 1800 6. Process the route to OrigAddr (and any other addresses included 1801 in the given prefix length) as specified in Section 6.7 1803 7. Check if the information in the message is redundant by comparing 1804 to entries in the Multicast Route Message table, following the 1805 procedure in Section 6.8 1807 * If redundant, ignore this RREQ for further processing. 1809 * If not redundant, continue processing. 1811 8. Check if the TargAddr belongs to one of the Router Clients 1813 * If so, generate an RREP as specified in Section 7.2.1. 1815 * If not, continue to RREQ regeneration. 1817 7.1.3. RREQ Regeneration 1819 By regenerating an RREQ, a router advertises that it will forward IP 1820 packets to the OrigAddr contained in the RREQ (and to other addresses 1821 included in the given prefix length) according to the information 1822 enclosed. The router MAY choose not to regenerate the RREQ, for 1823 example if the router is heavily loaded or low on energy and 1824 therefore unwilling to advertise routing capability for more traffic. 1825 This could, however, decrease connectivity in the network or result 1826 in non-optimal paths. 1828 The RREQ SHOULD NOT be regenerated if the limit for the rate of 1829 AODVv2 control message generation has been reached. If approaching 1830 the limit, the message should be sent if the priorities in 1831 Section 6.5 allow it. 1833 The procedure for RREQ regeneration is as follows: 1835 1. Set msg_hop_limit := received msg_hop_limit - 1 1837 2. If msg_hop_limit is now zero, do not continue the regeneration 1838 process 1840 3. Set msg_hop_count := received msg_hop_count + 1, if included, 1841 otherwise omit msg_hop_count 1843 4. Set AddressList, PrefixLengthList, sequence numbers and 1844 MetricType to the values in the received RREQ 1846 5. Set OrigMetric := LocalRoute[OrigAddr].Metric 1848 6. If the received RREQ contains a ValidityTime, or if the 1849 regenerating router wishes to limit the time that it offers a 1850 route to OrigAddr (and any other addresses included in the given 1851 prefix length), the regenerated RREQ MUST include ValidityTime 1853 * The ValidityTime is either the time limit the previous AODVv2 1854 router specified, or the time limit this router wishes to 1855 impose, whichever is lower. 1857 This AODVv2 message is used to create a corresponding [RFC5444] 1858 message (see Section 8) which is multicast, by default, to LL-MANET- 1859 Routers on all interfaces configured for AODVv2 operation. However, 1860 the regenerated RREQ can be unicast to the next hop address of the 1861 LocalRoute toward TargAddr, if known. 1863 7.2. Route Reply (RREP) Message 1865 When a Route Request message is received, requesting a route to a 1866 target address (TargAddr) which is configured as part of a Router 1867 Client entry, a Route Reply message is sent in response. The RREP 1868 offers a route to TargAddr (and any other addresses included in the 1869 prefix length). 1871 RREP messages have the following contents: 1873 +-----------------------------------------------------------------+ 1874 | msg_hop_limit, (optional) msg_hop_count | 1875 +-----------------------------------------------------------------+ 1876 | AckReq (optional) | 1877 +-----------------------------------------------------------------+ 1878 | AddressList | 1879 +-----------------------------------------------------------------+ 1880 | PrefixLengthList (optional) | 1881 +-----------------------------------------------------------------+ 1882 | TargSeqNum | 1883 +-----------------------------------------------------------------+ 1884 | MetricType | 1885 +-----------------------------------------------------------------+ 1886 | TargMetric | 1887 +-----------------------------------------------------------------+ 1888 | ValidityTime (optional) | 1889 +-----------------------------------------------------------------+ 1891 Figure 2: RREP message contents 1893 msg_hop_limit 1894 The remaining number of hops allowed for dissemination of the RREP 1895 message. 1897 msg_hop_count 1898 The number of hops already traversed during dissemination of the 1899 RREP message. 1901 AckReq 1902 The address of the intended next hop of the RREP. This is 1903 included when the link to the next hop toward OrigAddr is not 1904 known to be bidirectional. It indicates that an acknowledgement 1905 of the RREP is requested by the sender from the intended next hop 1906 (see Section 6.2). 1908 AddressList 1909 Contains OrigAddr and TargAddr, the source and destination 1910 addresses of the IP packet for which a route is requested. 1911 OrigAddr and TargAddr MUST be routable unicast addresses. 1913 PrefixLengthList 1914 Contains TargPrefixLen, i.e., the length, in bits, of the prefix 1915 associated with the Router Client entry which includes TargAddr. 1916 If omitted, the prefix length is equal to TargAddr's address 1917 length, in bits. 1919 TargSeqNum 1920 The sequence number associated with TargAddr. 1922 MetricType 1923 The metric type associated with TargMetric. 1925 TargMetric 1926 The metric value associated with the LocalRoute to TargAddr (and 1927 any other addresses included in the given prefix length), as seen 1928 from the sender of the message. 1930 ValidityTime 1931 The length of time that the message sender is willing to offer a 1932 route toward TargAddr (and any other addresses included in the 1933 given prefix length). Omitted if no time limit is imposed. 1935 7.2.1. RREP Generation 1937 A Route Reply message is generated when a Route Request arrives, 1938 requesting a route to an address which is configured as a Router 1939 Client of the AODVv2 router. 1941 Before creating an RREP, the router SHOULD check if the corresponding 1942 RREQ is redundant, i.e., a Route Reply has already been generated in 1943 response to the RREQ, or if the limit for the rate of AODVv2 control 1944 message generation has been reached. If so, the RREP SHOULD NOT be 1945 created. If approaching the limit, the message should be sent if the 1946 priorities in Section 6.5 allow it. 1948 The RREP will follow the path of the route to OrigAddr. If the best 1949 route to OrigAddr in the Local Route Set is Unconfirmed, the link to 1950 the next hop neighbor is not yet confirmed as bidirectional (as 1951 described in Section 6.2). In this case the RREP MUST include AckReq 1952 set to the intended next hop address. The AckReq indicates that an 1953 acknowledgement to the RREP is requested from the intended next hop 1954 router in the form of a Route Reply Acknowledgement (RREP_Ack). If 1955 the best route to OrigAddr in the Local Route Set is valid, the link 1956 to the next hop neighbor is already confirmed as bidirectional, and 1957 the AckReq can be omitted. 1959 Implementations MAY allow a number of retries of the RREP if a 1960 requested acknowledgement is not received within 1961 RREP_Ack_SENT_TIMEOUT, doubling the timeout with each retry, up to a 1962 maximum of RREP_RETRIES, using the same exponential backoff described 1963 in Section 6.6 for RREQ retries. The acknowledgement MUST be 1964 considered to have failed after the wait time for an RREP_Ack 1965 response to the final RREP. 1967 To generate the RREP, the router (also referred to as RREP_Gen) 1968 follows this procedure: 1970 1. Set msg_hop_limit := msg_hop_count from the received RREQ 1971 message, if it was included, or MAX_HOPCOUNT if it was not 1972 included 1974 2. Set msg_hop_count := 0, if including it 1976 3. If the link to the next hop router toward OrigAddr is not known 1977 to be bidirectional, include the AckReq with the address of the 1978 intended next hop router 1980 4. Set Address List := {OrigAddr, TargAddr} 1982 5. For the PrefixLengthList: 1984 * If TargAddr is part of an address range configured as a Router 1985 Client, set PrefixLengthList := {null, 1986 RouterClient.PrefixLength}. This allows receiving routers to 1987 learn a route to all the addresses included by the prefix 1988 length, not only to TargAddr. 1990 * Otherwise, omit PrefixLengthList. 1992 6. For the TargSeqNum: 1994 * Increment the router SeqNum as specified in Section 4.4. 1996 * Set TargSeqNum := SeqNum. 1998 7. Include MetricType and set the type to match the MetricType in 1999 the received RREQ message 2001 8. Set TargMetric := RouterClient.Cost for the Router Client entry 2002 which includes TargAddr 2004 9. Include ValidityTime if advertising that the route to TargAddr 2005 (and any other addresses included in the given prefix length) via 2006 this router is offered for a limited time, and set ValidityTime 2007 accordingly 2009 This AODVv2 message is used to create a corresponding [RFC5444] 2010 message (see Section 8). If the Neighbor Table contains an entry for 2011 the neighbor stored as LocalRoute[OrigAddr].NextHop, with 2012 Neighbor.State set to Confirmed, the RREP is sent by unicast to 2013 LocalRoute[OrigAddr].NextHop. Otherwise, the RREP is sent multicast 2014 to LL-MANET-Routers. 2016 7.2.2. RREP Reception 2018 Upon receiving a Route Reply, an AODVv2 router performs the following 2019 steps: 2021 1. Update the Neighbor Table according to Section 6.3 2023 2. Verify that the message hop count, if included, hasn't exceeded 2024 MAX_HOPCOUNT 2026 * If so, ignore this RREQ for further processing. 2028 3. Verify that the message contains the required data: 2029 msg_hop_limit, OrigAddr, TargAddr, TargSeqNum, and TargMetric, 2030 and that OrigAddr and TargAddr are valid addresses (routable and 2031 unicast) 2033 * If not, ignore this RREP for further processing. 2035 4. Check that the MetricType is supported and configured for use 2037 * If not, ignore this RREP for further processing. 2039 5. Verify that the cost of the advertised route does not exceed the 2040 maximum allowed metric value for the metric type (Metric <= 2041 MAX_METRIC[MetricType] - Cost(L)) 2043 * If it does, ignore this RREP for further processing. 2045 6. If the AckReq is present, check the intended recipient of the 2046 received RREP 2048 * If the receiving router is the intended recipient, send an 2049 acknowledgement as specified in Section 7.3 and continue 2050 processing. 2052 * If the receiving router is not the intended recipient, ignore 2053 this RREP for further processing. 2055 7. Process the route to TargAddr (and any other addresses included 2056 in the given prefix length) as specified in Section 6.7 2058 8. Check if the message is redundant by comparing to entries in the 2059 Multicast Route Message table (Section 6.8) 2061 * If redundant, ignore this RREP for further processing. 2063 * If not redundant, save the information in the Multicast Route 2064 Message table to identify future redundant RREP messages and 2065 continue processing. 2067 9. Check if the OrigAddr belongs to one of the Router Clients 2069 * If so, no further processing is necessary. 2071 * If not, continue to Step 10. 2073 10. Check if a valid (Active or Idle) or Unconfirmed LocalRoute 2074 exists to OrigAddr 2076 * If so, continue to RREP regeneration. 2078 * If not, a Route Error message SHOULD be transmitted to 2079 TargAddr according to Section 7.4.1 and the RREP SHOULD be 2080 discarded and not regenerated. 2082 7.2.3. RREP Regeneration 2084 A received Route Reply message is regenerated toward OrigAddr. 2085 Unless the router is prepared to advertise the route contained within 2086 the received RREP, it halts processing. By regenerating a RREP, a 2087 router advertises that it will forward IP packets to TargAddr (and 2088 any other addresses included in the given prefix length) according to 2089 the information enclosed. The router MAY choose not to regenerate 2090 the RREP, in the same way it MAY choose not to regenerate an RREQ 2091 (see Section 7.1.3), though this could decrease connectivity in the 2092 network or result in non-optimal paths. 2094 The RREP SHOULD NOT be regenerated if the limit for the rate of 2095 AODVv2 control message generation has been reached. If approaching 2096 the limit, the message should be sent if the priorities in 2097 Section 6.5 allow it. 2099 If the link to the next hop neighbor on the LocalRoute to OrigAddr is 2100 not yet confirmed as bidirectional (as described in Section 6.2), the 2101 RREP MUST include AckReq set to the intended next hop address, in 2102 order to perform next hop monitoring. If bidirectionality is already 2103 confirmed, the AckReq can be omitted. The AckReq indicates that an 2104 acknowledgement to the RREP is requested in the form of a Route Reply 2105 Acknowledgement (RREP_Ack) from the intended next hop router, within 2106 RREP_Ack_SENT_TIMEOUT. 2108 The procedure for RREP regeneration is as follows: 2110 1. Set msg_hop_limit := received msg_hop_limit - 1 2112 2. If msg_hop_limit is now zero, do not continue the regeneration 2113 process 2115 3. Set msg_hop_count := received msg_hop_count + 1, if it was 2116 included, otherwise omit msg_hop_count 2118 4. If the link to the next hop router toward OrigAddr is not known 2119 to be bidirectional, include the AckReq with the address of the 2120 intended next hop router 2122 5. Set AddressList, PrefixLengthList, TargSeqNum and MetricType to 2123 the values in the received RREP 2125 6. Set TargMetric := LocalRoute[TargAddr].Metric 2127 7. If the received RREP contains a ValidityTime, or if the 2128 regenerating router wishes to limit the time that it will offer a 2129 route to TargAddr (and any other addresses included in the given 2130 prefix length), the regenerated RREP MUST include ValidityTime 2132 * The ValidityTime is either the time limit the previous AODVv2 2133 router specified, or the time limit this router wishes to 2134 impose, whichever is lower. 2136 This AODVv2 message is used to create a corresponding [RFC5444] 2137 message (see Section 8). If the Neighbor Table contains an entry for 2138 the neighbor stored as LocalRoute[OrigAddr].NextHop, with 2139 Neighbor.State set to Confirmed, the RREP is sent by unicast to 2140 LocalRoute[OrigAddr].NextHop. Otherwise, the RREP is sent multicast 2141 to LL-MANET-Routers. 2143 7.3. Route Reply Acknowledgement (RREP_Ack) Message 2145 The Route Reply Acknowledgement is a response to a Route Reply 2146 message. When the RREP_Ack message is received by the sender of the 2147 RREP, it confirms that the link between the two routers is 2148 bidirectional (see Section 6.2). The RREP_Ack has no further data. 2150 7.3.1. RREP_Ack Generation 2152 An RREP_Ack MUST be generated if a received Route Reply includes an 2153 AckReq with an address matching one of the receiving router's IP 2154 addresses. The RREP_Ack SHOULD NOT be generated if the limit for the 2155 rate of AODVv2 control message generation has been reached. 2157 There is no further data in an RREP_Ack. The [RFC5444] 2158 representation is discussed in Section 8. The RREP_Ack is unicast, 2159 by default, to the source IP address of the RREP message that 2160 requested it. 2162 7.3.2. RREP_Ack Reception 2164 Upon receiving an RREP_Ack, an AODVv2 router performs the following 2165 steps: 2167 1. Update the Neighbor Table according to Section 6.3 2169 * If the sender has Neighbor.State set to Blacklisted after the 2170 update, ignore this RREQ for further processing. 2172 2. Check if the RREP_Ack was expected from the IP source address of 2173 the RREP_Ack, in response to an RREP sent previously by this 2174 router 2176 * If it was expected, the router cancels any associated 2177 timeouts. 2179 * If it was not expected, no actions are required. 2181 7.4. Route Error (RERR) Message 2183 A Route Error message is generated by an AODVv2 router to notify 2184 other AODVv2 routers of routes that are no longer available. An RERR 2185 message has the following contents: 2187 +-----------------------------------------------------------------+ 2188 | msg_hop_limit | 2189 +-----------------------------------------------------------------+ 2190 | PktSource (optional) | 2191 +-----------------------------------------------------------------+ 2192 | AddressList | 2193 +-----------------------------------------------------------------+ 2194 | PrefixLengthList (optional) | 2195 +-----------------------------------------------------------------+ 2196 | SeqNumList (optional) | 2197 +-----------------------------------------------------------------+ 2198 | MetricTypeList | 2199 +-----------------------------------------------------------------+ 2201 Figure 3: RERR message contents 2203 msg_hop_limit 2204 The remaining number of hops allowed for dissemination of the RERR 2205 message. 2207 PktSource 2208 The source address of the IP packet triggering the RERR. If the 2209 RERR is triggered by a broken link, PktSource is not required. 2211 AddressList 2212 The addresses of the routes not available through RERR_Gen. 2214 PrefixLengthList 2215 The prefix lengths, in bits, associated with the routes not 2216 available through RERR_Gen. These values indicate whether routes 2217 represent a single device or an address range. 2219 SeqNumList 2220 The sequence numbers of the routes not available through RERR_Gen 2221 (where known). 2223 MetricTypeList 2224 The metric types associated with the routes not available through 2225 RERR_Gen. 2227 7.4.1. RERR Generation 2229 A Route Error message is generated when an AODVv2 router (also 2230 referred to as RERR_Gen) needs to report that a destination is not 2231 reachable. There are three events that cause this response: 2233 o When an IP packet that has been forwarded from another router, but 2234 cannot be forwarded further because there is no valid route in the 2235 Routing Information Base for its destination, the source of the 2236 packet needs to be informed that the route to the destination of 2237 the packet does not exist. The RERR generated MUST include 2238 PktSource set to the source address of the IP packet, and MUST 2239 contain only one unreachable address in the AddressList, i.e., the 2240 destination address of the IP packet. RERR_Gen MUST discard the 2241 IP packet that triggered generation of the RERR. The prefix 2242 length and sequence number MAY be included if known from an 2243 Invalid LocalRoute entry to PktSource. The MetricTypeList MUST 2244 also be included if a MetricType can be determined from the IP 2245 packet or an existing Invalid LocalRoute to the unreachable 2246 address. 2248 o When an RREP message cannot be regenerated because the LocalRoute 2249 to OrigAddr has been lost or is Invalid, RREP_Gen needs to be 2250 informed that the route to OrigAddr does not exist. The RERR 2251 generated MUST include PktSource set to the TargAddr of the RREP, 2252 and MUST contain only one unreachable address in the AddressList, 2253 the OrigAddr from the RREP. RERR_Gen MUST discard the RREP 2254 message that triggered generation of the RERR. The prefix length, 2255 sequence number and metric type SHOULD be included if known from 2256 an Invalid LocalRoute to the unreachable address. 2258 o When a link breaks, multiple LocalRoutes may become Invalid, and 2259 the RERR generated MAY contain multiple unreachable addresses. 2260 The RERR MUST include MetricTypeList. PktSource is omitted. All 2261 previously Active LocalRoutes that used the broken link MUST be 2262 reported. The AddressList, PrefixLengthList, SeqNumList, and 2263 MetricTypeList will contain entries for each LocalRoute which has 2264 become Invalid. An RERR message is only sent if an Active 2265 LocalRoute becomes Invalid, though an AODVv2 router can also 2266 include Idle LocalRoutes that become Invalid if the configuration 2267 parameter ENABLE_IDLE_IN_RERR is set (see Section 11.3). 2269 In order to avoid flooding the network with RERR messages when a 2270 stream of IP packets to an unreachable address arrives, an AODVv2 2271 router SHOULD determine whether an RERR has recently been sent with 2272 the same unreachable address and PktSource, and SHOULD avoid creating 2273 duplicate RERR messages. 2275 The RERR SHOULD NOT be generated if the limit for the rate of AODVv2 2276 control message generation has been reached. If approaching the 2277 limit, the message should be sent if the priorities in Section 6.5 2278 allow it. 2280 Incidentally, if an AODVv2 router receives an ICMP error packet to or 2281 from the address of one of its Router Clients, it forwards the ICMP 2282 packet in the same way as any other IP packet, and will not generate 2283 any RERR message based on the contents of the ICMP packet. 2285 To generate the RERR, the router follows this procedure: 2287 1. Set msg_hop_limit := MAX_HOPCOUNT 2289 2. If necessary, include PktSource and set the value as given above 2291 3. For each LocalRoute that needs to be reported: 2293 * Insert LocalRoute.Address into the AddressList. 2295 * Insert LocalRoute.PrefixLength into PrefixLengthList, if known 2296 and not equal to the address length. 2298 * Insert LocalRoute.SeqNum into SeqNumList, if known. 2300 * Insert LocalRoute.MetricType into MetricTypeList. 2302 The AODVv2 message is used to create a corresponding [RFC5444] 2303 message (see Section 8). 2305 If the RERR is sent in response to an undeliverable IP packet or RREP 2306 message, i.e., if PktSource is included, the RERR SHOULD be sent 2307 unicast to the next hop on the route to PktSource, or alternatively, 2308 if there is no route to PktSource, the RERR MUST be multicast to LL- 2309 MANET-Routers. If the RERR is sent in response to a broken link, 2310 i.e., PktSource is not included, the RERR is, by default, multicast 2311 to LL-MANET-Routers. 2313 Section 10.2 describes processing steps when the optional precursor 2314 lists feature is enabled. 2316 7.4.2. RERR Reception 2318 Upon receiving a Route Error, an AODVv2 router performs the following 2319 steps: 2321 1. Verify that the message contains the required data: msg_hop_limit 2322 and at least one unreachable address 2324 * If not, ignore this RERR for further processing. 2326 2. For each address in the AddressList, check that: 2328 * The address is valid (routable and unicast) 2329 * The MetricType is supported and configured for use 2331 * There is a valid LocalRoute with the same MetricType matching 2332 the address using longest prefix matching 2334 * Either the LocalRoute's next hop is the sender of the RERR and 2335 the next hop interface is the interface on which the RERR was 2336 received, or PktSource is present in the RERR and is a Router 2337 Client address 2339 * The unreachable address' sequence number is either unknown, or 2340 is greater than the LocalRoute's sequence number 2342 If any of the above are false, a matching LocalRoute MUST NOT be 2343 made Invalid and the unreachable address MUST NOT be advertised 2344 in a regenerated RERR. 2346 If all of the above are true, the LocalRoute is no longer valid. 2347 If the LocalRoute was previously Active, it MUST be reported in a 2348 regenerated RERR. If the LocalRoute was previously Idle, it MAY 2349 be reported in a regenerated RERR, if ENABLE_IDLE_IN_RERR is 2350 configured. The Local Route Set MUST be updated according to 2351 these rules: 2353 * If the LocalRoute's prefix length is the same as the 2354 unreachable address' prefix length, set LocalRoute.State to 2355 Invalid. 2357 * If the LocalRoute's prefix length is longer than the 2358 unreachable address' prefix length, the LocalRoute MUST be 2359 expunged from the Local Route Set, since it is a sub-route of 2360 the route which is reported to be Invalid. 2362 * If the prefix length is different, create a new LocalRoute 2363 with the unreachable address, and its prefix length and 2364 sequence number, and set LocalRoute.State to Invalid. 2366 * Update the sequence number on the existing LocalRoute, if the 2367 reported sequence number is determined to be newer using the 2368 comparison technique described in Section 4.4. 2370 3. Check if there are unreachable addresses which MUST be reported 2371 in a regenerated RERR 2373 * If so, regenerate the RERR as detailed in Section 7.4.3. 2375 * If not, take no further action. 2377 7.4.3. RERR Regeneration 2379 The Route Error message SHOULD NOT be regenerated if the limit for 2380 the rate of AODVv2 control message generation has been reached. If 2381 approaching the limit, the message should be sent if the priorities 2382 in Section 6.5 allow it. 2384 The procedure for RERR regeneration is as follows: 2386 1. Set msg_hop_limit := received msg_hop_limit - 1 2388 2. If msg_hop_limit is now zero, do not continue the regeneration 2389 process 2391 3. If PktSource was included in the original RERR, and PktSource is 2392 not a Router Client, copy it into the regenerated RERR 2394 4. For each LocalRoute that needs to be reported: 2396 * Insert LocalRoute.Address into the AddressList. 2398 * Insert LocalRoute.PrefixLength into PrefixLengthList, if known 2399 and not equal to the address length. 2401 * Insert LocalRoute.SeqNum into SeqNumList, if known. 2403 * Insert LocalRoute.MetricType into MetricTypeList. 2405 The AODVv2 message is used to create a corresponding [RFC5444] 2406 message (see Section 8). If the RERR contains PktSource, the 2407 regenerated RERR SHOULD be sent unicast to the next hop on the 2408 LocalRoute to PktSource, or alternatively if there is no route to 2409 PktSource, or PktSource is a Router Client, it MUST be multicast to 2410 LL-MANET-Routers. If the RERR is sent in response to a broken link, 2411 the RERR is, by default, multicast to LL-MANET-Routers. 2413 8. RFC 5444 Representation 2415 AODVv2 specifies that all control messages between routers MUST use 2416 the Generalized Mobile Ad Hoc Network Packet/Message Format 2417 [RFC5444], and therefore AODVv2's route messages comprise data which 2418 is mapped to message elements in [RFC5444]. 2420 [RFC5444] provides a multiplexed transport for multiple protocols. 2421 An [RFC5444] multiplexer MAY choose to optimize the content of 2422 certain message elements to reduce control message overhead. 2424 A brief summary of the [RFC5444] format: 2426 1. A packet contains zero or more messages 2428 2. A message contains a Message Header, one Message TLV Block, zero 2429 or more Address Blocks, and one Address Block TLV Block per 2430 Address Block 2432 3. The Message TLV Block MAY contain zero or more Message TLVs 2434 4. An Address Block TLV Block MAY include zero or more Address Block 2435 TLVs 2437 5. Each TLV value in an Address Block TLV Block can be associated 2438 with all of the addresses, or with a contiguous set of addresses, 2439 or with a single address in the Address Block 2441 AODVv2 does not require access to the [RFC5444] packet header. 2443 In the message header, AODVv2 uses , , 2444 and . The field 2445 indicates the length of any addresses in the message, using := (address length in octets - 1), i.e. 3 for IPv4 and 2447 15 for IPv6. 2449 The addresses in an Address Block MAY appear in any order, and values 2450 in a TLV in the Address Block TLV Block must be associated with the 2451 correct address in the Address Block by the [RFC5444] implementation. 2452 To indicate which value is associated with each address, the AODVv2 2453 message representation uses lists where the order of the addresses in 2454 the AODVv2 AddressList matches the order of values in other data 2455 lists, e.g., the order of SeqNums in the SeqNumList in an RERR. 2456 [RFC5444] maps this information to Address Block TLVs associated with 2457 the relevant addresses in the Address Block. 2459 Each address included in the Address Block is identified as OrigAddr, 2460 TargAddr, PktSource, or Unreachable Address by including an 2461 ADDRESS_TYPE TLV in the Address Block TLV Block. 2463 The following sections show how AODVv2 data is represented in 2464 [RFC5444] messages. AODVv2 makes use of the VALIDITY_TIME TLV from 2465 [RFC5497], and defines (in Section 12) a number of new TLVs. 2467 Where the extension type of a TLV is set to zero, this is the default 2468 [RFC5444] value and the extension type will not be included in the 2469 message. 2471 8.1. Route Request Message Representation 2473 8.1.1. Message Header 2475 +---------------+-----------------+---------------------------------+ 2476 | Data | Header Field | Value | 2477 +---------------+-----------------+---------------------------------+ 2478 | None | | RREQ | 2479 | msg_hop_limit | | MAX_HOPCOUNT, reduced by number | 2480 | | | of hops traversed so far by the | 2481 | | | message. | 2482 | msg_hop_count | | Number of hops traversed so far | 2483 | | | by the message. | 2484 +---------------+-----------------+---------------------------------+ 2486 8.1.2. Message TLV Block 2488 An RREQ contains no Message TLVs. 2490 8.1.3. Address Block 2492 An RREQ contains two addresses, OrigAddr and TargAddr, and each 2493 address has an associated prefix length. If the prefix length has 2494 not been included in the AODVv2 message, it is equal to the address 2495 length in bits. 2497 +-------------------------+------------------------------+ 2498 | Data | Address Block | 2499 +-------------------------+------------------------------+ 2500 | OrigAddr/OrigPrefixLen |
+ | 2501 | TargAddr/TargPrefixLen |
+ | 2502 +-------------------------+------------------------------+ 2504 8.1.4. Address Block TLV Block 2506 Address Block TLVs are always associated with one or more addresses 2507 in the Address Block. The following sections show the TLVs that 2508 apply to each address. 2510 8.1.4.1. Address Block TLVs for OrigAddr 2511 +--------------+---------------+------------+-----------------------+ 2512 | Data | TLV Type | Extension | Value | 2513 | | | Type | | 2514 +--------------+---------------+------------+-----------------------+ 2515 | None | ADDRESS_TYPE | 0 | ADDRTYPE_ORIGADDR | 2516 | OrigSeqNum | SEQ_NUM | 0 | Sequence number of | 2517 | | | | RREQ_Gen, the router | 2518 | | | | which initiated route | 2519 | | | | discovery. | 2520 | OrigMetric | PATH_METRIC | MetricType | Metric value for the | 2521 | /MetricType | | | route to OrigAddr, | 2522 | | | | using MetricType. | 2523 | ValidityTime | VALIDITY_TIME | 0 | ValidityTime for | 2524 | | | | route to OrigAddr. | 2525 +--------------+---------------+------------+-----------------------+ 2527 8.1.4.2. Address Block TLVs for TargAddr 2529 +------------+--------------+-------------+-------------------------+ 2530 | Data | TLV Type | Extension | Value | 2531 | | | Type | | 2532 +------------+--------------+-------------+-------------------------+ 2533 | None | ADDRESS_TYPE | 0 | ADDRTYPE_TARGADDR | 2534 | TargSeqNum | SEQ_NUM | 0 | The last known | 2535 | | | | TargSeqNum for | 2536 | | | | TargAddr. | 2537 +------------+--------------+-------------+-------------------------+ 2539 8.2. Route Reply Message Representation 2541 8.2.1. Message Header 2543 +---------------+-----------------+---------------------------------+ 2544 | Data | Header Field | Value | 2545 +---------------+-----------------+---------------------------------+ 2546 | None | | RREP | 2547 | msg_hop_limit | | from | 2548 | | | corresponding RREQ, reduced by | 2549 | | | number of hops traversed so far | 2550 | | | by the message. | 2551 | msg_hop_count | | Number of hops traversed so far | 2552 | | | by the message. | 2553 +---------------+-----------------+---------------------------------+ 2555 8.2.2. Message TLV Block 2557 An RREP contains no Message TLVs. 2559 8.2.3. Address Block 2561 An RREP contains a minimum of two addresses, OrigAddr and TargAddr, 2562 and each address has an associated prefix length. If the prefix 2563 length has not been included in the AODVv2 message, it is equal to 2564 the address length in bits. 2566 It MAY also contain the address of the intended next hop, in order to 2567 request acknowledgement to confirm bidirectionality of the link, as 2568 described in Section 6.2. The prefix length associated with this 2569 address is equal to the address length in bits. 2571 +-------------------------+------------------------------+ 2572 | Data | Address Block | 2573 +-------------------------+------------------------------+ 2574 | OrigAddr/OrigPrefixLen |
+ | 2575 | TargAddr/TargPrefixLen |
+ | 2576 | AckReq |
+ | 2577 +-------------------------+------------------------------+ 2579 8.2.4. Address Block TLV Block 2581 Address Block TLVs are always associated with one or more addresses 2582 in the Address Block. The following sections show the TLVs that 2583 apply to each address. 2585 8.2.4.1. Address Block TLVs for OrigAddr 2587 +-------+---------------+-----------------+--------------------+ 2588 | Data | TLV Type | Extension Type | Value | 2589 +-------+---------------+-----------------+--------------------+ 2590 | None | ADDRESS_TYPE | 0 | ADDRTYPE_ORIGADDR | 2591 +-------+---------------+-----------------+--------------------+ 2593 8.2.4.2. Address Block TLVs for TargAddr 2594 +--------------+---------------+------------+-----------------------+ 2595 | Data | TLV Type | Extension | Value | 2596 | | | Type | | 2597 +--------------+---------------+------------+-----------------------+ 2598 | None | ADDRESS_TYPE | 0 | ADDRTYPE_TARGADDR | 2599 | TargSeqNum | SEQ_NUM | 0 | Sequence number of | 2600 | | | | RREP_Gen, the router | 2601 | | | | which created the | 2602 | | | | RREP. | 2603 | TargMetric | PATH_METRIC | MetricType | Metric value for the | 2604 | /MetricType | | | route to TargAddr, | 2605 | | | | using MetricType. | 2606 | ValidityTime | VALIDITY_TIME | 0 | ValidityTime for | 2607 | | | | route to TargAddr. | 2608 +--------------+---------------+------------+-----------------------+ 2610 8.2.4.3. Address Block TLVs for AckReq Intended Recipient Address 2612 +-------+---------------+-----------------+------------------+ 2613 | Data | TLV Type | Extension Type | Value | 2614 +-------+---------------+-----------------+------------------+ 2615 | None | ADDRESS_TYPE | 0 | ADDRTYPE_INTEND | 2616 +-------+---------------+-----------------+------------------+ 2618 8.3. Route Reply Acknowledgement Message Representation 2620 8.3.1. Message Header 2622 +-------+---------------+-----------+ 2623 | Data | Header Field | Value | 2624 +-------+---------------+-----------+ 2625 | None | | RREP_Ack | 2626 +-------+---------------+-----------+ 2628 8.3.2. Message TLV Block 2630 An RREP_Ack contains no Message TLVs. 2632 8.3.3. Address Block 2634 An RREP_Ack contains no Address Block. 2636 8.3.4. Address Block TLV Block 2638 An RREP_Ack contains no Address Block TLV Block. 2640 8.4. Route Error Message Representation 2642 Route Error Messages MAY be split into multiple [RFC5444] messages 2643 when the desired contents would exceed the MTU. However, all of the 2644 resulting messages MUST have the same message header as described 2645 below. If PktSource is included in the AODVv2 message, it MUST be 2646 included in all of the resulting [RFC5444] messages. 2648 8.4.1. Message Header 2650 +---------------+-----------------+---------------------------------+ 2651 | Data | Header Field | Value | 2652 +---------------+-----------------+---------------------------------+ 2653 | None | | RERR | 2654 | msg_hop_limit | | MAX_HOPCOUNT, reduced by number | 2655 | | | of hops traversed so far by the | 2656 | | | message. | 2657 +---------------+-----------------+---------------------------------+ 2659 8.4.2. Message TLV Block 2661 An RERR contains no Message TLVs. 2663 8.4.3. Address Block 2665 The Address Block in an RERR MAY contain PktSource, the source 2666 address of the IP packet triggering RERR generation, as detailed in 2667 Section 7.4. The prefix length associated with PktSource is equal to 2668 the address length in bits. 2670 Address Block always contains one address per route that is no longer 2671 valid, and each address has an associated prefix length. If a prefix 2672 length has not been included for this address, it is equal to the 2673 address length in bits. 2675 +------------------------------+------------------------------------+ 2676 | Data | Address Block | 2677 +------------------------------+------------------------------------+ 2678 | PktSource |
+ for | 2679 | | PktSource | 2680 | AddressList/PrefixLengthList |
+ for | 2681 | | each unreachable address in | 2682 | | AddressList | 2683 +------------------------------+------------------------------------+ 2685 8.4.4. Address Block TLV Block 2687 Address Block TLVs are always associated with one or more addresses 2688 in the Address Block. The following sections show the TLVs that 2689 apply to each type of address in the RERR. 2691 8.4.4.1. Address Block TLVs for PktSource 2693 +------------+---------------+----------------+---------------------+ 2694 | Data | TLV Type | Extension Type | Value | 2695 +------------+---------------+----------------+---------------------+ 2696 | PktSource | ADDRESS_TYPE | 0 | ADDRTYPE_PKTSOURCE | 2697 +------------+---------------+----------------+---------------------+ 2699 8.4.4.2. Address Block TLVs for Unreachable Addresses 2701 +----------------+--------------+------------+----------------------+ 2702 | Data | TLV Type | Extension | Value | 2703 | | | Type | | 2704 +----------------+--------------+------------+----------------------+ 2705 | None | ADDRESS_TYPE | 0 | ADDRTYPE_UNREACHABLE | 2706 | SeqNumList | SEQ_NUM | 0 | Sequence number | 2707 | | | | associated with | 2708 | | | | invalid route to the | 2709 | | | | unreachable address. | 2710 | MetricTypeList | PATH_METRIC | MetricType | None. Extension Type | 2711 | | | | set to MetricType of | 2712 | | | | the route to the | 2713 | | | | unreachable address. | 2714 +----------------+--------------+------------+----------------------+ 2716 9. Simple External Network Attachment 2718 Figure 4 shows a stub (i.e., non-transit) network of AODVv2 routers 2719 which is attached to an external network via a single External 2720 Network Access Router (ENAR). The interface to the external network 2721 MUST NOT be configured in the AODVv2_INTERFACES list. 2723 As in any externally-attached network, AODVv2 routers and Router 2724 Clients that wish to be reachable from the external network MUST have 2725 IP addresses within the ENAR's routable and topologically correct 2726 prefix (i.e., 191.0.2.0/24 in Figure 4). This AODVv2 network and 2727 networks attached to routers within it will be advertised to the 2728 external network using procedures which are out of scope for this 2729 specification. 2731 /-------------------------\ 2732 / +----------------+ \ 2733 / | AODVv2 Router | \ 2734 | | 191.0.2.2/32 | | 2735 | +----------------+ | Routable 2736 | +-----+--------+ Prefix 2737 | | ENAR | /191.0.2.0/24 2738 | | AODVv2 Router| / 2739 | | 191.0.2.1 |/ /---------------\ 2740 | | serving net +------+ External \ 2741 | | 191.0.2.0/24 | \ Network / 2742 | +-----+--------+ \---------------/ 2743 | +----------------+ | 2744 | | AODVv2 Router | | 2745 | | 191.0.2.3/32 | | 2746 \ +----------------+ / 2747 \ / 2748 \-------------------------/ 2750 Figure 4: Simple External Network Attachment Example 2752 When an AODVv2 router within the AODVv2 MANET wants to discover a 2753 route toward an address on the external network, it uses the normal 2754 AODVv2 route discovery for that IP Destination Address. The ENAR 2755 MUST respond to RREQ on behalf of all external network destinations, 2756 i.e., destinations not on the configured 191.0.2.0/24 network. RREQs 2757 for addresses inside the AODVv2 network, i.e. destinations on the 2758 configured 191.0.2.0/24 network, are handled using the standard 2759 processes described in Section 7. 2761 When an IP packet from an address on the external network destined 2762 for an address in the AODVv2 MANET reaches the ENAR, if the ENAR does 2763 not have a route toward that exact destination in its Routing 2764 Information Base, it will perform normal AODVv2 route discovery for 2765 that destination. 2767 Configuring the ENAR as a default router is outside the scope of this 2768 specification. 2770 10. Optional Features 2772 A number of optional features for AODVv2, associated initially with 2773 AODV, MAY be useful in networks with greater mobility or larger 2774 populations, or networks requiring reduced latency for application 2775 launches. These features are not required by minimal 2776 implementations. 2778 10.1. Expanding Rings Multicast 2780 For multicast RREQ, msg_hop_limit MAY be set in accordance with an 2781 expanding ring search as described in [RFC3561] to limit the RREQ 2782 propagation to a subset of the local network and possibly reduce 2783 route discovery overhead. 2785 10.2. Precursor Lists 2787 This section specifies an interoperable enhancement to AODVv2 2788 enabling more economical Route Error notifications. 2790 There can be several sources of traffic for a certain destination. 2791 Each source of traffic and each upstream router between the 2792 forwarding AODVv2 router and the traffic source is known as a 2793 "precursor" for the destination. For each destination, an AODVv2 2794 router MAY choose to keep track of precursors that have provided 2795 traffic for that destination. Route Error messages about that 2796 destination can be sent unicast to these precursors instead of 2797 multicast to all AODVv2 routers. 2799 Since an RERR will be regenerated if it comes from a next hop on a 2800 valid LocalRoute, the RERR SHOULD ideally be sent backwards along the 2801 route that the source of the traffic uses, to ensure it is 2802 regenerated at each hop and reaches the traffic source. If the 2803 reverse path is unknown, the RERR SHOULD be sent toward the source 2804 along some other route. Therefore, the options for saving precursor 2805 information are as follows: 2807 o Save the next hop on an existing route to the IP packet's source 2808 address as the precursor. In this case, it is not guaranteed that 2809 an RERR that is sent will follow the reverse of the source's 2810 route. In rare situations, this may prevent the route from being 2811 invalidated at the source of the data traffic. 2813 o Save the IP packet's source address as the precursor. In this 2814 case, the RERR can be sent along any existing route to the source 2815 of the data traffic, and SHOULD include PktSource to ensure that 2816 the route will be invalidated at the source of the traffic, in 2817 case the RERR does not follow the reverse of the source's route. 2819 o By inspecting the MAC address of each forwarded IP packet, 2820 determine which router forwarded the packet, and save the router 2821 address as a precursor. This ensures that when an RERR is sent to 2822 the precursor router, the route will be invalidated at that 2823 router, and the RERR will be regenerated toward the source of the 2824 IP packet. 2826 During normal operation, each AODVv2 router maintaining precursor 2827 lists for a LocalRoute must update the precursor list whenever it 2828 uses this route to forward traffic to the destination. Precursors 2829 are classified as Active if traffic has recently been forwarded by 2830 the precursor. The precursor is marked with a timestamp to indicate 2831 the time it last forwarded traffic on this route. 2833 When an AODVv2 router detects that one or more LocalRoutes are 2834 broken, it MAY notify each Active precursor using a unicast Route 2835 Error message instead of creating multicast traffic. Unicast is 2836 applicable when there are few Active precursors compared to the 2837 number of neighboring AODVv2 routers. However, the default multicast 2838 behavior is still preferable when there are many precursors, since 2839 fewer message transmissions are required. 2841 When an AODVv2 router supporting precursor lists receives an RERR 2842 message, it MAY identify the list of its own affected Active 2843 precursors for the routes in the RERR, and choose to send a unicast 2844 RERR to those, rather than send a multicast RERR. 2846 When a LocalRoute is expunged, any precursor list associated with it 2847 MUST also be expunged. 2849 10.3. Intermediate RREP 2851 Without iRREP, only the AODVv2 router responsible for the target 2852 address can respond to an RREQ. Using iRREP, route discoveries can 2853 be faster and create less control traffic. This specification has 2854 been published as a separate Internet Draft [I-D.perkins-irrep]. 2856 10.4. Message Aggregation Delay 2858 The aggregation of multiple messages into a packet is specified in 2859 [RFC5444]. 2861 Implementations MAY choose to briefly delay transmission of messages 2862 for the purpose of aggregation (into a single packet) or to improve 2863 performance by using jitter [RFC5148]. 2865 11. Configuration 2867 AODVv2 uses various parameters which can be grouped into the 2868 following categories: 2870 o Timers 2872 o Protocol constants 2873 o Administrative parameters and controls 2875 This section show the parameters along with their definitions and 2876 default values (if any). 2878 Note that several fields have limited size (bits or bytes). These 2879 sizes and their encoding may place specific limitations on the values 2880 that can be set. 2882 11.1. Timers 2884 AODVv2 requires certain timing information to be associated with 2885 Local Route Set entries and message replies. The default values are 2886 as follows: 2888 +------------------------+----------------+ 2889 | Name | Default Value | 2890 +------------------------+----------------+ 2891 | ACTIVE_INTERVAL | 5 second | 2892 | MAX_IDLETIME | 200 seconds | 2893 | MAX_BLACKLIST_TIME | 200 seconds | 2894 | MAX_SEQNUM_LIFETIME | 300 seconds | 2895 | RteMsg_ENTRY_TIME | 12 seconds | 2896 | RREQ_WAIT_TIME | 2 seconds | 2897 | RREP_Ack_SENT_TIMEOUT | 1 second | 2898 | RREQ_HOLDDOWN_TIME | 10 seconds | 2899 +------------------------+----------------+ 2901 Table 2: Timing Parameter Values 2903 The above timing parameter values have worked well for small and 2904 medium well-connected networks with moderate topology changes. The 2905 timing parameters SHOULD be administratively configurable. Ideally, 2906 for networks with frequent topology changes the AODVv2 parameters 2907 SHOULD be adjusted using experimentally determined values or dynamic 2908 adaptation. For example, in networks with infrequent topology 2909 changes MAX_IDLETIME MAY be set to a much larger value. 2911 If MAX_SEQNUM_LIFETIME was configured differently across the network, 2912 and any of the routers lost their sequence number or rebooted, this 2913 could result in their next route messages being classified as stale 2914 at any AODVv2 router using a greater value for MAX_SEQNUM_LIFETIME. 2915 This would delay route discovery from and to the re-initializing 2916 router. 2918 11.2. Protocol Constants 2920 AODVv2 protocol constants typically do not require changes. The 2921 following table lists these constants, along with their values and a 2922 reference to the section describing their use. 2924 +------------------------+---------+--------------------------------+ 2925 | Name | Default | Description | 2926 +------------------------+---------+--------------------------------+ 2927 | DISCOVERY_ATTEMPTS_MAX | 3 | Section 6.6 | 2928 | RREP_RETRIES | 2 | Section 7.2.1 | 2929 | MAX_METRIC[MetricType] | [TBD] | Section 5 | 2930 | MAX_METRIC[HopCount] | 255 | Section 5 and Section 7 | 2931 | MAX_HOPCOUNT | 20 | Limit to number of hops an | 2932 | | | AODVv2 message can traverse | 2933 | INFINITY_TIME | [TBD] | Maximum expressible clock time | 2934 | | | (Section 6.7.2) | 2935 +------------------------+---------+--------------------------------+ 2937 Table 3: AODVv2 Constants 2939 Note that is an 8-bit field in the [RFC5444] message 2940 header and therefore MAX_HOPCOUNT cannot be larger than 255. 2942 MAX_METRIC[MetricType] MUST always be the maximum expressible metric 2943 value of type MetricType. Field lengths associated with metric 2944 values are found in Section 11.6. 2946 These protocol constants MUST have the same values for all AODVv2 2947 routers in the ad hoc network. If the values were configured 2948 differently, the following consequences may be observed: 2950 o DISCOVERY_ATTEMPTS_MAX: Routers with higher values are likely to 2951 be more successful at finding routes, at the cost of additional 2952 control traffic. 2954 o RREP_RETRIES: Routers with lower values are more likely to 2955 blacklist neighbors when there is a 2957 o MAX_METRIC[MetricType]: No interoperability problems due to 2958 variations on different routers, but routers with lower values may 2959 exhibit overly restrictive behavior during route comparisons. 2960 temporary fluctuation in link quality. 2962 o MAX_HOPCOUNT: Routers with a value too small would not be able to 2963 discover routes to distant addresses. 2965 o INFINITY_TIME: No interoperability problems due to variations on 2966 different routers, but if a lower value is used, route state 2967 management may exhibit overly restrictive behavior. 2969 11.3. Local Settings 2971 The following table lists AODVv2 parameters which SHOULD be 2972 administratively configured for each router: 2974 +------------------------+------------------------+--------------+ 2975 | Name | Default Value | Description | 2976 +------------------------+------------------------+--------------+ 2977 | AODVv2_INTERFACES | | Section 3 | 2978 | BUFFER_SIZE_PACKETS | 2 | Section 6.6 | 2979 | BUFFER_SIZE_BYTES | MAX_PACKET_SIZE [TBD] | Section 6.6 | 2980 | CONTROL_TRAFFIC_LIMIT | [TBD - 50 pkts/sec?] | Section 7 | 2981 +------------------------+------------------------+--------------+ 2983 Table 4: Configuration for Local Settings 2985 11.4. Network-Wide Settings 2987 The following administrative controls MAY be used to change the 2988 operation of the network. The same settings SHOULD be used across 2989 the network. Inconsistent settings at different routers in the 2990 network will not result in protocol errors, but poor performance may 2991 result. 2993 +----------------------+-----------+----------------+ 2994 | Name | Default | Description | 2995 +----------------------+-----------+----------------+ 2996 | ENABLE_IDLE_IN_RERR | Disabled | Section 7.4.1 | 2997 +----------------------+-----------+----------------+ 2999 Table 5: Configuration for Network-Wide Settings 3001 11.5. Optional Feature Settings 3003 These options are not required for correct routing behavior, although 3004 they may reduce AODVv2 protocol overhead in certain situations. The 3005 default behavior is to leave these options disabled. 3007 +---------------------------+----------+----------------------------+ 3008 | Name | Default | Description | 3009 +---------------------------+----------+----------------------------+ 3010 | PRECURSOR_LISTS | Disabled | Local setting (Section | 3011 | | | 10.2) | 3012 | MSG_AGGREGATION | Disabled | Local setting (Section | 3013 | | | 10.4) | 3014 | ENABLE_IRREP | Disabled | Network-wide setting | 3015 | | | (Section 10.3) | 3016 | EXPANDING_RINGS_MULTICAST | Disabled | Network-wide setting | 3017 | | | (Section 10.1) | 3018 +---------------------------+----------+----------------------------+ 3020 Table 6: Configuration for Optional Features 3022 11.6. MetricType Allocation 3024 The metric types used by AODVv2 are identified according to the 3025 assignments in [RFC6551]. All implementations MUST use these values. 3027 +---------------------+----------+--------------------+ 3028 | Name of MetricType | Type | Metric Value Size | 3029 +---------------------+----------+--------------------+ 3030 | Unassigned | 0 | Undefined | 3031 | Hop Count | 3 [TBD] | 1 octet | 3032 | Unallocated | 9 - 254 | TBD | 3033 | Reserved | 255 | Undefined | 3034 +---------------------+----------+--------------------+ 3036 Table 7: AODVv2 Metric Types 3038 11.7. AddressType Allocation 3040 These values are used in the [RFC5444] Address Type TLV discussed in 3041 Section 8. All implementations MUST use these values. 3043 +-----------------------+--------+ 3044 | Address Type | Value | 3045 +-----------------------+--------+ 3046 | ADDRTYPE_ORIGADDR | 0 | 3047 | ADDRTYPE_TARGADDR | 1 | 3048 | ADDRTYPE_UNREACHABLE | 2 | 3049 | ADDRTYPE_PKTSOURCE | 3 | 3050 | ADDRTYPE_INTEND | 4 | 3051 | ADDRTYPE_UNSPECIFIED | 255 | 3052 +-----------------------+--------+ 3054 Table 8: AODVv2 Address Types 3056 12. IANA Considerations 3058 This section specifies several [RFC5444] message types and address 3059 tlv-types required for AODVv2. 3061 12.1. RFC 5444 Message Types 3063 This specification defines four Message Types, to be allocated from 3064 the 0-223 range of the "Message Types" namespace defined in 3065 [RFC5444], as specified in Table 9. 3067 +-----------------------------------------+-----------+ 3068 | Name of Message | Type | 3069 +-----------------------------------------+-----------+ 3070 | Route Request (RREQ) | 10 (TBD) | 3071 | Route Reply (RREP) | 11 (TBD) | 3072 | Route Error (RERR) | 12 (TBD) | 3073 | Route Reply Acknowledgement (RREP_Ack) | 13 (TBD) | 3074 +-----------------------------------------+-----------+ 3076 Table 9: AODVv2 Message Types 3078 12.2. RFC 5444 Address Block TLV Types 3080 This specification defines three Address Block TLV Types, to be 3081 allocated from the "Address Block TLV Types" namespace defined in 3082 [RFC5444], as specified in Table 10. 3084 +------------------------+----------+---------------+---------------+ 3085 | Name of TLV | Type | Length | Reference | 3086 | | | (octets) | | 3087 +------------------------+----------+---------------+---------------+ 3088 | PATH_METRIC | 10 (TBD) | depends on | Section 7 | 3089 | | | MetricType | | 3090 | SEQ_NUM | 11 (TBD) | 2 | Section 7 | 3091 | ADDRESS_TYPE | 15 (TBD) | 1 | Section 8 | 3092 +------------------------+----------+---------------+---------------+ 3094 Table 10: AODVv2 Address Block TLV Types 3096 13. Security Considerations 3098 This section describes various security considerations and potential 3099 avenues to secure AODVv2 routing. The objective of the AODVv2 3100 protocol is for each router to communicate reachability information 3101 about addresses for which it is responsible, and for routes it has 3102 learned from other AODVv2 routers. Positive routing information 3103 (i.e. a route exists) is distributed via RREQ and RREP messages. 3105 AODVv2 routers store the information contained in these messages in 3106 order to properly forward IP packets, and they generally provide this 3107 information to other AODVv2 routers. Negative routing information 3108 (i.e. a route does not exist) is distributed via RERR messages. 3109 AODVv2 routers process these messages and remove routes, and forward 3110 this information to other AODVv2 routers. 3112 Networks using AODVv2 to maintain connectivity and establish routes 3113 on demand may be vulnerable to certain well-known types of threats. 3114 Flooding attacks using RREQ amount to a denial of service for route 3115 discovery. Valid route table entries can be replaced by maliciously 3116 constructed RREQ and RREP messages. Links could be erroneously 3117 treated as bidirectional if malicious unsolicited RREP or RREP_Ack 3118 messages were to be accepted. Replay attacks using RERR messages 3119 could, in some circumstances, be used to disrupt active routes. 3120 Passive inspection of AODVv2 control messages could enable 3121 unauthorized devices to gain information about the network topology, 3122 since exchanging such information is the main purpose of AODVv2. 3124 The on-demand nature of AODVv2 route discovery reduces the 3125 vulnerability to route disruption. Since control traffic for 3126 updating route tables is diminished, there is less opportunity for 3127 failure. Processing requirements for AODVv2 are typically quite 3128 small, and would typically be dominated by calculations to verify 3129 integrity. This has the effect of reducing (but by no means 3130 eliminating) AODVv2's vulnerability to denial of service attacks. 3132 Encryption MAY be used for AODVv2 messages. If the routers share a 3133 packet-level security association, the message data can be encrypted 3134 prior to message transmission. The establishment of such security 3135 associations is outside the scope of this specification. Encryption 3136 will not only protect against unauthorized devices obtaining 3137 information about network topology but will ensure that only trusted 3138 routers participate in routing operations. 3140 Message integrity checking is enabled by the Integrity Check Value 3141 mechanisms defined in [RFC7182]. The data contained in AODVv2 3142 routing protocol messages SHOULD be verified using ICV values, to 3143 avoid the use of message data if the message has been tampered with 3144 or replayed. Otherwise, it would be possible to disrupt 3145 communications by injecting nonexistent or malicious routes into the 3146 route tables of routers within the ad hoc network. This can result 3147 in loss of data or message processing by unauthorized devices. 3149 The remainder of this section provides specific recommendations for 3150 the use of the integrity checking and timestamp functions defined in 3151 [RFC7182] to ensure the integrity of each AODVv2 message. The 3152 calculation used for the Integrity Check Value will depend on the 3153 message type. Sequence numbers can be used as timestamps to protect 3154 against replay, since they are known to be strictly increasing. 3156 RREQ messages advertise a route to OrigAddr, and impose very little 3157 processing requirement for receivers. The main threat presented by 3158 sending an RREQ message with false information is that traffic to 3159 OrigAddr could be disrupted. Since RREQ is multicast and likely to 3160 be received by all routers in the ad hoc network, this threat could 3161 have serious impact on applications communicating by way of OrigAddr. 3162 The actual threat to disrupt routes to OrigAddr is reduced by the 3163 AODVv2 mechanism of marking RREQ-derived routes as "Unconfirmed" 3164 until the link to the next hop is confirmed. If AODVv2 routers 3165 always verify the integrity of the RREQ message data, then the threat 3166 of disruption is minimized. The ICV mechanisms offered in [RFC7182] 3167 are sufficient for this purpose. Since OrigAddr is included in the 3168 RREQ, the ICV can be calculated and verified using message contents. 3169 The ICV SHOULD be verified at every step along the dispersal path of 3170 the RREQ to mitigate the threat. Since RREQ_Gen's sequence number is 3171 incremented for each new RREQ, replay protection is already afforded 3172 and no extra timestamp mechanism is required. 3174 RREP messages advertise a route to TargAddr, and impose very little 3175 processing requirement for receivers. The main threat presented by 3176 sending an RREP message with false information is that traffic to 3177 TargAddr could be disrupted. Since RREP is unicast, this threat is 3178 restricted to receivers along the path from OrigAddr to TargAddr. If 3179 AODVv2 routers always verify the integrity of the RREP message data, 3180 then this threat is minimized. This facility is offered by the ICV 3181 mechanisms in [RFC7182]. Since TargAddr is included as a Data 3182 Element of the RREP, the ICV can be calculated and verified using 3183 message contents. The ICV SHOULD be verified at every step along the 3184 unicast path of the RREP. Since RREP_Gen's sequence number is 3185 incremented for each new RREP, replay protection is afforded and no 3186 extra timestamp mechanism is required. 3188 RREP_Ack messages are intended to verify bidirectional neighbor 3189 connectivity, and impose very little processing requirement for 3190 receivers. The main threat presented by sending an RREP_Ack message 3191 with false information is that the route advertised to a target 3192 address in an RREP might be erroneously accepted even though the 3193 route would contain a unidirectional link and thus not be suitable 3194 for most traffic. Since RREP_Ack is unicast, this threat is strictly 3195 local to the RREP transmitter expecting the acknowledgement. A 3196 malicious router could also attempt to send an unsolicited RREP_Ack 3197 to convince another router that a bidirectional link exists and 3198 subsequently use further messages to divert traffic along a route 3199 which is not valid. If AODVv2 routers always verify the integrity of 3200 the RREP_Ack message data, then this threat is minimized. This 3201 facility is offered by the ICV mechanisms in [RFC7182]. The RREP_Gen 3202 SHOULD use the source IP address of the RREP_Ack to identify the 3203 sender, and so the ICV SHOULD be calculated using the message 3204 contents and the IP source address. The message must also include 3205 the Timestamp defined in [RFC7182] to protect against replay attacks, 3206 using TargSeqNum from the RREP as the value in the TIMESTAMP TLV. 3208 RERR messages remove routes, and impose very little processing 3209 requirement for receivers. The main threat presented by sending an 3210 RERR message with false information is that traffic to the advertised 3211 destinations could be disrupted. Since RERR is multicast and can be 3212 received by many routers in the ad hoc network, this threat could 3213 have serious impact on applications communicating by way of the 3214 sender of the RERR message. However, since the sender of the RERR 3215 message with erroneous information MAY be presumed to be either 3216 malicious or broken, it is better that such routes not be used 3217 anyway. Another threat is that a malicious RERR message MAY be sent 3218 with a PktSource included, to disrupt PktSource's ability to send to 3219 the addresses contained in the RERR. If AODVv2 routers always verify 3220 the integrity of the RERR message data, then this threat is reduced. 3221 This facility is offered by the ICV mechanisms in [RFC7182]. The 3222 receiver of the RERR SHOULD use the source IP address of the RERR to 3223 identify the sender. The message must also include the Timestamp 3224 defined in [RFC7182] to protect against replay attacks, using SeqNum 3225 from RERR_Gen as the value in the TIMESTAMP TLV. 3227 14. Acknowledgments 3229 AODVv2 is a descendant of the design of previous MANET on-demand 3230 protocols, especially AODV [RFC3561] and DSR [RFC4728]. Changes to 3231 previous MANET on-demand protocols stem from research and 3232 implementation experiences. Thanks to Elizabeth Belding and Ian 3233 Chakeres for their long time authorship of AODV. Additional thanks 3234 to Derek Atkins, Emmanuel Baccelli, Abdussalam Baryun, Ramon Caceres, 3235 Thomas Clausen, Justin Dean, Christopher Dearlove, Ulrich Herberg, 3236 Henner Jakob, Luke Klein-Berndt, Lars Kristensen, Tronje Krop, 3237 Koojana Kuladinithi, Kedar Namjoshi, Keyur Patel, Alexandru Petrescu, 3238 Henning Rogge, Fransisco Ros, Pedro Ruiz, Christoph Sommer, Romain 3239 Thouvenin, Richard Trefler, Jiazi Yi, Seung Yi, and Cong Yuan, for 3240 their reviews of AODVv2 and DYMO, as well as numerous specification 3241 suggestions. 3243 15. References 3244 15.1. Normative References 3246 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3247 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 3248 RFC2119, March 1997, 3249 . 3251 [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- 3252 Demand Distance Vector (AODV) Routing", RFC 3561, DOI 3253 10.17487/RFC3561, July 2003, 3254 . 3256 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 3257 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 3258 2006, . 3260 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. 3261 Pignataro, "The Generalized TTL Security Mechanism 3262 (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, 3263 . 3265 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 3266 "Generalized Mobile Ad Hoc Network (MANET) Packet/Message 3267 Format", RFC 5444, DOI 10.17487/RFC5444, February 2009, 3268 . 3270 [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value 3271 Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, DOI 3272 10.17487/RFC5497, March 2009, 3273 . 3275 [RFC5498] Chakeres, I., "IANA Allocations for Mobile Ad Hoc Network 3276 (MANET) Protocols", RFC 5498, DOI 10.17487/RFC5498, March 3277 2009, . 3279 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 3280 and D. Barthel, "Routing Metrics Used for Path Calculation 3281 in Low-Power and Lossy Networks", RFC 6551, DOI 10.17487/ 3282 RFC6551, March 2012, 3283 . 3285 [RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity 3286 Check Value and Timestamp TLV Definitions for Mobile Ad 3287 Hoc Networks (MANETs)", RFC 7182, DOI 10.17487/RFC7182, 3288 April 2014, . 3290 15.2. Informative References 3292 [I-D.perkins-irrep] 3293 Perkins, C., "Intermediate RREP for dynamic MANET On- 3294 demand (AODVv2) Routing", draft-perkins-irrep-03 (work in 3295 progress), May 2015. 3297 [Koodli01] 3298 Koodli, R. and C. Perkins, "Fast handovers and context 3299 transfers in mobile networks", Proceedings of the ACM 3300 SIGCOMM Computer Communication Review 2001, Volume 31 3301 Issue 5, 37-47, October 2001. 3303 [Perkins94] 3304 Perkins, C. and P. Bhagwat, "Highly Dynamic Destination- 3305 Sequenced Distance-Vector Routing (DSDV) for Mobile 3306 Computers", Proceedings of the ACM SIGCOMM '94 Conference 3307 on Communications Architectures, Protocols and 3308 Applications, London, UK, pp. 234-244, August 1994. 3310 [Perkins99] 3311 Perkins, C. and E. Royer, "Ad hoc On-Demand Distance 3312 Vector (AODV) Routing", Proceedings of the 2nd IEEE 3313 Workshop on Mobile Computing Systems and Applications, New 3314 Orleans, LA, pp. 90-100, February 1999. 3316 [RFC2501] Corson, S. and J. Macker, "Mobile Ad hoc Networking 3317 (MANET): Routing Protocol Performance Issues and 3318 Evaluation Considerations", RFC 2501, DOI 10.17487/ 3319 RFC2501, January 1999, 3320 . 3322 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 3323 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 3324 . 3326 [RFC4728] Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source 3327 Routing Protocol (DSR) for Mobile Ad Hoc Networks for 3328 IPv4", RFC 4728, DOI 10.17487/RFC4728, February 2007, 3329 . 3331 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 3332 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 3333 DOI 10.17487/RFC4861, September 2007, 3334 . 3336 [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter 3337 Considerations in Mobile Ad Hoc Networks (MANETs)", RFC 3338 5148, DOI 10.17487/RFC5148, February 2008, 3339 . 3341 [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc 3342 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 3343 RFC 6130, DOI 10.17487/RFC6130, April 2011, 3344 . 3346 [Sholander02] 3347 Sholander, P., Coccoli, P., Oakes, T., and S. Swank, "A 3348 Portable Software Implementation of a Hybrid MANET Routing 3349 Protocol", 2002. 3351 Appendix A. AODVv2 Draft Updates 3353 This section lists the changes between AODVv2 revisions ...-12.txt 3354 and ...-13.txt. 3356 o Updated uses of host and node. 3358 o Removed use of Data Element. 3360 o Added explanation of self-healing issue of hop-by-hop 3361 acknowledgements. 3363 o Moved appendix on relocation of routing prefix to a different 3364 router into the main draft. 3366 o Added notes on forwarding plane to the Overview and added to text 3367 in the Applicability Statement. 3369 o Separated AODVv2's Local Route Set from the Routing Information 3370 Base. 3372 o Updated Adjacency Monitoring to Next Hop Monitoring. 3374 o Added extra description in Multicast Route Message Table section. 3376 o Added extra notes on possible implementations of Local Route Set. 3378 o Added short description of reactive routing protocols to 3379 Applicability Statement. 3381 o Added extra note in Applicability Statement about multiple IP 3382 addresses per router interface. 3384 o Used clear references to Neighbor.State and LocalRoute.State. 3386 o Added reference for text aboute buffering TCP packets. 3388 o Updated text about Route.State to be clear which routes may be 3389 copied to a Routing Information Base. 3391 o Added explanation of when a route discovery might not be attempted 3392 and action taken instead. 3394 o Added text to explain that routes to prefixes are learned when 3395 prefix lengths are included in AODVv2 messages. 3397 o Changed rule for adding new route if current routes to the same 3398 address have Route.State set to Unconfirmed. 3400 o Changed text about reporting broken routes to use MUST instead of 3401 SHOULD. 3403 o Updated message processing algorithms to refer to Neighbor 3404 Table updates. 3406 o Added extra explanation for use of AckReq in RREP message. 3408 o Added extra explanation for RREP_Ack handling. 3410 o Removed references to MTU in RERR section and updated processing 3411 rules. 3413 o Removed reference to RFC 6621. 3415 o Removed appendix about multi-homing. 3417 o Removed appendix containing pseudo-code. 3419 o Minor editorial improvements. 3421 Authors' Addresses 3423 Charles E. Perkins 3424 Futurewei Inc. 3425 2330 Central Expressway 3426 Santa Clara, CA 95050 3427 USA 3429 Phone: +1-408-330-4586 3430 Email: charliep@computer.org 3431 Stan Ratliff 3432 Idirect 3433 13861 Sunrise Valley Drive, Suite 300 3434 Herndon, VA 20171 3435 USA 3437 Email: ratliffstan@gmail.com 3439 John Dowdell 3440 Airbus Defence and Space 3441 Celtic Springs 3442 Newport, Wales NP10 8FZ 3443 United Kingdom 3445 Email: john.dowdell@airbus.com 3447 Lotte Steenbrink 3448 HAW Hamburg, Dept. Informatik 3449 Berliner Tor 7 3450 D-20099 Hamburg 3451 Germany 3453 Email: lotte.steenbrink@haw-hamburg.de 3455 Victoria Mercieca 3456 Airbus Defence and Space 3457 Celtic Springs 3458 Newport, Wales NP10 8FZ 3459 United Kingdom 3461 Email: victoria.mercieca@airbus.com