INTERNET-DRAFT Zygmunt J. Haas, Cornell University Marc R. Pearlman, Cornell University Prince Samar, Cornell University Expires in six months on January 2003 July 2002 The Intrazone Routing Protocol (IARP) for Ad Hoc Networks Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026, except the right to produce derivative works is not granted. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. Abstract This document describes the Intrazone Routing Protocol (IARP), a limited scope proactive routing protocol used to improve the performance of existing globally reactive routing protocols. With each node monitoring changes in its surrounding R-hop neighborhood (routing zone), global route discoveries to local destinations can be avoided. When a global route search is needed, the IARP's routing zones can be used to efficiently guide route queries outwards (via bordercasting) rather than blindly relaying queries from neighbor to neighbor. The proactive maintenance of routing zones also helps improve the quality of discovered routes, by making them more robust to changes in network topology. Once routes have been discovered, IARP's routing zone offers enhanced, real-time, route maintenance. Link failures can be bypassed by multiple hop paths within the routing zone. Similarly, suboptimal route segments can be identified and traffic re-routed along shorter paths. Haas, Pearlman, Samar Expires January 2003 [Page i] INTERNET DRAFT Intrazone Routing Protocol July 2002 Contents Status of this Memo . . . . . . . . . . . . . . . . . . . . . . i Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . i Applicability Statement . . . . . . . . . . . . . . . . . . . iii A. Networking Context . . . . . . . . . . . . . . . . . iii B. Protocol Characteristics and Mechanisms . . . . . . . iii 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 1 2. Routing Zones and Intrazone Routing . . . . . . . . . . . . 2 3. IARP Conversion Guidelines . . . . . . . . . . . . . . . . 3 4. Implementation Example - Timer Based Link State . . . . . . 3 A. Packet Format . . . . . . . . . . . . . . . . . . . . . 4 B. Data Structures . . . . . . . . . . . . . . . . . . . . 5 C. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 6 D. State Machine . . . . . . . . . . . . . . . . . . . . . 6 E. Pseudocode Implementation . . . . . . . . . . . . . . . 7 5. References . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Information . . . . . . . . . . . . . . . . . . . . . 11 MANET Contact Information . . . . . . . . . . . . . . . . . . . 11 Haas, Pearlman, Samar Expires January 2003 [Page ii] INTERNET DRAFT Intrazone Routing Protocol July 2002 Applicability Statement A. Networking Context The Intrazone Routing Protocol (IARP) is a limited scope proactive routing protocol, which is used to support a primary global routing protocol. The scope of the IARP is defined by the routing zone radius: the distance in hops that IARP route updates are relayed. IARP's proactive tracking of local network connectivity provides support for route acquisition and route maintenance. First, routes to local destinations are immediately available, avoiding the traffic overhead and latency of a route discovery. When a global route discovery is required for more distant destinations, inefficient query broadcasting can be replaced by a more bandwidth efficient query bordercasting [2], which directs queries to the periphery of the routing zone. Once routes have been discovered, IARP's routing zone offers enhanced, real-time, route maintenance. Link failures can be bypassed by multiple hop paths within the routing zone. Similarly, suboptimal route segments can be identified, enabling traffic to be re-routed along shorter paths. B. Protocol Characteristics and Mechanisms * Does the protocol provide support for unidirectional links? (if so, how?) Yes. The IARP can provide "local" support for unidirectional links. A unidirectional link can be used as long as the link source and link destination lie within each other's routing zone. * Does the protocol require the use of tunneling? (if so, how?) No. * Does the protocol require using some form of source routing? (if so, how?) No. * Does the protocol require the use of periodic messaging? (if so, how?) Yes. The IARP proactively maintains local routing information (routing zones) based on periodic exchanges of neighbor discovery messages. Haas, Pearlman, Samar Expires January 2003 [Page iii] INTERNET DRAFT Intrazone Routing Protocol (IARP) July 2002 * Does the protocol require the use of reliable or sequenced packet delivery? (if so, how?) IARP only assumes that link-layer (neighbor) unicasts are delivered reliably and in-sequence. Reliable and sequenced delivery of neighbor broadcasts and IP unicasts is not required. * Does the protocol provide support for routing through a multi- technology routing fabric? (if so, how?) Yes. It is assumed that each node's network interface is assigned a unique IP address. * Does the protocol provide support for multiple hosts per router? (if so, how?) Yes. Multiple hosts may be associated with a router. These hosts can be identified by the neighbor discovery/maintenance process. By default, it is assumed that a host's association with a router is not permanent. As a result, IARP exchanges routing information for individual hosts in the same manner as routing information for routers. In cases where a router is permanently associated with a network (subnetwork), IARP supports the exchange of network (subnetwork) prefixes in place of all aggregated host IP addresses. * Does the protocol support the IP addressing architecture? (if so, how?) Yes. Each node is assumed to have a unique IP address (or set of unique IP addresses in the case of multiple interfaces). The IARP references all nodes/interfaces by their IP address. * Does the protocol require link or neighbor status sensing (if so, how?) Yes. IARP proactively maintains local routing information (routing zones) based on detected changes in neighbor status. * Does the protocol have dependence on a central entity? (if so, how?) No. IARP is a fully distributed protocol. Haas, Pearlman, Samar Expires January 2003 [Page iv] INTERNET DRAFT Intrazone Routing Protocol (IARP) July 2002 * Does the protocol function reactively? (if so, how?) No. * Does the protocol function proactively? (if so, how?) Yes. IARP proactively maintains LOCAL routing information (routing zones) for each node. The routing zone information is leveraged, through the bordercasting mechanism, to support efficient global propagation of route queries. * Does the protocol provide loop-free routing? (if so, how?) Yes. IARP's link state proactive protocol is inherently loop-free, although temporary loops may form while new link state updates propagate through the routing zone. * Does the protocol provide for sleep period operation? (if so, how?) No. Sleep period operation is not addressed in this draft. However, sleep period support can be included as needed. * Does the protocol provide some form of security? (if so, how?) No. It is assumed that security issues are adequately addressed by the underlying protocols (IPsec, for example). * Does the protocol provide support for utilizing multi-channel, link-layer technologies? (if so, how?) Yes. It is assumed that each node's network interface is assigned a unique IP address. Haas, Pearlman, Samar Expires January 2003 [Page v] INTERNET DRAFT Intrazone Routing Protocol July 2002 1. Introduction The design of ad hoc network routing protocols is influenced by link instability (due to node mobility) and limitations in available bandwidth and transmission power. Traditional wired networks use proactive routing protocols, like OSPF [7] and RIP [15] to maintain up-to-date routes to all networks nodes. More efficient proactive routing protocols have been developed for ad hoc networks [1][5][8] [9][14]. However, continuously tracking the frequent topology changes in a practical ad hoc network can still produce an overwhelming amount of control traffic. Even worse, most of the acquired route information expires before it is ever used, making the proactive control traffic a poor investment of bandwidth. In contrast, reactive routing protocols [6][10][13] only initiate a global, query-based, route discovery as routes are needed. While some delay is incurred in route acquisition, the amount of overhead traffic is generally much less than proactive routing protocols, because routing information is not wasted. For this reason, reactive protocols are generally viewed as being more suitable than proactive routing protocols for the power/ bandwidth limited mobile ad hoc network. Although a global proactive routing protocol may overwhelm an ad hoc network's resources, a LIMITED SCOPE proactive routing protocol can be used to the advantage of a global reactive routing protocol. This hybrid routing approach forms the basis for the Zone Routing Protocol (ZRP) framework [4]. The cost for each node to proactively track the topology of its surrounding R-hop neighborhood (routing zone) can be justified by improved route discovery efficiency and more effective route maintenance [11][12]. Routes to local destinations are immediately available, avoiding route discoveries. When global route discovery is needed, the routing zones can be used to efficiently guide route queries outwards through bordercasting [2], rather than blindly relaying queries from neighbor to neighbor. The proactive maintenance of routing zones also helps improve the quality and survivability of discovered routes, by making them more robust to changes in network topology. Once routes have been discovered, routing zone offers enhanced, real-time, route maintenance. Link failures can be bypassed by multiple hop paths within the routing zone. Similarly, suboptimal route segments can be identified and traffic re-routed along shorter paths. Within the context of the ZRP, we refer to the locally proactive routing component as the Intrazone Routing Protocol (IARP). The IARP is not a specific routing protocol. Rather, it is a family of limited-depth, proactive, link state routing protocols. In this document, we provide an implementation of a simple timer-based IARP. In addition, we provide a set of basic guidelines which can be used to convert an existing proactive routing protocol to an IARP. Haas, Pearlman, Samar Expires January 2003 [Page 1] INTERNET DRAFT Intrazone Routing Protocol July 2002 2. Routing Zones and Intrazone Routing A routing zone for a node X is defined as the set of nodes whose minimum distance in *hops* from X is no greater than some parameter referred to as the zone radius. An example of a radius R = 2 hop routing zone (for node A) is shown below. +-----------------------------------------+ | +---+ | | +---+ ---| F |-------| | +---+ | +---+ --| C |--/ +---+ +---+ | | G |-----| D |--/ +---+ | E | | Routing Zone of +---+ | +---+ | +---+ +---+ | node A | +---+ ---| B |-------| | (radius = 2 hops) | | A |--/ +---+ | | +---+ | +-----------------------------------------+ In this example nodes B through F are within the routing zone of A. Node G is outside A's routing zone. Also note that E can be reached by two paths from A, one with length 2 hops and one with length 3 hops. Since the minimum is less than or equal to 2, E is within A's routing zone. Peripheral nodes are routing zone nodes whose minimum distance to the node in question is equal exactly to the zone radius. In the above figure, nodes D, F and E are A's peripheral nodes. These peripheral nodes play an important role in efficient querying based on bordercasting. We note that each node maintains its own routing zone. As a result, routing zones of nearby nodes may overlap heavily. Each node proactively tracks the topology of its routing zone through an IntrAzone Routing Protocol (IARP). IARP is derived from globally proactive link state routing protocols (for example, OSPF). The base protocol needs to be modified to ensure that the scope of the route updates is restricted to the radius of the node's routing zone. The required modifications and example IARP are described in the next sections. Haas, Pearlman, Samar Expires January 2003 [Page 2] INTERNET DRAFT Intrazone Routing Protocol July 2002 3. IARP Conversion Guidelines Traditional proactive link state protocols can be modified to serve as an IARP by limiting link state updates to the scope of the link source's routing zone. The following guidelines can be used to convert existing proactive link state routing protocols to an IARP: - The scope of link state advertisements are limited by a TTL (time to live) in the link state update packet. The TTL is initialized to R-1 hops by the link source. When a node receives the update packet, it decrements the TTL value. When the TTL reaches 0, the packet is discarded. - If the base routing protocol performs link state table transfers with new neighbors, link sources that are at least R-1 hops away SHOULD be excluded from the transfer. This reduces the transmission of redundant link state to neighbors closer to the link source, and prevents transmission of out-of-zone link state to neighbors farther from the link source. - Nodes periodically update their link state tables, discarding link sources that are farther than R-1 hops away. - The IARP SHOULD support link state metrics that are consistent with the metrics used by the Interzone Routing Protocol (IERP) [3]. These additional metrics allow the IERP to import IARP routes in support of enhanced route maintenance (route repair, route shortening, etc.). 4. Implementation Example - Timer Based Link State IARP Nodes compute intrazone routes based on the proactively tracked link state of each routing zone member. Each node periodically advertises its link state (current set of neighbors and corresponding lists of link metrics) throughout its routing zone. Nodes monitor their own link state by means of a neighbor discovery protocol *. The scope of a link state update is controlled by a TTL (time-to- live) value that is carried in the link state packet. The TTL is initialized by the link source to R-1 hops (where R is the zone radius). Upon receipt of link state update packet, the link state is recorded, the routing table is recomputed and the packet's TTL value is decremented. As long as the TTL value is greater than 0, the link state update packet is rebroadcasted. * This IARP relies on the services of a separate protocol (referred to here as the Neighbor Discovery Protocol (NDP)) to provide current information about a node's neighbors. At the least, this informa- tion must include the IP addresses of all the neighbors. IARP and NDP can be configured to support supplemental link quality metrics. Haas, Pearlman, Samar Expires January 2003 [Page 3] INTERNET DRAFT Intrazone Routing Protocol July 2002 A. Packet Format 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State Seq Num | Zone Radius | TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESERVED | RESERVED | Link Dest Cnt | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Destination 1 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Destination 1 Subnet Mask (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --+-- | RESERVED | Metric Type | Metric Value | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Link | RESERVED | Metric Type | Metric Value | Metrics +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | RESERVED | Metric Type | Metric Value | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --+-- | | | | \| |/ \ / \/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Destination n Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Destination n Subnet Mask (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --+-- | RESERVED | Metric Type | Metric Value | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Link | RESERVED | Metric Type | Metric Value | Metrics +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | RESERVED | Metric Type | Metric Value | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --+-- Field Description: * Link Source Address (node_id) (32 bits) IP address of the reported link's source node. * Link State Seq Num (unsigned int) (16 bits) Sequence number used to track the link state history of the Link Source node. * Zone Radius (char) (8 bits) Routing zone radius of the link's source node. Determines the extent that link state information propagates. Haas, Pearlman, Samar Expires January 2003 [Page 4] INTERNET DRAFT Intrazone Routing Protocol July 2002 * TTL (char) (8 bits) number of hops remaining until packet is to be discarded * Link Dest Count (char) (8 bits) number of link source's neighbors * Link Destination Address (node_id) (n * 32 bits) IP addresses of the link source's neighbor nodes. * Node/Link Metrics (metric) (n*X * 32 bits) This section of the packet is used to report the quality of this link (or link source node). * Metric Type (char) (8 bits) Type of metric being reported (based on pre-defined metric types) * Metric Value (unsigned int) (16 bits) Value of node / link metric specified by Metric Type B. Data Structures B.1 Routing Table +-----------------------|--------------------------------+ | Dest | Subnet | Routes | Route | | Addr | Mask | | Metrics | | (node_id) | (node_id) | (node_id list) | (metric list) | |-----------+-----------|----------------+---------------| | | | | | |-----------+-----------|----------------+---------------| | | | | | |-----------+-----------|----------------+---------------| | | | | | +-----------------------|--------------------------------+ B.2 Link State Table +-----------|--------+-------+--------+------------------+ | Link | Zone | Link | Insert | Link State | | Source | Radius | State | Time | Information | | Addr | | ID | | | | (node_id) | (int) | (int) | (int) | (ls_info list) | +-----------|--------+-------+--------+------------------| | | | | | | |-----------|--------+-------+--------+------------------| | | | | | | |-----------|--------+-------+--------+------------------| | | | | | | +-----------|--------------------------------------------+ Haas, Pearlman, Samar Expires January 2003 [Page 5] INTERNET DRAFT Intrazone Routing Protocol July 2002 ## detail of (ls_info) data type +---+---|---| | | ||||| +---+---|---| (a) (b) (c) (a) Link Destination Address (b) Link Destination Subnet Mask (c) Link Metrics C. Interfaces C.1 Higher Layer (N/A) C.2 Lower Layer (IP) C.1.1 Deliver(packet) Used by IP to deliver packet to IARP C.3 NDP C.3.1 Deliver() Used by NDP to indicate an update in link state. IARP retrieves the actual link state from NDP via Neighbor_State(&neighbor[n],&mask[n],&metrics[n][x]). D. State Machine The IARP protocol consists of only one state (IDLE). Therefore, no state transitions need to be specified. The IARP immediately acts upon an event and then returns back to the IDLE state. Notes: 1) X is used as a label for the node running this state machine. D.1 Event: Link state broadcast timer interrupt. Action: X consults the neighbor discovery process for its own link state (list of neighbors and corresponding link metrics). X updates its Link State Table and Routing Table accordingly. The TTL value is initialized to R-1 hops (where R is the zone radius). If the TTL is greater than 0 then X loads a link state packet and broadcasts it to its neighbors. Haas, Pearlman, Samar Expires January 2003 [Page 6] INTERNET DRAFT Intrazone Routing Protocol July 2002 D.2 Event: An IARP link state packet is received. Action: The link state update is recorded in the Link State Table and the Routing Table is updated accordingly. The TTL is decremented. If the TTL is greater than 0 then X broadcasts the link state packet to its neighbors. D.3 Event: Link State Table refresh interrupt. Action: Remove from the Link State Table any links that are older than LINK_STATE_LIFETIME. E. Pseudocode Implementation We define two complimentary operations on packets: extract(packet) and load(packet) extract (packet) extracts the fields of the IARP packet to the following variables: {link_source, state_seq_num, radius, TTL, link_dest[n], mask[n], link_metric[n][x]} load (packet) loads the values of the aforementioned variables into the fields of the IARP packet. E.1 Deliver(packet) Deliver() // This procedure handles both incoming link state packet and // periodic advertisement of own link state if(packet) extract(packet); else { link_source = MY_ID; Neighbor_State(&neighbor[n],&mask[n],&metrics[n][x]); TTL = R; } // Record link state information in Link State Table add(Link_State_Table, link_source, link_dest, mask, radius, link_metric, state_id, flags); Haas, Pearlman, Samar Expires January 2003 [Page 7] INTERNET DRAFT Intrazone Routing Protocol July 2002 // Recompute Routing Table Routing_Table =compute_routes_from_links(Link_State_Table,node); // Report Routing Table update to IERP IARP_updated(); // Relay link state update only if link source lies inside of // of routing zone (evaluated based on TTL value) TTL--; if(TTL > 0) { load(packet); broadcast(packet); } else discard(packet); E.2 Refresh Link State Table args: () // Periodically remove from the Link State Table link states // that are older than LINK_STATE_LIFETIME for each link_source (BELONGING TO) Link_State_Table { insert_time = Link_State_Table[link_source].insert_time; if(current_time()-insert_time > LINK_STATE_LIFETIME) remove_from_table(Link_State_Table, link_source); } // Recompute Routing Table Routing_Table = compute_routes_from_links(Link_State_Table,node); // Report Routing Table update to IERP IARP_updated(); Haas, Pearlman, Samar Expires January 2003 [Page 8] INTERNET DRAFT Intrazone Routing Protocol July 2002 5. References [1] Garcia-Luna-Aceves, J.J. and Spohn, M., "Efficient Routing in Packet-Radio Networks Using Link-State Information," WCNC '99, September 1999. [2] Haas, Z.J., Pearlman, M.R. and Samar, P., "Bordercast Resolution Protocol (BRP)," IETF Internet Draft, draft-ietf-manet-brp-02.txt, July 2002. [3] Haas, Z.J., Pearlman, M.R. and Samar, P., "Interzone Routing Protocol (IERP)," IETF Internet Draft, draft-ietf-manet-ierp-02.txt, July 2002. [4] Haas, Z.J., Pearlman, M.R. and Samar, P., "Zone Routing Protocol (ZRP)," IETF Internet Draft, draft-ietf-manet-zrp-04.txt, July 2002. [5] Jacquet, P., Muhlethaler, P., Qayyum A., Laouiti A., Viennot L., and Clausen T., "Optimized Link State Routing Protocol," IETF Internet Draft, draft-ietf-manet-olsr-03.txt, November 2000. [6] Johnson, D.B. and Maltz, D.A., "Dynamic Source Routing in Ad-Hoc Wireless Networks," in Mobile Computing, edited by T. Imielinski and H. Korth, chapter 5, pp. 153-181, Kluwer, 1996. [7] Moy, J., "OSPF Version 2," INTERNET DRAFT STANDARD, RFC 2178, July 1997. [8] Murthy, S. and Garcia-Luna-Aceves, J.J., "An Efficient Routing Protocol for Wireless Networks," MONET, vol. 1, no. 2, pp. 183-197, October 1996. [9] Ogier, R. "Efficient Routing Protocols for Packet-Radio Networks Based on Tree Sharing," MoMUC '99, November 1999. [10] Park, V.D. and Corson, M.S., "A Highly Adaptive Distributed Routing Algorithm for Mobile Wireless Networks," IEEE INFOCOM'97, Kobe, Japan, 1997. [11] Pearlman, M.R. and Haas, Z.J., "Determining the Optimal Configuration for the Zone Routing Protocol," IEEE JSAC, August, 1999. [12] Pearlman, M.R., Haas, Z.J. and S.I. Mir, "Using Routing Zones to Support Route Maintenance in Ad Hoc Networks," IEEE WCNC 2000, Chicago, IL, Sept. 2000. Haas, Pearlman, Samar Expires January 2003 [Page 9] INTERNET DRAFT Intrazone Routing Protocol July 2002 [13] Perkins, C.E. and Royer, E.M., "Ad Hoc On-Demand Distance Vector Routing," IEEE WMCSA'99, New Orleans, LA, Feb. 1999 [14] Perkins, C.E. and Bhagwat, P., "Highly Dynamic Destination-Sequenced Distance-Vector Routing (DSDV) for Mobile Computers," ACM SIGCOMM, vol.24, no.4, October 1994. [15] Postel, J., "Internet Protocol," RFC 791, Sept. 1981. Haas, Pearlman, Samar Expires January 2003 [Page 10] INTERNET DRAFT Intrazone Routing Protocol July 2002 Authors' Information Zygmunt J. Haas Wireless Networks Laboratory 323 Frank Rhodes Hall School of Electrical & Computer Engineering Cornell University Ithaca, NY 14853 United States of America tel: (607) 255-3454, fax: (607) 255-9072 Email: haas@ece.cornell.edu Marc R. Pearlman 389 Frank Rhodes Hall School of Electrical & Computer Engineering Cornell University Ithaca, NY 14853 United States of America tel: (607) 255-0236, fax: (607) 255-9072 Email: pearlman@ece.cornell.edu Prince Samar 374 Frank Rhodes Hall School of Electrical & Computer Engineering Cornell University Ithaca, NY 14853 United States of America tel: (607) 255-9068, fax: (607) 255-9072 Email: samar@ece.cornell.edu The MANET Working Group contacted through its chairs: M. Scott Corson Institute for Systems Research University of Maryland College Park, MD 20742 (301) 405-6630 corson@isr.umd.edu Joseph Macker Information Technology Division Naval Research Laboratory Washington, DC 20375 (202) 767-2001 macker@itd.nrl.navy.mil Haas, Pearlman, Samar Expires January 2003 [Page 11]