idnits 2.17.1 draft-ietf-manet-aodvv2-03.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 4 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 (February 4, 2014) is 3735 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: 'MANETs' is mentioned on line 132, but not defined == Missing Reference: 'Address' is mentioned on line 285, but not defined -- Looks like a reference, but probably isn't: '1' on line 297 == Missing Reference: 'N' is mentioned on line 298, but not defined == Missing Reference: 'OrigNode' is mentioned on line 1359, but not defined == Missing Reference: 'OrigNdx' is mentioned on line 1223, but not defined == Missing Reference: 'TargNode' is mentioned on line 1118, but not defined == Missing Reference: 'TargNdx' is mentioned on line 1221, but not defined -- Looks like a reference, but probably isn't: '3' on line 701 == Missing Reference: 'TBD' is mentioned on line 1773, but not defined == Outdated reference: A later version (-03) exists of draft-perkins-irrep-02 Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 3 comments (--). 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: August 8, 2014 Cisco 6 J. Dowdell 7 Cassidian 8 February 4, 2014 10 Dynamic MANET On-demand (AODVv2) Routing 11 draft-ietf-manet-aodvv2-03 13 Abstract 15 The revised Ad Hoc On-demand Distance Vector (AODVv2) routing 16 protocol is intended for use by mobile routers in wireless, multihop 17 networks. AODVv2 determines unicast routes among AODVv2 routers 18 within the network in an on-demand fashion, offering on-demand 19 convergence in dynamic topologies. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 8, 2014. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Notational Conventions . . . . . . . . . . . . . . . . . . . 7 58 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 7 59 5. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 9 60 5.1. Route Table Entry . . . . . . . . . . . . . . . . . . . . 9 61 5.2. Bidirectional Connectivity and Blacklists . . . . . . . . 11 62 5.3. Router Clients and Client Networks . . . . . . . . . . . 11 63 5.4. AODVv2 Packet Header Fields and Information Elements . . 12 64 5.5. Sequence Numbers . . . . . . . . . . . . . . . . . . . . 13 65 5.6. Enabling Alternate Metrics . . . . . . . . . . . . . . . 14 66 5.7. RREQ Table: Received RREQ Messages . . . . . . . . . . . 16 67 6. AODVv2 Operations on Route Table Entries . . . . . . . . . . 17 68 6.1. Evaluating Incoming Routing Information . . . . . . . . . 17 69 6.2. Applying Route Updates To Route Table Entries . . . . . . 19 70 6.3. Route Table Entry Timeouts . . . . . . . . . . . . . . . 19 71 7. Routing Messages RREQ and RREP (RteMsgs) . . . . . . . . . . 20 72 7.1. Route Discovery Retries and Buffering . . . . . . . . . . 20 73 7.2. RteMsg Structure . . . . . . . . . . . . . . . . . . . . 21 74 7.3. RREQ Generation . . . . . . . . . . . . . . . . . . . . . 23 75 7.4. RREP Generation . . . . . . . . . . . . . . . . . . . . . 24 76 7.5. Handling a Received RteMsg . . . . . . . . . . . . . . . 24 77 7.5.1. Additional Handling for Incoming RREQ . . . . . . . . 25 78 7.5.2. Additional Handling for Incoming RREP . . . . . . . . 26 79 7.6. Suppressing Redundant RREQ messages . . . . . . . . . . . 27 80 8. Route Maintenance and RERR Messages . . . . . . . . . . . . . 27 81 8.1. Maintaining Route Lifetimes During Packet Forwarding . . 27 82 8.2. Active Next-hop Router 83 Adjacency Monitoring . . . . . . . . . . . . . . . . . . 28 84 8.3. RERR Generation . . . . . . . . . . . . . . . . . . . . . 28 85 8.3.1. Case 1: Undeliverable Packet . . . . . . . . . . . . 29 86 8.3.2. Case 2: Broken Link . . . . . . . . . . . . . . . . . 30 87 8.4. Receiving and Handling RERR Messages . . . . . . . . . . 30 88 9. Unknown Message and TLV Types . . . . . . . . . . . . . . . . 32 89 10. Simple Internet Attachment . . . . . . . . . . . . . . . . . 32 90 11. Multiple Interfaces . . . . . . . . . . . . . . . . . . . . . 33 91 12. AODVv2 Control Packet/Message Generation Limits . . . . . . . 33 92 13. Optional Features . . . . . . . . . . . . . . . . . . . . . . 33 93 13.1. Expanding Rings Multicast . . . . . . . . . . . . . . . 34 94 13.2. Intermediate RREP . . . . . . . . . . . . . . . . . . . 34 95 13.3. Precursor Lists and Notifications . . . . . . . . . . . 34 96 13.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . 34 97 13.3.2. Precursor Notification Details . . . . . . . . . . . 35 98 13.4. Multicast RREP Response to RREQ . . . . . . . . . . . . 35 99 13.5. RREP_ACK . . . . . . . . . . . . . . . . . . . . . . . . 36 100 13.6. Message Aggregation . . . . . . . . . . . . . . . . . . 36 101 14. Administratively Configurable 102 Parameters and Timer Values . . . . . . . . . . . . . . . . . 36 103 14.1. Timers . . . . . . . . . . . . . . . . . . . . . . . . . 36 104 14.2. Protocol constants . . . . . . . . . . . . . . . . . . . 37 105 14.3. Administrative (functional) controls . . . . . . . . . . 37 106 14.4. Other administrative parameters and lists . . . . . . . 38 107 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 108 15.1. AODVv2 Message Types Specification . . . . . . . . . . . 38 109 15.2. Message TLV Type Specification . . . . . . . . . . . . . 39 110 15.3. Address Block TLV Specification . . . . . . . . . . . . 39 111 15.4. Metric Type Number Allocation . . . . . . . . . . . . . 40 112 16. Security Considerations . . . . . . . . . . . . . . . . . . . 40 113 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42 114 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 115 18.1. Normative References . . . . . . . . . . . . . . . . . . 42 116 18.2. Informative References . . . . . . . . . . . . . . . . . 43 117 Appendix A. Example RFC 5444-compliant packet formats . . . . . 44 118 A.1. RREQ Message Format . . . . . . . . . . . . . . . . . . . 44 119 A.2. RREP Message Format . . . . . . . . . . . . . . . . . . . 46 120 A.3. RERR Message Format . . . . . . . . . . . . . . . . . . . 48 121 A.4. RREP_ACK Message Format . . . . . . . . . . . . . . . . . 49 122 Appendix B. Changes since revision ...-02.txt . . . . . . . . . 49 123 Appendix C. Shifting Network Prefix Advertisement Between AODVv2 124 Routers . . . . . . . . . . . . . . . . . . . . . . 50 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 127 1. Overview 129 The revised Ad Hoc On-demand Distance Vector (AODVv2) routing 130 protocol [formerly named DYMO] enables on-demand, multihop unicast 131 routing among AODVv2 routers in mobile ad hod networks 132 [MANETs][RFC2501]. The basic operations of the AODVv2 protocol are 133 route discovery and route maintenance. Route discovery is performed 134 when an AODVv2 router must transmit a packet towards a destination 135 for which it does not have a route. Route maintenance is performed 136 to avoid prematurely expunging routes from the route table, and to 137 avoid dropping packets when an active route breaks. 139 During route discovery, the originating AODVv2 router (RREQ_Gen) 140 multicasts a Route Request message (RREQ) to find a route toward some 141 target destination. Using a hop-by-hop retransmission algorithm, 142 each AODVv2 router receiving the RREQ message records a route toward 143 the originator. When the target's AODVv2 router (RREP_Gen) receives 144 the RREQ, it records a route toward RREQ_Gen and generates a Route 145 Reply (RREP) unicast toward RREQ_Gen. Each AODVv2 router that 146 receives the RREP stores a route toward the target, and again 147 unicasts the RREP toward the originator. When RREQ_Gen receives the 148 RREP, routes have then been established between RREQ_Gen (the 149 originating AODVv2 router) and RREP_Gen (the target's AODVv2 router) 150 in both directions. 152 Route maintenance consists of two operations. In order to maintain 153 active routes, AODVv2 routers extend route lifetimes upon 154 successfully forwarding a packet. When a data packet is received to 155 be forwarded downstream but there is no valid route for the 156 destination, then the AODVv2 router of the source of the packet is 157 notified via a Route Error (RERR) message. Each upstream router that 158 receives the RERR marks the route as broken. Before such an upstream 159 AODVv2 router could forward a packet to the same destination, it 160 would have to perform route discovery again for that destination. 162 AODVv2 uses sequence numbers to assure loop freedom [Perkins99], 163 similarly to AODV. Sequence numbers enable AODVv2 routers to 164 determine the temporal order of AODVv2 route discovery messages, 165 thereby avoiding use of stale routing information. Unlike AODV, 166 AODVv2 uses RFC 5444 message and TLV formats. 168 2. Terminology 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 172 "OPTIONAL" in this document are to be interpreted as described in 173 [RFC2119]. 175 This document also uses some terminology from [RFC5444]. 177 This document defines the following terminology: 179 Adjacency 180 A bi-directional relationship between neighboring AODVv2 routers 181 for the purpose of exchanging routing information. Not every pair 182 of neighboring routers will necessarily form an adjacency. 183 Neighboring routers may form an adjacency based on various 184 information or other protocols; for example, exchange of AODVv2 185 routing messages, other protocols (e.g. NDP [RFC4861] or NHDP 186 [RFC6130]), or manual configuration. Loss of a routing adjacency 187 may also be indicated by similar information; monitoring of 188 adjacencies where packets are being forwarded is required (see 189 Section 8.2). 190 AODVv2 Router 191 An IP addressable device in the ad-hoc network that performs the 192 AODVv2 protocol operations specified in this document. 194 AODVv2 Sequence Number (SeqNum) 195 Same as Sequence Number. 196 Current_Time 197 The current time as maintained by the AODVv2 router. 198 Disregard 199 Ignore for further processing (see Section 5.4), and discard 200 unless it is required to keep the message in the packet for 201 purposes of authentication. 202 Handling Router (HandlingRtr) 203 HandlingRtr denotes the AODVv2 router receiving and handling an 204 AODVv2 message. 205 Incoming Link 206 A link over which an AODVv2 router has received a message from an 207 adjacent router. 208 MANET 209 A Mobile Ad Hoc Network as defined in [RFC2501]. 210 Node 211 An IP addressable device in the ad-hoc network. A node may be an 212 AODVv2 router, or it may be a device in the network that does not 213 perform any AODVv2 protocol operations. All nodes in this 214 document are either AODVv2 Routers or else Router Clients. 215 Originating Node (OrigNode) 216 The Originating Node is the node that launched the application 217 requiring communication with the Target Node. If OrigNode is not 218 itself an AODVv2 router, its AODVv2 router (RREQ_Gen) has the 219 responsibility to generate a AODVv2 RREQ message on behalf of 220 OrigNode when necessary to discover a route. 221 Reactive 222 A protocol operation is said to be "reactive" if it is performed 223 only in reaction to specific events. As used in this document, 224 "reactive" is essentially synonymous with "on-demand". 225 Routable Unicast IP Address 226 A routable unicast IP address is a unicast IP address that when 227 put into the IP.DestinationAddress field is scoped sufficiently to 228 be forwarded by a router. Globally-scoped unicast IP addresses 229 and Unique Local Addresses (ULAs) [RFC6549] are examples of 230 routable unicast IP addresses. 231 Route Error (RERR) 232 A RERR message is used to indicate that an AODVv2 router does not 233 have a route toward one or more particular destinations. 234 Route Reply (RREP) 235 A RREP message is used to establish a route between the RREQ 236 TargetNode and OrigNode, at all the AODVv2 routers between them. 237 Route Request (RREQ) 238 An AODVv2 router uses a RREQ message to discover a valid route to 239 a particular destination address, called the TargetNode. An 240 AODVv2 router processing a RREQ receives routing information for 241 the RREQ OrigNode. 243 Router Client 244 An AODVv2 router may be configured with a list of other IP 245 addresses and networks which correspond to other non-router nodes 246 which require the services of the AODVv2 router for route 247 discovery and maintenance. An AODVv2 router is always its own 248 client, so that the list of client IP addresses is never empty. 249 RREP Generating Router (RREP_Gen) 250 The RREP Generating Router is the AODVv2 router that serves 251 TargNode. RREP_Gen generates the RREP message to advertise a 252 route for TargNode. 253 RREQ Generating Router (RREQ_Gen) 254 The RREQ Generating Router is the AODVv2 router that serves 255 OrigNode. RREQ_Gen generates the RREQ message to discover a route 256 for TargNode. 257 Sequence Number (SeqNum) 258 AODVv2 mandates that each AODVv2 router maintain an unsigned 259 integer known as the router's "Sequence Number". The Sequence 260 Number guarantees the temporal order of routing information to 261 maintain loop-free routes, and fulfills the same role as the 262 "Destination Sequence Number" of DSDV, and as the AODV Sequence 263 Number in RFC 3561[RFC3561]. The value zero (0) is reserved to 264 indicate that the Sequence Number for an address is unknown. 265 Target Node (TargNode) 266 The Target Node denotes the node for which a route is needed. 267 Type-Length-Value structure (TLV) 268 A generic way to represent information as specified in [RFC5444]. 269 Unreachable Node (UnreachableNode) 270 An UnreachableNode is a node for which a forwarding route is 271 unknown. 272 Valid route 273 A route that can be used for forwarding; in other words a route 274 that is not Broken or Expired. 276 3. Notational Conventions 278 This document uses the conventions found in Table 1 to describe 279 information in the fields from [RFC5444]. 281 +------------------------+------------------------------------------+ 282 | Notation | Information Location and/or Meaning | 283 +------------------------+------------------------------------------+ 284 | Route[Address] | A route table entry towards Address | 285 | Route[Address].{field} | A field in a route table entry | 286 | -- | -- | 287 | | RFC 5444 Message Header | 288 | | RFC 5444 Message Header | 289 | AddrBlk | an RFC 5444 Address TLV Block | 290 | AddrBlk[1] | The first address slot in AddrBlk | 291 | AddrBlk[N] | The Nth address slot in AddrBlk | 292 | OrigNdx | The index of OrigNode within the AddrBlk | 293 | TargNdx | The index of TargNode within the AddrBlk | 294 | AddrBlk[OrigNode] | AddrBlk[OrigNdx] | 295 | AddrBlk[TargNode] | AddrBlk[TargNdx] | 296 | AddrTLV | an RFC 5444 Address Block TLV | 297 | AddrTLV[1] | the first item in AddrTLV | 298 | AddrTLV[N] | the Nth item in AddrTLV | 299 | AddrTLV[OrigNode] | AddrTLV[OrigNdx] | 300 | AddrTLV[TargNode] | AddrTLV[TargNdx] | 301 | Metric_TLV | Metric AddrTLV for AddrBlk | 302 | SeqNum_TLV | Sequence Number AddrTLV for AddrBlk | 303 | OrigSeqNum_TLV | Originating Node Sequence Number AddrTLV | 304 | TargSeqNum_TLV | Target Node Sequence Number AddrTLV | 305 | -- | -- | 306 | OrigNode | Originating Node | 307 | RREQ_Gen | AODVv2 router originating an RREQ | 308 | RREP_Gen | AODVv2 router responding to an RREQ | 309 | RteMsg | Either RREQ or RREP | 310 | RteMsg.{field} | Field in RREQ or RREP | 311 | HandlingRtr | Handling Router | 312 | TargNode | Target Node | 313 | UnreachableNode | Unreachable Node | 314 +------------------------+------------------------------------------+ 316 Table 1 318 4. Applicability Statement 320 The AODVv2 routing protocol is designed for stub (i.e., non-transit) 321 or disconnected (i.e., from the Internet) mobile ad hoc networks 322 (MANETs). AODVv2 handles a wide variety of mobility patterns by 323 determining routes on-demand. AODVv2 also handles a wide variety of 324 traffic patterns. In networks with a large number of routers, AODVv2 325 is best suited for relatively sparse traffic scenarios where any 326 particular router forwards packets to only a small percentage of the 327 AODVv2 routers in the network, due to the on-demand nature of route 328 discovery and route maintenance. AODVv2 supports routers with 329 multiple interfaces, as long as each interface has its own (unicast 330 routeable) IP address; the set of all network interfaces supporting 331 AODVv2 is administratively configured in a list (namely, 332 AODVv2_INTERFACES). 334 Although AODVv2 is closely related to AODV [RFC3561], and has some of 335 the features of DSR [RFC4728], AODVv2 is not interoperable with 336 either of those other two protocols. 338 AODVv2 is applicable to memory constrained devices, since little 339 routing state is maintained in each AODVv2 router. Only routing 340 information related to routes between active sources and destinations 341 is maintained, in contrast to proactive routing protocols that 342 require routing information to all routers within the MANET be 343 maintained. 345 In addition to routing for its own local applications, each AODVv2 346 router can also route on behalf of other non-routing nodes (i.e., 347 "hosts", or, in this document, "clients"), reachable via those 348 interfaces. Each AODVv2 router, if serving router clients other than 349 itself, is configured with information about the IP addresses of its 350 clients. No AODVv2 router is required to have information about the 351 relationship between any other AODVv2 router and its router clients 352 (see Section 5.3). 354 The coordination among multiple AODVv2 routers to distribute routing 355 information correctly for a shared address (i.e. an address that is 356 advertised and can be reached via multiple AODVv2 routers) is not 357 described in this document. The AODVv2 router operation of shifting 358 responsibility for a routing client from one AODVv2 router to another 359 is mentioned in Appendix C. Address assignment procedures are 360 entirely out of scope for AODVv2. Any such node which is not itself 361 an AODVv2 router SHOULD NOT be served by more than one AODVv2 router 362 at any one time. 364 Multi-homing is difficult unless the sequence number is expanded to 365 include the AODVv2 router's IP address as well as SeqNum. Otherwise, 366 comparing sequence numbers would not work to evaluate freshness. 367 Even when the IP address is included, there isn't a good way to 368 compare sequence numbers from different IP addresses, but at least a 369 handling node can determine whether the two given sequence numbers 370 are comparable. If the route table can store multiple routes for the 371 same destination, then multi-homing can work with sequence numbers 372 augmented by IP addresses. 374 AODVv2 routers perform route discovery to find a route toward a 375 particular destination. Therefore, AODVv2 routers MUST must be 376 configured to respond to RREQs for a certain set of addresses. When 377 AODVv2 is the only protocol interacting with the forwarding table, 378 AODVv2 MAY be configured to perform route discovery for all unknown 379 unicast destinations. 381 AODVv2 only supports bidirectional links. In the case of possible 382 unidirectional links, either blacklists (see Section 5.2) or other 383 means (e.g. adjacency establishment with only neighboring routers 384 that have bidirectional communication as indicated by NHDP [RFC6130]) 385 of assuring and monitoring bi-directionality are recommended. 386 Otherwise, persistent packet loss or persistent protocol failures 387 could occur. The cost of bidirectional link L (denoted Cost(L)) may 388 depend upon the direction across the link for which the cost is 389 measured. Metric information from incoming AODVv2 messages SHOULD 390 NOT be used for route table updates unless it has been received over 391 a link that is bidirectional. 393 The routing algorithm in AODVv2 may be operated at layers other than 394 the network layer, using layer-appropriate addresses. The routing 395 algorithm makes of some persistent state; if there is no persistent 396 storage available for this state, recovery can impose a performance 397 penalty (e.g., in case of AODVv2 router reboots). 399 5. Data Structures 401 5.1. Route Table Entry 403 The route table entry is a conceptual data structure. 404 Implementations may use any internal representation so long as it 405 provides access to the information specified below. 407 Conceptually, a route table entry has the following fields: 409 Route.Address 410 The (host or network) destination address of the node(s) 411 associated with the routing table entry 412 Route.PrefixLength 413 The length of the netmask/prefix. If the value of the 414 Route.PrefixLength is less than the length of addresses in the 415 address family used by the AODVv2 routers, the associated address 416 is a routing prefix, rather than a host address. A PrefixLength 417 is stored for every route in the route table. 418 Route.SeqNum 419 The Sequence Number associated with destination of the route, as 420 obtained from the last packet that updated the route table entry 421 associated with a route table entry. 422 Route.NextHopAddress 423 An IP address of the adjacent AODVv2 router on the path toward the 424 Route.Address 425 Route.NextHopInterface 426 The interface used to send packets toward the Route.Address 427 Route.LastUsed 428 The time that this route was last used 429 Route.ExpirationTime 430 The time at which this route must expire 431 Route.Broken 432 A flag indicating whether this Route is broken. This flag is set 433 to true if the next-hop becomes unreachable or in response to 434 processing to a RERR (see Section 8.4) 435 Route.MetricType 436 The type of the metric for the route towards Route.Address 437 Route.Metric 438 The cost of the route towards Route.Address 440 A route table entry (i.e., a route) may be in one of the following 441 states: 443 Active 444 An Active route is in current use for forwarding packets 445 Idle 446 An Idle route can be used for forwarding packets, even though it 447 is not in current use 448 Expired 449 After a route has been idle for too long, it expires, and may no 450 longer be used for forwarding packets 451 Broken 452 A route marked as Broken cannot be used for forwarding packets but 453 still has valid destination sequence number information. 454 Timed 455 The expiration of a Timed route is controlled by the 456 Route.ExpirationTime time of the route table entry (instead of 457 MAX_IDLETIME). Until that time, a Timed route can be used for 458 forwarding packets. Afterwards, the route must be Expired (or 459 expunged). 461 The route's state determines the operations that can be performed on 462 the route table entry. During use, an Active route is maintained 463 continuously by AODVv2 and is considered to remain active as long as 464 it is used at least once during every ACTIVE_INTERVAL. When a route 465 is no longer Active, it becomes an Idle route. After an idle route 466 remains Idle for MAX_IDLETIME, it becomes an Expired route. An 467 Expired route is not used for forwarding, but the sequence number 468 information can be maintained until the destination sequence number 469 has had no updates for MAX_SEQNUM_LIFETIME; after that time, old 470 sequence number information is considered no longer valuable and the 471 Expired route MUST BE expunged. 473 MAX_SEQNUM_LIFETIME is the time after a reboot during which an AODVv2 474 router MUST NOT transmit any routing messages. Thus, if all other 475 AODVv2 routers expunge routes to the rebooted router after that time 476 interval, the rebooted AODVv2 router's sequence number will not be 477 considered stale by any other AODVv2 router in the MANET. 479 When the link to a route's next hop is broken, the route is marked as 480 being Broken, and the route may no longer be used. 482 5.2. Bidirectional Connectivity and Blacklists 484 To avoid repeated failure of Route Discovery, an AODVv2 router 485 (HandlingRtr) handling a RREP message SHOULD attempt to verify 486 connectivity to the next upstream router towards AODVv2 router 487 originating an RREQ message. This MAY be done by including the 488 Acknowledgement Request (AckReq) message TLV (see Section 15.2) in 489 the RREP. Any unicast packet will satisfy the Acknowledgement 490 Request, for example an ICMP REPLY message. If the verification is 491 not received within UNICAST_MESSAGE_SENT_TIMEOUT, HandlingRtr SHOULD 492 put the upstream neighbor in the blacklist. RREQs received from a 493 blacklisted node, or any node over a link that is known to be 494 incoming-only, SHOULD NOT be retransmitted by HandlingRtr. However, 495 the upstream neighbor SHOULD NOT be permanently blacklisted; after a 496 certain time (MAX_BLACKLIST_TIME), it SHOULD once again be considered 497 as a viable upstream neighbor for route discovery operations. 499 For this purpose, a list of blacklisted nodes along with their time 500 of removal SHOULD be maintained: 502 Blacklist.Node 503 The IP address of the node that did not verify bidirectional 504 connectivity. 505 Blacklist.RemoveTime 506 The time at which Blacklist.Node will be removed from the 507 blacklist. 509 5.3. Router Clients and Client Networks 511 An AODVv2 router may offer routing services to other nodes that are 512 not AODVv2 routers. AODVv2 defines the Sequence Number to be the 513 same for the AODVv2 router and each of its clients. 515 For this purpose, CLIENT_ADDRESSES must be configured on each AODVv2 516 router with the following information: 518 Client IP address 519 The IP address of the node that requires routing service from the 520 AODVv2 router. 521 Client Prefix Length 522 The length of the routing prefix associated with the client IP 523 address. 525 If the Client Prefix Length is not the full length of the Client IP 526 address, then the prefix defines a Client Network. If an AODVv2 527 router is configured to serve a Client Network, then the AODVv2 528 router MUST serve every node that has an address within the range 529 defined by the routing prefix of the Client Network. The list of 530 Routing Clients for an AODVv2 router is never empty, since an AODVv2 531 router is always its own client as well. 533 5.4. AODVv2 Packet Header Fields and Information Elements 535 In its default mode of operation, AODVv2 transmits UDP packets using 536 the parameters for port number and IP protocol specified in [RFC5498] 537 to carry protocol packets. By default, AODVv2 packets are sent with 538 the IP destination address set to the link-local multicast address 539 LL-MANET-Routers [RFC5498] unless otherwise specified. Therefore, 540 all AODVv2 routers MUST subscribe to LL-MANET-Routers [RFC5498] to 541 receiving AODVv2 messages. In order to reduce multicast overhead, 542 retransmitting multicast packets in MANETs SHOULD be done according 543 to methods specified in [RFC6621]. AODVv2 does not specify which 544 method should be used to restrict the set of AODVv2 routers that have 545 the responsibility to retransmit multicast packets. Note that 546 multicast packets MAY be sent via unicast. For example, this may 547 occur for certain link-types (non-broadcast media), for manually 548 configured router adjacencies, or in order to improve robustness. 550 The IPv4 TTL (IPv6 Hop Limit) field for all packets containing AODVv2 551 messages is set to 255. If a packet is received with a value other 552 than 255, any AODVv2 message contained in the packet MUST be 553 disregarded by AODVv2. This mechanism, known as "The Generalized TTL 554 Security Mechanism" (GTSM) [RFC5082] helps to assure that packets 555 have not traversed any intermediate routers. 557 IP packets containing AODVv2 protocol messages SHOULD be given 558 priority queuing and channel access. 560 AODVv2 messages are transmitted in packets that conform to the packet 561 and message format specified in [RFC5444]. Here is a brief summary 562 of the format. 564 A packet formatted according to RFC 5444 contains zero or more 565 messages. 566 A message contains a message header, message TLV block, and zero 567 or more address blocks. 568 Each address block may also have an associated TLV block; this TLV 569 block may encode multiple TLVs. According to RFC 5444, each such 570 TLV may itself include an array of values. 572 If a packet contains only a single AODVv2 message and no packet TLVs, 573 it need only include a minimal Packet-Header [RFC5444]. The length 574 of an address (32 bits for IPv4 and 128 bits for IPv6) inside an 575 AODVv2 message is indicated by the msg-addr-length (MAL) in the msg- 576 header, as specified in [RFC5444]. 578 When multiple messages are aggregated into a single packet according 579 to RFC 5444 formatting, and the aggregation of messages is also 580 authenticated (e.g., with IPsec), and the IP destination is multiple 581 hops away, it becomes infeasible to delete individual messages. In 582 such cases, instead of deleting individual messages, they are 583 maintained in the aggregation of messages, but simply ignored for 584 further processing. In such cases where individual messages cannot 585 be deleted, in this document "disregarded" means "ignored". 586 Otherwise, any such "disregarded" AODVv2 messages SHOULD be deleted 587 from the aggregated messages in the RFC 5444 packet. 589 5.5. Sequence Numbers 591 Sequence Numbers allow AODVv2 routers to evaluate the freshness of 592 routing information. Each AODVv2 router in the network MUST maintain 593 its own sequence number. Each RREQ and RREQ generated by an AODVv2 594 router includes that sequence number. Each AODVv2 router MUST make 595 sure that its sequence number is unique and monotonically increasing. 596 This can be achieved by incrementing it with every RREQ or RREP it 597 generates. 599 Every router receiving a RREQ or RREP can thus use the Sequence 600 Number of a RREQ or RREP as information concerning the freshness of 601 the packet's route update: If the new packet's Sequence Number is 602 lower than the one already stored in the routing table, its 603 information is considered stale. 605 As a consequence, loop freedom is assured. 607 An AODVv2 router increments its SeqNum as follows. Most of the time, 608 SeqNum is incremented by simply adding one (1). But when the SeqNum 609 has the value of the largest possible number representable as a 610 16-bit unsigned integer (i.e., 65,535), it MUST be incremented by 611 setting to one (1). In other words, the sequence number after 65,535 612 is 1. 614 An AODVv2 router SHOULD maintain its SeqNum in persistent storage. 615 If an AODVv2 router's SeqNum is lost, it MUST take the following 616 actions to avoid the danger of routing loops. First, the AODVv2 617 router MUST invalidate all route table entries, by setting 618 Route.Broken for each entry. Furthermore the AODVv2 router MUST wait 619 for at least MAX_SEQNUM_LIFETIME before transmitting or 620 retransmitting any AODVv2 RREQ or RREP messages. If an AODVv2 621 protocol message is received during this waiting period, the AODVv2 622 router SHOULD perform normal route table entry updates, but not 623 forward the message to other nodes. If a data packet is received for 624 forwarding to another destination during this waiting period, the 625 AODVv2 router MUST transmit a RERR message indicating that no route 626 is available. At the end of the waiting period the AODVv2 router 627 sets its SeqNum to one (1) and begins performing AODVv2 protocol 628 operations again. 630 5.6. Enabling Alternate Metrics 632 AODVv2 route selection in MANETs depends upon associating metric 633 information with each route table entry. When presented with 634 candidate route update information, deciding whether to use the 635 update involves evaluating the metric. Some applications may require 636 metric information other than Hop Count, which has traditionally been 637 the default metric associated with routes in MANET. Unfortunately, 638 it is well known that reliance on Hop Count can cause selection of 639 the worst possible route in many situations. 641 It is beyond the scope of this document to describe how applications 642 specify route selection at the time they launch processing. One 643 possibility would be to provide a route metric preference as part of 644 the library routines for opening sockets. In view of the above 645 considerations, it is important to enable route selection based on 646 metric information other than Hop Count -- in other words, based on 647 "alternate metrics". Each such alternate metric measures a "cost" of 648 using the associated route, and there are many different kinds of 649 cost (latency, delay, monetary, energy, etc.). 651 The most significant change when enabling use of alternate metrics is 652 to require the possibility of multiple routes to the same 653 destination, where the "cost" of each of the multiple routes is 654 measured by a different metric. Moreover, the method by which route 655 updates are tested for usefulness has to be slightly generalized to 656 depend upon a more abstract method of evaluation which, in this 657 document, is named "Cost(R)", where 'R' is the route for which the 658 Cost is to be evaluated. From the above, the route table information 659 for 'R' must always include the type of metric by which Cost(R) is 660 evaluated, so the metric type does not have to be shown as a distinct 661 parameter for Cost(R). Since determining loop freedom is known to 662 depend on comparing the Cost(R) of route update information to the 663 Cost(R) of an existing stored route using the same metric, AODVv2 664 must also be able to invoke an abstract routine which in this 665 document is called "LoopFree(R1, R2)". LoopFree(R1, R2) returns TRUE 666 when, (under the assumption of nondecreasing SeqNum during Route 667 Discovery) given that R2 is loop-free and Cost(R2) is the cost of 668 route R2, Cost(R1) is known to guarantee loop freedom of the route 669 R1. In this document, LoopFree(R1,R2) will only be invoked for 670 routes R1 and R2 to the same destination which use the same metric. 672 Generally, HopCount may still be considered the default metric for 673 use in MANETs, notwithstanding the above objections. Each metric has 674 to have a Metric Type, and the Metric Type is allocated by IANA as 675 specified in [RFC6551]. Each Route has to include the Metric Type as 676 part of the route table entry for that route. Hop Count has Metric 677 Type assignment 3. The Cost of a route using Metric Type 3 is simply 678 the hop count between the router and the destination. For routes R1 679 and R2 using Metric Type 3, LoopFree (R1, R2) is TRUE when Cost(R2) 680 <= (Cost(R1) + 1). The specification of Cost(R) and LoopFree(R1,R2) 681 for metric types other than 3 is beyond the scope of this document. 683 Whenever an AODV router receives metric information in an incoming 684 message, the value of the metric is as measured by the transmitting 685 router, and does not reflect the cost of traversing the incoming 686 link. In order to simplify the description of storing accrued route 687 costs in the route table, the Cost() function is also defined to 688 return the value of traversing a link 'L'. In other words, the 689 domain of the Cost() function is enlarged to include links as well as 690 routes. For Metric Type 3, (i.e., the HopCount metric) Cost(L) = 1 691 for all links. The specification of Cost(L) for metric types other 692 than 3 is beyond the scope of this document. Whether the argument of 693 the Cost() function is a link or a route will, in this document, 694 always be clear. As a natural result of the way routes are looked up 695 according to conformant metric type, all intermediate routers 696 handling a RteMsg will assign the same metric type to all metric 697 information in the RteMsg. 699 For some metrics, a maximum value is defined, namely MAX_METRIC[i] 700 where 'i' is the Metric Type. AODVv2 does not store routes that cost 701 more than MAX_METRIC[i]. MAX_METRIC[3] is defined to be 702 MAX_HOPCOUNT, where as before 3 is the Metric Type of the HopCount 703 metric. MAX_HOPCOUNT MUST be larger than the AODVv2 network 704 diameter. Otherwise, AODVv2 protocol messages may not reach their 705 intended destinations. 707 5.7. RREQ Table: Received RREQ Messages 709 Two incoming RREQ messages are considered to be "comparable" if they 710 were generated by the same AODVv2 router in order to discover a route 711 for the same destination with the same metric type. According to 712 that notion of comparability, when RREQ messages are flooded in a 713 MANET, an AODVv2 router may well receive comparable RREQ messages 714 from more than one of its neighbors. A router, after receiving an 715 RREQ message, MUST check against previous RREQs to assure that its 716 response message would contain information that is not redundant. 717 Otherwise, multicast RREQs are likely to be retransmitted again and 718 again with almost no additional benefit, but generating a great deal 719 of unnecessary signaling traffic and interference. 721 To avoid transmission of redundant RREQ messages, while still 722 enabling the proper handling of earlier RREQ messages that may have 723 somehow been delayed in the network, it is needed for each AODVv2 724 router to keep a list of the certain information about RREQ messages 725 which it has recently received. 727 This list is called the AODVv2 Received RREQ Table -- or, more 728 briefly, the RREQ Table. Two AODVv2 RREQ messages are comparable if: 730 o they have the same metric type 731 o they have the same OrigNode and TargNode addresses 733 Each entry in the RREQ Table has the following fields: 735 o Metric Type 736 o OrigNode address 737 o TargNode address 738 o Sequence Number 739 o Metric 740 o Timestamp 742 The RREQ Table is maintained so that no two entries in the RREQ 743 Table are comparable -- that is, all RREQs represented in the RREQ 744 Table either have different OrigNode addresses, different TargNode 745 addresses, or different metric types. If two RREQs have the same 746 metric type and OrigNode and Targnode addresses, the information from 747 the one with the older Sequence Number is not needed in the table; in 748 case they have the same Sequence Number, the one with the greater 749 Metric value is not needed; in case they have the same Metric as 750 well, it does not matter which table entry is maintained. Whenever a 751 RREQ Table entry is updated, its Timestamp field should also be 752 updated to reflect the Current_Time. 754 When optional multicast RREP (see Section 13.4) is used to enable 755 selection from among multiple possible return routes, an AODVv2 756 router can eliminate redundant RREP messages using the analogous 757 mechanism along with a RREP Table. Nevertheless, the description in 758 this section only refers to RREQ multicast messages. 760 Protocol handling of RERR messages eliminates the need for tracking 761 RERR messages, since the rules for RERR regeneration prevent the 762 phenomenon of redundant retansmission that affects RREQ and RREP 763 multicast. 765 6. AODVv2 Operations on Route Table Entries 767 In this section, operations are specified for updating the route 768 table due to timeouts and route updates within AODVv2 messages. 769 Route update information in AODVv2 messages includes IP addresses, 770 along with the SeqNum and prefix length associated with each IP 771 address, and including the Metric measured from the node transmitting 772 the AODVv2 message to the IP address in the route update. IP 773 addresses and prefix length are encoded within an RFC 5444 AddrBlk, 774 and the SeqNum and Metric associated with each address in the AddrBlk 775 are encoded in RFC 5444 AddrTLVs. In this section, RteMsg is either 776 RREQ or RREP, RteMsg.Address[i] denotes the [i]th address in an RFC 777 5444 AddrBlk of the RteMsg. RteMsg.PrefixLength[i] denotes the 778 associated prefix length for RteMsg.Address[i], and RteMsg.{field} 779 denotes the corresponding value in the named AddrTLV block associated 780 with RteMsg.Address[i]. All SeqNum comparisons use signed 16-bit 781 arithmetic. 783 6.1. Evaluating Incoming Routing Information 785 If the incoming RteMsg does not have a Metric Type Message TLV, then 786 the metric information contained by RteMsg is considered to be of 787 type DEFAULT_METRIC_TYPE -- which is 3 (for HopCount) unless changed 788 by administrative action. Whenever an AODVv2 router (HandlingRtr) 789 handles an incoming RteMsg (i.e., RREQ or RREP), for every relevant 790 address (RteMsg.Address) in the RteMsg, HandlingRtr searches its 791 route table to see if there is a route table entry with the same 792 Metric Type of the RteMsg, matching RteMsg.Address. If not, 793 HandlingRtr creates a route table entry for RteMsg.Address as 794 described in Section 6.2. Otherwise, HandlingRtr compares the 795 incoming routing information in RteMsg against the already stored 796 routing information in the route table entry (Route) for 797 RteMsg.Address, as described below. 799 Suppose Route[RteMsg.Address] uses the same metric type as the 800 incoming routing information, and the route entry contains 801 Route.SeqNum, Route.Metric, and Route.Broken. Suppose the incoming 802 routing information for Route.Address is RteMsg.SeqNum and 803 RteMsg.Metric. Define RteMsg.Cost to be (RteMsg.Metric + Cost(L)), 804 where L is the incoming link. The incoming routing information is 805 classified as follows: 807 1. Stale:: RteMsg.SeqNum < Route.SeqNum : 808 If RteMsg.SeqNum < Route.SeqNum the incoming information is stale. 809 Using stale routing information is not allowed, since that might 810 result in routing loops. HandlingRtr MUST NOT update the route 811 table entry using the routing information for RteMsg.Address. 812 2. Unsafe against loops:: (TRUE != LoopFree (RteMsg, Route)) : 813 If RteMsg is not Stale (as in (1) above), RteMsg.Cost is next 814 considered to insure loop freedom. If (TRUE != LoopFree (RteMsg, 815 Route)) (see Section 5.6), then the incoming RteMsg information is 816 not guaranteed to prevent routing loops, and it MUST NOT be used 817 to update any route table entry. 818 3. More costly:: 819 (RteMsg.Cost >= Route.Metric) && (Route.Broken==FALSE) 820 When RteMsg.SeqNum is the same as in a valid route table entry, 821 and LoopFree (RteMsg, Route) assures loop freedom, incoming 822 information still does not offer any improvement over the existing 823 route table information if RteMsg.Cost >= Route.Metric. Using 824 such incoming routing information to update a route table entry is 825 not recommended. 826 4. Offers improvement:: 827 Incoming routing information that does not match any of the above 828 criteria is better than existing routing table information and 829 SHOULD be used to improve the route table. The following pseudo- 830 code illustrates whether incoming routing information should be 831 used to update an existing route table entry as described in 832 Section 6.2. 834 (RteMsg.SeqNum > Route.SeqNum) OR 835 {(RteMsg.SeqNum == Route.SeqNum) AND 836 [(RteMsg.Cost < Route.Metric) OR 837 ((Route.Broken == TRUE) && LoopFree (RteMsg, Route))]} 839 The above logic corresponds to placing the following conditions on 840 the incoming route update (compared to the existing route table 841 entry) before it can be used: 843 * it is more recent, or 844 * it is not stale and is less costly, or 845 * it can safely repair a broken route. 847 6.2. Applying Route Updates To Route Table Entries 849 To apply the route update, a route table entry for RteMsg.Address is 850 either found to already exist in the route table, or else a new route 851 table entry for RteMsg.Address is created and inserted into the route 852 table. The route table entry is populated with the following 853 information: 855 o If RteMsg.PrefixLength exists, then Route.PrefixLength := 856 RteMsg.PrefixLength. Otherwise, Route.PrefixLength := maximum 857 length for address family (either 32 or 128). 858 o Route.SeqNum := RteMsg.SeqNum 859 o Route.NextHopAddress := IP.SourceAddress (i.e., an address of the 860 node from which the RteMsg was received) 861 o Route.NextHopInterface is set to the interface on which RteMsg was 862 received 863 o Route.Broken flag := FALSE 864 o If RteMsg.MetricType is included, then 865 Route.MetricType := RteMsg.MetricType. Otherwise, 866 Route.MetricType := DEFAULT_METRIC_TYPE. 867 o Route.Metric := (RteMsg.Metric + Cost(L)), where L is the incoming 868 link. 869 o Route.LastUsed := Current_Time 870 o If RteMsg.VALIDITY_TIME is included, then 871 Route.ExpirationTime := Current_Time + RteMsg.VALIDITY_TIME, 872 otherwise, Route.ExpirationTime := Current_Time + (ACTIVE_INTERVAL 873 + MAX_IDLETIME). 875 With these assignments to the route table entry, a route has been 876 made available, and the route can be used to send any buffered data 877 packets and subsequently to forward any incoming data packets for 878 Route.Address. An updated route entry also fulfills any outstanding 879 route discovery (RREQ) attempts for Route.Address. 881 6.3. Route Table Entry Timeouts 883 During normal operation, AODVv2 does not require any explicit 884 timeouts to manage the lifetime of a route. However, the route table 885 entry MUST be examined before using it to forward a packet, as 886 discussed in Section 8.1. Any required expiry or deletion can occur 887 at that time. Nevertheless, it is permissible to implement timers 888 and timeouts to achieve the same effect. 890 At any time, the route table can be examined and route table entries 891 can be expunged according to their current state at the time of 892 examination, as follows. 894 o An Active route MUST NOT be expunged. 896 o An Idle route SHOULD NOT be expunged. 897 o An Expired route MAY be expunged (least recently used first). 898 o A route MUST be expunged if (Current_Time - Route.LastUsed) >= 899 MAX_SEQNUM_LIFETIME. 900 o A route MUST be expunged if Current_Time >= Route.ExpirationTime 902 If precursor lists are maintained for the route (as described in 903 Section 13.3) then the precursor lists must also be expunged at the 904 same time that the route itself is expunged. 906 7. Routing Messages RREQ and RREP (RteMsgs) 908 AODVv2 message types RREQ and RREP are together known as Routing 909 Messages (RteMsgs) and are used to discover a route between an 910 Originating and Target Node, denoted here by OrigNode and TargNode. 911 The constructed route is bidirectional, enabling packets to flow 912 between OrigNode and TargNode. RREQ and RREP have similar 913 information and function, but have some differences in their rules 914 for handling. The main difference between the two messages is that 915 RREQ messages are typically multicast to solicit a RREP, whereas RREP 916 is typically unicast as a response to RREQ. 918 When an AODVv2 router needs to forward a data packet from a node 919 (OrigNode) in its set of router clients, and it does not have a 920 forwarding route toward the packet's IP destination address 921 (TargNode), the AODVv2 router (RREQ_Gen) generates a RREQ (as 922 described in Section 7.3) to discover a route toward TargNode. 923 Subsequently RREQ_Gen awaits reception of an RREP message (see 924 Section 7.4) or other route table update (see Section 6.2) to 925 establish a route toward TargNode. Optionally, RREQ_Gen MAY specify 926 that only the router serving TargNode is allowed to generate an RREP 927 message, by including the DestOnly message TLV (see Section 7.3). 928 The RREQ message contains routing information to enable RREQ 929 recipients to route packets back to OrigNode, and the RREP message 930 contains routing information enabling RREP recipients to route 931 packets to TargNode. 933 7.1. Route Discovery Retries and Buffering 935 After issuing a RREQ, as described above RREQ_Gen awaits a RREP 936 providing a bidirectional route toward Target Node. If the RREP is 937 not received within RREQ_WAIT_TIME, RREQ_Gen may retry the Route 938 Discovery by generating another RREQ. Route Discovery SHOULD be 939 considered to have failed after DISCOVERY_ATTEMPTS_MAX and the 940 corresponding wait time for a RREP response to the final RREQ. After 941 the attempted Route Discovery has failed, RREQ_Gen MUST wait at least 942 RREQ_HOLDDOWN_TIME before attempting another Route Discovery to the 943 same destination. 945 To reduce congestion in a network, repeated attempts at route 946 discovery for a particular Target Node SHOULD utilize a binary 947 exponential backoff. 949 Data packets awaiting a route SHOULD be buffered by RREQ_Gen. This 950 buffer SHOULD have a fixed limited size (BUFFER_SIZE_PACKETS or 951 BUFFER_SIZE_BYTES). Determining which packets to discard first is a 952 matter of policy at each AODVv2 router; in the absence of policy 953 constraints, by default older data packets SHOULD be discarded first. 954 Buffering of data packets can have both positive and negative effects 955 (albeit usually positive). Nodes without sufficient memory available 956 for buffering SHOULD be configured to disable buffering by 957 configuring BUFFER_SIZE_PACKETS == 0 and BUFFER_SIZE_BYTES == 0. 958 Doing so will affect the latency required for launching TCP 959 applications to new destinations. 961 If a route discovery attempt has failed (i.e., DISCOVERY_ATTEMPTS_MAX 962 attempts have been made without receiving a RREP) to find a route 963 toward the Target Node, any data packets buffered for the 964 corresponding Target Node MUST BE dropped and a Destination 965 Unreachable ICMP message (Type 3) SHOULD be delivered to the source 966 of the data packet. The code for the ICMP message is 1 (Host 967 unreachable error). If RREQ_Gen is not the source (OrigNode), then 968 the ICMP is sent over the interface from which OrigNode sent the 969 packet to the AODVv2 router. 971 7.2. RteMsg Structure 973 RteMsgs have the following general format: 975 +---------------------------------------------------------------+ 976 | RFC 5444 Message Header | 977 +---------------------------------------------------------------+ 978 | MsgTLVs (e.g., Metric Type TLV {OrigNode,TargNode}(optional)) | 979 +---------------------------------------------------------------+ 980 | AddrBlk := {OrigNode,TargNode} | 981 +---------------------------------------------------------------+ 982 | AddrBlk.PrefixLength[OrigNode OR TargNode] (Optional) | 983 +---------------------------------------------------------------+ 984 | OrigSeqNum_TLV AND/OR TargSeqNum_TLV | 985 +---------------------------------------------------------------+ 986 | Metric TLV {OrigNode, TargNode} | 987 +---------------------------------------------------------------+ 989 Figure 1: RREQ and RREP (RteMsg) message structure 991 Required Message Header Fields 992 The RteMsg MUST contain the following: 994 * 995 * Metric Type Message TLV, if Metric Type != 3 996 Optional Message Header Fields 997 The RteMsg may contain the following: 999 * 1000 * DestOnly TLV (RREQ only: no Intermediate RREP) 1001 * Metric Type TLV (Metric Type for Metric AddrTLV) 1002 * AckReq TLV (Acknowledgement Requested) 1003 AddrBlk 1004 This Address Block contains the IP addresses for RREQ Originating 1005 and Target Node (OrigNode and TargNode). For both RREP and RREQ, 1006 OrigNode and TargNode are as identified in the context of the RREQ 1007 message originator. 1008 OrigSeqNum AND/OR TargSeqNum AddrTLV 1009 At least one of OrigSeqNum or TargSeqNum Address Block TLV is 1010 REQUIRED and carries the destination sequence numbers associated 1011 with either OrigNode or TargNode. Both may appear when SeqNum 1012 information is available for both OrigNode and TargNode. 1013 Metric AddrTLV 1014 The Metric AddrTLV is REQUIRED and carries the route metric 1015 information associated with either OrigNode or TargNode. 1017 RteMsgs carry information about OrigNode and TargNode. Since their 1018 addresses may appear in arbitrary order within the RFC 5444 AddrBlk, 1019 the OrigSeqNum and/or TargSeqNum TLVs must be used to distinguish the 1020 nature of the node addresses present in the AddrBlk. In each RteMsg, 1021 either the OrigSeqNum TLV or TargSeqNum TLV MUST appear. Both TLVs 1022 MAY appear in the same RteMsg, but each one MUST NOT appear more than 1023 once, because there is only one OrigNode and only one TargNode 1024 address in the AddrBlk. 1026 If the OrigSeqNum TLV appears, then the address range for the 1027 OrigSeqNum TLV MUST be limited to a single position in the AddrBlk. 1028 That position is used as the OrigNdx, identifying the OrigNode 1029 address. The other address in the AddrBlk is, by elimination, the 1030 TargNode address, and TargNdx is set appropriately. 1032 Otherwise, if the TargSeqNum TLV appears, then the address range for 1033 the TargSeqNum TLV MUST be limited to a single position in the 1034 AddrBlk. That position is used as the TargNdx, identifying the 1035 TargNode address. The other address in the AddrBlk is, by 1036 elimination, the OrigNode address, and OrigNdx is set appropriately. 1038 7.3. RREQ Generation 1040 The AODVv2 router generating the RREQ (RREQ_Gen) on behalf of its 1041 client OrigNode follows the steps in this section. OrigNode MUST be 1042 a unicast address. The order of protocol elements is illustrated 1043 schematically in Figure 1. 1045 1. RREQ_Gen MUST increment its SeqNum by one (1) according to the 1046 rules specified in Section 5.5. This assures that each node 1047 receiving the RREQ will update its route table using the 1048 information in the RREQ. 1049 2. If RREQ_Gen requires that only the router providing connectivity 1050 to TargNode is allowed to generate a RREP, then RREQ_Gen includes 1051 the "Destination RREP Only" (DestOnly) TLV as part of the RFC 1052 5444 message header. This also assures that RREP_Gen increments 1053 its sequence number. Otherwise, (if the optional behavior is 1054 enabled) other AODVv2 routers MAY respond to the RREQ if they 1055 have a valid route to TargNode (see Section 13.2). 1056 3. SHOULD be set to MAX_HOPCOUNT. 1057 4. , if included, MUST be set to 0. 1059 * This RFC 5444 constraint causes certain RREQ payloads to incur 1060 additional enlargement (otherwise, could often 1061 be used as the metric). 1062 5. RREQ.AddrBlk := {OrigNode.Addr, TargNode.Addr} 1064 Let OrigNdx and TargNdx denote the indexes of OrigNode and 1065 TargNode respectively in the RREQ.AddrBlk list. 1066 6. If Route[OrigNode].PrefixLength/8 is equal to the number of bytes 1067 in the addresses of the RREQ (4 for IPv4, 16 for IPv6), then no 1068 is included with the RREQ.AddrBlk. Otherwise, 1069 RREQ.PrefixLength[OrigNdx] := Route[OrigNode].PrefixLength 1070 according to the rules of RFC 5444 AddrBlk encoding. 1071 7. RREQ.OrigSeqNum_TLV[OrigNdx] := RREQ_Gen's SeqNum 1072 8. RREQ.TargSeqNum_TLV[TargNdx] := TargNode's SeqNum (only if known) 1074 RREQ_Gen SHOULD include TargNode's SeqNum, if a previous value of 1075 the TargNode's SeqNum is known (e.g., from an invalid routing 1076 table entry using longest-prefix matching). If TargNode's SeqNum 1077 is not included, AODVv2 routers handling the RREQ assume that 1078 RREQ_Gen does not have that information. If ENABLE_IRREP is 1079 enabled, then any route to TargNode will satisfy the RREQ 1080 [I-D.perkins-irrep]. 1081 9. RREQ.Metric_TLV[OrigNdx] := Route[OrigNode].Metric 1083 An example RREQ message format is illustrated in Appendix A.1. 1085 7.4. RREP Generation 1087 This section specifies the generation of an RREP by an AODVv2 router 1088 (RREP_Gen) that provides connectivity for the Target Node (TargNode) 1089 of a RREQ, thus enabling the establishment of a route between 1090 OrigNode and TargNode. If TargNode is not a unicast IP address the 1091 RREP MUST NOT be generated, and processing for the RREQ is complete. 1092 Before transmitting a RREP, the routing information of the RREQ is 1093 processed as specified in Section 6.2; after such processing, 1094 RREP_Gen has an updated route to OrigNode as well as TargNode. The 1095 basic format of an RREP conforms to the structure for RteMsgs as 1096 shown in Figure 1. 1098 RREP_Gen generates the RREP as follows: 1100 1. RREP_Gen checks the RREQ against recently received RREQ 1101 information as specified in Section 7.6. If a previously 1102 received RREQ has made the information in the incoming RREQ to 1103 be redundant, no RREP is generated and processing is complete. 1104 2. RREP_Gen MUST increment its SeqNum by one (1) according to the 1105 rules specified in Section 5.5. 1106 3. RREP.AddrBlk := {OrigNode.Addr, TargNode.Addr} 1108 Let OrigNdx and TargNdx denote the indexes of OrigNode and 1109 TargNode respectively in the RREQ.AddrBlk list. 1110 4. RREP.TargSeqNum_TLV[TargNdx] := RREP_Gen's SeqNum 1111 5. If Route[TargNode].PrefixLength/8 is equal to the number of 1112 bytes in the addresses of the RREQ (4 for IPv4, 16 for IPv6), 1113 then no is included with the RREP.AddrBlk. 1114 Otherwise, RREP.PrefixLength[TargNdx] := 1115 Route[TargNode].PrefixLength according to the rules of RFC 5444 1116 AddrBlk encoding. 1117 6. RREP.MetricType[TargNdx] := Route[TargNode].MetricType 1118 7. RREP.Metric_TLV[TargNdx] := Route[TargNode].Metric 1119 8. , if included, MUST be set to 0. 1120 9. SHOULD be set to RREQ.. 1121 10. IP.DestinationAddr := Route[OrigNode].NextHop 1123 An example message format for RREP is illustrated in Appendix A.2. 1125 7.5. Handling a Received RteMsg 1127 Before an AODVv2 router can make use of a received RteMsg (i.e., RREQ 1128 or RREP), the router first must verify that the RteMsg is permissible 1129 according to the following steps. OrigNdx and TargNdx are set 1130 according to the rules in Section 7.2. For RREQ, RteMsg.Metric is 1131 Metric_TLV[OrigNdx]. For RREP, RteMsg.Metric is Metric_TLV[TargNdx]. 1132 In this section (unless qualified by additional description such as 1133 "upstream" or "neighboring") all occurrences of the term "router" 1134 refer to the AODVv2 router handling the received RteMsg. 1136 1. A router MUST handle RteMsgs only from neighbors as specified in 1137 Section 5.4. RteMsgs from other sources MUST be disregarded. 1138 2. The router examines the RteMsg to ascertain that it contains the 1139 required information: , TargNode.Addr, 1140 OrigNode.Addr, RteMsg.Metric, and either RteMsg.OrigSeqNum or 1141 RteMsg.TargSeqNum. If the required information does not exist, 1142 the message is disregarded. 1143 3. The router checks that OrigNode.Addr and TargNode.Addr are valid 1144 routable unicast addresses. If not, the message is disregarded. 1145 4. The router checks the Metric Type MsgTLV (if present) to assure 1146 that the Metric Type associated with the Metric AddrTLV 1147 information in the RREQ or RREP is known. If not, the message is 1148 disregarded. 1150 * DISCUSSION: or, can change the AddrBlk metric to use HopCount, 1151 e.g., measured from . 1152 5. If (MAX_METRIC[RteMsg.MetricType] - Cost(L)) <= RteMsg.Metric, 1153 the RteMsg is disregarded, where Cost(L) denotes the cost of 1154 traversing the incoming link (i.e., as measured by the network 1155 interface receiving the incoming RteMsg). 1157 An AODVv2 router handles a permissible RteMsg according to the 1158 following steps. 1160 1. The router MUST process the routing information for OrigNode and 1161 TargNode contained in the RteMsg as specified in Section 6.1. 1162 2. If RteMsg. is zero (0), no further action is 1163 taken, and the RteMsg is not retransmitted. Otherwise, the 1164 router MUST decrement RteMsg.. 1165 3. If the RteMsg. is present, and MAX_HOPCOUNT <= 1166 , then no further action is taken. Otherwise, the 1167 router MUST increment RteMsg. 1169 Further actions to transmit an updated RteMsg depend upon whether the 1170 incoming RteMsg is an RREP or an RREQ. 1172 7.5.1. Additional Handling for Incoming RREQ 1174 o By sending a RREQ, a router advertises that it will route for 1175 addresses contained in the RteMsg based on the information 1176 enclosed. The router MAY choose not to send the RREQ, though not 1177 resending the RREQ could decrease connectivity in the network or 1178 result in nonoptimal paths. The circumstances under which a 1179 router might choose not to re-transmit a RREQ are not specified in 1180 this document. Some examples might include the following: 1182 * The router is already heavily loaded and does not want to 1183 advertise routing for more traffic 1184 * The router recently transmitted identical routing information 1185 (e.g. in a RREQ advertising the same metric) Section 7.6 1186 * The router is low on energy and has to reduce energy expended 1187 for sending protocol messages or packet forwarding 1189 Unless the router is prepared to send a RREQ, it halts processing. 1190 o If the upstream router sending a RREQ is in the Blacklist, and 1191 Current_Time < Blacklist.RemoveTime, then the router receiving 1192 that RREQ MUST NOT transmit any outgoing RteMsg, and processing is 1193 complete. 1194 o Otherwise, if the upstream router is in the Blacklist, and 1195 Current_Time >= Blacklist.RemoveTime, then the upstream router 1196 SHOULD be removed from the Blacklist, and message processing 1197 continued. 1198 o The incoming RREQ MUST be checked against previously received 1199 information from the RREQ Table Section 7.6. If the information 1200 in the incoming RteMsg is redundant, then then no further action 1201 is taken. 1202 o If TargNode is a client of the router receiving the RREQ, then the 1203 router generates a RREP message as specified in Section 7.4, and 1204 subsequently processing for the RREQ is complete. Otherwise, 1205 processing continues as follows. 1206 o RREQ.MetricType := Route[OrigNode].MetricType 1207 o RREQ.Metric_TLV[OrigNdx] := Route[OrigNode].Metric 1208 o The RREQ (with updated fields as specified above>) SHOULD be sent 1209 to the IP multicast address LL-MANET-Routers [RFC5498]. If the 1210 RREQ is unicast, the IP.DestinationAddress is set to 1211 Route[RREQ.TargNode].NextHopAddress. 1213 7.5.2. Additional Handling for Incoming RREP 1215 As before, OrigNode and TargNode are named in the context of RREQ_Gen 1216 (i.e., the router originating the RREQ for which the RREP was 1217 generated) (see Table 1). OrigNdx and TargNdx are set according to 1218 the rules in Section 7.2. 1220 o If no forwarding route exists to OrigNode, then a RERR SHOULD be 1221 transmitted to RREP.AddrBlk[TargNdx]. Otherwise, if HandlingRtr 1222 is not RREQ_Gen then the outgoing RREP is sent to the 1223 Route.NextHopAddress for the RREP.AddrBlk[OrigNdx]. 1224 o If HandlingRtr is RREQ_Gen then the RREP satisfies RREQ_Gen's 1225 earlier RREQ, and RREP processing is completed. Any packets 1226 buffered for OrigNode should be transmitted. 1228 7.6. Suppressing Redundant RREQ messages 1230 Since RREQ messages are multicast, there are common circumstances in 1231 which an AODVv2 router might transmit a redundant response (RREQ or 1232 RREP), duplicating the information transmitted in response to some 1233 other recent RREQ (see Section 5.7). Before responding, an AODVv2 1234 router MUST suppress such redundant RREQ messages. This is done by 1235 checking the list of recently received RREQs to determine whether the 1236 incoming RREQ contains new information, as follows: 1238 o The AODVv2 router searches the RREQ Table for recent entries with 1239 the same OrigNode, TargNode, and Metric Type. If there is no such 1240 entry, the incoming RREQ message is not suppressed. A new entry 1241 for the incoming RREQ is created in the RREQ Table. 1242 o If there is such an entry, and the incoming RREQ has a newer 1243 sequence number, the incoming RREQ is not suppressed, and the 1244 existing table entry MUST be updated to reflect the new Sequence 1245 Number and Metric. 1246 o Similarly, if the Sequence Numbers are the same, and the incoming 1247 RREQ offers a better Metric, the incoming RREQ is not suppressed, 1248 and the RREQ Table entry MUST be updated to reflect the new 1249 Metric. 1250 o Otherwise, the incoming RREQ is suppressed. 1252 8. Route Maintenance and RERR Messages 1254 AODVv2 routers attempt to maintain active routes. When a routing 1255 problem is encountered, an AODVv2 router (denoted RERR_Gen) attempts 1256 to quickly notify upstream routers. Two kinds of routing problems 1257 may trigger generation of a RERR message. The first case happens 1258 when the router receives a packet but does not have a route for the 1259 destination of the packet. The second case happens immediately upon 1260 detection of a broken link (see Section 8.2) of an Active route, to 1261 quickly notify upstream AODVv2 routers that that route is no longer 1262 available. 1264 8.1. Maintaining Route Lifetimes During Packet Forwarding 1266 Before using a route to forward a packet, an AODVv2 router MUST check 1267 the status of the route as follows. 1269 If the route is marked has been marked as Broken, it cannot be 1270 used for forwarding. 1271 If Current_Time > Route.ExpirationTime, the route table entry has 1272 expired, and cannot be used for forwarding. 1273 Similarly, if (Route.ExpirationTime == MAXTIME), and if 1274 (Current_Time - Route.LastUsed) > (ACTIVE_INTERVAL + 1275 MAX_IDLETIME), the route has expired, and cannot be used for 1276 forwarding. 1277 Furthermore, if Current_Time - Route.LastUsed > 1278 (MAX_SEQNUM_LIFETIME), the route table entry MUST be expunged. 1280 If any of the above route error conditions hold true, the route 1281 cannot be used to forward the packet, and an RERR message MUST be 1282 generated (see Section 8.3). 1284 Otherwise, Route.LastUsed := Current_Time, and the packet is 1285 forwarded to the route's next hop. 1287 Optionally, if a precursor list is maintained for the route, see 1288 Section 13.3 for precursor lifetime operations. 1290 8.2. Active Next-hop Router Adjacency Monitoring 1292 AODVv2 routers SHOULD monitor connectivity to adjacent routers along 1293 active routes. This monitoring can be accomplished by one or several 1294 mechanisms, including: 1296 o Neighborhood discovery [RFC6130] 1297 o Route timeout 1298 o Lower layer trigger that a link is broken 1299 o TCP timeouts 1300 o Promiscuous listening 1301 o Other monitoring mechanisms or heuristics 1303 If a next-hop AODVv2 router has become unreachable, RERR_Gen follows 1304 the procedures specified in Section 8.3.2. 1306 8.3. RERR Generation 1308 An RERR message is generated by a AODVv2 router (i.e., RERR_Gen) in 1309 order to notify upstream routers that packets cannot be delivered to 1310 certain destinations. An RERR message has the following general 1311 structure: 1313 +---------------------------------------------------------------+ 1314 | RFC 5444 Message Header | 1315 +---------------------------------------------------------------+ 1316 | UnreachableNode AddrBlk (Unreachable Node addresses) | 1317 +---------------------------------------------------------------+ 1318 | UnreachableNode SeqNum AddrBlk TLV | 1319 +---------------------------------------------------------------+ 1321 Figure 2: RERR message structure 1323 Required Message Header Fields 1324 The RERR MUST contain the following: 1326 * 1327 * PktSource Message TLV (see Section 15), if the RERR is unicast 1328 * Metric Type Message TLV (see Section 15), if Metric Type != 3 1329 Optional Message Header Fields 1330 The RERR SHOULD contain the following: 1332 * 1333 UnreachableNode AddrBlk 1334 This Address Block contains the IP addresses unreachable by AODVv2 1335 router transmitting the RERR. 1336 Sequence Number AddrBlk TLV 1337 This Address Block TLV carries the destination sequence number 1338 associated with each UnreachableNode when that information is 1339 available. 1340 UnreachableNode.PrefixLength 1341 The prefix length associated with an UnreachableNode. 1343 There are two kinds of events indicating that packets cannot be 1344 delivered to certain destinations. The two cases differ in the way 1345 that the neighboring IP destination address for the RERR is chosen, 1346 and in the way that the set of UnreachableNodes is identified. 1348 In both cases, the MUST be included and SHOULD be set 1349 to MAX_HOPCOUNT. SHOULD be included and set to 0, to 1350 facilitate use of various route repair strategies including expanding 1351 rings multicast and Intermediate RREP [I-D.perkins-irrep]. 1353 8.3.1. Case 1: Undeliverable Packet 1355 The first case happens when the router receives a packet from another 1356 AODVv2 router but does not have a valid route for the destination of 1357 the packet. In this case, there is exactly one UnreachableNode to be 1358 included in the RERR's AddrBlk (either IP.DestinationAddress from a 1359 data packet or RREP.AddrBlk[OrigNode]). The RERR SHOULD be sent to 1360 the multicast address LL-MANET-Routers, but RERR_Gen MAY instead send 1361 the RERR to the next hop towards the source IP address of the packet 1362 which was undeliverable. For unicast RERR, the PktSource Message TLV 1363 MUST be included, containing the the source IP address of the 1364 undeliverable packet, or the IP address of TargRtr in case the 1365 undeliverable packet was an RREP message generated by TargRtr. If a 1366 Sequence Number for UnreachableNode is known, that Sequence Number 1367 SHOULD be included in a Seqnum AddrTLV the RERR. Otherwise all nodes 1368 handling the RERR will assume their route through RERR_Gen towards 1369 the UnreachableNode is no longer valid and flag those routes as 1370 broken, regardless of the Sequence Number information for those 1371 routes. RERR_Gen MUST discard the packet or message that triggered 1372 generation of the RERR. 1374 If an AODVv2 router receives an ICMP packet from the address of one 1375 of its client nodes, it simply relays the packet to the ICMP packet's 1376 destination address, and does not generate any RERR message. 1378 8.3.2. Case 2: Broken Link 1380 The second case happens when the link breaks to an active adjacent 1381 AODVv2 router (i.e., the next hop of an active route). In this case, 1382 the RERR MUST be sent to the multicast address LL-MANET-Routers, 1383 except when the optional feature of maintaining precursor lists is 1384 used as specified in Section 13.3. All routes (Active, Idle and 1385 Expired) that use the broken link MUST be marked as Broken. The set 1386 of UnreachableNodes is initialized by identifying those Active routes 1387 which use the broken link. For each such Active Route, Route.Dest is 1388 added to the set of Unreachable Nodes. After the Active Routes using 1389 the broken link have all been included as UnreachableNodes, Idle 1390 routes MAY also be included, if allowed by the setting of 1391 ENABLE_IDLE_UNREACHABLE, as long as the packet size of the RERR does 1392 not exceed the MTU (interface "Maximum Transfer Unit") of the 1393 physical medium. 1395 If the set of UnreachableNodes is empty, no RERR is generated. 1396 Otherwise, RERR_Gen generates a new RERR, and the address of each 1397 UnreachableNode is inserted into an AddrBlock. The value for each 1398 UnreachableNode's SeqNum (UnreachableNode.SeqNum) MUST be placed in 1399 the SeqNum AddrTLV. If none of UnreachableNode.Addr entries are 1400 associated with routing prefixes (i.e., no prefix length is shorter 1401 than the maximum length for the address family), then the AddrBlk 1402 SHOULD NOT include any prefix-length information. 1404 Every broken route reported in the RERR MUST have the same Metric 1405 Type. If the Metric Type is not 3, then the RERR message MUST 1406 contain a Metric Type MsgTLV indicating the Metric Type of the broken 1407 route(s). 1409 8.4. Receiving and Handling RERR Messages 1411 When an AODVv2 router (HandlingRtr) receives a RERR message, it uses 1412 the information provided to invalidate affected routes. If the 1413 information in the RERR may be relevant to upstream neighbors using 1414 those routes, HandlingRtr subsequently sends another RERR to those 1415 neighbors. This operation has the effect of retransmitting the RERR 1416 information and is counted as another "hop" for purposes of properly 1417 modifying and in the RERR message 1418 header. 1420 HandlingRtr examines the incoming RERR to assure that it contains 1421 and at least one UnreachableNode.Address. If the 1422 required information does not exist, the incoming RERR message is 1423 disregarded and further processing stopped. Otherwise, for each 1424 UnreachableNode.Address, HandlingRtr searches its route table for a 1425 route using longest prefix matching. If no such Route is found, 1426 processing is complete for that UnreachableNode.Address. Otherwise, 1427 HandlingRtr verifies the following: 1429 1. The UnreachableNode.Address is a routable unicast address. 1430 2. Route.NextHopAddress is the same as RERR IP.SourceAddress. 1431 3. Route.NextHopInterface is the same as the interface on which the 1432 RERR was received. 1433 4. The UnreachableNode.SeqNum is unknown, OR Route.SeqNum <= 1434 UnreachableNode.SeqNum (using signed 16-bit arithmetic). 1436 If the Route satisfies all of the above conditions, HandlingRtr 1437 checks whether Route.PrefixLength is the same as the prefix length 1438 for UnreachableNode.Address. If so, HandlingRtr simply sets the 1439 Route.Broken flag for that Route. Otherwise, HandlingRtr creates a 1440 new route (call it BrokenRoute) with the same PrefixLength as the 1441 prefix length for UnreachableNode.Address, and sets the 1442 BrokenRoute.Broken flag for that new route. If the prefix length for 1443 BrokenRoute is shorter than Route.PrefixLength, then Route MUST be 1444 expunged from the routing table (since it is a subroute of the larger 1445 route which is reported to be broken). Furthermore, if is greater than 0, then HandlingRtr adds the UnreachableNode 1447 address and TLV information to an AddrBlk for delivery in the 1448 outgoing RERR message. 1450 If there are no UnreachableNode addresses to be transmitted in an 1451 RERR to upstream routers, HandlingRtr MUST discard the RERR, and no 1452 further action is taken. 1454 Otherwise, is decremented by one (1) and processing 1455 continues as follows: 1457 o (Optional) If precursor lists are maintained, the outgoing RERR 1458 SHOULD be sent to the active precursors of the broken route as 1459 specified in Section 13.3. 1460 o Otherwise, if the incoming RERR message was received at the LL- 1461 MANET-Routers [RFC5498] multicast address, the outgoing RERR 1462 SHOULD also be sent to LL-MANET-Routers. 1463 o Otherwise, if the PktSource Message TLV is present, and 1464 HandlingRtr has a Route to PktSource.Addr, then HandlingRtr MUST 1465 send the outgoing RERR to Route[PktSource.Addr].NextHop. 1466 o Otherwise, the outgoing RERR MUST be sent to LL-MANET-Routers. 1468 9. Unknown Message and TLV Types 1470 If a message with an unknown type is received, the message is 1471 disregarded. 1473 For handling of messages that contain unknown TLV types, ignore the 1474 information for processing, but preserve it unmodified for 1475 forwarding. 1477 10. Simple Internet Attachment 1479 Simple Internet attachment means attachment of a stub (i.e., non- 1480 transit) network of AODVv2 routers to the Internet via a single 1481 Internet AODVv2 router (called IAR). 1483 As in any Internet-attached network, AODVv2 routers, and their 1484 clients, wishing to be reachable from hosts on the Internet MUST have 1485 IP addresses within the IAR's routable and topologically correct 1486 prefix (e.g. 191.0.2.0/24). 1488 /-------------------------\ 1489 / +----------------+ \ 1490 / | AODVv2 Router | \ 1491 | | 191.0.2.2/32 | | 1492 | +----------------+ | Routable 1493 | +-----+--------+ Prefix 1494 | | Internet | /191.0.2/24 1495 | | AODVv2 Router| / 1496 | | 191.0.2.1 |/ /---------------\ 1497 | | serving net +------+ Internet \ 1498 | | 191.0.2/24 | \ / 1499 | +-----+--------+ \---------------/ 1500 | +----------------+ | 1501 | | AODVv2 Router | | 1502 | | 191.0.2.3/32 | | 1503 \ +----------------+ / 1504 \ / 1505 \-------------------------/ 1507 Figure 3: Simple Internet Attachment Example 1509 When an AODVv2 router within the AODVv2 MANET wants to discover a 1510 route toward a node on the Internet, it uses the normal AODVv2 route 1511 discovery for that IP Destination Address. The IAR MUST respond to 1512 RREQ on behalf of all Internet destinations. 1514 When a packet from a node on the Internet destined for a node in the 1515 AODVv2 MANET reaches the IAR, if the IAR does not have a route toward 1516 that destination it will perform normal AODVv2 route discovery for 1517 that destination. 1519 11. Multiple Interfaces 1521 AODVv2 may be used with multiple interfaces; therefore, the 1522 particular interface over which packets arrive MUST be known whenever 1523 a packet is received. Whenever a new route is created, the interface 1524 through which the Route.Address can be reached is also recorded in 1525 the route table entry. 1527 When multiple interfaces are available, a node transmitting a 1528 multicast packet with IP.DestinationAddress set to LL-MANET-Routers 1529 SHOULD send the packet on all interfaces that have been configured 1530 for AODVv2 operation. 1532 Similarly, AODVv2 routers SHOULD subscribe to LL-MANET-Routers on all 1533 their AODVv2 interfaces. 1535 12. AODVv2 Control Packet/Message Generation Limits 1537 To avoid messaging overload, each AODVv2 router's rate of packet/ 1538 message generation SHOULD be limited. The rate and algorithm for 1539 limiting messages (CONTROL_TRAFFIC_LIMITS) is left to the implementor 1540 and should be administratively configurable. AODVv2 messages SHOULD 1541 be discarded in the following order of preference: RREQ, RREP, and 1542 finally RERR. 1544 13. Optional Features 1546 Some optional features of AODVv2, associated with AODV, are not 1547 required by minimal implementations. These features are expected to 1548 apply in networks with greater mobility, or larger node populations, 1549 or requiring reduced latency for application launches. The optional 1550 features are as follows: 1552 o Expanding Rings Multicast 1553 o Intermediate RREPs (iRREPs): Without iRREP, only the destination 1554 can respond to a RREQ. 1555 o Precursor lists. 1556 o Reporting Multiple Unreachable Nodes. An RERR message can carry 1557 more than one Unreachable Destination node for cases when a single 1558 link breakage causes multiple destinations to become unreachable 1559 from an intermediate router. 1560 o RREP_ACK. 1561 o Message Aggregation. 1563 13.1. Expanding Rings Multicast 1565 For multicast RREQ, MAY be set in accordance with an 1566 expanding ring search as described in [RFC3561] to limit the RREQ 1567 propagation to a subset of the local network and possibly reduce 1568 route discovery overhead. 1570 13.2. Intermediate RREP 1572 This specification has been published as a separate Internet Draft 1573 [I-D.perkins-irrep]. 1575 13.3. Precursor Lists and Notifications 1577 This section specifies an interoperable enhancement to AODVv2 (and 1578 possibly other reactive routing protocols) enabling more economical 1579 notifications to active sources of traffic upon determination that a 1580 route needed to forward such traffic to its destination has become 1581 Broken. 1583 13.3.1. Overview 1585 In many circumstances, there can be several sources of traffic for a 1586 certain destination. Each such source of traffic is known as a 1587 "precursor" for the destination, as well as all upstream routers 1588 between the forwarding AODVv2 router and the traffic source. For 1589 each active destination, an AODVv2 router MAY choose to keep track of 1590 the upstream neighbors that have provided traffic for that 1591 destination; there is no need to keep track of upstream routers any 1592 farther away than the next hop. 1594 Moreover, any particular link to an adjacent AODVv2 router may be a 1595 path component of multiple routes towards various destinations. The 1596 precursors for all destinations using the next hop across any link 1597 are collectively known as the precursors for that next hop. 1599 When an AODVv2 router determines that an active link to one of its 1600 downstream neighbors has broken, the AODVv2 router detecting the 1601 broken link must mark multiple routes as Broken, for each of the 1602 newly unreachable destinations, as described in Section 8.3. Each 1603 route that relies on the newly broken link is no longer valid. 1604 Furthermore, the precursors of the broken link should be notified 1605 (using RERR) about the change in status of their route to a 1606 destination downstream along the broken next hop. 1608 13.3.2. Precursor Notification Details 1610 During normal operation, each AODVv2 router wishing to maintain 1611 precursor lists as described above, maintains a precursor table and 1612 updates the table whenever the node forwards traffic to one of the 1613 destinations in its route table. For each precursor in the precursor 1614 list, a record must be maintained to indicate whether the precursor 1615 has been used for recent traffic (in other words, whether the 1616 precursor is an Active precursor). So, when traffic arrives from a 1617 precursor, the Current_Time is used to mark the time of last use for 1618 the precursor list element associated with that precursor. 1620 When an AODVv2 router detects that a link is broken, then for each 1621 precursor using that next hop, the node MAY notify the precursor 1622 using either unicast or multicast RERR: 1624 unicast RERR to each Active precursor 1625 This option is applicable when there are few Active precursors 1626 compared to the number of neighboring AODVv2 routers. 1627 multicast RERR to RERR_PRECURSORS 1628 RERR_PRECURSORS is, by default, LL-MANET-Routers [RFC5498]. This 1629 option is typically preferable when there are many precursors, 1630 since fewer packet transmissions are required. 1632 Each active upstream neighbor (i.e., precursor) MAY then execute the 1633 same procedure until all active upstream routers have received the 1634 RERR notification. 1636 13.4. Multicast RREP Response to RREQ 1638 The RREQ Target Router (RREP_Gen) MAY, as an alternative to 1639 unicasting a RREP, be configured to distribute routing information 1640 about the route toward the RREQ TargNode (RREP_Gen's client) more 1641 widely. That is, RREP_Gen MAY be configured respond to a route 1642 discovery by generating a RREP, using the procedure in Section 7.4, 1643 but multicasting the RREP to LL-MANET-Routers [RFC5498] (subject to 1644 similar suppression algorithm for redundant RREP multicasts as 1645 described in Section 7.6). The redundant message suppression must 1646 occur at every router handling the multicast RREP. Afterwards, 1647 RREP_Gen processing for the incoming RREQ is complete. 1649 Broadcast RREP response to incoming RREQ was originally specified to 1650 handle unidirectional links, but it is expensive. Due to the 1651 significant overhead, AODVv2 routers MUST NOT use multicast RREP 1652 unless configured to do so by setting the administrative parameter 1653 USE_MULTICAST_RREP. 1655 13.5. RREP_ACK 1657 Instead of relying on existing mechanisms for requesting verification 1658 of link bidirectionality during Route Discovery, RREP_Ack is provided 1659 as an optional feature and modeled on the RREP_Ack message type from 1660 AODV [RFC3561]. 1662 Since the RREP_ACK is simply echoed back to the node from which the 1663 RREP was received, there is no need for any additional RFC 5444 1664 address information (or TLVs). Considerations of packet TTL are as 1665 specified in Section 5.4. An example message format is illustrated 1666 in section Appendix A.4. 1668 13.6. Message Aggregation 1670 The aggregation of multiple messages into a packet is specified in 1671 RFC 5444 [RFC5444]. 1673 Implementations MAY choose to briefly delay transmission of messages 1674 for the purpose of aggregation (into a single packet) or to improve 1675 performance by using jitter [RFC5148]. 1677 14. Administratively Configurable Parameters and Timer Values 1679 AODVv2 uses various configurable parameters of various types: 1681 o Timers 1682 o Protocol constants 1683 o Administrative (functional) controls 1684 o Other administrative parameters and lists 1686 The tables in the following sections show the parameters along their 1687 definitions and default values (if any). 1689 Note: several fields have limited size (bits or bytes). These sizes 1690 and their encoding may place specific limitations on the values that 1691 can be set. For example, is a 8-bit field and 1692 therefore MAX_HOPCOUNT cannot be larger than 255. 1694 14.1. Timers 1696 AODVv2 requires certain timing information to be associated with 1697 route table entries. The default values are as follows, subject to 1698 future experience: 1700 +------------------------------+---------------+ 1701 | Name | Default Value | 1702 +------------------------------+---------------+ 1703 | ACTIVE_INTERVAL | 5 second | 1704 | MAX_IDLETIME | 200 seconds | 1705 | MAX_BLACKLIST_TIME | 200 seconds | 1706 | MAX_SEQNUM_LIFETIME | 300 seconds | 1707 | RREQ_WAIT_TIME | 2 seconds | 1708 | UNICAST_MESSAGE_SENT_TIMEOUT | 1 second | 1709 | RREQ_HOLDDOWN_TIME | 10 seconds | 1710 +------------------------------+---------------+ 1712 Table 2: Timing Parameter Values 1714 The above timing parameter values have worked well for small and 1715 medium well-connected networks with moderate topology changes. 1717 The timing parameters SHOULD be administratively configurable for the 1718 network where AODVv2 is used. Ideally, for networks with frequent 1719 topology changes the AODVv2 parameters should be adjusted using 1720 either experimentally determined values or dynamic adaptation. For 1721 example, in networks with infrequent topology changes MAX_IDLETIME 1722 may be set to a much larger value. 1724 14.2. Protocol constants 1726 AODVv2 protocol constants typically do not require changes. The 1727 following table lists these constants, along with their values and a 1728 reference to the specification describing their use. 1730 +------------------------+--------------------+---------------------+ 1731 | Name | Default Value | Description | 1732 +------------------------+--------------------+---------------------+ 1733 | DISCOVERY_ATTEMPTS_MAX | 3 | Section 7.1 | 1734 | MAX_HOPCOUNT | 20 hops | Section 5.6 | 1735 | MAX_METRIC[i] | Specified only for | Section 5.6 | 1736 | | HopCount | | 1737 | MAXTIME | [TBD] | Maximum expressible | 1738 | | | clock time | 1739 +------------------------+--------------------+---------------------+ 1741 Table 3: Parameter Values 1743 14.3. Administrative (functional) controls 1745 The following administrative controls may be used to change the 1746 operation of the network, by enabling optional behaviors. These 1747 options are not required for correct routing behavior, although they 1748 may potentially reduce AODVv2 protocol messaging in certain 1749 situations. The default behavior is to NOT enable most such options, 1750 options. Packet buffering is enabled by default. 1752 +-------------------------+-------------------------------+ 1753 | Name | Description | 1754 +-------------------------+-------------------------------+ 1755 | DEFAULT_METRIC_TYPE | 3 {Hop Count (see [RFC6551])} | 1756 | ENABLE_IDLE_UNREACHABLE | Section 8.3.2 | 1757 | ENABLE_IRREP | Section 7.3 | 1758 | USE_MULTICAST_RREP | Section 13.4 | 1759 +-------------------------+-------------------------------+ 1761 Table 4: Administratively Configured Controls 1763 14.4. Other administrative parameters and lists 1765 The following table lists contains AODVv2 parameters which should be 1766 administratively configured for each specific network. 1768 +-----------------------+-----------------------+-----------------+ 1769 | Name | Default Value | Cross Reference | 1770 +-----------------------+-----------------------+-----------------+ 1771 | AODVv2_INTERFACES | | Section 4 | 1772 | BUFFER_SIZE_PACKETS | 2 | Section 7.1 | 1773 | BUFFER_SIZE_BYTES | MAX_PACKET_SIZE [TBD] | Section 7.1 | 1774 | CLIENT_ADDRESSES | AODVv2_INTERFACES | Section 5.3 | 1775 | CONTROL_TRAFFIC_LIMIT | TBD [50 packets/sec?] | Section 12 | 1776 +-----------------------+-----------------------+-----------------+ 1778 Table 5: Other Administrative Parameters 1780 15. IANA Considerations 1782 This section specifies several message types, message tlv-types, and 1783 address tlv-types. Also, a new registry of 16-bit alternate metric 1784 types is specified. 1786 15.1. AODVv2 Message Types Specification 1787 +----------------------------------------+------------+ 1788 | Name | Type (TBD) | 1789 +----------------------------------------+------------+ 1790 | Route Request (RREQ) | 10 | 1791 | Route Reply (RREP) | 11 | 1792 | Route Error (RERR) | 12 | 1793 | Route Reply Acknowledgement (RREP_ACK) | 13 | 1794 +----------------------------------------+------------+ 1796 Table 6: AODVv2 Message Types 1798 15.2. Message TLV Type Specification 1800 +-----------------------------------+-------+---------+-------------+ 1801 | Name | Type | Length | Cross | 1802 | | (TBD) | in | Reference | 1803 | | | octets | | 1804 +-----------------------------------+-------+---------+-------------+ 1805 | Acknowledgment Request (AckReq) | 10 | 0 | Section 5.2 | 1806 | Destination RREP Only (DestOnly) | 11 | 0 | Section 7.3 | 1807 | Packet Source (PktSource) | 12 | 4 or 16 | Section 8.3 | 1808 | Metric Type | 13 | 1 | Section 7.2 | 1809 +-----------------------------------+-------+---------+-------------+ 1811 Table 7: Message TLV Types 1813 15.3. Address Block TLV Specification 1815 +-----------------------------+--------+--------------+-------------+ 1816 | Name | Type | Length | Value | 1817 | | (TBD) | | | 1818 +-----------------------------+--------+--------------+-------------+ 1819 | Metric | 10 | depends on | Section 7.2 | 1820 | | | Metric Type | | 1821 | Sequence Number (SeqNum) | 11 | 2 octets | Section 7.2 | 1822 | Originating Node Sequence | 12 | 2 octets | Section 7.2 | 1823 | Number (OrigSeqNum) | | | | 1824 | Target Node Sequence Number | 13 | 2 octets | Section 7.2 | 1825 | (TargSeqNum) | | | | 1826 | VALIDITY_TIME | 1 | 1 octet | [RFC5497] | 1827 +-----------------------------+--------+--------------+-------------+ 1829 Table 8: Address Block TLV (AddrTLV) Types 1831 15.4. Metric Type Number Allocation 1833 Metric types are identified according to the assignments as specified 1834 in [RFC6551]. The metric type of the Hop Count metric is assigned to 1835 be 3, in order to maintain compatibility with that existing table of 1836 values from RFC 6551. Non-addititve metrics are not supported in 1837 this draft. 1839 +-----------------------+----------+-------------+ 1840 | Name | Type | Metric Size | 1841 +-----------------------+----------+-------------+ 1842 | Unallocated | 0 -- 2 | TBD | 1843 | Hop Count | 3 - TBD | 1 octet | 1844 | Unallocated | 4 -- 254 | TBD | 1845 | Reserved | 255 | Undefined | 1846 +-----------------------+----------+-------------+ 1848 Table 9: Metric Types 1850 16. Security Considerations 1852 The objective of the AODVv2 protocol is for each router to 1853 communicate reachability information about addresses for which it is 1854 responsible. Positive routing information (i.e. a route exists) is 1855 distributed via RteMsgs and negative routing information (i.e. a 1856 route does not exist) via RERRs. AODVv2 routers that handle these 1857 messages store the contained information to properly forward data 1858 packets, and they generally provide this information to other AODVv2 1859 routers. 1861 This section does not mandate any specific security measures. 1862 Instead, this section describes various security considerations and 1863 potential avenues to secure AODVv2 routing. 1865 The most important security mechanisms for AODVv2 routing are 1866 integrity/authentication and confidentiality. 1868 In situations where routing information or router identity are 1869 suspect, integrity and authentication techniques SHOULD be applied to 1870 AODVv2 messages. In these situations, routing information that is 1871 distributed over multiple hops SHOULD also verify the integrity and 1872 identity of information based on originator of the routing 1873 information. 1875 A digital signature could be used to identify the source of AODVv2 1876 messages and information, along with its authenticity. A nonce or 1877 timestamp SHOULD also be used to protect against replay attacks. S/ 1878 MIME and OpenPGP are two authentication/integrity protocols that 1879 could be adapted for this purpose. 1881 In situations where confidentiality of AODVv2 messages is important, 1882 cryptographic techniques can be applied. 1884 In certain situations, for example sending a RREP or RERR, an AODVv2 1885 router could include proof that it has previously received valid 1886 routing information to reach the destination, at one point of time in 1887 the past. In situations where routers are suspected of transmitting 1888 maliciously erroneous information, the original routing information 1889 along with its security credentials SHOULD be included. 1891 Note that if multicast is used, any confidentiality and integrity 1892 algorithms used MUST permit multiple receivers to handle the message. 1894 Routing protocols, however, are prime targets for impersonation 1895 attacks. In networks where the node membership is not known, it is 1896 difficult to determine the occurrence of impersonation attacks, and 1897 security prevention techniques are difficult at best. However, when 1898 the network membership is known and there is a danger of such 1899 attacks, AODVv2 messages must be protected by the use of 1900 authentication techniques, such as those involving generation of 1901 unforgeable and cryptographically strong message digests or digital 1902 signatures. While AODVv2 does not place restrictions on the 1903 authentication mechanism used for this purpose, IPsec Authentication 1904 Message (AH) is an appropriate choice for cases where the nodes share 1905 an appropriate security association that enables the use of AH. 1907 In particular, routing messages SHOULD be authenticated to avoid 1908 creation of spurious routes to a destination. Otherwise, an attacker 1909 could masquerade as that destination and maliciously deny service to 1910 the destination and/or maliciously inspect and consume traffic 1911 intended for delivery to the destination. RERR messages SHOULD be 1912 authenticated in order to prevent malicious nodes from disrupting 1913 active routes between communicating nodes. 1915 If the mobile nodes in the ad hoc network have pre-established 1916 security associations, the purposes for which the security 1917 associations are created should include that of authorizing the 1918 processing of AODVv2 control packets. Given this understanding, the 1919 mobile nodes should be able to use the same authentication mechanisms 1920 based on their IP addresses as they would have used otherwise. 1922 If the mobile nodes in the ad hoc network have pre-established 1923 security associations, the purposes for which the security 1924 associations Most AODVv2 messages are transmitted to the multicast 1925 address LL-MANET-Routers [RFC5498]. It is therefore required for 1926 security that AODVv2 neighbors exchange security information that can 1927 be used to insert an ICV [RFC6621] into the AODVv2 message block 1928 [RFC5444]. This enables hop-by-hop security, which is proper for 1929 these message types that may have mutable fields. For destination- 1930 only RREP discovery procedures, AODVv2 routers that share a security 1931 association SHOULD use the appropriate mechanisms as specified in RFC 1932 6621. The establishment of these security associations is out of 1933 scope for this document. 1935 17. Acknowledgments 1937 AODVv2 is a descendant of the design of previous MANET on-demand 1938 protocols, especially AODV [RFC3561] and DSR [RFC4728]. Changes to 1939 previous MANET on-demand protocols stem from research and 1940 implementation experiences. Thanks to Elizabeth Belding-Royer for 1941 her long time authorship of AODV. Additional thanks to Derek Atkins, 1942 Emmanuel Baccelli, Ramon Caceres, Thomas Clausen, Christopher 1943 Dearlove, Ulrich Herberg, Henner Jakob, Luke Klein-Berndt, Lars 1944 Kristensen, Tronje Krop, Koojana Kuladinithi, Alexandru Petrescu, 1945 Henning Rogge, Fransisco Ros, Pedro Ruiz, Christoph Sommer, Lotte 1946 Steenbrink, Romain Thouvenin, Jiazi Yi, Seung Yi, and Cong Yuan, for 1947 their reviews AODVv2 and DYMO, as well as several specification 1948 suggestions. 1950 18. References 1952 18.1. Normative References 1954 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1955 Requirement Levels", BCP 14, RFC 2119, March 1997. 1957 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 1958 Pignataro, "The Generalized TTL Security Mechanism 1959 (GTSM)", RFC 5082, October 2007. 1961 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 1962 "Generalized Mobile Ad Hoc Network (MANET) Packet/Message 1963 Format", RFC 5444, February 2009. 1965 [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value 1966 Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, March 1967 2009. 1969 [RFC5498] Chakeres, I., "IANA Allocations for Mobile Ad Hoc Network 1970 (MANET) Protocols", RFC 5498, March 2009. 1972 [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. 1973 Barthel, "Routing Metrics Used for Path Calculation in 1974 Low-Power and Lossy Networks", RFC 6551, March 2012. 1976 18.2. Informative References 1978 [I-D.perkins-irrep] 1979 Perkins, C. and I. Chakeres, "Intermediate RREP for 1980 dynamic MANET On-demand (AODVv2) Routing", draft-perkins- 1981 irrep-02 (work in progress), November 2012. 1983 [Perkins99] 1984 Perkins, C. and E. Belding-Royer, "Ad hoc On-Demand 1985 Distance Vector (AODV) Routing", Proceedings of the 2nd 1986 IEEE Workshop on Mobile Computing Systems and 1987 Applications, New Orleans, LA, pp. 90-100, February 1999. 1989 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 1990 (MANET): Routing Protocol Performance Issues and 1991 Evaluation Considerations", RFC 2501, January 1999. 1993 [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- 1994 Demand Distance Vector (AODV) Routing", RFC 3561, July 1995 2003. 1997 [RFC4728] Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source 1998 Routing Protocol (DSR) for Mobile Ad Hoc Networks for 1999 IPv4", RFC 4728, February 2007. 2001 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2002 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2003 September 2007. 2005 [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter 2006 Considerations in Mobile Ad Hoc Networks (MANETs)", RFC 2007 5148, February 2008. 2009 [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc 2010 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 2011 RFC 6130, April 2011. 2013 [RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi- 2014 Instance Extensions", RFC 6549, March 2012. 2016 [RFC6621] Macker, J., "Simplified Multicast Forwarding", RFC 6621, 2017 May 2012. 2019 Appendix A. Example RFC 5444-compliant packet formats 2021 The following subsections show example RFC 5444-compliant packets for 2022 AODVv2 message types RREQ, RREP, RERR, and RREP-Ack. These proposed 2023 message formats are designed based on expected savings from IPv6 2024 addressable MANET nodes, and a layout for the Address TLVs that may 2025 be viewed as natural, even if perhaps not the absolute most compact 2026 possible encoding. 2028 For RteMsgs, the msg-hdr fields are followed by at least one and 2029 optionally two Address Blocks. The first AddrBlk contains OrigNode 2030 and TargNode. For each AddrBlk, there must be AddrTLVs of type 2031 Metric and one of the SeqNum types (i.e, OrigSeqNum, TargSeqNum, or 2032 Seqnum). 2034 There is no Metric Type Message TLV present, so the Metric AddrTLV 2035 measures HopCount. The Metric AddrTLV also provides a way for the 2036 AODV router generating the RREQ or RREP to supply an initial nonzero 2037 cost for the route to its client node (OrigNode or TargNode, for RREQ 2038 or RREP respectively). 2040 In all cases, the length of an address (32 bits for IPv4 and 128 bits 2041 for IPv6) inside an AODVv2 message is indicated by the msg-addr- 2042 length (MAL) in the msg-header, as specified in [RFC5444]. 2044 The RFC 5444 header preceding AODVv2 messages in this document has 2045 the format illustrated in Figure 4. 2047 0 1 2 3 2048 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2049 +-+-+-+-+-+-+-+-+ 2050 | PV=0 | PF=0 | 2051 +-+-+-+-+-+-+-+-+ 2053 Figure 4: RFC 5444 Packet Header 2055 The fields in Figure 4 are to be interpreted as follows: 2057 o PV=0 (Packet Header Version = 0) 2058 o PF=0 (Packet Flags = 0) 2060 A.1. RREQ Message Format 2062 Figure 5 illustrates an example RREQ message format. 2064 0 1 2 3 2065 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2067 | msg-type=RREQ | MF=4 | MAL=3 | msg-size=28 | 2068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2069 | msg-hop-limit | msg.tlvs-length=0 | num-addr=2 | 2070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2071 |1|0|0|0|0| Rsv | head-length=3 | Head (bytes for Orig & Target): 2072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2073 :Head(Orig&Targ)| Orig.Tail | Target.Tail |addr.TLV.len=11: 2074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2075 :addr.TLV.len=11|type=OrigSeqNum|0|1|0|1|0|0|Rsv| Index-start=0 | 2076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2077 | tlv-length=2 | Orig.Node Sequence # | type=Metric | 2078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2079 |0|1|0|1|0|0|Rsv| Index-start=0 | tlv-length=1 | OrigNodeHopCt | 2080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2082 Figure 5: Example IPv4 RREQ, with OrigSeqNum and Metric AddrTLVs 2084 The fields in Figure 5 are to be interpreted as follows: 2086 o msg-type=RREQ (first [and only] message is of type RREQ) 2087 o MF=4 (Message Flags = 4 [only msg-hop-limit field is present]) 2088 o MAL=3 (Message Address Length indicator [3 for IPv4, 15 for IPv6]) 2089 o msg-size=28 (octets -- counting MsgHdr, MsgTLVs, and AddrBlks) 2090 o msg-hop-limit (initially MAX_HOPCOUNT by default) 2091 o msg.tlvs-length=0 (no Message TLVs) 2092 o num-addr=2 (OrigNode and TargNode addresses in RteMsg AddrBlock) 2093 o AddrBlk flags: 2095 * bit 0 (ahashead): 1 2096 * bit 1 (ahasfulltail): 0 2097 * bit 2 (ahaszerotail): 0 2098 * bit 3 (ahassingleprelen): 0 2099 * bit 4 (ahasmultiprelen): 0 2100 * bits 5-7: RESERVED 2101 o head-length=3 (length of head part of each address is 3 octets) 2102 o Head (3 initial bytes for both Originating & Target addresses) 2103 o Orig.Tail (4th byte of Originating Node IP address) 2104 o Target.Tail (4th byte of Target Node IP address) 2105 o addr.TLV.len = 11 (length in bytes for OrigSeqNum and Metric TLVs 2106 o type=OrigSeqNum (type of first AddrBlk TLV, value 2 octets) 2107 o AddrTLV flags for the OrigSeqNum TLV: 2109 * bit 0 (thastypeext): 0 2110 * bit 1 (thassingleindex): 1 2111 * bit 2 (thasmultiindex): 0 2112 * bit 3 (thasvalue): 1 2113 * bit 4 (thasextlen): 0 2114 * bit 5 (tismultivalue): 0 2115 * bits 6-7: RESERVED 2116 o Index-start=0 (OrigSeqNum TLV value applies at index 0) 2117 o tlv-length=2 (so there is only one TLV value, [1 = 2/2]) 2118 o Orig.Node Sequence # (TLV value for the OrigSeqNum TLV 2119 o type=Metric (AddrTLV type of second AddrBlk TLV, values 1 octet) 2120 o AddrTLV flags for Metric_TLV: 2122 * bit 0 (thastypeext): 0 2123 * bit 1 (thassingleindex): 1 2124 * bit 2 (thasmultiindex): 0 2125 * bit 3 (thasvalue): 1 2126 * bit 4 (thasextlen): 0 2127 * bit 5 (tismultivalue): 0 2128 * bits 6-7: RESERVED 2129 o Index-start=0 (Metric TLV values start at index 0) 2130 o tlv-length=1 (so there is only one TLV value, [1 = 1/1]) 2131 o OrigNodeHopCt (first [and only] TLV value for the Metric TLV) 2133 A.2. RREP Message Format 2135 Figure 6 illustrates a packet format for an example RREP message. 2137 0 1 2 3 2138 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2140 | msg-type=RREP | MF=4 | MAL=3 | msg-size=28 | 2141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2142 | msg-hop-limit | msg.tlvs-length=0 | num-addr=2 | 2143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2144 |1|0|0|0|0| Rsv | head-length=3 | Head (bytes for Orig & Target): 2145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2146 :Head(Orig&Targ)| Orig.Tail | Target.Tail |addr.TLV.len=11: 2147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2148 :addr.TLV.len=11|type=TargSeqNum|0|1|0|1|0|0|Rsv| Index-start=1 | 2149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2150 | tlv-length=2 | Targ.Node Sequence # | type=Metric | 2151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2152 |0|1|0|1|0|0|Rsv| Index-start=1 | tlv-length=1 | TargNodeHopCt | 2153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2155 Figure 6: Example IPv4 RREP, with TargSeqNum TLV and 1 Metric 2157 The fields in Figure 6 are to be interpreted as follows: 2159 o msg-type=RREP (first [and only] message is of type RREP) 2160 o MF=4 (Message Flags = 4 [only msg-hop-limit field is present]) 2161 o MAL=3 (Message Address Length indicator [3 for IPv4, 15 for IPv6]) 2162 o msg-size=28 (octets -- counting MsgHdr, MsgTLVs, and AddrBlks) 2163 o msg-hop-limit (initially MAX_HOPCOUNT by default) 2164 o msg.tlvs-length=0 (no Message TLVs) 2165 o num-addr=2 (OrigNode and TargNode addresses in RteMsg AddrBlock) 2166 o AddrBlk flags: 2168 * bit 0 (ahashead): 1 2169 * bit 1 (ahasfulltail): 0 2170 * bit 2 (ahaszerotail): 0 2171 * bit 3 (ahassingleprelen): 0 2172 * bit 4 (ahasmultiprelen): 0 2173 * bits 5-7: RESERVED 2174 o head-length=3 (length of head part of each address is 3 octets) 2175 o Head (3 initial bytes for both Originating & Target addresses) 2176 o Orig.Tail (4th byte of Originating Node IP address) 2177 o Target.Tail (4th byte of Target Node IP address) 2178 o addr.TLV.len = 11 (length in bytes for TargSeqNum TLV and Metric 2179 TLV 2180 o type=TargSeqNum (type of first AddrBlk TLV, value 2 octets) 2181 o AddrTLV flags for the TargSeqNum TLV: 2183 * bit 0 (thastypeext): 0 2184 * bit 1 (thassingleindex): 1 2185 * bit 2 (thasmultiindex): 0 2186 * bit 3 (thasvalue): 1 2187 * bit 4 (thasextlen): 0 2188 * bit 5 (tismultivalue): 0 2189 * bits 6-7: RESERVED 2190 o Index-start=1 (TargSeqNum TLV value applies to address at index 1) 2191 o tlv-length=2 (there is one TLV value, 2 bytes in length) 2192 o Targ.Node Sequence # (value for the TargSeqNum TLV) 2193 o type=Metric (AddrTLV type of second AddrBlk TLV, value 1 octet) 2194 o AddrTLV flags for the Metric TLV [01010000, same as for TargSeqNum 2195 TLV] 2196 o Index-start=1 (Metric TLV values start at index 1) 2197 o tlv-length=1 (there is one TLV value, 1 byte in length) 2198 o TargNodeHopCt (first [and only] TLV value for Metric TLV) 2200 A.3. RERR Message Format 2202 Figure 7 illustrates an example RERR message format. 2204 0 1 2 3 2205 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2207 | msg-type=RERR | MF=4 | MAL=3 | msg-size=24 | 2208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2209 | msg-hop-limit | msg.tlvs-length=0 | num-addr=2 | 2210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2211 |1|0|0|0|0| Rsv | head-length=3 | Head (for both destinations) : 2212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2213 :Head (3rd byte)| Tail(Dest_1) | Tail(Dest_2) | addr.TLV.len=7: 2214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2215 :addr.TLV.len=7 | type=SeqNum |0|0|1|1|0|1|Rsv| tlv-length=4 | 2216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2217 | Dest_1 Sequence # | Dest_2 Sequence # | 2218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2220 Figure 7: Example IPv4 RERR with Two Unreachable Nodes 2222 The fields in Figure 7 are to be interpreted as follows: 2224 o msg-type=RERR (first [and only] message is of type RERR) 2225 o MF=4 (Message Flags = 4 [only msg-hop-limit field is present]) 2226 o MAL=3 (Message Address Length indicator [3 for IPv4, 15 for IPv6]) 2227 o msg-size=24 (octets -- counting MsgHdr, MsgTLVs, and AddrBlks) 2228 o msg-hop-limit (initially MAX_HOPCOUNT by default) 2229 o msg.tlvs-length=0 (no Message TLVs) 2230 o num-addr=2 (OrigNode and TargNode addresses in RteMsg AddrBlock) 2231 o AddrBlk flags == 10000000 [same as RREQ and RREP AddrBlk examples] 2232 o head-length=3 (length of head part of each address is 3 octets) 2233 o Head (3 initial bytes for both Unreachable Nodes, Dest_1 and 2234 Dest_2) 2235 o Dest_1.Tail (4th byte of Dest_1 IP address) 2236 o Dest_2.Tail (4th byte of Dest_2 IP address) 2237 o addr.TLV.len = 7 (length in bytes for SeqNum TLV 2238 o type=SeqNum (AddrTLV type of AddrBlk TLV, values 2 octets each) 2239 o AddrTLV flags for SeqNum TLV: 2241 * bit 0 (thastypeext): 0 2242 * bit 1 (thassingleindex): 0 2243 * bit 2 (thasmultiindex): 1 2244 * bit 3 (thasvalue): 1 2245 * bit 4 (thasextlen): 0 2246 * bit 5 (tismultivalue): 1 2247 * bits 6-7: RESERVED 2249 o tlv-length=4 (so there are two TLV values, [2 = 4/2]) 2250 o Dest_1 Sequence # (first of two TLV values for the SeqNum TLV) 2251 o Dest_2 Sequence # (second of two TLV values for the SeqNum TLV) 2253 A.4. RREP_ACK Message Format 2255 The figure below illustrates a packet format for an example RREP_ACK 2256 message. 2258 0 1 2 3 2259 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2261 |msgtype=RREPAck| MF=0 | MAL=3 | msg-size=4 | 2262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2264 Figure 8: Example IPv4 RREP_ACK 2266 Appendix B. Changes since revision ...-02.txt 2268 This section lists the changes since AODVv2 revision ...-02.txt 2270 o The "Added Node" feature was removed. This feature was intended 2271 to enable additional routing information to be carried within a 2272 RREQ or a RREP message, thus increasing the amount of topological 2273 information available to nodes along a routing path. However, 2274 enlarging the packet size to include information which might never 2275 be used can increase congestion of the wireless medium. The 2276 feature can be included as an optional feature at a later date 2277 when better algorithms are understood for determining when the 2278 inclusion of additional routing information might be worthwhile. 2279 o Numerous editorial improvements and improvements to consistent 2280 terminology were made. Instances of OrigNodeNdx and TargNodeNdx 2281 were replaced by OrigNdx and TargNdx, to be consistent with the 2282 terminology shown in Table 1. 2283 o Example RREQ and RREP message formats shown in the Appendices were 2284 changed to use OrigSeqNum and TargSeqNum message TLVs instead of 2285 using the SeqNum message TLV. 2286 o Inclusion of the OrigNode's SeqNum in the RREP message is not 2287 specified. The processing rules for the OrigNode's SeqNum were 2288 incompletely specified in previous versions of the draft, and very 2289 little benefit is foreseen for including that information, since 2290 reverse path forwarding is used for the RREP. 2291 o Additional acknowledgements were included, and contributors names 2292 were alphabetized. 2293 o Definitions in the Terminology section capitalize the term to be 2294 defined. 2295 o Uncited bibliographic entries deleted. 2296 o Ancient "Changes" sections were deleted. 2298 Appendix C. Shifting Network Prefix Advertisement Between AODVv2 2299 Routers 2301 Only one AODVv2 router within a MANET SHOULD be responsible for a 2302 particular address at any time. If two AODVv2 routers dynamically 2303 shift the advertisement of a network prefix, correct AODVv2 routing 2304 behavior must be observed. The AODVv2 router adding the new network 2305 prefix must wait for any existing routing information about this 2306 network prefix to be purged from the network. Therefore, it must 2307 wait at least ROUTER_SEQNUM_AGE_MAX_TIMEOUT after the previous AODVv2 2308 router for this address stopped advertising routing information on 2309 its behalf. 2311 Authors' Addresses 2313 Charles E. Perkins 2314 Futurewei Inc. 2315 2330 Central Expressway 2316 Santa Clara, CA 95050 2317 USA 2319 Phone: +1-408-330-5305 2320 Email: charliep@computer.org 2322 Stan Ratliff 2323 Cisco 2324 170 West Tasman Drive 2325 San Jose, CA 95134 2326 USA 2328 Email: sratliff@cisco.com 2329 John Dowdell 2330 Cassidian 2331 Celtic Springs 2332 Newport, Wales NP10 8FZ 2333 United Kingdom 2335 Email: John.Dowdell@Cassidian.com