idnits 2.17.1 draft-ietf-manet-odmrp-02.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-19) 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: ---------------------------------------------------------------------------- ** 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 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 238 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 (January 2000) is 8861 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 975, 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' Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 21 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF MANET Working Group Sung-Ju Lee 2 INTERNET-DRAFT William Su 3 Expiration: July 2000 Mario Gerla 4 University of California, Los Angeles 5 January 2000 7 On-Demand Multicast Routing Protocol (ODMRP) for Ad Hoc Networks 9 11 Status of This Memo 13 This document is an Internet-Draft and is NOT offered in accordance 14 with Section 10 of RFC2026, and the author does not provide the IETF 15 with any rights other than to publish as an Internet-Draft. This 16 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 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 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 build 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 4 57 2. Terminology 5 58 2.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 5 59 2.2. Specification Language . . . . . . . . . . . . . . . . . 5 61 3. Protocol Overview 6 62 3.1. Multicast Route and Mesh Creation . . . . . . . . . . . . 6 63 3.2. Reliability . . . . . . . . . . . . . . . . . . . . . . . 8 64 3.3. Soft State . . . . . . . . . . . . . . . . . . . . . . . 10 65 3.4. Selection of Timer Values . . . . . . . . . . . . . . . . 10 66 3.5. Unicast Capability . . . . . . . . . . . . . . . . . . . 10 67 3.6. Contents of Tables . . . . . . . . . . . . . . . . . . . 11 68 3.6.1. Routing Table . . . . . . . . . . . . . . . . . . 11 69 3.6.2. Forwarding Group Table . . . . . . . . . . . . . 11 70 3.6.3. Message Cache . . . . . . . . . . . . . . . . . . 11 71 3.7. Mobility Prediction 12 72 3.7.1. Adapting the Refresh Interval via 73 Mobility Prediction . . . . . . . . . . . . . . . 12 74 3.7.2. Route Selection Criteria . . . . . . . . . . . . 14 75 3.7.3. Alternative Method of Prediction . . . . . . . . 14 77 4. Packet and Table Formats 15 78 4.1. Join Query Packet Header . . . . . . . . . . . . . . . 15 79 4.2. Join Reply Packet . . . . . . . . . . . . . . . . . . . 17 81 5. Operation 19 82 5.1. Forwarding Group Setup . . . . . . . . . . . . . . . . . 19 83 5.1.1. Originating a Join Query . . . . . . . . . . . . 19 84 5.1.2. Processing a Join Query . . . . . . . . . . . . . 19 85 5.1.3. Processing a Join Query When GPS is Used . . . . 20 86 5.1.4. Originating a Join Reply . . . . . . . . . . . . 21 87 5.1.5. Processing a Join Reply . . . . . . . . . . . . . 21 88 5.1.6. Processing a Join Reply When GPS is Used . . . . 21 89 5.2. Handling a Multicast Data Packet . . . . . . . . . . . . 22 91 6. Simulation and Implementation Status 23 93 7. Protocol Applicability 24 94 7.1. Networking Context . . . . . . . . . . . . . . . . . . . . . 24 95 7.2. Protocol Characteristics and Mechanisms . . . . . . . . . . 24 97 Acknowledgments 26 99 References 26 101 Chair's Address 29 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 2. Terminology 142 2.1. General Terms 144 This section defines terminology used in ODMRP. 146 node 148 A device that implements IP. 150 neighbor 152 Nodes that are within the radio transmission range. 154 forwarding group 156 A group of nodes participating in multicast packet forwarding. 158 multicast mesh 160 The topology defined by the link connection between forwarding 161 group members. 163 join query 165 The special data packet sent by multicast sources to establish 166 and update group memberships and routes. 168 join reply 170 The table broadcasted by each multicast receiver and forwarding 171 node to establish and update group membership and routes 173 2.2. Specification Language 175 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 177 document are to be interpreted as described in RFC 2119 [4]. 179 3. Protocol Overview 181 3.1. Multicast Route and Mesh Creation 183 In ODMRP, group membership and multicast routes are established and 184 updated by the source on demand. Similar to on-demand unicast 185 routing protocols, a request phase and a reply phase comprise the 186 protocol. When a multicast source has packets to send but no route 187 and group membership is known, it floods a member advertising packet 188 with data payload piggybacked. This packet, called "Join Query" 189 (format shown in Section 4.1) is periodically broadcasted to the 190 entire network to refresh the membership information and update the 191 routes. When a node receives a Join Query packet, it stores the 192 source address and the unique identifier of the packet to its 193 "Message Cache" to detect duplicates. The upstream node address is 194 inserted or updated as the next node for the source node in its 195 "Routing Table." If the Join Query packet is not a duplicate and 196 the Time-To-Live value is greater than zero, appropriate fields are 197 updated and it is rebroadcast (operation details are illustrated 198 in Section 5.1.2). 200 When a Join Query packet reaches the multicast receiver, it creates 201 and broadcasts a "Join Reply" to its neighbors. When a node receives 202 a Join Reply, it checks if the next node address of one of the 203 entries matches its own address. If it does, the node realizes that 204 it is on the path to the source and thus is part of the forwarding 205 group; it sets the FG_FLAG (Forwarding Group Flag). It then 206 broadcasts its own Join Reply built upon matched entries. The next 207 node address field is filled in by extracting the information from 208 its routing table. This way, the Join Reply is propagated by each 209 forward group member until it reaches the multicast source via the 210 selected path. This process constructs (or updates) the routes from 211 sources to receivers and builds a mesh of nodes, the forwarding 212 group. 214 +--+ +--+ +--+ 215 |S1|-------|I1|-------|R1| 216 +--+\ +--+ /+--+ Join Replies of Node R1 and Node I1 217 \ / +----------------+ +----------------+ 218 \ / |Sender|Next Node| |Sender|Next Node| 219 \ / |------+---------| |------+---------| 220 \ / | S1 | I1 | | S1 | S1 | 221 \ / |------+---------| +----------------+ 222 +--+ \+--+/ +--+ | S2 | I2 | 223 |S2|-------|I2|-------|R2| +----------------+ 224 +--+ +--+ +--+ 226 Let us consider the above figure as an example of Join Reply 227 forwarding process. Nodes S1 and S2 are multicast sources, and nodes 228 R1 and R2 are multicast receivers. Node R2 sends its Join Reply to 229 both S1 and S2 via I2, and R1 sends its packet to S1 via I1 and to 230 S2 via I2. When receivers send their Join Replies to next hop nodes, 231 an intermediate node I1 sets the FG_FLAG and builds its own Join 232 Reply since there is a next node ID entry in the Join Reply received 233 from R1 that matches its ID. Note that the Join Reply built by I1 234 has an entry for sender S1 but not for S2 because the next node 235 address for S2 in the received Join Reply is not I1. In the 236 meanwhile, node I2 sets the FG_FLAG, constructs its own Join Reply 237 and sends it to its neighbors. Note that I2 broadcasts the Join 238 Reply only once even though it receives two Join Replies from the 239 receivers because the second table arrival carries no new source 240 information. Channel overhead is thus reduced dramatically in cases 241 where numerous multicast receivers share the same links to the 242 source. 244 After this group establishment and route construction process, a 245 source can multicast packets to receivers via selected routes and 246 forwarding groups. While outgoing data packets exist, the source 247 sends Join Query every REFRESH_INTERVAL. This Join Query and Join 248 Reply propagation process refreshes forwarding group and routes. 249 When receiving the multicast data packet, a node forwards it only 250 when it is not a duplicate and the setting of the FG_FLAG for the 251 multicast group has not expired. This procedure minimizes the 252 traffic overhead and prevents sending packets through stale routes. 254 3.2. Reliability 256 The reliable transmission of Join Replies plays an important role 257 in establishing and refreshing multicast routes and forwarding 258 groups. Hence, if Join Replies are not properly delivered, 259 effective multicast routing cannot be achieved by ODMRP. The IEEE 260 802.11 MAC (Medium Access Control) protocol [8], which is the 261 emerging standard in wireless networks, performs reliable 262 transmission by retransmitting the packet if no acknowledgment is 263 received. However, if the packet is broadcasted, no acknowledgments 264 or retransmissions are sent. In ODMRP, the transmission of Join 265 Replies are often broadcasted to more than one upstream neighbors 266 since we are handling multiple sources (e.g., see the Join Reply 267 from node R1 in the example of Section 3.1.). In such cases, the 268 hop-by-hop verification of Join Reply delivery and the 269 retransmission cannot be handled by the MAC layer. It must be done 270 indirectly by ODMRP. Another option for reliable delivery is to 271 subdivide the Join Reply into separate sub-tables, one for each 272 distinct next node. In the figure of Section 3.1. for example, the 273 Join Reply at node R1 is split into two Join Replies, one for 274 neighbor I1 and the other for neighbor I2. These Join Replies are 275 separately unicasted using a reliable MAC protocol such as IEEE 276 802.11 or MACAW [3]. Since the number of neighbors is generally 277 limited (typically, about six neighbors in the optimum in a 278 multihop network [12]), the scheme still scales well to large number 279 of sources. This option can actually be used as backup to the 280 passive acknowledgment option as discussed below. 282 We adopt a scheme that was used in [10]. When a node transmits a 283 Join Reply packet to the immediate upstream node of the route, the 284 immediate downstream node can hear the transmission if it is 285 within the transmitter's radio range. Hence, the packet is used as 286 an "passive acknowledgment." We can utilize this passive 287 acknowledgment to verify the delivery of a Join Reply. Note that 288 the source itself must send an active acknowledgment to the 289 previous hop since it does not have any next hop to send a Join 290 Reply to unless it is also a forwarding group node for other 291 sources. 293 Considering the case in figure of Section 3.1. again, we note that 294 once the nodes I1 and I2 receive the Join Reply from node R1, they 295 will construct and forward their own Join Replies to next hops (in 296 this case, sources S1 and S2). In transmitting their Join Replies, 297 nodes I1 and I2 may overlap with each other. If I1 and I2} are 298 within receiving range, they will recover because of the carrier 299 sense feature in CSMA (Carrier Sense Multiple Access) [13]. However, 300 if they are out of range, they will be unaware of the "hidden 301 terminal" condition of node R1, which cannot hear the (overlapped) 302 passive acknowledgments. Thus, a node may not hear the passive 303 acknowledgments of its upstream neighbor because of conflicts due 304 to the hidden terminal problem. It will also not hear the passive 305 acknowledgment if the upstream neighbor has moved away. In either 306 case, when no acknowledgment is received within the timeout 307 interval, the node retransmits the message. Note that the node may 308 get acknowledgments from some, but not all upstream neighbors. As 309 an option, the retransmission could be carried out in unicast mode, 310 to selected neighbors, with reduced sub-tables. If packet delivery 311 cannot be verified after an appropriate number of retransmissions, 312 the node considers the route to be invalidated. At this point, the 313 most likely cause of route failure is the fact that a node on the 314 route has failed or has moved out of range. An alternate route must 315 be found "on the spot." The node thus broadcasts a message to its 316 neighbors specifying that the next hop to a set of sources cannot 317 be reached. Upon receiving this packet, each neighbor builds and 318 unicasts the Join Reply to its next hop if it has a route to the 319 multicast sources. If no route is known, it simply broadcasts the 320 packet specifying the next hop is not available. In both cases, the 321 node sets its FG_FLAG. In practical implementations, this 322 redundancy is sufficient to establish alternate paths until a more 323 efficient route is established during the next refresh phase. The 324 FG_FLAG setting of every neighbor may create excessive redundancy, 325 but most of these settings will expire because only necessary 326 forwarding group nodes will be refreshed in the next Join Reply 327 propagation phase. 329 3.3. Soft State 331 In ODMRP, no explicit control packets need to be sent to leave the 332 group. If a multicast source wants to leave the group, it simply 333 stops sending any Join Query packets since it does not have any 334 multicast data to send to the group. If a receiver no longer wants 335 to receive from a particular multicast group, it does not send the 336 Join Reply for that group. Nodes in the forwarding group are demoted 337 to non-forwarding nodes if not refreshed (no Join Replies received) 338 before they timeout. 340 3.4. Selection of Timer Values 342 Timer values for route refresh interval and forwarding group 343 timeout interval can have impacts on ODMRP performance. The 344 selection of these soft state timers should be adaptive to network 345 environment (e.g., traffic type, traffic load, mobility pattern, 346 mobility speed, channel capacity, etc.). When small route refresh 347 interval values are used, fresh route and membership information 348 can be obtained frequently at the expense of producing more packets 349 and causing network congestion. On the other hand, when large route 350 refresh values are selected, even though less control traffic will 351 be generated, nodes may not know up-to-date route and multicast 352 membership. Thus in highly mobile networks, using large route 353 refresh interval values can yield poor protocol performance. The 354 forwarding group timeout interval should also be carefully 355 selected. In networks with heavy traffic load, small values should 356 be used so that unnecessary nodes can timeout quickly and not 357 create excessive redundancy. In situations with high mobility, 358 however, large values should be chosen so that more alternative 359 paths can be provided. It is important to note that the forwarding 360 group timeout value must be larger (e.g., 3 to 5 times) than the 361 value of route refresh interval. 363 3.5. Unicast Capability 365 One of the major strengths of ODMRP is its unicast routing 366 capability. Not only can ODMRP coexist with any unicast routing 367 protocol, it can also operate very efficiently as an unicast 368 routing protocol. Thus, a network equipped with ODMRP does not 369 require a separate unicast protocol. Other ad hoc multicast routing 370 protocols such as AMRoute [5], CAMP [7], RBM [6], and LAM [9] 371 must be run on top of a unicast routing protocol. CAMP, RBM, and 372 LAM in particular, only work with certain underlying unicast 373 protocols. 375 3.6. Contents of Tables 377 Nodes running ODMRP are required to maintain the following tables. 378 These tables MAY be implemented in any format, but MUST include the 379 fields specified in this document. 381 3.6.1. Routing Table 383 A routing table is created on demand and is maintained by each node. 384 An entry is inserted or updated when a non-duplicate Join Query is 385 received. The node stores the destination (i.e., the source of the 386 Join Query) and the next hop to the destination (i.e., the last 387 node that propagated the Join Query). The routing table provides 388 the next hop information when transmitting Join Replies. 390 3.6.2. Forwarding Group Table 392 When a node is a forwarding group node of the multicast group, it 393 maintains the group information in the forwarding group table. The 394 multicast group ID and the time when the node was last refreshed 395 are recorded. 397 3.6.3. Message Cache 399 The message cache is maintained by each node to detect duplicates. 400 When a node receives a new Join Query or data, it stores the source 401 address and the unique identifier of the packet. Note that entries 402 in the message cache need not be maintained permanently. Schemes 403 such as LRU (Least Recently Used) or FIFO (First In First Out) can 404 be employed to expire and remove old entries and prevent the size 405 of the message cache to be extensive. 407 3.7. Mobility Prediction 409 3.7.1 Adapting the Refresh Interval via Mobility Prediction 411 ODMRP requires periodic flooding of Join Query to build and refresh 412 routes. Excessive flooding, however, is not desirable in ad hoc 413 networks because of bandwidth constraints. Furthermore, flooding 414 often causes congestion, contention, and collisions. Finding the 415 optimal flooding interval is critical in ODMRP performance. In 416 highly mobile networks where nodes are equipped with GPS [11] (e.g., 417 tactical networks with tanks, ships, aircrafts, etc.), we can 418 efficiently adapt the REFRESH_INTERVAL to mobility patterns and 419 speeds by utilizing the location and movement information. We use 420 the location and movement information to predict the duration 421 of time routes will remain valid. With the predicted time of route 422 disconnection, Join Queries are only flooded when route breaks of 423 ongoing data sessions are imminent. Note that ODMRP can still 424 operate efficiently in networks where no such information is 425 available, but the protocol can be further improved if those 426 information can be utilized. 428 In our prediction method, we assume a free space propagation model, 429 where the received signal strength solely depends on its distance 430 to the transmitter. We also assume that all nodes in the network 431 have their clock synchronized (e.g., by using the NTP (Network Time 432 Protocol) [16] or the GPS clock itself). Therefore, if the motion 433 parameters of two neighbors (e.g., speed, direction, radio 434 propagation range, etc.) are known, we can determine the duration 435 of time these two nodes will remain connected. Assume two nodes i 436 and j are within the transmission range r of each other. Let 437 (x_{i}, y_{i}) be the coordinate of node i and (x_{j}, y_{j}) be 438 that of node j. Also let v_{i} and v_{j} be the speeds, and 439 theta_{i} and theta_{j} (0 <= theta_{i}, theta_{j} < 2 * pi) be the 440 moving directions of nodes i and j, respectively. Then, the 441 duration of time that the link between two nodes will stay 442 connected, D_{t}, is given by: 444 -(a*b + c*d) + sqrt((a^{2} + c^{2})*r^{2} - (a*d - b*c)^{2}) 445 D_{t} = ------------------------------------------------------------ 446 a^{2} + c^{2} 448 where 449 a = v_{i}*cos(theta_{i}) - v_{j}*cos(theta_{j}), 450 b = x_{i} - x_{j}, 451 c = v_{i}*sin(theta_{i}) - v_{j}*sin(theta_{j}), and 452 d = y_{i} - y_{j}. 454 Note that when v_{i} = v_{j} and theta_{i} = theta_{j}, D_{t} is 455 set to infinity without applying the above equation. 457 To utilize the information obtained from the prediction, extra 458 fields must be added into Join Query and Join Reply packets. When a 459 source sends Join Query, it appends its location, speed, and 460 direction. It sets the MIN_LET (Minimum Link Expiration Time) field 461 to the MAX_LET_VALUE since the source does not have any previous 462 hop node. The next hop neighbor, upon receiving a Join Query, 463 predicts the link expiration time between itself and the previous 464 hop using the above equation. The minimum between this value and 465 the MIN_LET indicated by the Join Query is included in the packet. 466 The rationale is that as soon as a single link on a path is 467 disconnected, the entire path is invalidated. The node also 468 overwrites the location and mobility information field written by 469 the previous node with its own information. When a multicast member 470 receives the Join Query, it calculates the predicted LET of the 471 last link of the path. The minimum between the last link expiration 472 time and the MIN_LET value specified in the Join Query is the RET 473 (Route Expiration Time). This RET value is enclosed in the Join 474 Reply and broadcasted. If a forwarding group node receives multiple 475 Join Replies with different RET values (i.e., lies in paths from 476 the same source to multiple receivers), it selects the minimum RET 477 among them and sends its own Join Reply with the chosen RET value 478 attached. When the source receives Join Replies, it selects the 479 minimum RET among all the Join Replies received. Then the source 480 can build new routes by flooding a Join Query before the minimum 481 RET approaches (i.e., route breaks). 483 In addition to the estimated RET value, other factors need to be 484 considered when choosing the refresh interval. If the node mobility 485 rate is high and the topology changes frequently, routes will 486 expire quickly and often. The source may propagate Join Query 487 excessively and this excessive flooding can cause collisions and 488 congestion, and clogs the network with control packets. Thus, the 489 MIN_REFRESH_INTERVAL should be enforced to avoid control message 490 overflow. On the other hand, if nodes are stationary or move slowly 491 and link connectivity remains unchanged for a long duration of time, 492 routes will hardly expire and the source will rarely send Join 493 Query. A few problems arise in this situation. First, if a node in 494 the route suddenly changes its movement direction or speed, the 495 predicted RET value becomes obsolete and routes will not be 496 reconstructed in time. Second, when a non-member node which is 497 located remotely to multicast members wants to join the group, 498 it cannot inform the new membership or receive data until a Join 499 Query is received. Hence, the MAX_REFRESH_INTERVAL should be set. 500 The selection of the MIN_REFRESH_INTERVAL and the 501 MAX_REFRESH_INTERVAL values should be adaptive to network 502 environments. 504 3.7.2. Route Selection Criteria 506 In ODMRP, a multicast receiver selects routes based on the minimum 507 delay (i.e., routes taken by the first Join Query received. A 508 different route selection method is applied when we use the 509 mobility prediction. The idea is inspired by the Associativity-Based 510 Routing (ABR) protocol [18] which chooses associatively stable 511 routes. In our algorithm, instead of using the minimum delay path, 512 we can choose a route that is the most stable (i.e., the one that 513 will remain connected for the longest duration of time). To select 514 a route, a multicast receiver must wait for an appropriate amount of 515 time after receiving the first Join Query so that all possible 516 routes and their route qualities will be known. The receiver then 517 chooses the most stable route and broadcasts a Join Reply. Route 518 breaks will occur less often and the number of Join Query 519 propagation will reduce because stable routes are used. 521 3.7.3. Alternative Method of Prediction 523 Since GPS may not work properly in certain situations (e.g., 524 indoor, fading, etc.), we may not always be able to accurately 525 predict the link expiration time for a particular link. However, 526 there is an alternative method to predict the LET. This method is 527 based on a more realistic propagation model and has been proposed 528 in [1] and [17]. Basically, transmission power samples are measured 529 periodically from packets received from a mobile's neighbor. From 530 this information it is possible to compute the rate of change for a 531 particular neighbor's transmission power level. Therefore, the time 532 when the transmission power level will drop below the acceptable 533 value (i.e., hysteresis region) can be predicted. We plan to 534 investigate this option in our future work. 536 4. Packet and Table Formats 538 4.1. Join Query Packet Header 540 0 1 2 3 541 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 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Type | Reserved | Time To Live | Hop Count | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | Multicast Group IP Address | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | Sequence Number | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | Source IP Address | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Previous Hop IP Address | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | Previous Hop X Coordinate | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | Previous Hop Y Coordinate | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | Previous Hop Moving Speed | Previous Hop Moving Direction | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | Minimum Link Expiration Time | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 Type 564 01; ODMRP Join Query. 566 Reserved 568 Sent as 0; ignored on reception. 570 Time To Live 572 Number of hops this packet can traverse. 574 Hop Count 576 The number of hops traveled so far by this packet. 578 Multicast Group IP Address 580 The IP address of the multicast group. 582 Sequence Number 584 The sequence number assigned by the source to uniquely 585 identify the packet. 587 Source IP Address 589 The IP address of the node originating the packet. 591 Previous Hop IP Address 593 The IP address of the last node that has processed this packet. 595 Previous Hop X Coordinate (Optional) 597 The x-coordinate of the last node that has processed this 598 packet. The information can be obtained from the GPS. This 599 field is required only when network hosts are GPS equipped. 601 Previous Hop Y Coordinate (Optional) 603 The y-coordinate of the last node that has processed this 604 packet. The information can be obtained from the GPS. This 605 field is required only when network hosts are GPS equipped.. 607 Previous Hop Moving Speed (Optional) 609 The mobility speed of the last node that has processed this 610 packet. The information can be obtained from the GPS or the 611 node's own instruments and sensors (e.g., campus, odometer, 612 speed sensors, etc.). This field is required only when network 613 hosts are GPS equipped. 615 Previous Hop Moving Direction (Optional) 617 The moving direction of the last node that has processed this 618 packet. The information can be obtained from the GPS or the 619 node's own instruments and sensors (e.g., campus, odometer, 620 speed sensors, etc.). This field is required only when network 621 hosts are GPS equipped. 623 Minimum Link Expiration Time (Optional) 625 The minimum expiration time among the links taken by this 626 packet so far. This field is required only when network hosts 627 are GPS equipped. 629 4.2. Join Reply Packet 631 0 1 2 3 632 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 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | Type | Count |R|F| Reserved | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | Multicast Group IP Address | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | Previous Hop IP Address | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | Sequence Number | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | Sender IP Address [1] | 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | Next Hop IP Address [1] | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | Route Expiration Time [1] | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | : | 649 | : | 650 | : | 651 | : | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | Sender IP Address [n] | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | Next Hop IP Address [n] | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | Route Expiration Time [n] | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 Type 662 02; ODMRP Join Reply. 664 Count 666 Number of (Sender IP Address, Next Hop IP Address) 667 combinations. 669 R 671 Acknowledgment request flag. This flag is set when active 672 acknowledgment packet is requested. 674 F 676 Forwarding group flag. This flag is set when the packet is 677 transmitted by a forwarding group node. 679 Reserved 681 Sent as 0; ignored on reception. 683 Multicast Group IP address 685 The IP address of the multicast group. 687 Previous Hop IP Address 689 The IP address of the last node that has processed this packet. 691 Sequence Number 693 The sequence number assigned by the previous hop node to 694 uniquely identify the packet. 696 Sender IP Address [1..n] 698 The IP addresses of the sources of this multicast group. 700 Next Hop IP Address [1..n] 702 The IP addresses of next nodes that this packet is target to. 704 Route Expiration Time [1..n] (Optional) 706 The minimum route expiration times of this multicast group. 707 This field is required only when network hosts are GPS equipped. 709 5. Operation 711 5.1. Forwarding Group Setup 713 5.1.1. Originating a Join Query 715 When a multicast source has data packets to send but no route is 716 known, it originates a "Join Query" packet. The Type field MUST be 717 set to 01. TTL MAY be set to TIME_TO_LIVE_VALUE, but SHOULD be 718 adjusted based on network size and network diameter. The Sequence 719 Number MUST be large enough to prevent wraparound ambiguity, and the 720 Hop Count is initially set to zero. The source puts its IP address 721 in the Source IP Address and Last Hop IP Address field. It appends 722 its location, speed, and direction into Join Query if nodes in the 723 network are equipped with GPS. 725 When location and movement information is utilized, it sets the 726 MIN_LET (Link Expiration Time) field to the MAX_LET_VALUE since the 727 source does not have any previous hop node. When the source receives 728 Join Replies from multicast receivers, it selects the minimum RET 729 (Route Expiration Time) among all the Join Replies received. Then the 730 source can build new routes by originating a Join Query before the 731 minimum RET approaches (i.e., route breaks of ongoing data sessions 732 are imminent). 734 5.1.2. Processing a Join Query 736 When a node receives a Join Query packet: 738 1. Check if it is a duplicate by comparing the (Source IP Address, 739 Sequence Number) combination with the entries in the message 740 cache. If a duplicate, then discard the packet. DONE. 742 2. If it is not a duplicate, insert an entry into the message cache 743 with the information of the received packet (i.e., sequence 744 number and source IP address) and insert/update the entry for 745 routing table (i.e., backward learning). 747 3. If the node is a member of the multicast group, it originates a 748 Join Reply packet with the RET value enclosed (see Section 5.1.4). 750 4. Increase the Hop Count field by 1 and decrease the TTL field by 1. 752 5. If the TTL field value is less than or equal to 0, then discard 753 the packet. DONE. 755 6. If the TTL field value is greater than 0, then set the node's IP 756 Address into Last Hop IP Address field and broadcast. DONE. 758 5.1.3. Processing a Join Query When GPS is Used 760 When a node receives a Join Query packet: 762 1. Check if it is a duplicate by comparing the (Source IP Address, 763 Sequence Number) combination with the entries in the message 764 cache. If a duplicate, then discard the packet. DONE. 766 2. If it is not a duplicate, insert an entry into the message cache 767 with the information of the received packet (i.e., sequence 768 number and source IP address) and insert/update the entry for 769 routing table (i.e., backward learning). 771 3. Predict the duration of time the link between the node and the 772 upstream node will remain connected using the equation given in 773 Section 3.7.1. 775 The minimum between the newly obtained D_{t} value and the 776 indicated value in MIN_LET field of the Join Query is included in 777 the packet. The rationale is that as soon as a single link on the 778 path is disconnected, the entire path is invalidated. The node 779 also overwrites the location and mobility information field 780 written by the previous node with its own information. 782 4. If the node is a member of the multicast group, it calculates the 783 predicted LET of the last link of the path. The minimum between 784 the last link expiration time and the MIN_LET value specified in 785 the Join Query is the RET (Route Expiration Time). 787 To select a route, a multicast receiver must wait for an 788 appropriate amount of time after receiving the first Join Query 789 so that all possible routes and their RET will be known. The 790 receiver then chooses the most stable route (i.e., the route with 791 the largest RET) and originates a Join Reply packet with the RET 792 value enclosed (see Section 5.1.3.). 794 5. Increase the Hop Count field by 1 and decrease the TTL field by 1. 796 6. If the TTL field value is less than or equal to 0, then discard 797 the packet. DONE. 799 7. If the TTL field value is greater than 0, then set the node's IP 800 Address into Last Hop IP Address field and broadcast. DONE. 802 5.1.4. Originating a Join Reply 804 A multicast receiver transmits a "Join Reply" packet after selecting 805 the multicast route. Each sender IP address and next hop IP address 806 of a multicast group are contained in the Join Reply packet. The 807 route expiration time is also included if the network hosts operate 808 with GPS. 810 5.1.5. Processing a Join Reply 812 When a Join Reply is received: 814 1. The node looks up the Next Hop IP Address field of the received 815 Join Reply entries. If no entries match the node's IP Address, do 816 nothing. DONE. 818 2. If one or more entries coincide with the node's IP Address, set 819 the FG_FLAG and build its own Join Reply. The next hop IP address 820 can be obtained from the routing table. 822 3. Broadcast the Join Reply packet to the neighbor nodes. DONE. 824 5.1.6. Processing a Join Reply When GPS is Used 826 When a Join Reply is received: 828 1. The node looks up the Next Hop IP Address field of the received 829 Join Reply entries. If no entries match the node's IP Address, do 830 nothing. DONE. 832 2. If one or more entries coincide with the node's IP Address, set 833 the FG_FLAG and build its own Join Reply. If multiple Join Replies 834 with different RET values are received (i.e., the node lies in 835 paths from the same source to multiple receivers), it selects the 836 minimum RET among them and attaches the chosen RET value. Next 837 hop IP address can be obtained from the routing table. 839 3. Broadcast the Join Reply packet to the neighbor nodes. 841 4. If the node is a source, it selects the minimum RET among all the 842 Join Replies received. Then the source can build new routes by 843 flooding a Join Query before the minimum RET approaches (i.e., 844 route breaks of ongoing data sessions are imminent). 846 5.2. Handling a Multicast Data Packet 848 Multicast sources send the data whenever they have packets to send. 849 Nodes relay data packets only if the packet is not a duplicate and 850 the setting of FG_FLAG for the multicast group has not expired. 852 6. Simulation and Implementation Status 854 ODMRP has been implemented in both simulation and real ad hoc 855 network testbed. For simulation, the protocols is implemented 856 within the GloMoSim library [19], which is written in PARSEC[1]. 857 As for the real system implementation, ODMRP is developed on Linux 858 kernel version 2.0.36, the kernel version provided by the Red Hat 859 Linux version 5.2. All tools and software packages that are used 860 in our development originate from software bundle incorporated 861 within the Red Hat Linux version 5.2 operating system package with 862 the singular exception of Lucent WaveLan IEEE 802.11 device driver. 864 The papers presenting our simulation results and working wireless 865 testbed implementation can be downloaded from the following 866 website: 868 http://www.cs.ucla.edu/NRL/wireless 870 7. Protocol Applicability 872 7.1. Networking Context 874 ODMRP is best suited for mobile ad hoc wireless networks. 876 7.2. Protocol Characteristics and Mechanisms 878 * Does the protocol provide support for unidirectional links? (if so, 879 how?) 881 - No. We assume bidirectional links. 883 * Does the protocol require the use of tunneling? (if so, how?) 885 - No. 887 * Does the protocol require using some form of source routing? (if 888 so, how?) 890 - No. 892 * Does the protocol require the use of periodic messaging? (if so, 893 how?) 895 - Yes, but only when multicast sources have data packets to send. 897 * Does the protocol require the use of reliable or sequenced packet 898 delivery? (if so, how?) 900 - No. 902 * Does the protocol provide support for routing through a multi- 903 technology routing fabric? (if so, how?) 905 - No. 907 * Does the protocol provide support for multiple hosts per router? 908 (if so, how?) 910 - No. In this document, we assume each mobile host is combined 911 with a router, sharing the same IP address. It is possible, 912 however, to extend the protocol to handle multiple hosts per 913 router. 915 * Does the protocol support the IP addressing architecture? (if so, 916 how?) 918 - Yes. The message contains host IP address as its identification. 920 * Does the protocol require link or neighbor status sensing (if so, 921 how?) 923 - No. 925 * Does the protocol have dependence on a central entity? (if so, 926 how?) 928 - No. 930 * Does the protocol function reactively? (if so, how?) 932 - Yes. For example, the source creates and maintains routes and 933 multicast group membership only when it has data packets to 934 send. 936 * Does the protocol function proactively? (if so, how?) 938 - No. 940 * Does the protocol provide loop-free routing? (if so, how?) 942 - Yes. By using the Message Cache, duplicate packets are detected 943 and packets can only go through the loop-free route. 945 * Does the protocol provide for sleep period operation? (if so, how?) 947 - TBD. The work is in progress. 949 * Does the protocol provide some form of security? (if so, how?) 951 - TBD. The work is in progress. 953 * Does the protocol provide support for utilizing multi-channel, 954 link-layer technologies? (if so, how?) 956 - This document assumed an arbitrary single channel link-layer 957 protocol. The protocol can work with any MAC and link-layer 958 technology. It can also support multi-channel link-layer 959 technology (e.g., separate channels for data, control packets, 960 etc.). 962 Acknowledgments 964 Authors thank Ching-Chuan Chiang and Guangyu Pei for their initial 965 contributions. We also send our gratitude to Sang Ho Bae who 966 implemented ODMRP in a real ad hoc network testbed. 968 References 970 [1] P. Agrawal, D.K. Anvekar, and B. Narendran. Optimal 971 Prioritization of Handovers in Mobile Cellular Networks. In 972 Proceedings of IEEE PIMRC'94, The Hague, Netherlands, Sep. 1994, 973 pp. 1393-1398. 975 [2] R. Bagrodia, R. Meyer, M. Takai, Y. Chen, X. Zeng, J. Martin, 976 and H.Y. Song. PARSEC: A Parallel Simulation Environment for 977 Complex Systems. IEEE Computer, vol. 31, no. 10, Oct. 1998, 978 pp.77-85. 980 [3] V. Bharghavan, A. Demers, S. Shenker, and L. Zhang. MACAW: A 981 Media Access Protocol for Wireless LANs. In Proceedings of ACM 982 SIGCOMM'94, London, UK, Sep. 1994, pp. 212-225. 984 [4] S. Bradner. Key words for use in RFCs to Indicate 985 Requirement Levels. RFC 2119, March 1997. 987 [5] E. Bommaiah, M. Liu, A. McAuley, and R. Talpade. AMRoute: 988 Adhoc Multicast Routing Protocol. Internet Draft, 989 draft-talpade-manet-amroute-00.txt, Aug. 1998. Work in progress. 991 [5] C.-C. Chiang, M. Gerla, and L. Zhang. Forwarding Group 992 Multicast Protocol (FGMP) for Multihop, Mobile Wireless Networks. 993 ACM/Baltzer Cluster Computing, vol. 1, no. 2, 1998. 995 [6] M.S. Corson and S.G. Batsell. A Reservation-Based Multicast 996 (RBM) Routing Protocol for Mobile Networks: Initial Route 997 Construction Phase. ACM/Baltzer Wireless Networks, vol. 1, 998 no. 4, Dec. 1999, pp. 427-450. 1000 [7] J.J. Garcia-Luna-Aceves and E.L. Madruga. A Multicast Routing 1001 Protocol for Ad-Hoc Networks. In Proceedings of IEEE 1002 INFOCOM'99, New York, NY, Mar. 1999, pp. 784-792. 1004 [8] IEEE Computer Society LAN MAN Standards Committee. Wireless 1005 LAN Medium Access Protocol (MAC) and Physical Layer (PHY) 1006 Specification. IEEE std 802.11-1997. The Institute of Electrical 1007 and Electronics Engineers, New York, NY, 1997. 1009 [9] L. Ji and M.S. Corson. A Lightweight Adaptive Multicast 1010 Algorithm. In Proceedings of IEEE GLOBECOM'98, Sydney, 1011 Australia, Nov. 1998, pp. 1036-1042. 1013 [10] J. Jubin and J.D. Tornow. The DARPA Packet Radio Network 1014 Protocols. Proceedings of the IEEE, vol. 75, no. 1, Jan. 1987, 1015 pp. 21-32. 1017 [11] E.D. Kaplan (Editor). Understanding the GPS: Principles and 1018 Applications, Artech House, Boston, MA, Feb. 1996. 1020 [12] L. Kleinrock and J. Silvester. Optimum Transmission Radii for 1021 Packet Radio Networks or Why Six is a Magic Number. In 1022 Proceedings of National Telecommunications Conference, 1023 Birmingham, AL, Dec. 1978, pp. 4.3.2-4.3.5. 1025 [13] L. Kleinrock and F.A. Tobagi. Packet Switching in Radio 1026 Channels: Part I - Carrier Sense Multiple-Access Modes and Their 1027 Throughput-Delay Characteristics. IEEE Transactions on 1028 Communications, vol. COM-23, no. 12, Dec. 1975, pp. 1400-1416. 1030 [14] S.-J. Lee, M. Gerla, and C.-C. Chiang. On-Demand Multicast 1031 Routing Protocol. In Proceedings of IEEE WCNC'99, New Orleans, 1032 LA, Sep. 1999, pp. 1298-1302. 1034 [15] S.-J. Lee, W. Su, and M. Gerla. Ad hoc Wireless Multicast with 1035 Mobility Prediction. In Proceedings of IEEE ICCCN'99, Boston, 1036 MA, Oct. 1999, pp. 4-9. 1038 [16] D.L. Mills. Internet Time Synchronization: the Network Time 1039 Protocol. IEEE Transactions on Communications, vol. 39, no. 10, 1040 Oct. 1991, pp. 1482-1493. 1042 [17] B. Narendran, P. Agrawal, and D.K. Anvekar. Minimizing 1043 Cellular Handover Failures Without Channel Utilization Loss. 1044 In Proceedings of IEEE GLOBECOM'94, San Francisco, CA, 1045 Dec. 1994, pp. 1679-1685. 1047 [18] C.-K. Toh. Associativity-Based Routing for Ad-Hoc Mobile 1048 Networks. Wireless Personal Communications Journal, Special 1049 Issue on Mobile Networking and Computing Systems, Kluwer 1050 Academic Publishers, vol. 4, no. 2, Mar. 1997, pp. 103-139. 1052 [19] UCLA Parallel Computing Laboratory and Wireless Adaptive Mobility 1053 Laboratory. GloMoSim: A Scalable Simulation Environment for 1054 Wireless and Wired Network Systems. 1055 http://pcl.cs.ucla.edu/projects/domains/glomosim.html 1057 [20] UCLA Wireless Adaptive Mobility (WAM) Laboratory. 1058 http://www.cs.ucla.edu/NRL/wireless 1060 Chair's Address 1062 The Working Group can be contacted via its current chairs: 1064 M. Scott Corson 1065 Institute for Systems Research 1066 University of Maryland 1067 College Park, MD 20742 1068 USA 1070 Phone: +1 301 405-6630 1071 Email: corson@isr.umd.edu 1073 Joseph Macker 1074 Information Technology Division 1075 Naval Research Laboratory 1076 Washington, DC 20375 1077 USA 1079 Phone: +1 202 767-2001 1080 Email: macker@itd.nrl.navy.mil 1082 Authors' Addresses 1084 Questions about this document can also be directed to the authors: 1086 Sung-Ju Lee 1087 3771 Boelter Hall 1088 Computer Science Department 1089 University of California 1090 Los Angeles, CA 90095-1596 1091 USA 1093 Phone: +1 310 206-8589 1094 Fax: +1 310 825-7578 1095 Email: sjlee@cs.ucla.edu 1097 William Su 1098 3771 Boelter Hall 1099 Computer Science Department 1100 University of California 1101 Los Angeles, CA 90095-1596 1102 USA 1104 Phone: +1 310 206-8589 1105 Fax: +1 310 825-7578 1106 Email: wsu@cs.ucla.edu 1108 Mario Gerla 1109 3732F Boelter Hall 1110 Computer Science Department 1111 University of California 1112 Los Angeles, CA 90095-1596 1113 USA 1115 Phone: +1 310 825-4367 1116 Fax: +1 310 825-7578 1117 Email: gerla@cs.ucla.edu