idnits 2.17.1 draft-ietf-manet-odmrp-04.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 28 longer pages, the longest (page 29) being 73 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 30 pages 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. ** There are 16 instances of too long lines in the document, the longest one being 44 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 240 has weird spacing: '... Reply only ...' == 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 2002) is 7832 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) == Unused Reference: '2' is defined on line 1046, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 1123, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' -- Possible downref: Non-RFC (?) normative reference: ref. '16' -- Possible downref: Non-RFC (?) normative reference: ref. '17' -- Possible downref: Non-RFC (?) normative reference: ref. '18' -- Possible downref: Non-RFC (?) normative reference: ref. '19' -- Possible downref: Non-RFC (?) normative reference: ref. '20' -- Possible downref: Normative reference to a draft: ref. '21' Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 22 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF MANET Working Group Yunjung Yi 2 INTERNET-DRAFT Sung-Ju Lee 3 Expiration: Febuary 2003 William Su 4 Mario Gerla 5 University of California, Los Angeles 6 November 2002 8 On-Demand Multicast Routing Protocol (ODMRP) for Ad Hoc Networks 10 12 Status of This Memo 14 This document is an Internet-Draft and is subject to 15 all provisions of Section 10 of RFC2026 except that the 16 right to produce derivative works is not granted. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet- 26 Drafts as reference material or to cite them other than as 27 "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 Abstract 37 On-Demand Multicast Routing Protocol (ODMRP) is a multicast routing 38 protocol designed for ad hoc networks with mobile hosts. ODMRP is 39 a mesh-based, rather than a conventional tree-based, multicast 40 scheme and uses a forwarding group concept (only a subset of nodes 41 forwards the multicast packets via scoped flooding). It applies 42 on-demand procedures to dynamically build routes and maintain 43 multicast group membership. ODMRP is well suited for ad hoc 44 wireless networks with mobile hosts where bandwidth is limited, 45 topology changes frequently and rapidly, and power is constrained. 47 Contents 49 Status of This Memo 1 51 Abstract 1 53 1. Introduction 4 55 2. Terminology 5 56 2.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 5 57 2.2. Specification Language . . . . . . . . . . . . . . . . . 5 59 3. Protocol Overview 6 60 3.1. Multicast Route and Mesh Creation . . . . . . . . . . . . 6 61 3.2. Reliability . . . . . . . . . . . . . . . . . . . . . . . 8 62 3.3. Soft State . . . . . . . . . . . . . . . . . . . . . . . 10 63 3.4. Selection of Timer Values . . . . . . . . . . . . . . . . 10 64 3.5. Unicast Capability . . . . . . . . . . . . . . . . . . . 10 65 3.6. Contents of Tables . . . . . . . . . . . . . . . . . . . 11 66 3.6.1. Routing Table . . . . . . . . . . . . . . . . . . 11 67 3.6.2. Forwarding Group Table . . . . . . . . . . . . . 11 68 3.6.3. Message Cache . . . . . . . . . . . . . . . . . . 11 69 3.7. Mobility Prediction 12 70 3.7.1. Adapting the Refresh Interval via 71 Mobility Prediction . . . . . . . . . . . . . . . 12 72 3.7.2. Route Selection Criteria . . . . . . . . . . . . 14 73 3.7.3. Alternative Method of Prediction . . . . . . . . 14 74 3.8. Scalability via Efficient Flooding . . . . . . . . . . . . 14 75 3.8.1. Passive Clustering . . . . . . . . . . . . . . . 15 77 4. Packet and Table Formats 16 78 4.1. Join Query Packet Header . . . . . . . . . . . . . . . 16 79 4.2. Join Reply Packet . . . . . . . . . . . . . . . . . . . 18 81 5. Operation 20 82 5.1. Forwarding Group Setup . . . . . . . . . . . . . . . . . 20 83 5.1.1. Originating a Join Query . . . . . . . . . . . . 20 84 5.1.2. Processing a Join Query . . . . . . . . . . . . . 20 85 5.1.3. Processing a Join Query When GPS is Used . . . . 21 86 5.1.4. Processing a Join Query When PC is Used . . . . . 22 87 5.1.5. Originating a Join Reply . . . . . . . . . . . . 23 88 5.1.6. Processing a Join Reply . . . . . . . . . . . . . 23 89 5.1.7. Processing a Join Reply When GPS is Used . . . . 23 90 5.1.8. Processing a Join Reply When PC is Used . . . . . 23 91 5.2. Handling a Multicast Data Packet . . . . . . . . . . . . 24 93 6. Protocol Applicability 25 94 6.1. Networking Context . . . . . . . . . . . . . . . . . . . . . 25 95 6.2. Protocol Characteristics and Mechanisms . . . . . . . . . . 25 97 Acknowledgments 27 99 References 27 101 Chair's Address 28 103 Authors' Addresses 29 104 1. Introduction 106 This document describes the On-Demand Multicast Routing Protocol 107 (ODMRP) [14][15] developed by the Wireless Adaptive Mobility (WAM) 108 Laboratory [20] at University of California, Los Angeles. ODMRP 109 applies "on-demand" routing techniques to avoid channel overhead and 110 improve scalability. It uses the concept of "forwarding group," [5] 111 a set of nodes responsible for forwarding multicast data, to build a 112 forwarding mesh for each multicast group. By maintaining and using a 113 mesh instead of a tree, the drawbacks of multicast trees in mobile 114 wireless networks (e.g., intermittent connectivity, traffic 115 concentration, frequent tree reconfiguration, non-shortest path in a 116 shared tree, etc.) are avoided. A soft-state approach is taken to 117 maintain multicast group members. No explicit control message is 118 required to leave the group. We believe the reduction of 119 channel/storage overhead and the relaxed connectivity make ODMRP 120 more attractive in mobile wireless networks. 122 The following properties of ODMRP highlight its advantages. 124 * Simplicity 126 * Low channel and storage overhead 128 * Usage of up-to-date shortest routes 130 * Reliable construction of routes and forwarding group 132 * Robustness to host mobility 134 * Maintenance and exploitation of multiple redundant paths 136 * Exploitation of the broadcast nature of wireless environments 138 * Unicast routing capability 140 * Scalability using efficient flooding 142 2. Terminology 144 2.1. General Terms 146 This section defines terminology used in ODMRP. 148 node 150 A device that implements IP. 152 neighbor 154 Nodes that are within the radio transmission range. 156 forwarding group 158 A group of nodes participating in multicast packet forwarding. 160 multicast mesh 162 The topology defined by the link connection between forwarding 163 group members. 165 join query 167 The special data packet sent by multicast sources to establish 168 and update group memberships and routes. 170 join reply 172 The table broadcasted by each multicast receiver and forwarding 173 node to establish and update group membership and routes 175 2.2. Specification Language 177 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 179 document are to be interpreted as described in RFC 2119 [4]. 181 3. Protocol Overview 183 3.1. Multicast Route and Mesh Creation 185 In ODMRP, group membership and multicast routes are established and 186 updated by the source on demand. Similar to on-demand unicast 187 routing protocols, a request phase and a reply phase comprise the 188 protocol. When a multicast source has packets to send but no route 189 and group membership is known, it floods a member advertising packet 190 with data payload piggybacked. This packet, called "Join Query" 191 (format shown in Section 4.1) is periodically broadcasted to the 192 entire network to refresh the membership information and update the 193 routes. When a node receives a Join Query packet, it stores the 194 source address and the unique identifier of the packet to its 195 "Message Cache" to detect duplicates. The upstream node address is 196 inserted or updated as the next node for the source node in its 197 "Routing Table." If the Join Query packet is not a duplicate and 198 the Time-To-Live value is greater than zero, appropriate fields are 199 updated and it is rebroadcast (operation details are illustrated 200 in Section 5.1.2). 202 When a Join Query packet reaches the multicast receiver, it creates 203 and broadcasts a "Join Reply" to its neighbors. When a node receives 204 a Join Reply, it checks if the next node address of one of the 205 entries matches its own address. If it does, the node realizes that 206 it is on the path to the source and thus is part of the forwarding 207 group; it sets the FG_FLAG (Forwarding Group Flag). It then 208 broadcasts its own Join Reply built upon matched entries. The next 209 node address field is filled in by extracting the information from 210 its routing table. This way, the Join Reply is propagated by each 211 forward group member until it reaches the multicast source via the 212 selected path. This process constructs (or updates) the routes from 213 sources to receivers and builds a mesh of nodes, the forwarding 214 group. 216 +--+ +--+ +--+ 217 |S1|-------|I1|-------|R1| 218 +--+\ +--+ /+--+ Join Replies of Node R1 and Node I1 219 \ / +----------------+ +----------------+ 220 \ / |Sender|Next Node| |Sender|Next Node| 221 \ / |------+---------| |------+---------| 222 \ / | S1 | I1 | | S1 | S1 | 223 \ / |------+---------| +----------------+ 224 +--+ \+--+/ +--+ | S2 | I2 | 225 |S2|-------|I2|-------|R2| +----------------+ 226 +--+ +--+ +--+ 228 Let us consider the above figure as an example of Join Reply 229 forwarding process. Nodes S1 and S2 are multicast sources, and nodes 230 R1 and R2 are multicast receivers. Node R2 sends its Join Reply to 231 both S1 and S2 via I2, and R1 sends its packet to S1 via I1 and to 232 S2 via I2. When receivers send their Join Replies to next hop nodes, 233 an intermediate node I1 sets the FG_FLAG and builds its own Join 234 Reply since there is a next node ID entry in the Join Reply received 235 from R1 that matches its ID. Note that the Join Reply built by I1 236 has an entry for sender S1 but not for S2 because the next node 237 address for S2 in the received Join Reply is not I1. In the 238 meanwhile, node I2 sets the FG_FLAG, constructs its own Join Reply 239 and sends it to its neighbors. Note that I2 broadcasts the Join 240 Reply only once even though it receives two Join Replies from the 241 receivers because the second table arrival carries no new source 242 information. Channel overhead is thus reduced dramatically in cases 243 where numerous multicast receivers share the same links to the 244 source. 246 After this group establishment and route construction process, a 247 source can multicast packets to receivers via selected routes and 248 forwarding groups. While outgoing data packets exist, the source 249 sends Join Query every REFRESH_INTERVAL. This Join Query and Join 250 Reply propagation process refreshes forwarding group and routes. 251 When receiving the multicast data packet, a node forwards it only 252 when it is not a duplicate and the setting of the FG_FLAG for the 253 multicast group has not expired. This procedure minimizes the 254 traffic overhead and prevents sending packets through stale routes. 256 3.2. Reliability 258 The reliable transmission of Join Replies plays an important role 259 in establishing and refreshing multicast routes and forwarding 260 groups. Hence, if Join Replies are not properly delivered, 261 effective multicast routing cannot be achieved by ODMRP. The IEEE 262 802.11 MAC (Medium Access Control) protocol [8], which is the 263 emerging standard in wireless networks, performs reliable 264 transmission by retransmitting the packet if no acknowledgment is 265 received. However, if the packet is broadcasted, no acknowledgments 266 or retransmissions are sent. In ODMRP, the transmission of Join 267 Replies are often broadcasted to more than one upstream neighbors 268 since we are handling multiple sources (e.g., see the Join Reply 269 from node R1 in the example of Section 3.1.). In such cases, the 270 hop-by-hop verification of Join Reply delivery and the 271 retransmission cannot be handled by the MAC layer. It must be done 272 indirectly by ODMRP. Another option for reliable delivery is to 273 subdivide the Join Reply into separate sub-tables, one for each 274 distinct next node. In the figure of Section 3.1. for example, the 275 Join Reply at node R1 is split into two Join Replies, one for 276 neighbor I1 and the other for neighbor I2. These Join Replies are 277 separately unicasted using a reliable MAC protocol such as IEEE 278 802.11 or MACAW [3]. Since the number of neighbors is generally 279 limited (typically, about six neighbors in the optimum in a 280 multihop network [12]), the scheme still scales well to large number 281 of sources. This option can actually be used as backup to the 283 passive acknowledgment option as discussed below. 285 We adopt a scheme that was used in [10]. When a node transmits a 286 Join Reply packet to the immediate upstream node of the route, the 287 immediate downstream node can hear the transmission if it is 288 within the transmitter's radio range. Hence, the packet is used as 289 an "passive acknowledgment." We can utilize this passive 290 acknowledgment to verify the delivery of a Join Reply. Note that 291 the source itself must send an active acknowledgment to the 292 previous hop since it does not have any next hop to send a Join 293 Reply to unless it is also a forwarding group node for other 294 sources. 296 Considering the case in figure of Section 3.1. again, we note that 297 once the nodes I1 and I2 receive the Join Reply from node R1, they 298 will construct and forward their own Join Replies to next hops (in 299 this case, sources S1 and S2). In transmitting their Join Replies, 300 nodes I1 and I2 may overlap with each other. If I1 and I2} are 301 within receiving range, they will recover because of the carrier 302 sense feature in CSMA (Carrier Sense Multiple Access) [13]. However, 303 if they are out of range, they will be unaware of the "hidden 304 terminal" condition of node R1, which cannot hear the (overlapped) 305 passive acknowledgments. Thus, a node may not hear the passive 306 acknowledgments of its upstream neighbor because of conflicts due 307 to the hidden terminal problem. It will also not hear the passive 308 acknowledgment if the upstream neighbor has moved away. In either 309 case, when no acknowledgment is received within the timeout 310 interval, the node retransmits the message. Note that the node may 311 get acknowledgments from some, but not all upstream neighbors. As 312 an option, the retransmission could be carried out in unicast mode, 313 to selected neighbors, with reduced sub-tables. If packet delivery 314 cannot be verified after an appropriate number of retransmissions, 315 the node considers the route to be invalidated. At this point, the 316 most likely cause of route failure is the fact that a node on the 317 route has failed or has moved out of range. An alternate route must 318 be found "on the spot." The node thus broadcasts a message to its 319 neighbors specifying that the next hop to a set of sources cannot 320 be reached. Upon receiving this packet, each neighbor builds and 321 unicasts the Join Reply to its next hop if it has a route to the 322 multicast sources. If no route is known, it simply broadcasts the 323 packet specifying the next hop is not available. In both cases, the 324 node sets its FG_FLAG. In practical implementations, this 325 redundancy is sufficient to establish alternate paths until a more 326 efficient route is established during the next refresh phase. The 327 FG_FLAG setting of every neighbor may create excessive redundancy, 328 but most of these settings will expire because only necessary 329 forwarding group nodes will be refreshed in the next Join Reply 330 propagation phase. 332 3.3. Soft State 334 In ODMRP, no explicit control packets need to be sent to leave the 335 group. If a multicast source wants to leave the group, it simply 336 stops sending any Join Query packets since it does not have any 337 multicast data to send to the group. If a receiver no longer wants 338 to receive from a particular multicast group, it does not send the 339 Join Reply for that group. Nodes in the forwarding group are demoted 340 to non-forwarding nodes if not refreshed (no Join Replies received) 341 before they timeout. 343 3.4. Selection of Timer Values 345 Timer values for route refresh interval and forwarding group 346 timeout interval can have impacts on ODMRP performance. The 347 selection of these soft state timers should be adaptive to network 348 environment (e.g., traffic type, traffic load, mobility pattern, 349 mobility speed, channel capacity, etc.). When small route refresh 350 interval values are used, fresh route and membership information 351 can be obtained frequently at the expense of producing more packets 352 and causing network congestion. On the other hand, when large route 353 refresh values are selected, even though less control traffic will 354 be generated, nodes may not know up-to-date route and multicast 355 membership. Thus in highly mobile networks, using large route 356 refresh interval values can yield poor protocol performance. The 357 forwarding group timeout interval should also be carefully 358 selected. In networks with heavy traffic load, small values should 359 be used so that unnecessary nodes can timeout quickly and not 360 create excessive redundancy. In situations with high mobility, 361 however, large values should be chosen so that more alternative 362 paths can be provided. It is important to note that the forwarding 363 group timeout value must be larger (e.g., 3 to 5 times) than the 364 value of route refresh interval. 366 3.5. Unicast Capability 368 One of the major strengths of ODMRP is its unicast routing 369 capability. Not only can ODMRP coexist with any unicast routing 370 protocol, it can also operate very efficiently as an unicast 371 routing protocol. Thus, a network equipped with ODMRP does not 372 require a separate unicast protocol. Other ad hoc multicast routing 373 protocols such as AMRoute [5], CAMP [7], RBM [6], and LAM [9] 374 must be run on top of a unicast routing protocol. CAMP, RBM, and 375 LAM in particular, only work with certain underlying unicast 376 protocols. 378 3.6. Contents of Tables 380 Nodes running ODMRP are required to maintain the following tables. 381 These tables MAY be implemented in any format, but MUST include the 382 fields specified in this document. 384 3.6.1. Routing Table 386 A routing table is created on demand and is maintained by each node. 387 An entry is inserted or updated when a non-duplicate Join Query is 388 received. The node stores the destination (i.e., the source of the 389 Join Query) and the next hop to the destination (i.e., the last 390 node that propagated the Join Query). The routing table provides 391 the next hop information when transmitting Join Replies. 393 3.6.2. Forwarding Group Table 395 When a node is a forwarding group node of the multicast group, it 396 maintains the group information in the forwarding group table. The 397 multicast group ID and the time when the node was last refreshed 398 are recorded. 400 3.6.3. Message Cache 402 The message cache is maintained by each node to detect duplicates. 403 When a node receives a new Join Query or data, it stores the source 404 address and the unique identifier of the packet. Note that entries 405 in the message cache need not be maintained permanently. Schemes 406 such as LRU (Least Recently Used) or FIFO (First In First Out) can 407 be employed to expire and remove old entries and prevent the size 408 of the message cache to be extensive. 410 3.7. Mobility Prediction 412 3.7.1 Adapting the Refresh Interval via Mobility Prediction 414 ODMRP requires periodic flooding of Join Query to build and refresh 415 routes. Excessive flooding, however, is not desirable in ad hoc 416 networks because of bandwidth constraints. Furthermore, flooding 417 often causes congestion, contention, and collisions. Finding the 418 optimal flooding interval is critical in ODMRP performance. In 419 highly mobile networks where nodes are equipped with GPS [11] (e.g., 420 tactical networks with tanks, ships, aircrafts, etc.), we can 421 efficiently adapt the REFRESH_INTERVAL to mobility patterns and 422 speeds by utilizing the location and movement information. We use 423 the location and movement information to predict the duration 424 of time routes will remain valid. With the predicted time of route 425 disconnection, Join Queries are only flooded when route breaks of 426 ongoing data sessions are imminent. Note that ODMRP can still 427 operate efficiently in networks where no such information is 428 available, but the protocol can be further improved if those 429 information can be utilized. 431 In our prediction method, we assume a free space propagation model, 432 where the received signal strength solely depends on its distance 433 to the transmitter. We also assume that all nodes in the network 434 have their clock synchronized (e.g., by using the NTP (Network Time 435 Protocol) [16] or the GPS clock itself). Therefore, if the motion 436 parameters of two neighbors (e.g., speed, direction, radio 437 propagation range, etc.) are known, we can determine the duration 438 of time these two nodes will remain connected. Assume two nodes i 439 and j are within the transmission range r of each other. Let 440 (x_{i}, y_{i}) be the coordinate of node i and (x_{j}, y_{j}) be 441 that of node j. Also let v_{i} and v_{j} be the speeds, and 442 theta_{i} and theta_{j} (0 <= theta_{i}, theta_{j} < 2 * pi) be the 443 moving directions of nodes i and j, respectively. Then, the 444 duration of time that the link between two nodes will stay 445 connected, D_{t}, is given by: 447 -(a*b + c*d) + sqrt((a^{2} + c^{2})*r^{2} - (a*d - b*c)^{2}) 448 D_{t} = ------------------------------------------------------------ 449 a^{2} + c^{2} 451 where 452 a = v_{i}*cos(theta_{i}) - v_{j}*cos(theta_{j}), 453 b = x_{i} - x_{j}, 454 c = v_{i}*sin(theta_{i}) - v_{j}*sin(theta_{j}), and 455 d = y_{i} - y_{j}. 457 Note that when v_{i} = v_{j} and theta_{i} = theta_{j}, D_{t} is 458 set to infinity without applying the above equation. 460 To utilize the information obtained from the prediction, extra 461 fields must be added into Join Query and Join Reply packets. When a 462 source sends Join Query, it appends its location, speed, and 463 direction. It sets the MIN_LET (Minimum Link Expiration Time) field 464 to the MAX_LET_VALUE since the source does not have any previous 465 hop node. The next hop neighbor, upon receiving a Join Query, 466 predicts the link expiration time between itself and the previous 467 hop using the above equation. The minimum between this value and 468 the MIN_LET indicated by the Join Query is included in the packet. 469 The rationale is that as soon as a single link on a path is 470 disconnected, the entire path is invalidated. The node also 471 overwrites the location and mobility information field written by 472 the previous node with its own information. When a multicast member 473 receives the Join Query, it calculates the predicted LET of the 474 last link of the path. The minimum between the last link expiration 475 time and the MIN_LET value specified in the Join Query is the RET 476 (Route Expiration Time). This RET value is enclosed in the Join 477 Reply and broadcasted. If a forwarding group node receives multiple 478 Join Replies with different RET values (i.e., lies in paths from 479 the same source to multiple receivers), it selects the minimum RET 480 among them and sends its own Join Reply with the chosen RET value 481 attached. When the source receives Join Replies, it selects the 482 minimum RET among all the Join Replies received. Then the source 483 can build new routes by flooding a Join Query before the minimum 484 RET approaches (i.e., route breaks). 486 In addition to the estimated RET value, other factors need to be 487 considered when choosing the refresh interval. If the node mobility 488 rate is high and the topology changes frequently, routes will 489 expire quickly and often. The source may propagate Join Query 490 excessively and this excessive flooding can cause collisions and 491 congestion, and clogs the network with control packets. Thus, the 492 MIN_REFRESH_INTERVAL should be enforced to avoid control message 493 overflow. On the other hand, if nodes are stationary or move slowly 494 and link connectivity remains unchanged for a long duration of time, 495 routes will hardly expire and the source will rarely send Join 496 Query. A few problems arise in this situation. First, if a node in 497 the route suddenly changes its movement direction or speed, the 498 predicted RET value becomes obsolete and routes will not be 499 reconstructed in time. Second, when a non-member node which is 500 located remotely to multicast members wants to join the group, 501 it cannot inform the new membership or receive data until a Join 502 Query is received. Hence, the MAX_REFRESH_INTERVAL should be set. 503 The selection of the MIN_REFRESH_INTERVAL and the 504 MAX_REFRESH_INTERVAL values should be adaptive to network 505 environments. 507 3.7.2. Route Selection Criteria 509 In ODMRP, a multicast receiver selects routes based on the minimum 510 delay (i.e., routes taken by the first Join Query received. A 511 different route selection method is applied when we use the 512 mobility prediction. The idea is inspired by the Associativity-Based 513 Routing (ABR) protocol [18] which chooses associatively stable 514 routes. In our algorithm, instead of using the minimum delay path, 515 we can choose a route that is the most stable (i.e., the one that 516 will remain connected for the longest duration of time). To select 517 a route, a multicast receiver must wait for an appropriate amount of 518 time after receiving the first Join Query so that all possible 519 routes and their route qualities will be known. The receiver then 520 chooses the most stable route and broadcasts a Join Reply. Route 521 breaks will occur less often and the number of Join Query 522 propagation will reduce because stable routes are used. 524 3.7.3. Alternative Method of Prediction 526 Since GPS may not work properly in certain situations (e.g., 527 indoor, fading, etc.), we may not always be able to accurately 528 predict the link expiration time for a particular link. However, 529 there is an alternative method to predict the LET. This method is 530 based on a more realistic propagation model and has been proposed 531 in [1] and [17]. Basically, transmission power samples are measured 532 periodically from packets received from a mobile's neighbor. From 534 this information it is possible to compute the rate of change for a 535 particular neighbor's transmission power level. Therefore, the time 536 when the transmission power level will drop below the acceptable 537 value (i.e., hysteresis region) can be predicted. We plan to 538 investigate this option in our future work. 540 3.8. Scalabiity via Efficient Flooding 542 Periodic Join Query floods to maintain a multicast mesh structure in 543 ODMRP may significantly increase the network congestion and thus 544 dramatically degrade network throughput. Especially, excessive 545 flooding can become very inefficient as the node geographic density 546 (i.e., the number of neighbors within a node's radio reach) grows 547 due to redundant, "superfluous" forwarding. In fact, superfluous 548 flooding increases the link overhead and wireless medium congestion 549 and contention. In a large network, with heavy load, this extra overhead 550 can have severe impact on performance and should be eliminated. 552 We developed passive clustering [21], a cluster formation protocol 553 mechanism designed for mobile ad hoc networks. Passive clustering (PC) 554 constructs and maintains clusters using on-going data packets instead of 555 extra explicit control messages. Thus PC does not require excessive extra overhead. 556 The cluster platform developed by PC can be used for efficient flooding, where only 557 a set of dominant nodes forwards a flood packet rather all nodes participate in flooding. 558 With cluster platform, only non-ORDINARY nodes (e.g., cluster heads and 559 gateways) are allowed to relay the flood packet. Since the portion of cluster 560 heads and gateways decreases as node geographical density increases, PC helps 561 the more effectively as the network becomes denser. 563 3.8.1. Passive clustering 565 Passive Clustering (PC) dynamically partitions the network in clusters 566 interconnected by gateway nodes. The resulting clusters have only one 567 CLUSTER HEAD (a representative node) on the center of each cluster and 568 the transmission range of each cluster head defines the area of the 569 cluster. 570 Other nodes not cluster head in the cluster are called cluster members. 571 A GATEWAY node, one of cluster members, interconnects two adjacent 572 clusters. 573 If a node is not a cluster head nor gateway, the node is an 574 ORDINARY NODE. 575 Note that clusters are formed only when on-going traffic exists. 576 Initially or without on-going traffic, each node set its state to INITIAL NODE. 578 PC is an "on demand" protocol. It constructs and maintains the clus- 579 ter architecture only when there are on-going data packets that pig- 580 gyback "cluster-related information" such as the state of a node in a 581 cluster and an IP address of a node. Each node collects neighbor 582 information through promiscuous packet receptions. Thus, PC does not 583 necessitate background overhead of clustering. 584 PC has two innovative mechanisms for the cluster formation: the 585 "First Declaration Wins" rule and "Gateway Selec- 586 tion Heuristic". With the "First Declaration Wins" 587 rule, a node that first claims to be a CLUSTER HEAD 'rules' the rest 588 of nodes in its clustered area (radio coverage). There is no waiting 589 period (to make sure all the neighbors have been checked). Also, 590 "Gateway Selection Heuristic" provides a procedure to 591 elect the minimal number of gateways required to maintain connectiv- 592 ity (including distributed gateway nodes) in a distributed manner [21]. 594 " 595 4. Packet and Table Formats 597 4.1. Join Query Packet Header 599 0 1 2 3 600 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 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | Type | Reserved | Time To Live | Hop Count | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | Multicast Group IP Address | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | Sequence Number | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | Source IP Address | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | Previous Hop IP Address | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | Previous Hop X Coordinate | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | Previous Hop Y Coordinate | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | Previous Hop Moving Speed | Previous Hop Moving Direction | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | Minimum Link Expiration Time | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 Type 623 01; ODMRP Join Query. 625 Reserved 627 Sent as 0; ignored on reception. 629 Time To Live 631 Number of hops this packet can traverse. 633 Hop Count 635 The number of hops traveled so far by this packet. 637 Multicast Group IP Address 639 The IP address of the multicast group. 641 Sequence Number 643 The sequence number assigned by the source to uniquely 644 identify the packet. 646 Source IP Address 648 The IP address of the node originating the packet. 650 Previous Hop IP Address 652 The IP address of the last node that has processed this packet. 654 Previous Hop X Coordinate (Optional) 656 The x-coordinate of the last node that has processed this 657 packet. The information can be obtained from the GPS. This 658 field is required only when network hosts are GPS equipped. 660 Previous Hop Y Coordinate (Optional) 662 The y-coordinate of the last node that has processed this 663 packet. The information can be obtained from the GPS. This 664 field is required only when network hosts are GPS equipped.. 666 Previous Hop Moving Speed (Optional) 668 The mobility speed of the last node that has processed this 669 packet. The information can be obtained from the GPS or the 670 node's own instruments and sensors (e.g., campus, odometer, 671 speed sensors, etc.). This field is required only when network 672 hosts are GPS equipped. 674 Previous Hop Moving Direction (Optional) 676 The moving direction of the last node that has processed this 677 packet. The information can be obtained from the GPS or the 678 node's own instruments and sensors (e.g., campus, odometer, 679 speed sensors, etc.). This field is required only when network 680 hosts are GPS equipped. 682 Minimum Link Expiration Time (Optional) 684 The minimum expiration time among the links taken by this 685 packet so far. This field is required only when network hosts 686 are GPS equipped. 688 4.2. Join Reply Packet 690 0 1 2 3 691 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 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | Type | Count |R|F| Reserved | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | Multicast Group IP Address | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | Previous Hop IP Address | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | Sequence Number | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | Sender IP Address [1] | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | Next Hop IP Address [1] | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | Route Expiration Time [1] | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | : | 708 | : | 709 | : | 710 | : | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | Sender IP Address [n] | 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 | Next Hop IP Address [n] | 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 | Route Expiration Time [n] | 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 Type 721 02; ODMRP Join Reply. 723 Count 725 Number of (Sender IP Address, Next Hop IP Address) 726 combinations. 728 R 730 Acknowledgment request flag. This flag is set when active 731 acknowledgment packet is requested. 733 F 735 Forwarding group flag. This flag is set when the packet is 736 transmitted by a forwarding group node. 738 Reserved 740 Sent as 0; ignored on reception. 742 Multicast Group IP address 744 The IP address of the multicast group. 746 Previous Hop IP Address 748 The IP address of the last node that has processed this packet. 750 Sequence Number 752 The sequence number assigned by the previous hop node to 753 uniquely identify the packet. 755 Sender IP Address [1..n] 757 The IP addresses of the sources of this multicast group. 759 Next Hop IP Address [1..n] 761 The IP addresses of next nodes that this packet is target to. 763 Route Expiration Time [1..n] (Optional) 765 The minimum route expiration times of this multicast group. 766 This field is required only when network hosts are GPS equipped. 768 5. Operation 770 5.1. Forwarding Group Setup 772 5.1.1. Originating a Join Query 774 When a multicast source has data packets to send but no route is 775 known, it originates a "Join Query" packet. The Type field MUST be 776 set to 01. TTL MAY be set to TIME_TO_LIVE_VALUE, but SHOULD be 777 adjusted based on network size and network diameter. The Sequence 778 Number MUST be large enough to prevent wraparound ambiguity, and the 779 Hop Count is initially set to zero. The source puts its IP address 780 in the Source IP Address and Last Hop IP Address field. It appends 781 its location, speed, and direction into Join Query if nodes in the 782 network are equipped with GPS. 784 When location and movement information is utilized, it sets the 785 MIN_LET (Link Expiration Time) field to the MAX_LET_VALUE since the 786 source does not have any previous hop node. When the source receives 787 Join Replies from multicast receivers, it selects the minimum RET 788 (Route Expiration Time) among all the Join Replies received. Then the 789 source can build new routes by originating a Join Query before the 790 minimum RET approaches (i.e., route breaks of ongoing data sessions 791 are imminent). 793 5.1.2. Processing a Join Query 795 When a node receives a Join Query packet: 797 1. Check if it is a duplicate by comparing the (Source IP Address, 798 Sequence Number) combination with the entries in the message 799 cache. If a duplicate, then discard the packet. DONE. 801 2. If it is not a duplicate, insert an entry into the message cache 802 with the information of the received packet (i.e., sequence 803 number and source IP address) and insert/update the entry for 804 routing table (i.e., backward learning). 806 3. If the node is a member of the multicast group, it originates a 807 Join Reply packet with the RET value enclosed (see Section 5.1.5). 809 4. Increase the Hop Count field by 1 and decrease the TTL field by 1. 811 5. If the TTL field value is less than or equal to 0, then discard 812 the packet. DONE. 814 6. If the TTL field value is greater than 0, then set the node's IP 815 Address into Last Hop IP Address field and broadcast. DONE. 817 5.1.3. Processing a Join Query When GPS is Used 819 When a node receives a Join Query packet: 821 1. Check if it is a duplicate by comparing the (Source IP Address, 822 Sequence Number) combination with the entries in the message 823 cache. If a duplicate, then discard the packet. DONE. 825 2. If it is not a duplicate, insert an entry into the message cache 826 with the information of the received packet (i.e., sequence 827 number and source IP address) and insert/update the entry for 828 routing table (i.e., backward learning). 830 3. Predict the duration of time the link between the node and the 831 upstream node will remain connected using the equation given in 832 Section 3.7.1. 834 The minimum between the newly obtained D_{t} value and the 835 indicated value in MIN_LET field of the Join Query is included in 836 the packet. The rationale is that as soon as a single link on the 837 path is disconnected, the entire path is invalidated. The node 838 also overwrites the location and mobility information field 839 written by the previous node with its own information. 841 4. If the node is a member of the multicast group, it calculates the 842 predicted LET of the last link of the path. The minimum between 843 the last link expiration time and the MIN_LET value specified in 844 the Join Query is the RET (Route Expiration Time). 846 To select a route, a multicast receiver must wait for an 847 appropriate amount of time after receiving the first Join Query 848 so that all possible routes and their RET will be known. The 849 receiver then chooses the most stable route (i.e., the route with 850 the largest RET) and originates a Join Reply packet with the RET 851 value enclosed (see Section 5.1.3.). 853 5. Increase the Hop Count field by 1 and decrease the TTL field by 1. 855 6. If the TTL field value is less than or equal to 0, then discard 856 the packet. DONE. 858 7. If the TTL field value is greater than 0, then set the node's IP 859 Address into Last Hop IP Address field and broadcast. DONE. 861 5.1.4. Processing a Join Query When PC is Used 863 When a node receives a Join Query packet: 865 1. Check if it is a duplicate by comparing the (Source IP Address, 866 Sequence Number) combination with the entries in the message 867 cache. If a duplicate, then discard the packet. DONE. 869 2. If it is not a duplicate, insert an entry into the message cache 870 with the information of the received packet (i.e., sequence 871 number and source IP address) and insert/update the entry for 872 routing table (i.e., backward learning). 874 3. If the node is a member of the multicast group, it originates a 875 Join Reply packet with the RET value enclosed (see Section 5.1.4). 877 4. Increase the Hop Count field by 1 and decrease the TTL field by 1. 879 5. If the TTL field value is less than or equal to 0, then discard 880 the packet. DONE. 882 6. If the TTL field value is greater than 0 and the state of node in the 883 cluster platform is NOT ORDINARY_NODE, then set the node's IP 884 Address into Last Hop IP Address field and broadcast. 885 Otherwise, discard the packet. DONE. 887 5.1.5. Originating a Join Reply 889 A multicast receiver transmits a "Join Reply" packet after selecting 890 the multicast route. Each sender IP address and next hop IP address 891 of a multicast group are contained in the Join Reply packet. The 892 route expiration time is also included if the network hosts operate 893 with GPS. 895 5.1.6. Processing a Join Reply 897 When a Join Reply is received: 899 1. The node looks up the Next Hop IP Address field of the received 900 Join Reply entries. If no entries match the node's IP Address, do 901 nothing. DONE. 903 2. If one or more entries coincide with the node's IP Address, set 904 the FG_FLAG and build its own Join Reply. The next hop IP address 905 can be obtained from the routing table. 907 3. Broadcast the Join Reply packet to the neighbor nodes. DONE. 909 5.1.7. Processing a Join Reply When GPS is Used 911 When a Join Reply is received: 913 1. The node looks up the Next Hop IP Address field of the received 914 Join Reply entries. If no entries match the node's IP Address, do 915 nothing. DONE. 917 2. If one or more entries coincide with the node's IP Address, set 918 the FG_FLAG and build its own Join Reply. If multiple Join Replies 919 with different RET values are received (i.e., the node lies in 920 paths from the same source to multiple receivers), it selects the 921 minimum RET among them and attaches the chosen RET value. Next 922 hop IP address can be obtained from the routing table. 924 3. Broadcast the Join Reply packet to the neighbor nodes. 926 4. If the node is a source, it selects the minimum RET among all the 927 Join Replies received. Then the source can build new routes by 928 flooding a Join Query before the minimum RET approaches (i.e., 929 route breaks of ongoing data sessions are imminent). 931 5.1.8. Processing a Join Reply When PC is Used 933 Same to 5.1.6. 935 5.2. Handling a Multicast Data Packet 937 Multicast sources send the data whenever they have packets to send. 938 Nodes relay data packets only if the packet is not a duplicate and 939 the setting of FG_FLAG for the multicast group has not expired. 941 6. Protocol Applicability 943 6.1. Networking Context 945 ODMRP is best suited for mobile ad hoc wireless networks. 947 6.2. Protocol Characteristics and Mechanisms 949 * Does the protocol provide support for unidirectional links? (if so, 950 how?) 952 - No. We assume bidirectional links. 954 * Does the protocol require the use of tunneling? (if so, how?) 956 - No. 958 * Does the protocol require using some form of source routing? (if 959 so, how?) 961 - No. 963 * Does the protocol require the use of periodic messaging? (if so, 964 how?) 966 - Yes, but only when multicast sources have data packets to send. 968 * Does the protocol require the use of reliable or sequenced packet 969 delivery? (if so, how?) 971 - No. 973 * Does the protocol provide support for routing through a multi- 974 technology routing fabric? (if so, how?) 976 - No. 978 * Does the protocol provide support for multiple hosts per router? 979 (if so, how?) 981 - No. In this document, we assume each mobile host is combined 982 with a router, sharing the same IP address. It is possible, 983 however, to extend the protocol to handle multiple hosts per 984 router. 986 * Does the protocol support the IP addressing architecture? (if so, 987 how?) 989 - Yes. The message contains host IP address as its identification. 991 * Does the protocol require link or neighbor status sensing (if so, 992 how?) 994 - No. 996 * Does the protocol have dependence on a central entity? (if so, 997 how?) 999 - No. 1001 * Does the protocol function reactively? (if so, how?) 1003 - Yes. For example, the source creates and maintains routes and 1004 multicast group membership only when it has data packets to 1005 send. 1007 * Does the protocol function proactively? (if so, how?) 1009 - No. 1011 * Does the protocol provide loop-free routing? (if so, how?) 1013 - Yes. By using the Message Cache, duplicate packets are detected 1014 and packets can only go through the loop-free route. 1016 * Does the protocol provide for sleep period operation? (if so, how?) 1018 - TBD. The work is in progress. 1020 * Does the protocol provide some form of security? (if so, how?) 1022 - TBD. The work is in progress. 1024 * Does the protocol provide support for utilizing multi-channel, 1025 link-layer technologies? (if so, how?) 1027 - This document assumed an arbitrary single channel link-layer 1028 protocol. The protocol can work with any MAC and link-layer 1029 technology. It can also support multi-channel link-layer 1030 technology (e.g., separate channels for data, control packets, 1031 etc.). 1033 Acknowledgments 1035 Authors thank Ching-Chuan Chiang and Guangyu Pei for their initial 1036 contributions. We also send our gratitude to Sang Ho Bae who 1037 implemented ODMRP in a real ad hoc network testbed. 1039 References 1041 [1] P. Agrawal, D.K. Anvekar, and B. Narendran. Optimal 1042 Prioritization of Handovers in Mobile Cellular Networks. In 1043 Proceedings of IEEE PIMRC'94, The Hague, Netherlands, Sep. 1994, 1044 pp. 1393-1398. 1046 [2] R. Bagrodia, R. Meyer, M. Takai, Y. Chen, X. Zeng, J. Martin, 1047 and H.Y. Song. PARSEC: A Parallel Simulation Environment for 1048 Complex Systems. IEEE Computer, vol. 31, no. 10, Oct. 1998, 1049 pp.77-85. 1051 [3] V. Bharghavan, A. Demers, S. Shenker, and L. Zhang. MACAW: A 1052 Media Access Protocol for Wireless LANs. In Proceedings of ACM 1053 SIGCOMM'94, London, UK, Sep. 1994, pp. 212-225. 1055 [4] S. Bradner. Key words for use in RFCs to Indicate 1056 Requirement Levels. RFC 2119, March 1997. 1058 [5] E. Bommaiah, M. Liu, A. McAuley, and R. Talpade. AMRoute: 1059 Adhoc Multicast Routing Protocol. Internet Draft, 1060 draft-talpade-manet-amroute-00.txt, Aug. 1998. Work in progress. 1062 [5] C.-C. Chiang, M. Gerla, and L. Zhang. Forwarding Group 1063 Multicast Protocol (FGMP) for Multihop, Mobile Wireless Networks. 1064 ACM/Baltzer Cluster Computing, vol. 1, no. 2, 1998. 1066 [6] M.S. Corson and S.G. Batsell. A Reservation-Based Multicast 1067 (RBM) Routing Protocol for Mobile Networks: Initial Route 1068 Construction Phase. ACM/Baltzer Wireless Networks, vol. 1, 1069 no. 4, Dec. 1999, pp. 427-450. 1071 [7] J.J. Garcia-Luna-Aceves and E.L. Madruga. A Multicast Routing 1072 Protocol for Ad-Hoc Networks. In Proceedings of IEEE 1073 INFOCOM'99, New York, NY, Mar. 1999, pp. 784-792. 1075 [8] IEEE Computer Society LAN MAN Standards Committee. Wireless 1076 LAN Medium Access Protocol (MAC) and Physical Layer (PHY) 1077 Specification. IEEE std 802.11-1997. The Institute of Electrical 1078 and Electronics Engineers, New York, NY, 1997. 1080 [9] L. Ji and M.S. Corson. A Lightweight Adaptive Multicast 1081 Algorithm. In Proceedings of IEEE GLOBECOM'98, Sydney, 1082 Australia, Nov. 1998, pp. 1036-1042. 1084 [10] J. Jubin and J.D. Tornow. The DARPA Packet Radio Network 1085 Protocols. Proceedings of the IEEE, vol. 75, no. 1, Jan. 1987, 1086 pp. 21-32. 1088 [11] E.D. Kaplan (Editor). Understanding the GPS: Principles and 1089 Applications, Artech House, Boston, MA, Feb. 1996. 1091 [12] L. Kleinrock and J. Silvester. Optimum Transmission Radii for 1092 Packet Radio Networks or Why Six is a Magic Number. In 1093 Proceedings of National Telecommunications Conference, 1094 Birmingham, AL, Dec. 1978, pp. 4.3.2-4.3.5. 1096 [13] L. Kleinrock and F.A. Tobagi. Packet Switching in Radio 1097 Channels: Part I - Carrier Sense Multiple-Access Modes and Their 1098 Throughput-Delay Characteristics. IEEE Transactions on 1099 Communications, vol. COM-23, no. 12, Dec. 1975, pp. 1400-1416. 1101 [14] S.-J. Lee, M. Gerla, and C.-C. Chiang. On-Demand Multicast 1102 Routing Protocol. In Proceedings of IEEE WCNC'99, New Orleans, 1103 LA, Sep. 1999, pp. 1298-1302. 1105 [15] S.-J. Lee, W. Su, and M. Gerla. Ad hoc Wireless Multicast with 1106 Mobility Prediction. In Proceedings of IEEE ICCCN'99, Boston, 1107 MA, Oct. 1999, pp. 4-9. 1109 [16] D.L. Mills. Internet Time Synchronization: the Network Time 1110 Protocol. IEEE Transactions on Communications, vol. 39, no. 10, 1111 Oct. 1991, pp. 1482-1493. 1113 [17] B. Narendran, P. Agrawal, and D.K. Anvekar. Minimizing 1114 Cellular Handover Failures Without Channel Utilization Loss. 1115 In Proceedings of IEEE GLOBECOM'94, San Francisco, CA, 1116 Dec. 1994, pp. 1679-1685. 1118 [18] C.-K. Toh. Associativity-Based Routing for Ad-Hoc Mobile 1119 Networks. Wireless Personal Communications Journal, Special 1120 Issue on Mobile Networking and Computing Systems, Kluwer 1121 Academic Publishers, vol. 4, no. 2, Mar. 1997, pp. 103-139. 1123 [19] UCLA Parallel Computing Laboratory and Wireless Adaptive Mobility 1124 Laboratory. GloMoSim: A Scalable Simulation Environment for 1125 Wireless and Wired Network Systems. 1126 http://pcl.cs.ucla.edu/projects/domains/glomosim.html 1128 [20] UCLA Wireless Adaptive Mobility (WAM) Laboratory. 1129 http://www.cs.ucla.edu/NRL/wireless 1131 [21] Y. Yi, T.-J. Kwon, M. Gerla, Passive Clustering (PC) in Ad Hoc Networks. IETF Draft, draft-yi-manet-pc-00.txt 1133 Chair's Address 1135 The Working Group can be contacted via its current chairs: 1137 M. Scott Corson 1138 Institute for Systems Research 1139 University of Maryland 1140 College Park, MD 20742 1141 USA 1143 Phone: +1 301 405-6630 1144 Email: corson@isr.umd.edu 1146 Joseph Macker 1147 Information Technology Division 1148 Naval Research Laboratory 1149 Washington, DC 20375 1150 USA 1152 Phone: +1 202 767-2001 1153 Email: macker@itd.nrl.navy.mil 1155 Authors' Addresses 1157 Questions about this document can also be directed to the authors: 1159 Yunjung Yi 1160 3771 Boelter Hall 1161 Computer Science Department 1162 University of California 1163 Los Angeles, CA 90095 1164 USA 1166 Phone: +1 310 206-8589 1167 Fax: +1 310 825-7578 1168 Email: yjyi@cs.ucla.edu 1170 Sung-Ju Lee 1171 Internet Systems 1172 Storage Laboratory 1173 Hwelett-Packard Laboratories 1174 1501 Page Mill Road, M/S 1138 1175 Palo Alto, CA 94304 1176 USA 1178 Phone: +1 650 857-3894 1179 Fax: +1 650 857-5100 1180 Email: sjlee@hpl.hp.com 1182 William Su 1183 3771 Boelter Hall 1184 Computer Science Department 1185 University of California 1186 Los Angeles, CA 90095-1596 1187 USA 1189 Phone: +1 310 206-8589 1190 Fax: +1 310 825-7578 1191 Email: wsu@cs.ucla.edu 1193 Mario Gerla 1194 3732F Boelter Hall 1195 Computer Science Department 1196 University of California 1197 Los Angeles, CA 90095-1596 1198 USA 1200 Phone: +1 310 825-4367 1201 Fax: +1 310 825-7578 1202 Email: gerla@cs.ucla.edu