idnits 2.17.1 draft-ietf-manet-maodv-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 225: '...ss of a Next Hop MUST NOT be used to f...' RFC 2119 keyword, line 231: '... Nodes MAY also maintain a Group Lea...' RFC 2119 keyword, line 245: '...ed words such as MUST, SHOULD, etc., t...' RFC 2119 keyword, line 385: '... next hop to the multicast tree SHOULD...' RFC 2119 keyword, line 445: '... MAY be performed by broadcasting th...' (9 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- No information found for draft-ietf-manet-terms - is the name correct? -- Possible downref: Normative reference to a draft: ref. '3' Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobile Ad Hoc Networking Working Group Elizabeth M. Royer 2 INTERNET DRAFT University of California, Santa Barbara 3 15 July 2000 Charles E. Perkins 4 Nokia Research Center 6 Multicast Ad hoc On-Demand Distance Vector (MAODV) Routing 7 draft-ietf-manet-maodv-00.txt 9 Status of This Memo 11 This document is a submission by the Mobile Ad Hoc Networking Working 12 Group of the Internet Engineering Task Force (IETF). Comments should 13 be submitted to the manet@itd.nrl.navy.mil mailing list. 15 Distribution of this memo is unlimited. 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at 25 any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at: 29 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at: 31 http://www.ietf.org/shadow.html. 33 Abstract 35 The multicast operation of the Ad hoc On-Demand Distance Vector 36 (AODV) routing protocol (MAODV) is intended for use by mobile nodes 37 in an ad hoc network. It offers quick adaptation to dynamic link 38 conditions, low processing and memory overhead, and low network 39 utilization. It creates bi-directional shared multicast trees 40 connecting multicast sources and receivers. These multicast trees 41 are maintained as long as group members exist within the connected 42 portion of the network. Each multicast group has a group leader 43 whose responsibility is maintaining the group sequence number, which 44 is used to ensure freshness of routing information. 46 Contents 48 Status of This Memo i 50 Abstract i 52 1. Introduction 2 54 2. Overview 2 56 3. Route Tables 3 58 4. MAODV Terminology 5 60 5. Route Request (RREQ) Message Format 6 62 6. Route Reply (RREP) Message Format 6 64 7. Multicast Activation (MACT) Message Format 7 66 8. Group Hello (GRPH) Message Format 8 68 9. Protocol Operation 9 69 9.1. Maintaining Multicast Tree Utilization Records . . . . . 9 70 9.2. Generating Route Requests . . . . . . . . . . . . . . . . 9 71 9.2.1. Controlling Route Request broadcasts . . . . . . 10 72 9.3. Receiving Route Requests . . . . . . . . . . . . . . . . 10 73 9.4. Generating Route Replies . . . . . . . . . . . . . . . . 11 74 9.5. Forwarding Route Replies . . . . . . . . . . . . . . . . 12 75 9.6. Route Activation . . . . . . . . . . . . . . . . . . . . 12 76 9.7. Multicast Tree Pruning . . . . . . . . . . . . . . . . . 13 77 9.8. Repairing a Broken Link . . . . . . . . . . . . . . . . . 14 78 9.9. Tree Partitions . . . . . . . . . . . . . . . . . . . . . 16 79 9.10. Reconnecting Two Trees . . . . . . . . . . . . . . . . . 17 80 9.11. Maintaining Local Connectivity . . . . . . . . . . . . . 17 81 9.12. Group Hello Messages . . . . . . . . . . . . . . . . . . 18 82 9.13. Actions After Reboot . . . . . . . . . . . . . . . . . . 19 83 9.14. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 20 85 10. Extensions 20 86 10.1. Multicast Group Leader Extension Format . . . . . . . . . 20 87 10.2. Multicast Group Rebuild Extension Format . . . . . . . . 21 88 10.3. Multicast Group Information Extension Format . . . . . . 21 90 11. Configuration Parameters 22 91 12. Security Considerations 23 93 1. Introduction 95 The Multicast Ad hoc On-Demand Distance Vector (MAODV) protocol 96 enables dynamic, self-starting, multihop routing between 97 participating mobile nodes wishing to join or participate in a 98 multicast group within an ad hoc network. The membership of these 99 multicast groups is free to change during the lifetime of the 100 network. MAODV enables mobile nodes to establish a tree connecting 101 multicast group members. Mobile nodes are able to respond quickly 102 to link breaks in multicast trees by repairing these breaks in a 103 timely manner. In the event of a network partition, multicast trees 104 are established independently in each partition, and trees for the 105 same multicast group are quickly connected if the network components 106 merge. 108 One distinguishing feature of MAODV is its use of sequence numbers 109 for multicast groups. Each multicast group has its own sequence 110 number, which is initialized by the multicast group leader and 111 incremented periodically. Using these sequence numbers ensures that 112 routes found to multicast groups are always the most current ones 113 available. Given the choice between two routes to a multicast tree, 114 a requesting node always selects the one with the greatest sequence 115 number. 117 MAODV is the multicast protocol associated with the Ad hoc On-Demand 118 Distance Vector (AODV) routing protocol, and as such it shares many 119 similarities and packet formats with AODV. The Route Request and 120 Route Reply packet types are based on those used by AODV, as is the 121 unicast Route Table. Similarly, many of the configuration parameters 122 used by MAODV are defined by AODV. The reader is referred to the AODV 123 Internet draft [2] for the suggested values of those parameters, as 124 well as for details on the unicast operation of AODV. 126 2. Overview 128 Route Requests (RREQs), Route Replies (RREPs), Multicast Activations 129 (MACTs), and Group Hellos (GRPHs) are the message types utilized 130 by the multicast operation AODV. RREQs and RREPs are handled as 131 specified in [2], except for certain procedures controlled by new 132 flags (see section 5, 6). These message types are handled by UDP, 133 and normal IP header processing applies. So, for instance, the 134 requesting node is expected to use its IP address as the source IP 135 address for the messages. The range of dissemination of broadcast 136 RREQs can be indicated by the TTL in the IP header. Fragmentation is 137 typically not required. 139 As long as the multicast group members remain connected (within 140 a ``multicast tree''), MAODV does not play any role. When a 141 node either wishes to join a multicast group or find a route to a 142 multicast group, the node uses a broadcast RREQ to discover a route 143 to the multicast tree associated with that group. For join requests, 144 a route is determined when the RREQ reaches a node that is already a 145 member of the multicast tree, and the node's record of the multicast 146 group sequence number is at least as great as that contained in the 147 RREQ. For non-join requests, any node with a current route to the 148 multicast tree may respond to the RREQ. A current route is defined as 149 an unexpired multicast route table entry whose associated sequence 150 number for the multicast group is at least as great as that contained 151 in the RREQ. The route to the multicast tree is made available by 152 unicasting a RREP back to the source of the RREQ. Since each node 153 receiving the request caches a route back to the source of the 154 request, the RREP can be unicast back to the source from any node 155 able to satisfy the request. Once the source node has waited the 156 discovery period to receive RREPs, it selects the best route to the 157 multicast tree and unicasts the next hop along that route a MACT 158 message. This message activates the route. 160 Nodes monitor the link status of next hops on the multicast tree. 161 When a link break on the multicast tree is detected, the tree branch 162 should be immediately repaired through the use of the RREQ/RREP/MACT 163 messages. 165 A multicast group leader is associated with each multicast group. 166 The primary responsibility of this node is the initialization and 167 maintenance of the group sequence number. A Group Hello message is 168 periodically broadcast across the network by the multicast group 169 leader. This message carries a multicast group and group sequence 170 number and corresponding group leader IP address. This information 171 is used for disseminating updated group sequence numbers throughout 172 the multicast group and for repairing multicast trees after a 173 previously disconnected portion of the network containing part of the 174 multicast tree becomes reachable once again. 176 3. Route Tables 178 MAODV is a routing protocol, and it deals with route table 179 management. Route table information must be kept even for ephemeral 180 routes, such as are created to temporarily store reverse paths 181 towards nodes originating RREQs. MAODV uses the following fields 182 with each route table entry, which are based on the route table 183 defined in the AODV Internet Draft [2]: 185 - Destination IP Address 186 - Destination Sequence Number 188 - Hop Count (number of hops needed to reach destination) 189 - Last Hop Count (described in subsection 9.2.1) 191 - Next Hop 192 - Next Hop Interface 194 - List of Precursors 195 - Lifetime (expiration or deletion time of the route) 197 - Routing Flags 199 The following information is stored in each entry of the multicast 200 route table for multicast tree routes: 202 - Multicast Group IP Address 203 - Multicast Group Leader IP Address 205 - Multicast Group Sequence Number 206 - Next Hops 208 - Hop Count to next Multicast Group Member 210 - Hop Count to Multicast Group Leader 212 The Next Hops field is a linked list of structures, each of which 213 contains the following fields: 215 - Next Hop IP Address 216 - Next Hop Interface 218 - Link Direction 219 - Activated Flag 221 The direction of the link is relative to the location of the group 222 leader, i.e. UPSTREAM is a next hop towards the group leader, and 223 DOWNSTREAM is a next hop away from the group leader. A node on the 224 multicast tree must necessarily have only one UPSTREAM link. The IP 225 Address of a Next Hop MUST NOT be used to forward multicast messages 226 until after a MACT message has activated the route (see Section 9.6). 227 The Next Hop Interface fields in the Route Table and Next Hop field 228 of the Multicast Route Table are used for recording the outgoing 229 interface on which the next hop can be reached (see Section 9.14). 231 Nodes MAY also maintain a Group Leader Table, which is an association 232 between multicast groups and their corresponding group leaders. The 233 fields of the group leader table are the following: 235 - Multicast Group IP Address 237 - Group Leader IP Address 239 This table can be used when discovering routes to multicast groups, 240 as described in Section 9.2. 242 4. MAODV Terminology 244 This protocol specification uses conventional meanings [1] for 245 capitalized words such as MUST, SHOULD, etc., to indicate requirement 246 levels for various protocol features. This section defines other 247 terminology used with MAODV that is not already defined in [3]. 249 group leader 251 A node which is a member of the given multicast group 252 and which is typically the first such group member in the 253 connected portion of the network. This node is responsible for 254 initializing and maintaining the multicast group destination 255 sequence number. 257 group leader table 259 The table where ad hoc nodes keep information concerning each 260 multicast group and its corresponding group leader. There is 261 one entry in the table for each multicast group for which the 262 node has received a Group Hello (see Section 9.2). 264 multicast tree 266 The tree containing all nodes which are members of the 267 multicast group and all nodes which are needed to connect the 268 multicast group members. 270 multicast route table 272 The table where ad hoc nodes keep routing (including next hops) 273 information for various multicast groups. 275 reverse route 277 A route set up to forward a reply (RREP) packet back to the 278 source from the destination or from an intermediate node having 279 a route to the destination. 281 5. Route Request (RREQ) Message Format 283 0 1 2 3 284 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 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Type |J|R|G| Reserved | Hop Count | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Other fields as specified for AODV....... 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 The format of the Route Request message remains as specified in [2], 292 except that the following flags have been added: 294 J Join flag; set when source node wants to join a 295 multicast group. 297 R Repair flag; set when a node wants to initiate 298 a repair to connect two previously disconnected 299 portions of the multicast tree. 301 When a node wishes to repair a multicast tree, it appends the 302 Multicast Group Rebuild extension (see Section 10.2). When a node 303 wishes to unicast the RREQ for a multicast group to the group leader, 304 it includes the Multicast Group Leader extension (see Section 10.1). 306 6. Route Reply (RREP) Message Format 308 0 1 2 3 309 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 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Type |R| Reserved |Prefix Sz| Hop Count | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Other fields as specified for AODV....... 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 The format of the Route Reply message remains as specified in [2], 317 except that the following flag has been added: 319 R Repair flag; set when a node is responding 320 to a repair request to connect two previously 321 disconnected portions of the multicast tree. 323 When the RREP is sent for a multicast destination, the Multicast 324 Group Information extension is appended (see Section 10.3). 326 7. Multicast Activation (MACT) Message Format 328 0 1 2 3 329 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Type |J|P|G|U|R| Reserved | Hop Count | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Multicast Group IP address | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Source IP address | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Source Sequence Number | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 The format of the Multicast Activation message is illustrated above, 341 and contains the following fields: 343 Type 4 345 J Join flag; set when a node is joining the multicast 346 group, as opposed to finding a route to the group for 347 the transmission of data messages. 349 P Prune flag; set when a node wishes to prune itself 350 from the tree, unset when the node is activating a 351 tree link. 353 G Group Leader flag; set by a multicast tree member that 354 fails to repair a multicast tree link breakage, and 355 indicates to the group member receiving the message 356 that it should become the new multicast group leader. 358 U Update flag; set when a multicast tree member has 359 repaired a broken tree link and is now a new distance 360 from the group leader. 362 R Reboot flag; set when a node has just rebooted (see 363 Section 9.13). 365 Reserved Sent as 0; ignored on reception. 367 Hop Count The distance of the sending node from the multicast 368 group leader. Used only when the 'U' flag is set; 369 otherwise sent as 0. 371 Multicast Group IP Address 372 The IP address of the Multicast Group for which a 373 route is supplied. 375 Source IP Address 376 The IP address of the sending node. 378 Source Sequence Number 379 The current sequence number for route information 380 generated by the source of the route request. 382 To prune itself from the tree (i.e., inactivate its last link to the 383 multicast tree), a multicast tree member sends a MACT with the 'P' 384 flag = 1 to its next hop on the multicast tree. A multicast tree 385 member that has more than one next hop to the multicast tree SHOULD 386 NOT prune itself from the multicast tree. 388 8. Group Hello (GRPH) Message Format 390 0 1 2 3 391 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 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Type |U|O| Reserved | Hop Count | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Group Leader IP address | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Multicast Group IP address | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Multicast Group Sequence Number | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 The format of the Group Hello message is illustrated above, and 403 contains the following fields: 405 Type 5 407 U Update flag; set when there has been a change in group 408 leader information. 410 O Off_Mtree flag; set by a node receiving the group 411 hello that is not on the multicast tree. 413 Reserved Sent as 0; ignored on reception. 415 Hop Count The number of hops the packet has traveled. Used by 416 multicast tree nodes to update their distance from the 417 group leader when the M flag is not set. 419 Group Leader IP Address 420 The IP address of the group leader. 422 Multicast Group IP Address 423 The IP address of the Multicast Group for which the 424 sequence number is supplied. 426 Multicast Group Sequence Number 427 The current sequence number of the multicast group. 429 9. Protocol Operation 431 This section describes the scenarios under which nodes generate 432 control messages for multicast communication, and how the fields in 433 the messages are handled. 435 9.1. Maintaining Multicast Tree Utilization Records 437 For each multicast tree to which a node belongs, either because 438 it is a member of the group or because it is a router for the 439 multicast tree, the node maintains a list of next hops -- i.e., those 440 1-hop neighbors that are likewise a part of the multicast tree. 441 This list of next hops is used for forwarding messages received 442 for the multicast group. A node forwards a multicast message to 443 every such next hop, except that neighbor from which the message 444 arrived. If there are multiple next hops, the forwarding operation 445 MAY be performed by broadcasting the multicast packet to the node's 446 neighbors; only the neighbors that belong to the multicast tree 447 and have not already received the packet continue to forward the 448 multicast packet. 450 9.2. Generating Route Requests 452 A node sends a RREQ either when it determines that it should be a 453 part of a multicast group, and it is not already a member of that 454 group, or when it has a message to send to the multicast group but 455 does not have a route to that group. If the node wishes to join the 456 multicast group, it sets the `J' flag in the RREQ; otherwise, it 457 leaves the flag unset. The destination address of the RREQ is always 458 set to the multicast group address. If the node knows the group 459 leader and has a route to it, the node MAY place the group leader's 460 address in the Multicast Group Leader extension (Section 10.1), and 461 unicast the RREQ to the corresponding next hop for that destination. 462 Otherwise, if the node does not have a route to the group leader, or 463 if it does not know who the multicast group leader is, it broadcasts 464 the RREQ and does not include the extension field. 466 After transmitting the RREQ, the node waits for the reception of a 467 RREP. The node may resend the RREQ up to RREQ_RETRIES additional 468 times if a RREP is not received. If a RREQ was unicast to a group 469 leader and a RREP is not received within RREP_WAIT_TIME milliseconds, 470 the node broadcasts subsequent RREQs for that multicast group across 471 the network. If a RREP is not received after RREQ_RETRIES additional 472 requests, the node may assume that there are no other members of that 473 particular group within the connected portion of the network. If it 474 wanted to join the multicast group, it then becomes the multicast 475 group leader for that multicast group and initializes the sequence 476 number of the multicast group. Otherwise, if it only wanted to send 477 packets to that group without actually joining the group, it drops 478 the packets it had for that group and aborts the session. 480 When the node wishes to join or send a message to a multicast group, 481 it first consults its Group Leader Table. Based on the existence 482 of an entry for the multicast group in this table, the node then 483 formulates and sends the RREQ as described at the beginning of this 484 section. 486 9.2.1. Controlling Route Request broadcasts 488 To prevent unnecessary network-wide broadcasts of RREQs, the source 489 node SHOULD use an expanding ring search technique as specified 490 in [2]. When a RREP is received, the Hop Count to the group leader 491 used in the RREP packet is remembered as Last Hop Count for that node 492 in the routing table. When a new route to the same multicast group 493 is required at a later time (e.g., upon a link break in the multicast 494 tree), the TTL in the RREQ IP header is initially set to this Last 495 Hop Count plus TTL_INCREMENT. Thereafter, following each timeout the 496 TTL is incremented by TTL_INCREMENT until TTL = TTL_THRESHOLD is 497 reached, as in [2]. 499 9.3. Receiving Route Requests 501 When a node receives a RREQ, the node checks whether the 'J' flag of 502 the RREQ is set. If the 'J' flag is set, the node can only respond 503 if it is a member of the multicast tree for the indicated multicast 504 group, and if its record of the multicast group sequence number is 505 at least as great as that contained in the RREQ. If the 'J' flag is 506 not set, then the node can respond if it has an unexpired route to 507 the multicast group and the above multicast group sequence number 508 criteria is met. 510 If the node does not meet either of these conditions, it rebroadcasts 511 the RREQ from its interface(s) but using its own IP address in the IP 512 header of the outgoing RREQ. The Destination Sequence Number in the 513 RREQ is updated to the maximum of the existing Destination Sequence 514 Number in the RREQ and the multicast group sequence number in the 515 multicast route table (if an entry exists) of the current node. The 516 TTL or hop limit field in the outgoing IP header is decreased by one. 517 The Hop Count field in the broadcast RREQ message is incremented by 518 one, to account for the new hop through the intermediate node. 520 The node always creates or updates a reverse route as specified 521 in [2]. This reverse route would be needed in case the node 522 receives an eventual RREP back to the node which originated the RREQ 523 (identified by the Source IP Address). 525 In addition to creating or updating the route table entry for the 526 source node, the node receiving the RREQ also creates a next hop 527 entry for the multicast group in its multicast route table. If no 528 entry exists for the multicast group, it creates one, and then places 529 the node from which it received the RREQ as next hop for that group. 530 It leaves the Activated flag associated with this next hop unset. 531 The direction for this next hop entry is DOWNSTREAM. 533 9.4. Generating Route Replies 535 If a node receives a join RREQ for a multicast group, and it is 536 already a member of the multicast tree for that group, the node 537 updates its multicast route table and then generates a RREP message. 538 The Source and Destination IP Addresses in RREQ message are copied 539 to corresponding fields in the RREP message. The RREP contains the 540 current sequence number for the multicast group and the IP address 541 of the group leader. Furthermore, the node initializes the Hop 542 Count field of the RREP to zero. Additional information about the 543 multicast group is entered into the Multicast Group Information 544 extension (see Section 10.3). It unicasts the RREP back to the node 545 indicated by the Source IP Address field of the received RREQ. 547 A node can respond to a join RREQ only if it is a member of the 548 multicast tree. If a node receives a multicast route request that 549 is not a join message, it can reply if it has a current route to the 550 multicast tree. Otherwise it continues forwarding the request. If a 551 node receives a join RREQ for a multicast group and it is not already 552 a member of the multicast tree for that group, it rebroadcasts the 553 RREQ to its neighbors. 555 When a node receives a RREQ for a multicast group which has its own 556 IP address in the Destination IP address of the IP header, that 557 means that the source node expects this destination node to be the 558 multicast group leader. In this case, if the node is in fact not the 559 group leader, it can simply ignore the RREQ. The source node will 560 time out after RREP_WAIT_TIME milliseconds and will broadcast a new 561 RREQ without the group leader address specified. 563 Regardless of whether the multicast group leader or a multicast tree 564 member generates the RREP, the RREP fields are set as follows: 566 Hop Count 0 568 Destination IP Address 569 The IP address of the multicast group. 571 Destination Sequence Number 572 The current multicast group sequence number. 574 Lifetime The time for which nodes receiving the RREP consider 575 the route to be valid (only used it the RREQ is not a 576 join request). 578 The Multicast Group Information extension described in Section 10.3 579 is also included for join requests. If the node generating the RREP 580 is not on the multicast tree (because the RREQ was not a join RREQ), 581 it places its distance from the multicast tree in the Hop Count 582 field, instead of 0. 584 9.5. Forwarding Route Replies 586 If an intermediate node receives a RREP in response to a RREQ that it 587 has transmitted (or retransmitted on behalf of some other node), it 588 creates a multicast group next hop entry for the node from which it 589 received the RREP. The direction of this next hop is UPSTREAM, and 590 the Activated flag is left unset. Additionally, the node updates 591 the Lifetime field in the route table entry associated with the node 592 from which it received the RREP. It then increments the Hop Count and 593 Multicast Group Hop Count fields or the RREP and forwards this packet 594 along the path to the source of the RREQ. 596 When the node receives more than one RREP for the same RREQ, it saves 597 the route information with the greatest sequence number, and beyond 598 that the lowest hop count; it discards all other RREPs. This node 599 forwards the first RREP towards the source of the RREQ, and then 600 forwards later RREPs only if they have a greater sequence number or 601 smaller metric. 603 9.6. Route Activation 605 When a node broadcasts a RREQ message, it is likely to receive more 606 than one reply since any node in the multicast tree can respond. The 607 RREP message sets up route pointers as it travels back to the source 608 node. If the request is a join request, these route pointers may 609 eventually graft a branch onto the multicast tree. Also, because 610 multicast data packets may be transmitted as broadcast traffic, the 611 route to the multicast tree must be explicitly selected. Otherwise, 612 each node with a route to the tree which receives a multicast data 613 packet will rebroadcast the packet, resulting in an inefficient use 614 of network bandwidth. Hence, it is necessary to activate only one 615 of the routes created by the RREP messages. The RREP containing 616 the largest destination sequence number is chosen to be the branch 617 added to the multicast tree (or the path to the multicast tree, if 618 the request was a non-join). In the event that a node receives more 619 than one RREP with the same (largest) sequence number, it selects the 620 first one with the smallest hop count, i.e., the shortest distance to 621 a member of the multicast tree. 623 After waiting RREP_WAIT_TIME milliseconds, the node must select the 624 route it wishes to use as its link to the multicast tree. This is 625 accomplished by sending a Multicast Activation (MACT) message. The 626 Destination IP Address field of the MACT packet is set to the IP 627 address of the multicast group. If the node is joining the multicast 628 group, it sets the join flag of this message. The node unicasts this 629 message to the selected next hop, effectively activating the route. 630 It then sets the Activated flag in the next hop Multicast Route Table 631 entry associated with that node. After receiving this message, the 632 node to which the MACT was sent activates the route entry for the 633 link in its multicast route table, thereby finalizing the creation of 634 the tree branch. All neighbors not receiving this message time out 635 and delete that node as a next hop for the multicast group in their 636 route tables, having never activated the route entry for that next 637 hop. 639 Two scenarios exist for a neighboring node receiving the MACT 640 message. If this node was previously a member of the multicast 641 tree, it does not propagate the MACT message any further. However, 642 if the next hop selected by the source node's MACT message was not 643 previously a multicast tree member, it will have propagated the 644 original RREQ further up the network in search of nodes which are 645 tree members. Thus it is possible that this node also received more 646 than one RREP, as noted in Section 9.5. 648 When the node receives a MACT selecting it as the next hop, it 649 unicasts its own MACT to the node it has chosen as its next hop, 650 and so on up the tree, until a node which was already a part of the 651 multicast tree is reached. 653 9.7. Multicast Tree Pruning 655 A multicast group member can revoke its member status at any time. 656 However, it can only actually leave the multicast tree if it is not a 657 tree router for any other nodes in the multicast group (i.e., if it 658 is a leaf node). If a node wishing to leave the multicast group is 659 a leaf node, it unicasts to its next hop on the tree a MACT message 660 with the 'P' flag set and with the Destination IP Address set to the 661 IP address of the multicast group. It then deletes the multicast 662 group information for that group from its multicast route table. 663 When its next hop receives this message, it deletes the sending 664 node's information from its list of next hops for the multicast tree. 665 If the removal of the sending node causes this node to become a leaf 666 node, and if this node is also not a member of the multicast group, 667 it may in turn prune itself by sending its own MACT message up the 668 tree. 670 When the multicast group leader wishes to leave the multicast group, 671 it proceeds in a manner similar to the one just described. If it 672 is a leaf node, it may leave the group and unicast a prune message 673 to its next hop. The next hop acts in the manner described in 674 Section 9.10, since the prune message is coming from its upstream 675 neighbor. Otherwise, if the group leader is not a leaf node, it may 676 not prune itself from the tree. It takes the actions described in 677 Section 9.9, where it selects one of its next hops and unicasts to it 678 the MACT with set 'G' flag. 680 9.8. Repairing a Broken Link 682 Branches of the multicast tree become invalid if a broken link 683 results in an infinite metric being associated with the next hop 684 route table entry. When a broken link is detected between two nodes 685 on the multicast tree, the two nodes should delete the link from 686 their list of next hops for the multicast group. The node downstream 687 of the break (i.e., the node which is further from the multicast 688 group leader) is responsible for initiating the repair of the broken 689 link. In order to repair the tree, the downstream node broadcasts 690 a RREQ with destination IP address set to the IP address of the 691 multicast group and with the 'J' flag set. The destination sequence 692 number of the RREQ is the last known sequence number of the multicast 693 group. The node also includes the Multicast Group Leader Extension. 694 The Multicast Group Hop Count field of this extension is set to the 695 distance of the source node from the multicast group leader. A node 696 MUST have a hop count to the multicast group leader less than or 697 equal to the indicated value in order to respond. This hop count 698 requirement prevents nodes on the same side of the break as the node 699 initiating the repair from replying to the RREQ. 701 The RREQ is broadcast using an expanding rings search, as described 702 in Section 9.2.1. Because of the high probability that other 703 nearby nodes can be used to rebuild the route, the original 704 RREQ is broadcast with a TTL (time to live) field value equal to 705 TTL_INCREMENT plus the Multicast Group Hop Count. In this way, 706 the effects of the link breakage may be localized. If no reply 707 is received within RREP_WAIT_TIME milliseconds, the node SHOULD 708 increment the TTL of each successive RREQ by TTL_INCREMENT, until 709 either a route is determined, or TTL_THRESHOLD is reached. After 710 this point, if a route is still not discovered, each additional RREQ 711 is broadcast with TTL = NET_DIAMETER. Up to RREQ_RETRIES additional 712 broadcasts may be attempted after TTL = NET_DIAMETER is reached. 714 A node receiving this RREQ can respond if it meets the following 715 conditions: 717 - It is a member of the multicast tree. 719 - Its record of the multicast group sequence number is at least as 720 great as that contained in the RREQ. 722 - Its hop count to the multicast group leader is less than or equal 723 to the contained in the Multicast Group Hop Count extension 724 field. 726 If the originating node receives more than one RREP, route activation 727 occurs as described in the previous section. 729 At the end of the discovery period, the node selects its next hop 730 and unicasts a MACT message to that node to activate the link, as 731 described in Section 9.6. Since the node was repairing a tree break, 732 it is likely that it is now a different distance from the group 733 leader than it was before the break. If this is the case, it must 734 inform its DOWNSTREAM next hops of their new distance from the group 735 leader. It does this by broadcasting a MACT message with the 'U' 736 flag set, and the Hop Count field set to the node's new distance 737 from the group leader. This 'U' flag indicates that multicast tree 738 nodes should update their distance from the group leader. When a 739 node on the multicast tree receives the MACT message with the 'U' 740 flag set, it determines whether this packet arrived from its UPSTREAM 741 neighbor. If it did not, the node discards the packet. Otherwise, 742 it increments the Hop Count value contained in the MACT packet and 743 updates it distance to the group leader to be this node value. If 744 this node has one or more downstream next hops, it in turn must send 745 a MACT message with a set 'U' flag to its next hops, and so on. 747 When a link break occurs, it is possible that the tree will be 748 repaired through different intermediate nodes. If the node UPSTREAM 749 of the break is not a group member, and if the loss of that link 750 causes it to become a leaf node, it sets a prune timer to wait 751 for the link to be repaired. This PRUNE_TIMEOUT should be larger 752 than RREP_WAIT_TIMEOUT to give the link time to be repaired. If, 753 when this timer expires, the node has not received a MACT message 754 selecting it to be a part of the repaired tree branch, it prunes 755 itself from the tree by sending a MACT with set 'P' flag to its next 756 hop, as previously described. 758 9.9. Tree Partitions 760 It is possible that after a link breaks, the tree cannot be repaired 761 due to a network partition. If the node attempting to repair a tree 762 link break does not receive a response after RREQ_RETRIES attempts, 763 it can be assumed that the network has become partitioned and the 764 multicast tree cannot be repaired at this time. In this situation, 765 if the node which initiated the route rebuilding is a multicast group 766 member, it becomes the new multicast group leader for its part of the 767 multicast tree partition. It increments the group sequence number 768 and then broadcasts a Group Hello (GRPH) for this multicast group. 769 The 'U' flag in the GRPH is set, indicating that there has been a 770 change in the group leader information. All nodes receiving this 771 message update their group leader table to indicate the new group 772 leader information. Nodes which are a part of the multicast tree 773 also update the group leader and sequence number information for that 774 group in their multicast route table. 776 On the other hand, if the node which had initiated the repair is not 777 a multicast group member, there are two possibilities. If it only 778 has one next hop for the multicast tree, it prunes itself from the 779 tree by unicasting a MACT message, with the 'P' flag set, to its 780 next hop. The node receiving this message notes that the message 781 came from its upstream link, i.e., from a node that is closer to 782 the group leader than it is. If the node receiving this message 783 is a multicast group member, it becomes the new group leader and 784 broadcasts a GRPH message as indicated above. Otherwise, if it is 785 not a multicast group member and it only has one other next hop link, 786 it similarly prunes itself from the tree. This process continues 787 until a multicast group member is reached. 789 The other possibility is that the node which initiated the rebuilding 790 is not a group member and has more than one next hop for the tree. 791 In this case, it cannot prune itself, since doing so would partition 792 the tree. It instead selects one of its next hops and unicasts a 793 MACT with the 'G' flag set to that node. This flag indicates that 794 the next group member to receive this message should become the new 795 group leader. It then changes the direction of that link to be 796 UPSTREAM. If the node receiving the MACT is a group member, then this 797 node becomes the new group leader. Otherwise, the node unicasts its 798 own MACT message with the 'G' flag set to one of its next hops, and 799 changes the direction of that link. Once a group member is reached, 800 the new group leader is determined. 802 9.10. Reconnecting Two Trees 804 In the event that a link break cannot be repaired, the multicast 805 tree remains partitioned until the two parts of the network become 806 connected once again. A node from one partition of the network knows 807 that it has come into contact with a node from the other partition of 808 the network by noting the difference in the GRPH message multicast 809 group leader information. The multicast group leader with the lower 810 IP address initiates the tree repair. For the purposes of this 811 explanation, call this node GL1. GL1 unicasts a RREQ with both 812 the 'J' and 'R' flags set to the group leader of the other network 813 partition (GL2), using the node from which it received the GRPH 814 as the next hop. This RREQ contains the current value of GL1's 815 multicast group sequence number. If any node that receives the RREQ 816 is a member of GL2's multicast tree, it MUST forward the RREQ along 817 its upstream link, i.e. towards GL2. This prevents any loops from 818 being formed after the repair. Upon receiving the RREQ, GL2 takes 819 the larger of its and the received multicast group sequence number, 820 increments this value by one, and responds with a RREP. This is the 821 group leader which becomes the leader of the reconnected multicast 822 tree. The 'R' flag of the RREP is set, indicating that this RREP is 823 in response to a repair request. 825 As the RREP is propagated back to GL1, nodes add the incoming and 826 outgoing links to the multicast route table next hop entries if 827 these entries do not already exist. The nodes also activate these 828 entries, thereby adding the branch on to the multicast tree. If a 829 node that was previously a member of GL1's tree receives the RREP, it 830 MUST forward the packet along its link to its previous group leader 831 (GL1). It then updates its group leader information to reflect GL2 832 as the new group leader, changes the direction of the next hop link 833 associated with GL1 to DOWNSTREAM, and sets the direction of the 834 link on which it received the RREP to UPSTREAM. When GL1 receives 835 the RREP, it updates its group leader information and sets the 836 link from which it received the RREP as its upstream link. The 837 tree is now reconnected. The next time GL2 broadcasts a GRPH, it 838 sets the `U' flag to indicate that there is a change in the group 839 leader information and group members should update the corresponding 840 information. All network nodes update their group leader table to 841 reflect the new group leader information. 843 9.11. Maintaining Local Connectivity 845 Each node on the multicast tree MUST keep track of its neighbors 846 which are next hops on the multicast tree. This is done as specified 847 in [2]. If a link to the next hop cannot be detected by any of the 848 methods specified therein, the forwarding node MUST assume that the 849 link is broken, and take corrective action by following the methods 850 specified in Section 9.8. 852 Whenever the multicast tree is used for the transmission of data 853 packets, a node on the tree must hear from each of its next hop 854 neighbors every RETRANSMIT_TIME. The node can hear from its neighbors 855 through one of the methods previously described, or through the 856 reception of a rebroadcast of a data packet from these next hops, 857 if the data packets are being transmitted by broadcast. If a 858 node does not hear from one of its multicast tree next hops within 859 RETRANSMIT_TIME, and if the multicast tree is actively being used 860 to transmit data packets, then the node MUST assume the link to 861 its next hop is broken, and proceed as described in Section 9.8. 862 Decreasing the amount of time between when a node must hear from its 863 next hops from ALLOWED_HELLO_LOSS * HELLO_INTERVAL milliseconds to 864 RETRANSMIT_TIME allows for the quickest detection of broken links and 865 fewer data packet losses. 867 9.12. Group Hello Messages 869 If a node sends a RREQ to join a multicast group (`J' flag set) 870 and after RREQ_RETRIES attempts does not receives a response, it 871 then becomes the multicast group leader. The node initializes the 872 multicast group sequence number and then broadcasts a GRPH message 873 to inform network nodes that it is now the group leader for the 874 multicast group. To ensure nodes maintain consistent and up-to-date 875 information about who the multicast group leaders are, any node which 876 is a group leader for a multicast group broadcasts such a GRPH across 877 the network every GROUP_HELLO_INTERVAL milliseconds. The contents of 878 the GRPH fields are set as follows: 880 U Flag 0 882 M Flag 0 884 Hop Count 0 886 Group Leader IP Address 887 The IP Address of the group leader. 889 Multicast Group IP Address 890 The IP Address of the Multicast Group for which the 891 node is the group leader. 893 Multicast Group Sequence Number 894 One plus the last known sequence number of the 895 multicast group. 897 Nodes receiving the GRPH increment the Hop Count field by one before 898 forwarding the message. When a node not on the multicast tree 899 receives the GRPH message, it sets the 'M' flag. This indicates that 900 this incarnation of the message has traveled off the multicast tree, 901 and hence cannot be used by group members to verify their distance 902 from the group leader. The 'U' flag is set by the group leader 903 whenever there has been a change in group leader information. It 904 informs nodes that they should update the group leader information 905 associated with the indicated multicast group. 907 A node receiving the GRPH message first verifies that is has 908 not already received the GRPH message with the same group IP 909 address/group sequence number pair in the last BCAST_ID_SAVE 910 milliseconds. If it has, it silently discards the message. 911 Otherwise, the node updates its group leader table to reflect 912 the current multicast group IP address/group leader IP address 913 combination, and increments the Hop Count value in the message. If 914 the node receiving the GRPH message is a member of the multicast 915 tree, it also updates this information in its multicast route table. 916 If the 'M' flag is unset, then this node can also use the Hop Count 917 value to verify its current distance from the group leader. 919 After processing the GRPH message, the node buffers the group 920 IP address/ group sequence number combination to avoid multiple 921 processings of the same GRPH message. It then rebroadcasts the 922 message to its neighbors. 924 9.13. Actions After Reboot 926 A node participating in the multicast tree that reboots (or 927 restarts the routing daemon) loses all of its multicast tree 928 information. Upon reboot, the rebooted node does not know whether 929 it was previously a member of the multicast tree. Hence, it should 930 unconditionally broadcast a MACT message with set Reboot ('R') flag 931 to inform neighboring nodes that it has lost its multicast group 932 information. When a node on the multicast tree receives the reboot 933 MACT message, it checks whether this message came from one of its 934 next hops on the multicast tree. If so, one of two situations 935 exists. 937 If the reboot MACT came from a downstream link, the node deletes that 938 link from its list of next hops and sets a prune timer according to 939 the guidelines in Section 9.8. Otherwise, if the reboot MACT came 940 from a node's upstream link, it must rebuild the tree branch as is 941 also indicated in Section 9.8. 943 9.14. Interfaces 945 Because MAODV should operate smoothly over wired, as well as 946 wireless, networks, and because it is likely that MAODV will also be 947 used with multi-homed radios, the interface over which packets arrive 948 must be known to MAODV whenever a packet is received. This includes 949 the reception of RREQ, RREP, MACT, and GRPH messages. Whenever a 950 packet is received from a new neighbor, the interface on which that 951 packet was received is recorded into the route table entry for that 952 neighbor, along with all the other appropriate routing information. 953 Similarly, whenever a route to a new destination is learned, the 954 interface through which the destination can be reached is also 955 recorded into the destination's route table entry. 957 When multiple interfaces are available, a node receiving and 958 rebroadcasting a RREQ or GRPH message rebroadcasts that message on 959 all interfaces except the one on which it was received. If a node is 960 participating on the multicast tree, and if multicast data packets 961 are being sent as broadcast traffic, a multicast tree node should 962 only rebroadcast a packet on those interfaces which have multicast 963 tree next hops. 965 10. Extensions 967 This section specifies for multicast extensions for RREQ and RREP 968 messages, conforming to the format defined in [2]. 970 10.1. Multicast Group Leader Extension Format 972 This extension is appended to a RREQ by a node wishing to repair a 973 multicast tree. 975 0 1 2 3 976 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 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 | Type | Length | Multicast Group Leader IP ... | 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 | ... Address (continued) | Previous Hop IP Address ... | 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 | ... (continued) | 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 985 Type 3 987 Length 8 988 Multicast Group Leader IP Address 989 The IP Address of the Multicast Group Leader. 991 Previous Hop IP Address 992 The IP Address of the node which previously received the 993 RREQ. This field is used when the RREQ is unicast to 994 the group leader when a node wishes to join a multicast 995 group. 997 This extension is used when unicasting the RREQ to the group leader. 998 Each node receiving the RREQ updates the Previous Hop IP Address 999 field to reflect its address. 1001 10.2. Multicast Group Rebuild Extension Format 1003 This extension is appended to a RREQ by a node wishing to repair a 1004 multicast tree. 1006 0 1 2 3 1007 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 1008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 | Type | Length | Multicast Group Hop Count | 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1012 Type 4 1014 Length 2 1016 Multicast Group Hop Count 1017 The distance in hops of the node sending the RREQ from 1018 the Multicast Group Leader. 1020 This extension is used for rebuilding a multicast tree branch. It is 1021 used to ensure that only nodes as least as close to the group leader 1022 as indicated by the Multicast Group Hop Count field respond to the 1023 request. 1025 10.3. Multicast Group Information Extension Format 1027 The following extension is used to carry additional information for 1028 the RREP message (see Section 6) when sent to establish a route to a 1029 multicast destination. 1031 0 1 2 3 1032 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 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 | Type | Length | Multicast Group Hop Count | 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 | Multicast Group Leader IP Address | 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 Type 5 1041 Length 6 1043 Multicast Group Hop Count 1044 The distance of the node from the Multicast Group Leader. 1046 Multicast Group Leader IP Address 1047 The IP Address of the current Multicast Group Leader. 1049 This extension is included when responding to a RREQ to join a 1050 multicast group. The node responding to the RREQ places its distance 1051 from the group leader in the Multicast Group Hop Count field. 1053 11. Configuration Parameters 1055 This section gives default values for some important values 1056 associated with MAODV protocol operations. A particular mobile node 1057 may wish to change certain of the parameters, in particular the 1058 NET_DIAMETER, MY_ROUTE_TIMEOUT, ALLOWED_HELLO_LOSS, RREQ_RETRIES, 1059 and possibly the HELLO_INTERVAL. In the latter case, the node should 1060 advertise the HELLO_INTERVAL in its Hello messages, by appending 1061 a Hello Interval Extension to the RREP message. Choice of these 1062 parameters may affect the performance of the protocol. 1064 Multicast Parameters Value 1065 ---------------------- ----- 1066 GROUP_HELLO_INTERVAL 5,000 Milliseconds 1067 MTREE_BUILD 2 * REV_ROUTE_LIFE 1068 PRUNE_TIMEOUT ACTIVE_ROUTE_TIMEOUT 1069 RETRANSMIT_TIME 750 Milliseconds 1071 Additional AODV Parameters 1072 -------------------------- 1073 ACTIVE_ROUTE_TIMEOUT 1074 ALLOWED_HELLO_LOSS 1075 BCAST_ID_SAVE 1076 DELETE_PERIOD 1077 HELLO_INTERVAL 1078 NET_DIAMETER 1079 NEXT_HOP_WAIT 1080 NODE_TRAVERSAL_TIME 1081 REV_ROUTE_LIFE 1082 RREP_WAIT_TIME 1083 RREQ_RETRIES 1084 TTL_START 1085 TTL_INCREMENT 1086 TTL_THRESHOLD 1088 Please see [2] for a discussion of and the appropriate values for the 1089 Additional AODV Parameters. 1091 12. Security Considerations 1093 Currently, MAODV does not specify any special security measures. 1094 Route protocols, however, are prime targets for impersonation 1095 attacks, and must be protected by use of authentication techniques 1096 involving generation of unforgeable and cryptographically strong 1097 message digests or digital signatures. It is expected that, in 1098 environments where security is an issue, that IPSec authentication 1099 headers will be deployed along with the necessary key management to 1100 distribute keys to the members of the ad hoc network using MAODV. 1102 References 1104 [1] S. Bradner. Key words for use in RFCs to Indicate Requirement 1105 Levels. Request for Comments (Best Current Practice) 2119, 1106 Internet Engineering Task Force, Mar. 1997. 1108 [2] C. Perkins, E. Royer, and S. Das. Ad hoc on demand distance 1109 vector (AODV) routing (work in progress). Internet Draft, 1110 Internet Engineering Task Force, Mar. 2000. 1112 [3] C. E. Perkins. Terminology for Ad-Hoc Networking (work in 1113 progress). draft-ietf-manet-terms-00.txt, Nov. 1997. 1115 Author's Addresses 1117 Questions about this memo can be directed to: 1119 Elizabeth M. Royer 1120 Dept. of Electrical and Computer Engineering 1121 University of California, Santa Barbara 1122 Santa Barbara, CA 93106 1123 +1 805 893 7788 1124 +1 805 893 3262 (fax) 1125 eroyer@alpha.ece.ucsb.edu 1127 Charles E. Perkins 1128 Communications Systems Laboratory 1129 Nokia Research Center 1130 313 Fairchild Drive 1131 Mountain View, CA 94303 1132 USA 1133 +1 650 625 2986 1134 +1 650 691 2170 (fax) 1135 charliep@iprg.nokia.com