idnits 2.17.1 draft-ietf-manet-odmrp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 a Security Considerations section. ** 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 516 has weird spacing: '...ith the entri...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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.) -- The document date (November 1998) is 9293 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) == Outdated reference: A later version (-10) exists of draft-ietf-manet-dsr-00 ** Downref: Normative reference to an Experimental draft: draft-ietf-manet-dsr (ref. '2') -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' == Outdated reference: A later version (-04) exists of draft-ietf-manet-zone-zrp-01 -- Possible downref: Normative reference to a draft: ref. '5' == Outdated reference: A later version (-04) exists of draft-ietf-manet-tora-spec-01 -- Possible downref: Normative reference to a draft: ref. '6' == Outdated reference: A later version (-01) exists of draft-ietf-manet-term-00 -- Possible downref: Normative reference to a draft: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' == Outdated reference: A later version (-13) exists of draft-ietf-manet-aodv-01 ** Downref: Normative reference to an Experimental draft: draft-ietf-manet-aodv (ref. '9') -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF MANET Working Group Mario Gerla 3 INTERNET-DRAFT Guangyu Pei 4 Expiration: May 1999 Sung-Ju Lee 5 University of California, Los Angeles 6 Ching-Chuan Chiang 7 Chung-Cheng Institute of Technology 8 November 1998 10 On-Demand Multicast Routing Protocol (ODMRP) for Ad-Hoc Networks 12 14 Status of This Memo 16 This document is a submission to the Mobile Ad-hoc Networks (manet) 17 Working Group of the Internet Engineering Task Force (IETF). 18 Comments should be submitted to the Working Group mailing list at 19 "manet@itd.nrl.navy.mil". Distribution of this memo is unlimited. 21 This document is an Internet-Draft. Internet-Drafts are working 22 documents of the Internet Engineering Task Force (IETF), its areas, 23 and its working groups. Note that other groups may also distribute 24 working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other documents 28 at any time. It is inappropriate to use Internet-Drafts as 29 reference material or to cite them other than as "work in progress." 31 To view the entire list of current Internet-Drafts, please check 32 the "1id-abstracts.txt" listing contained in the Internet-Drafts 33 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 34 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 35 ftp.isi.edu (US West Coast). 37 Abstract 39 On-Demand Multicast Routing Protocol (ODMRP) is a multicast routing 40 protocol designed for ad-hoc networks with mobile hosts. ODMRP is 41 a mesh-based, rather than a conventional tree-based, multicast 42 scheme and uses a Forwarding Group concept (only a subset of nodes 43 forwards the multicast packets via scoped flooding). It applies 44 on-demand procedures to dynamically set up routes and maintain 45 multicast group membership. ODMRP is well suited for ad-hoc 46 wireless networks with mobile hosts where bandwidth is limited, 47 topology changes frequently and rapidly, and power is constrained. 49 Contents 51 Status of This Memo 1 53 Abstract 1 55 1. Introduction 3 57 2. Terminology 4 58 2.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 4 59 2.2. Specification Language . . . . . . . . . . . . . . . . . 5 61 3. Protocol Overview 6 62 3.1. Group Establishment and Route Setup . . . . . . . . . . . 6 63 3.1.1. Mesh Creation . . . . . . . . . . . . . . . . . . 6 64 3.1.2. Joining the Group . . . . . . . . . . . . . . . . 7 65 3.1.3. Leaving the Group . . . . . . . . . . . . . . . . 8 66 3.1.4. Timers . . . . . . . . . . . . . . . . . . . . . 8 67 3.2. Contents of Tables . . . . . . . . . . . . . . . . . . . 9 68 3.2.1. Member Table . . . . . . . . . . . . . . . . . . 9 69 3.2.2. Routing Table . . . . . . . . . . . . . . . . . . 9 70 3.2.3. Message Cache . . . . . . . . . . . . . . . . . . 9 71 3.3. Relationship with Unicast Routing Protocols . . . . . . . 10 73 4. Packet and Table Formats 11 74 4.1. Join Request Packet . . . . . . . . . . . . . . . . . . 11 75 4.2. Join Table Packet . . . . . . . . . . . . . . . . . . . 12 77 5. Operation 14 78 5.1. Forwarding Group Setup . . . . . . . . . . . . . . . . . 14 79 5.1.1. Originating a Join Request . . . . . . . . . . . 14 80 5.1.2. Processing a Join Request . . . . . . . . . . . . 14 81 5.1.3. Originating a Join Table . . . . . . . . . . . . 15 82 5.1.4. Processing a Join Table . . . . . . . . . . . . . 15 83 5.2. Multicast Data Packet Handling . . . . . . . . . . . . . 15 85 6. Configuration Parameters 16 87 7. Protocol Applicability 17 88 7.1. Networking Context . . . . . . . . . . . . . . . . . . . . . 17 89 7.2. Protocol Characteristics and Mechanisms . . . . . . . . . . 17 91 References 19 93 Chair's Address 20 95 Authors' Addresses 20 96 1. Introduction 98 This document describes the On-Demand Multicast Routing Protocol 99 (ODMRP) developed by the Wireless Adaptive Mobility (WAM) Lab [11] 100 at UCLA. ODMRP applies "on-demand" routing techniques to avoid 101 channel overhead and increase scalability. It uses the concept of 102 "Forwarding Group," a set of nodes which is responsible for 103 forwarding multicast data, to build a forwarding mesh for each 104 multicast group. By establishing a mesh, drawbacks of multicast 105 trees in mobile wireless networks (e.g., intermittent connectivity, 106 traffic concentration, frequent tree reconfiguration, non-shortest 107 path in a shared tree, etc.) are avoided. The forwarding group 108 infrastructure reduces storage overhead and can handle a much 109 looser connectivity among multicast members. The reduction of 110 channel/storage overhead and the relaxed connectivity make ODMRP 111 more scalable for large networks and more stable for mobile wireless 112 networks. The following properties of ODMRP highlight its advantages 113 as well as limitations. 115 * Low channel and storage overhead 117 * Usage of up-to-date and shortest routes 119 * Robustness to host mobility 121 * Maintenance and exploitation of multiple, redundant paths 123 * Scalability to large number of nodes 125 * Exploitation of the broadcast nature of wireless environments 127 * Independence from unicast routing protocols 129 * Ease of implementation 131 * Redundant forwarding due to mesh configuration 133 * Growth of transmitting table size when the number of group 134 members increases 136 The Forwarding Group Multicast Protocol (FGMP) was first introduced 137 in [4] using a conventional routing structure (i.e., DSDV [8]). An 138 extension of FGMP by incorporating on-demand scheme was proposed in 139 [3]. ODMRP improves upon its predecessors by exploiting sender 140 advertisement scheme which is more efficient than receiver 141 advertisement scheme in a typical multicast environment where more 142 receivers are present than multicast senders. Moreover, the sender 143 advertisement fits better with unicast on-demand routing protocols. 145 2. Terminology 147 2.1. General Terms 149 This section defines terminology used in ODMRP that is not already 150 defined in [7]. 152 node 154 A device that implements IP. 156 neighbor 158 Nodes that are within the radio transmission range. 160 forwarding group 162 A group of nodes participating in multicast packet 163 forwarding. 165 multicast mesh 167 The topology defined by the link connection between forwarding 168 group members. 170 join request 172 The packet sent by multicast sources to establish/update 173 group memberships and routes. 175 join table 177 The table broadcasted by each multicast receiver and forwarding 178 node to establish/update group memberships and routes 180 member table 182 The table maintained by multicast receivers containing 183 information of multicast sources for each multicast group it is 184 associated with. 186 routing table 188 Table maintained by each node containing route information 189 (e.g., next hop node) of existing active routes. 191 2.2. Specification Language 193 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 194 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 195 document are to be interpreted as described in RFC 2119 [1]. 197 3. Protocol Overview 199 3.1. Group Establishment and Route Setup 201 3.1.1. Mesh Creation 203 In ODMRP, group membership and multicast routes are setup and 204 updated by the source on demand. While a multicast source has 205 packets to send, it periodically floods a member advertising 206 packet. This packet, called a "Join Request" packet (format will 207 be shown in Section 4.1.), is broadcasted periodically as long as 208 the source has packets to send. This periodic transmission refreshes 209 the membership information and updates the route in the face of 210 node movements. When a node receives a Join Request packet, it 211 stores multicast group ID, source ID, and sequence number to its 212 "Message Cache" to detect duplicates. Previous node ID is stored as 213 well for a use which will be described later. If the Join Request 214 packet is not a duplicate and the hop count does not exceed the 215 Time-To-Live value, it is relayed. 217 When the Join Request packet reaches a multicast receiver, the 218 receiving node creates or updates the source entry in its Member 219 Table, whose format will be shown in Section 3.2.1. Expired entries 220 are deleted from the member table. A multicast receiver also sends 221 periodic control packets. Namely, from its "Member Table," it builds 222 a "Join Table" and sends it to its neighbors. Section 4.2 will show 223 the format of the Join Table. When a node receives a Join Table, it 224 checks if the next node ID of one of the entries matches its own ID. 225 If it does, the node realizes that it is on the path to the source 226 and thus is part of the forwarding group; it sets the 227 FORWARDING_GROUP_FLAG. It then broadcasts its own Join Table built 228 upon matched entries. The next node ID field is filled in by 229 extracting the information from its Member Cache of received Join 230 Request packets. Namely, the next node ID is set to the previous 231 node ID field of the Join Request that matches multicast group ID 232 and sender ID of the Join Table just received. This way, the Join 233 Table is propagated by each forward group member until it 234 reaches the multicast source via the shortest delay path. This 235 process sets up (or updates) the route from source to each receiver 236 and builds a mesh of nodes, the forwarding group. 238 +--+ +--+ +--+ 239 |S1|-------|I1|-------|R1| 240 +--+\ +--+ /+--+ Join Table of Node R1 and Node I1 241 \ / +----------------+ +----------------+ 242 \ / |Sender|Next Node| |Sender|Next Node| 243 \ / |------+---------| |------+---------| 244 \ / | S1 | I1 | | S1 | S1 | 245 \ / |------+---------| +----------------+ 246 +--+ \+--+/ +--+ | S2 | I2 | 247 |S2|-------|I2|-------|R2| +----------------+ 248 +--+ +--+ +--+ 250 Let us consider the above figure as an example of Join Table 251 forwarding process. Nodes S1 and S2 are multicast sources, and nodes 252 R1 and R2 are multicast receivers. Node R2 sends its Join Table to 253 both S1 and S2 via I2, and R1 sends its packet to S1 via I1 and to 254 S2 via I2. When receivers send their Join Tables to next hop nodes, 255 an intermediate node I1 sets the FORWARDING_GROUP_FLAG and builds 256 its own Join Table since there is a next node ID entry in the 257 received Join Table that matches its ID. Note that I1 has an entry 258 for sender S1 but not for S2 because the next node ID for S2 in the 259 join table received from R1 is not I1. In the meanwhile, node I2 260 sets the FORWARDING_GROUP_FLAG, constructs its own Join Table and 261 sends it to its neighbors. Note that I2 broadcasts the join table 262 only once even though it receives two Join Tables from the 263 receivers. This is because the second table arrival carries no new 264 source information. Channel overhead is thus reduced dramatically in 265 cases where numerous multicast receivers share the same links to the 266 source. 268 After this group establishment and route setup process, a multicast 269 source can transmit packets to receivers via selected routes and 270 forwarding groups. The periodic control packets are sent as long as 271 data packets to send are still present. When receiving the multicast 272 data packet, a node forwards it only when it is not a duplicate and 273 the setting of FORWARDING_GROUP_FLAG has not expired. This procedure 274 minimizes the traffic overhead and prevents sending packets through 275 stale routes. 277 3.1.2. Joining the Group 279 If a node wants to join a particular multicast group as a source, 280 it simply sends the Join Request packet when it has data packets to 281 send. Thereafter, this packet is periodically sent as long as the 282 node has data to multicast. 284 If a node wants to join a particular multicast group as a receiver, 285 it needs to send Join Table to its neighbors periodically as well as 286 every time its Member Table is modified/updated. 288 3.1.3. Leaving the Group 290 No explicit control packet needs to be sent to leave the group. If a 291 multicast source wants to leave the group, it simply stops sending 292 any Join Request packet since it doesn't have any multicast data to 293 send to the group. 295 If a receiver no longer wants to receive from a particular multicast 296 group, it removes the corresponding entries from its Member Table 297 and does not forward the Join Table for that group. 299 3.1.4. Timers 301 ODMRP uses a soft state approach for maintaining routes and 302 multicast/forwarding group members. The refresh and timeout 303 intervals used in ODMRP are defined as follows: 305 RTE_TIMEOUT 307 Timeout interval for Routing Table entries (RTE). 309 MEM_REFRESH 311 Refresh period of transmitting Join Request by a source when it 312 has data packets to send. 314 MEM_TIMEOUT 316 Timeout interval of Member Table entries. 318 JT_REFRESH 320 Refresh period of sending Join Tables when there are entries in 321 Member Table. 323 FG_TIMEOUT 325 Timeout interval of FORWARDING_GROUP_FLAG by each forwarding 326 group members. 328 Sender advertising packets (Join Requests) are issued by source 329 members every MEM_REFRESH interval when there are data packets to 330 send; entries in the Member Table which have not been refreshed 331 (did not receive Join Request before MEM_TIMEOUT) are removed. 332 Entries in routing table are deleted if the routes are not used in 333 RTE_TIMEOUT period. Join Tables are issued every JT_REFRESH when 334 valid entries exist in the Member Table. Any update of the member 335 table triggers the transmission of a Join Table as well. If 336 forwarding nodes are not refreshed (by receiving Join Tables) 337 within FG_TIMEOUT, they are demoted to non-forwarding nodes. These 338 parameters MUST be set to proper values in order to adapt to a 339 rapidly changing topology. 341 3.2. Contents of Tables 343 Nodes running ODMRP are required to maintain the following tables. 344 These tables MAY be implemented in any format, but MUST include the 345 fields specified in this document. 347 3.2.1. Member Table 349 Member table needs to be maintained by multicast receivers. For 350 each multicast group they are participating, they should store 351 multicast source IP address and the timestamp value to detect the 352 expired source. If no Join Request is received from a source in the 353 Member Table within MEM_TIMEOUT, it is removed from the Member 354 Table. 356 3.2.2. Routing Table 358 A routing table is created on demand and is maintained by each node. 359 There is no specific routing table format required by ODMRP. 360 However, the routing table MUST include the next hop address for 361 each destination maintained in the routing table. 363 3.2.3. Message Cache 365 Message Cache is maintained by each node to detect duplicates and to 366 provide next hop information of routes. When a node receives a new 367 Join Request, it MUST insert the following information to the 368 Message Cache: 370 * Multicast Group ID 372 * Source Address 374 * Sequence Number 376 * Previous Hop Address 378 3.3. Relationship with Unicast Routing Protocols 380 ODMRP can coexist with any unicast routing protocol since it finds 381 its own routes independently. From the point of view of scalability 382 and mobility support, it makes most sense to use ODMRP in 383 conjunction with on-demand unicast routing protocols such as 384 DSR [2], ZRP [5], TORA [6], AODV [9], and ABR [10]. If, on the other 385 hand, a conventional table driven unicast routing protocol is used, 386 then, a conventional, tree based multicast protocol may be adequate. 388 4. Packet and Table Formats 390 4.1. Join Request Packet 392 0 1 2 3 393 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 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Ver | Type | Reserved | Time To Live | Hop Count | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Multicast Group IP Address | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Sequence Number | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Source IP Address | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Previous Hop IP Address | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 Ver 408 ODMRP version number. 410 Type 412 01; ODMRP source Join Request. 414 Reserved 416 Sent as 0; ignored on reception. 418 Time To Live 420 Maximum number of hops this packet can traverse. 422 Hop Count 424 The number of hops traveled so far by this packet. 426 Multicast Group IP Address 428 The IP address of the multicast group. 430 Sequence Number 432 The sequence number assigned by the source to uniquely 433 identify the packet. 435 Source IP Address 437 The IP address of the node originating the packet. 439 Previous Hop IP Address 441 The IP address of the last node that has processed this packet. 443 4.2. Join Table Packet 445 0 1 2 3 446 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 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Ver | Type | Count | Reserved | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Multicast Group IP Address | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Sender IP Address [1] | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Next Hop IP Address [1] | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | : | 457 | : | 458 | : | 459 | : | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Sender IP Address [n] | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Next Hop IP Address [n] | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 Ver 468 ODMRP version number. 470 Type 472 02; ODMRP receiver Join Table. 474 Count 476 Number of (Sender IP Address, Next Hop IP Address) 477 combinations. 479 Reserved 481 Sent as 0; ignored on reception. 483 Multicast Group IP address 485 The IP address of the multicast group. 487 Sender IP Address [1..n] 489 The IP addresses of the sources of this multicast group. 491 Next Hop IP Address [1..n] 493 The IP addresses of next nodes that this packet is target to. 495 5. Operation 497 5.1. Forwarding Group Setup 499 5.1.1. Originating a Join Request 501 When a multicast source has data packets to send, it periodically 502 originates "Join Request" packets every MEM_REFRESH interval. The 503 Type field MUST be set to 01. TTL MAY be set to TIME_TO_LIVE_VALUE, 504 but SHOULD be adjusted based on network size and network diameter. 505 Sequence number MUST be large enough to prevent wraparound 506 ambiguity, and Hop Count is initially set to zero. The source puts 507 its IP address in the Source IP Address and Last Hop IP Address 508 field. Note that Join Request packet is not sent when a source does 509 not have any multicast packets to send. 511 5.1.2. Processing a Join Request 513 When a node receives a Join Request packet: 515 1. Check if it is a duplicate by comparing the (Source IP Address, 516 Sequence Number) combination with the entries in Message Cache. 517 If duplicate, then discard the packet. DONE. 519 2. If it is not a duplicate, insert an entry into Message Cache 520 with the information of the received packet (i.e., Multicast 521 Group IP Address, Sequence Number, Source IP Address, and 522 Previous Hop IP Address). 524 3. If the node is a receiver member of the multicast group, then 525 insert/update the information into the Member Table and 526 originate a Join Table packet (see Section 5.1.3.). 528 4. Increase the Hop Count field by 1. 530 5. If the Hop Count field value is equal to or larger than TTL, 531 then discard the packet. DONE. 533 6. If the Hop Count field value is less than TTL, then set the 534 node's IP Address into Last Hop IP Address field and broadcast. 535 DONE. 537 5.1.3. Originating a Join Table 539 A multicast receiver broadcasts a "Join Table" packet every 540 JT_REFRESH as long as there are any entries in its Member Table. 541 The transmission of Join Table is also triggered by the update of 542 its Member Table. Each Sender IP Address and Next Hop IP Address 543 pairs of a multicast group are contained in the Join Table packet. 544 Next Hop IP Address information can be obtained from the Message 545 Cache entries(Last Hop IP Address field of the Join Request 546 packet). 548 5.1.4. Processing a Join Table 550 When a Join Table is received: 552 1. The node looks up the Next Hop IP Address field of the received 553 Join Table entries. If no entries match the node's IP Address, 554 do nothing. DONE. 556 2. If one or more entries coincide with the node's IP Address, set 557 the FORWARDING_GROUP_FLAG and build its own Join Table. Next Hop 558 IP Address information can be obtained from the Join Cache 559 entries (Last Hop IP Address field of the Join Request packet). 561 3. Broadcast the Join Table packet. 563 5.2. Multicast Data Packet Handling 565 Multicast sources broadcast the Data whenever they have packets 566 to send. Nodes relay data packets only if the packet is not a 567 duplicate and the FORWARDING_GROUP_FLAG has not expired. 569 6. Configuration Parameters 571 This section specifies default values associated with ODMRP 572 operation. Note that some of the values SHOULD be adjusted to nodes' 573 mobility speed and network size. 575 FG_TIMEOUT 480 milliseconds 577 JT_REFRESH 160 milliseconds 579 MEM_REFRESH 400 milliseconds 581 MEM_TIMEOUT 960 milliseconds 583 RTE_TIMEOUT 960 milliseconds 585 RT_DISCV_TIMEOUT 30 seconds 587 TIME_TO_LIVE_VALUE 32 hops 589 7. Protocol Applicability 591 7.1. Networking Context 593 ODMRP is best suited for mobile ad hoc wireless networks. 595 7.2. Protocol Characteristics and Mechanisms 597 * Does the protocol provide support for unidirectional links? (if so, 598 how?) 600 - No. We assume bidirectional links. 602 * Does the protocol require the use of tunneling? (if so, how?) 604 - No. 606 * Does the protocol require using some form of source routing? (if 607 so, how?) 609 - No. 611 * Does the protocol require the use of periodic messaging? (if so, 612 how?) 614 - Yes. The periodic messages are sent by multicast sources as 615 long as there exist multicast packets to send. Multicast 616 receivers also send periodic messages while there are multicast 617 source entries in the Member Table. 619 * Does the protocol require the use of reliable or sequenced packet 620 delivery? (if so, how?) 622 - No. 624 * Does the protocol provide support for routing through a multi- 625 technology routing fabric? (if so, how?) 627 - No. 629 * Does the protocol provide support for multiple hosts per router? 630 (if so, how?) 632 - No. In this document, we assume each mobile host is combined 633 with a router, sharing the same IP address. It is possible, 634 however, to extend the protocol to handle multiple hosts per 635 router. 637 * Does the protocol support the IP addressing architecture? (if so, 638 how?) 640 - Yes. The message contains host IP address as its identification. 642 * Does the protocol require link or neighbor status sensing (if so, 643 how?) 645 - No. 647 * Does the protocol have dependence on a central entity? (if so, 648 how?) 650 - No. 652 * Does the protocol function reactively? (if so, how?) 654 - Yes. For example, the source creates and maintains routes and 655 multicast group membership only when it has data packets to 656 send. 658 * Does the protocol function proactively? (if so, how?) 660 - No. 662 * Does the protocol provide loop-free routing? (if so, how?) 664 - Yes. By using the Message Cache, duplicate packets are detected 665 and packets can only go through the loop-free route. 667 * Does the protocol provide for sleep period operation? (if so, how?) 669 - No. 671 * Does the protocol provide some form of security? (if so, how?) 673 - TBD. The work is in progress. 675 * Does the protocol provide support for utilizing multi-channel, 676 link-layer technologies? (if so, how?) 678 - This document assumed an arbitrary single channel link-layer 679 protocol. The protocol can work with any MAC and link-layer 680 technology. It can also support multi-channel link-layer 681 technology (e.g., separate channels for data, control packets, 682 etc.). 684 References 686 [1] Scott Bradner. Key words for use in RFCs to Indicate 687 Requirement Levels. RFC 2119, March 1997. 689 [2] Josh Broch, David B. Johnson, and David A. Maltz. The Dynamic 690 Source Routing Protocol for Mobile Ad Hoc Networks. 691 Internet-Draft, draft-ietf-manet-dsr-00.txt, March 1998. Work 692 in progress. 694 [3] Ching-Chuan Chiang and Mario Gerla. On-Demand Multicast in 695 Mobile Wireless Networks. In proceedings of IEEE ICNP'98, 696 Austin, TX, October 1998. pp. 262-270. 698 [4] Ching-Chuan Chiang, Mario Gerla, and Lixia Zhang. Forwarding 699 Group Multicast Protocol (FGMP) for Multihop, Mobile Wireless 700 Networks. ACM/Baltzer Cluster Computing, vol. 1, no. 2, 1998. 702 [5] Zygmunt J. Haas and Marc R. Pearlman. The Zone Routing 703 Protocol (ZRP) for Ad Hoc Networks. Internet-Draft, 704 draft-ietf-manet-zone-zrp-01.txt, August 1998. Work in 705 progress. 707 [6] Vincent D. Park and M. Scott Corson. Temporally-Ordered 708 Routing Algorithm (TORA) Version 1 - Functional Specification. 709 Internet-Draft, draft-ietf-manet-tora-spec-01.txt, August 1998. 710 Work in progress. 712 [7] Charles E. Perkins. Mobile Ad Hoc Networking Terminology. 713 Internet-Draft, draft-ietf-manet-term-00.txt, October 1997. 714 Work in progress. 716 [8] Charles E. Perkins and Pravin Bhagwat. Highly Dynamic 717 Destination-Sequenced Distance-Vector Routing (DSDV) for 718 Mobile Computers. In proceedings of ACM SIGCOMM'94, London, UK, 719 September 1994, pp. 234-244. 721 [9] Charles E. Perkins and Elizabeth M. Royer. Ad Hoc On Demand 722 Distance Vector (AODV) Routing. Internet-Draft, 723 draft-ietf-manet-aodv-01.txt, August 1998. Work in progress. 725 [10] Chai-Keong Toh. Associativity-Based Routing for Ad-Hoc Mobile 726 Networks. Wireless Personal Communications Journal, Special 727 Issue on Mobile Networking and Computing Systems, Kluwer 728 Academic Publishers, vol. 4, no. 2, March 1997, pp. 103-139. 730 [11] UCLA Wireless Adaptive Mobility (WAM) Laboratory. 731 http://www.cs.ucla.edu/NRL/wireless 733 Chair's Address 735 The Working Group can be contacted via its current chairs: 737 M. Scott Corson 738 Institute for Systems Research 739 University of Maryland 740 College Park, MD 20742 741 USA 743 Phone: +1 301 405-6630 744 Email: corson@isr.umd.edu 746 Joseph Macker 747 Information Technology Division 748 Naval Research Laboratory 749 Washington, DC 20375 750 USA 752 Phone: +1 202 767-2001 753 Email: macker@itd.nrl.navy.mil 755 Authors' Addresses 757 Questions about this document can also be directed to the authors: 759 Mario Gerla 760 405 Hilgard Ave. 761 Computer Science Department 762 University of California 763 Los Angeles, CA 90095 764 USA 766 Phone: +1 310 825-4367 767 Fax: +1 310 825-2273 768 Email: gerla@cs.ucla.edu 769 Guangyu Pei 770 405 Hilgard Ave. 771 Computer Science Department 772 University of California 773 Los Angeles, CA 90095 774 USA 776 Phone: +1 310 825-1888 777 Email: pei@cs.ucla.edu 779 Sung-Ju Lee 780 405 Hilgard Ave. 781 Computer Science Department 782 University of California 783 Los Angeles, CA 90095 784 USA 786 Phone: +1 310 206-8589 787 Email: sjlee@cs.ucla.edu 789 Ching-Chuang Chiang 790 Computer Science Department 791 Chung-Cheng Institute of Technology 792 Ta-Shi, TaoYuan 335 793 Taiwan 795 Phone: +886 3 380-9331 796 Fax: +886 3 389-4770 797 Email: ccchiang@ccit.edu.tw