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 Zone Routing Protocol (ZRP) 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 Zone Routing Protocol (ZRP) framework, a hybrid routing framework suitable for a wide variety of mobile ad-hoc networks, especially those with large network spans and diverse mobility patterns. Each node proactively maintains routes within a local region (referred to as the routing zone). Knowledge of the routing zone topology is leveraged by the ZRP to improve the efficiency of a globally reactive route query/reply mechanism. The proactive maintenance of routing zones also helps improve the quality of discovered routes, by making them more robust to changes in network topology. The ZRP can be configured for a particular network by proper selection of a single parameter, the routing zone radius. Haas, Pearlman, Samar Expires January 2003 [Page i] INTERNET DRAFT The Zone 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. Overview of the Zone Routing Framework . . . . . . . . . . . 2 2.1 Routing Zones and the Intrazone Routing Protocol . . . 2 2.2 Bordercast-Based Global Reactive (Interzone) Routing . 4 3. The ZRP Architecture . . . . . . . . . . . . . . . . . . . . 5 4. Other Considerations . . . . . . . . . . . . . . . . . . . . 6 4.1 Sizing the Routing Zone . . . . . . . . . . . . . . . . 6 4.2 Hierarchical Routing and the ZRP . . . . . . . . . . . 6 5. Patent Rights Statement . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Information . . . . . . . . . . . . . . . . . . . . . 11 MANET Contact Information . . . . . . . . . . . . . . . . . . . 11 Haas, Pearlman, Samar Expires January 2003 [Page ii] INTERNET DRAFT The Zone Routing Protocol July 2002 Applicability Statement A. Networking Context The hybrid Zone Routing Protocol (ZRP) framework can adapt to a wide variety of network scenarios by adjusting the range of the nodes' proactively maintained routing zones. Large routing zones are preferred when demand for routes is high and/or the network consists of many slowly moving nodes. In the extreme case of a network with fixed topology, the ideal routing zone radius would be infinitely large. (Consider the purely proactive routing protocols used on the fixed Internet). On the other hand, smaller routing zones are appropriate in situations where route demand is low and/or the network consists of a small number of nodes that move fast relative to one another. In the "worst case", a routing zone radius of one hop is best, and the ZRP defaults to a traditional reactive flooding protocol. When the ZRP is properly configured for a particular network scenario, it can perform at least as well as (and often better than) its purely proactive and reactive constituent protocols. In situations where the network behavior varies across different regions, the ZRP performance can be fine-tuned by individual adjustment of each node's routing zone. The global reactive component of the ZRP uses the multicast based "bordercast" mechanism to propagate route queries throughout the network efficiently, rather than relying on neighbor-broadcast flooding found in traditional reactive protocols. Consequently, the ZRP provides the most benefit in networks where reliable neighbor broadcasting is either inefficient or altogether impossible. In particular, the ZRP is well suited for multi-channel, multi- technology routing fabrics and networks operating under high load. B. Protocol Characteristics and Mechanisms * Does the protocol provide support for unidirectional links? (if so, how?) Yes. The ZRP provides "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. The ZRP's framework supports global route discovery based on source routing, distributed distance vectors, or various combinations of both. Haas, Pearlman, Samar Expires January 2003 [Page iii] INTERNET DRAFT The Zone Routing Protocol July 2002 * Does the protocol require the use of periodic messaging? (if so, how?) Yes. The ZRP framework proactively maintains local routing information (routing zones) based on periodic exchanges of neighbor discovery messages. * Does the protocol require the use of reliable or sequenced packet delivery? (if so, how?) The ZRP 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, the ZRP 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), the ZRP 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 ZRP references all nodes/interfaces by their IP address. This version of the ZRP also supports IP network addressing (network prefixes) for routers that provide access to a network of non-router hosts. Haas, Pearlman, Samar Expires January 2003 [Page iv] INTERNET DRAFT The Zone Routing Protocol July 2002 * Does the protocol require link or neighbor status sensing (if so, how?) Yes. The ZRP 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. The ZRP is a fully distributed protocol. * Does the protocol function reactively? (if so, how?) Yes. The ZRP's GLOBAL route discovery mechanism is reactive. A route query is initiated, on demand, when a node requires routing information that is not immediately available in its routing table. The route query propagates through the network, using a special packet delivery service called "bordercasting". Bordercasting leverages knowledge of local network topology to direct route queries away from the source, thereby reducing redundancy. * Does the protocol function proactively? (if so, how?) Yes. The ZRP 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. If the reactive Interzone Routing is based on source routing, loop-freedom in the route discovery process is ensured by inspection of accumulated source routes. For distributed distance vector approaches, loop-freedom can be ensured by labeling queries (replies) with the source (destination) address and locally unique sequence number. Nodes that relay these messages can temporarily cache these identifiers in order to identify and terminate loops. The proactive Intrazone Routing based on link states 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. Haas, Pearlman, Samar Expires January 2003 [Page v] INTERNET DRAFT The Zone Routing Protocol July 2002 * 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 vi] INTERNET DRAFT The Zone Routing Protocol July 2002 1. Introduction One of the major challenges in designing a routing protocol for the ad hoc networks stems from the fact that, on one hand, to determine a packet route, a node needs to know at least the reachability information to its neighbors. On the other hand, in an ad hoc network, the network topology can change quite often. Furthermore, as the number of network nodes can be large, the potential number of destinations is also large, requiring large and frequent exchange of data (e.g., routes, routes updates, or routing tables) among the network nodes. Thus, the amount of update traffic can be quite high. This is in contradiction with the fact that all updates in a wirelessly interconnected ad hoc network travel over the air and, thus, are costly in resources. In general, the existing routing protocols can be classified either as proactive or as reactive. Proactive protocols attempt to continuously evaluate the routes within the network, so that when a packet needs to be forwarded, the route is already known and can be immediately used. The family of Distance-Vector protocols is an example of a proactive scheme. Examples of proactive routing protocols include the Wireless Routing Protocol (WRP) [11] and Destination-Sequenced Distance-Vector (DSDV) routing [16]. Reactive protocols, on the other hand, invoke a route determination procedure on demand only. Thus, when a route is needed, some sort of global search procedure is employed. The family of classical flooding algorithms belong to the reactive group. Some other examples of reactive (also called on-demand) ad hoc network routing protocols are Dynamic Source Routing (DSR) [9], Ad-hoc On demand Distance Vector Routing (AODV) [17] and the Temporally Ordered Routing Algorithm (TORA) [13]. The advantage of the proactive schemes is that, once a route is needed, there is little delay until the route is determined. In reactive protocols, because route information may not be available at the time a datagram is received, the delay to determine a route can be quite significant. Furthermore, the global flood-search procedure of the reactive protocols requires significant control traffic. Because of this long delay and excessive control traffic, pure reactive routing protocols may not be applicable to real-time communication. However, pure proactive schemes are likewise not appropriate for the ad hoc networking environment, as they continuously use a large portion of the network capacity to keep the routing information current. Since nodes in an ad hoc network move quite fast, and as the changes may be more frequent than the route requests, most of this routing information is never even used! This results in a further waste of the wireless network capacity. What is needed is a protocol that, on one hand, initiates the route determination procedure on-demand, but at limited search cost. The protocol described in this draft, termed the "Zone Routing Protocol (ZRP)" ([1],[2],[14]), is an example of a such a hybrid proactive/ reactive scheme. Haas, Pearlman, Samar Expires January 2003 [Page 1] INTERNET DRAFT The Zone Routing Protocol July 2002 The ZRP, on one hand, limits the scope of the proactive procedure only to the node's local neighborhood. On the other hand, the search throughout the network, although global in nature, is done by efficiently querying selected nodes in the network, as opposed to querying all the network nodes. A related issue is that of updates in the network topology. For a routing protocol to be efficient, changes in the network topology should have only a local effect. In other words, creation of a new link at one end of the network is an important local event but, most probably, not a significant piece of information at the other end of the network. Globally proactive protocols tend to distribute such topological changes widely in the network, incurring large costs. The ZRP limits propagation of such information to the neighborhood of the change only, thus limiting the cost of topological updates. 2. Overview of the Zone Routing Framework In the Zone Routing framework, a proactive routing protocol provides a detailed and fresh view of each node's surrounding local topology (routing zone) at the local level. The knowledge of local topology is used to support services such as proactive route maintenance, unidirectional link discovery and guided message distribution. One particular message distribution service, called bordercasting [5], directs queries throughout the network across overlapping routing zones. Bordercasting is used in place of traditional broadcasting to improve the efficiency of a global reactive routing protocol. The benefits provided by routing zones, compared with the overhead of proactively tracking routing zone topology, determine the optimal framework configuration. As network conditions change, the framework can be dynamically reconfigured through adjustment of each node's routing zone 2.1 Routing Zones and the Intrazone Routing Protocol (IARP) In Zone Routing, the Intrazone Routing Protocol (IARP) proactively maintains routes to destinations within a local neighborhood, which we refer to as a routing zone. More precisely, a node's routing zone is defined as a collection of nodes whose minimum distance in hops from the node in question is no greater than a parameter referred to as the zone radius. Note that each node maintains its own routing zone. An important consequence is that the routing zones of neighboring nodes overlap. Haas, Pearlman, Samar Expires January 2003 [Page 2] INTERNET DRAFT The Zone Routing Protocol July 2002 An example of a routing zone (for node A) of radius 2 is shown below. +-----------------------------------------+ | +---+ | | +---+ ---| F |-------| | +---+ | +---+ --| C |--/ +---+ +---+ | | G |-----| D |--/ +---+ | E | | Routing Zone of +---+ | +---+ | +---+ +---+ | node A | +---+ ---| B |-------| | (radius = 2 hops) | | A |--/ +---+ | | +---+ | +-----------------------------------------+ Note that 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 or equal than 2, E is within A's routing zone. Peripheral nodes are nodes whose minimum distance to the node in question is equal exactly to the zone radius. Thus, in the above figure, nodes D, F, and E are A's peripheral nodes. The construction of a routing zone requires a node to first know who its neighbors are. A neighbor is defined as a node with whom direct (point-to-point) communication can be established and is, thus, one hop away. Identification of a node's neighbors may be provided directly by the media access control (MAC) protocols, as in the case of polling-based protocols. In other cases, neighbor discovery may be implemented through a separate Neighbor Discovery Protocol (NDP). Such a protocol typically operates through the periodic broadcasting of "hello" beacons. The reception (or quality of reception) of a "hello" beacon can be used to indicate the status of a connection to the beaconing neighbor. Neighbor discovery information is used as a basis for the IARP. IARP can be derived from globally proactive link state routing protocols that provide a complete view of network connectivity. [3] describes the Intrazone Routing Protocol (IARP) in detail and lists the conversion guidelines for adapting a proactive link-state based routing protocol to serve as an IARP. Haas, Pearlman, Samar Expires January 2003 [Page 3] INTERNET DRAFT The Zone Routing Protocol July 2002 2.2 Bordercast-Based Global Reactive (Interzone) Routing Route discovery in the Zone Routing framework is distinguished from standard broadcast-based route discovery through a message distribution service known as the Bordercast Resolution Protocol (BRP) [5]. Rather than blindly broadcasting a route query from neighbor to neighbor, bordercasting allows the query to be directed outward, toward regions of the network (specifically, toward peripheral nodes) that have not yet been "covered" by the query. (A covered node is one that belongs to the routing zone of a node that has received a route query). The query control mechanisms reduce route query traffic by directing query messages outward from the query source and away from covered routing zones. A node can determine local query coverage by noting the addresses of neighboring nodes that have forwarded the query. In the case of multiple channel networks, a node can only detect query packets that have been directly forwarded to it. For single channel networks, a node may be able to detect any query packet forwarded within the node's radio range. When a node identifies a query forwarding neighbor, all known members of that neighbor's routing zone (i.e., those members which belong to both the node's and neighbor's routing zones) are marked as covered. When a node is called upon to relay a bordercast message, it again uses its routing zone topology to construct a bordercast tree, that is rooted at itself and spans its uncovered peripheral nodes. The message is then forwarded to those neighbors in the bordercast tree. By virtue of the fact that this node has forwarded the query, all of its routing zone members are marked as covered. Therefore, a bordercasting node will not forward a query more than once. The details of the Bordercast Resolution Protocol are described in [5]. Given the availability of an underlying bordercast service, the operation of Zone Routing's global reactive Interzone Routing Protocol (IERP) is quite similar to standard route discovery protocols. An IERP route discovery is initiated when no route is locally available to the destination of an outgoing data packet. The source generates a route query packet, which is uniquely identified by a combination of the source node's address and request number. The query is then relayed to a subset of neighbors as determined by the bordercast algorithm. Upon receipt of a route query packet, a node checks if the destination lies in its zone or if a valid route to it is available in its route cache. If the answer is affirmative, a route reply is sent back to the source. If not, the node bordercasts the query again. The operation of the IERP is sufficiently general, so that many existing reactive protocols can be used as an IERP with minimal modification. The details of IERP's operation can be found in [4]. Haas, Pearlman, Samar Expires January 2003 [Page 4] INTERNET DRAFT The Zone Routing Protocol July 2002 3.0 The ZRP Architecture ......................................... : Z R P : : : +---------+ : +---------+ +---------+ : +---------+ | NDP |========>| IARP |========>| IERP |<========| ICMP | +---------+ : +---------+ |---+-----+ : +---------+ /|\ : /|\ |BRP| /|\ : /|\ | : | +---+ | : | | : | /|\ | : | | :...........|................|.....|....: | | | | | | \|/ \|/ \|/ \|/ \|/ +---------+---------+---------+---------+---------+---------+---------+ | IP | +---------+---------+---------+---------+---------+---------+---------+ Legend: A <---> B exchange of packets between protocols A & B A ===> B information passed from protocol A to protocol B Existing Protocols ------------------ IP Internet Protocol ICMP Internet Control Message Protocol ZRP Entities ------------ IARP IntrAzone Routing Protocol IERP IntErzone Routing Protocol BRP Bordercast Resolution Protocol Additional Protocols -------------------- NDP Neighbor Discovery Protocol The architecture of the hybrid Zone Routing framework is modular, so that a link state routing protocol can be used as an IARP [3] and an on-demand routing protocol can be used as an IERP [4]. As an example, consider TBRPF [12] or OLSR [7] as an IARP and AODV [15] or DSR [8] as an IERP. Haas, Pearlman, Samar Expires January 2003 [Page 5] INTERNET DRAFT The Zone Routing Protocol July 2002 4. Other Considerations 4.1 Sizing the Zone Radius The performance of the Zone Routing Protocol is determined by the routing zone radius. In general, dense networks consisting of a few fast moving nodes favor smaller routing zones. On the other hand, a sparse network of many slowly moving nodes operates more efficiently with a larger zone radius. The simplest approach to configuring the routing zone radius is to make the assignment once, prior to deploying the network. This can be performed by the network administration, if one exists, or by the manufacturer, as a default value. This may provide acceptable performance, especially in situations where network characteristics do not vary greatly over space and time. Alternatively, the ZRP can adapt to changes in network behavior, through dynamic configuration of the zone radius [6]. In [14], it was shown that a node can accurately estimate its optimal zone radius, on-line, based on local measurements of ZRP traffic. The re-sizing of the routing zone can be carried out by a protocol that conveys the change in zone radius to the members of the routing zone. In Zone Routing with independently sized routing zones capability, each of the nodes in the network can adaptively configure its own optimal zone radius in a distributed fashion. The performance of Zone Routing is further improved by the ability to provide fine-tuned adaptation to local and temporal variations in network characteristics [19]. The details of the Independent Zone Routing (IZR) framework will be included in a future version of this draft. 4.2 Hierarchical Routing and the ZRP In a hierarchical network architecture, network nodes are organized into a smaller number of (often disjoint) clusters. This routing hierarchy is maintained by two component routing protocols. An intra- cluster protocol provides routes between nodes of the same cluster, while an inter-cluster protocol operates globally to provide routes between clusters. The ZRP, with its routing zones and intrazone / interzone routing protocol (IARP/IERP) architecture may give the appearance of being a hierarchical routing protocol. In actuality, the ZRP is a flat routing protocol. Each node maintains its own routing zone, which heavily overlaps with the routing zones of neighboring nodes. Because there is a one-to-one correspondence between nodes and routing zones, the routing zones, unlike hierarchical clusters, do not serve to hide the details of local network topology. As a result, the network-wide interzone routing protocol (IERP) actually determines routes between individual nodes, rather than just between higher level network entities. Haas, Pearlman, Samar Expires January 2003 [Page 6] INTERNET DRAFT The Zone Routing Protocol July 2002 For small to moderately sized networks, flat routing protocols, like the ZRP, are preferable to hierarchical routing protocols. In order for a node to be located, its address needs to reflect the node's location within the network hierarchy (i.e. {cluster id,node id}). Because of node mobility, a node's cluster membership (and thus address) is subject to change. This complicates mobility management, for the benefit of more efficient routing. In many hierarchical routing protocols, each cluster designates a single clusterhead node to relay inter-cluster traffic. These clusterhead nodes become traffic "hot-spots", potentially resulting in network congestion and single point of failure. Furthermore, restricting cluster access through clusterhead nodes can lead to sub-optimal routes, as potential neighbors in different clusters are prohibited from communicating directly. Some hierarchical routing protocols, such as the Zone-Based Hierarchical Link-State (ZHLS) [8], avoid these problems by distributing routing information to all cluster nodes, rather than maintaining a single clusterhead. In spite of these disadvantages, hierarchical routing protocols are often better suited for very large networks than flat routing protocols. Because hierarchical routing protocols provide global routes to network clusters, rather than individual nodes, routing table storage is more scalable. Similarly, the amount of route update messages is also more scalable. To some extent, the reduction in routing traffic is offset by extra mobility management overhead (i.e. identifying which cluster a node belongs to). However, it is quite common that the environment or existing organizational structure causes nodes to naturally cluster together. In these cases, there may be a high degree of intra-cluster mobility, with inter-cluster mobility is less common. A hierarchical routing protocol can be viewed as a set of flat routing protocols, each operating at different levels of granularity. In a two-tier routing protocol, the inter-cluster components is essentially a flat routing protocol that computes routes between clusters. Likewise, the intra-cluster component is a flat routing protocol, that computes routes between nodes in each cluster. For example, the Near Term Digital Radio (NTDR) System [18] and ZHLS both employ proactive link state protocols to determine inter and intracluster connectivity. In place of traditional proactive or reactive protocols, we recommend that the intra-cluster and inter-cluster routing protocol components be implemented based on the hybrid proactive/reactive ZRP. As described throughout this draft, the ZRP is designed to provide an optimal balance between purely proactive and reactive routing. This applies equally well to routing between nodes at the intra-cluster level and between clusters at the inter-cluster level. Additionally, the hybrid ZRP methodology can be applied to the related mobility management protocols, which determine complete node addresses based on a node's location in the network hierarchy. Haas, Pearlman, Samar Expires January 2003 [Page 7] INTERNET DRAFT The Zone Routing Protocol July 2002 5. Patent Rights Statement Cornell University has filed one or more patents protecting the inventions described in this submission (the "Patents"). If Cornell University's submission, or material portions thereof, is accepted and becomes part of the IETF standard (the "Standard"), then Cornell will grant any entity wishing to practice the Standard a non-exclusive, royalty-free license under the Patents to the extent, but only to the extent, that such license is required to implement (a) mandatory elements of the Standard; or (b) elements of Cornell's submission that are explicitly specified (and not merely incorporated by reference) in the Standard. Use of any elements of Cornell's submission that are neither required in order to implement the Standard nor explicitly specified in the Standard will require an additional license from Cornell University under terms to be negotiated between the parties. While the protocol disclosed in Cornell's submission is being evaluated by the IETF, whether on the standards track or otherwise, Cornell University will and hereby does grant any party a license to utilize, test and evaluate such protocol solely for non-commercial, research purposes. Haas, Pearlman, Samar Expires January 2003 [Page 8] INTERNET DRAFT The Zone Routing Protocol July 2002 6. References [1] Haas, Z.J., "A New Routing Protocol for the Reconfigurable Wireless Networks," ICUPC'97, San Diego, CA, Oct. 12,1997. [2] Haas, Z.J. and Pearlman, M.R., "The Performance of Query Control Schemes for the Zone Routing Protocol," SIGCOMM'98, Vancouver, BC, Sept. 2-4, 1998. [3] Haas, Z.J., Pearlman, M.R. and Samar, P., "Intrazone Routing Protocol (IARP)," IETF Internet Draft, draft-ietf-manet-iarp-02.txt, July 2002. [4] Haas, Z.J., Pearlman, M.R. and Samar, P., "Interzone Routing Protocol (IERP)," IETF Internet Draft, draft-ietf-manet-ierp-02.txt, July 2002. [5] Haas, Z.J., Pearlman, M.R. and Samar, P., "Bordercasting Resolution Protocol (BRP)," IETF Internet Draft, draft-ietf-manet-brp-02.txt, July 2002. [6] Haas, Z.J. and Tabrizi, S., "On Some Challenges and Design Choices in Ad-Hoc Communications," MILCOM'98, Boston, MA, October 18-21, 1998. [7] 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. [8] Joa-Ng, M. and Lu, I.T., "A Peer-to-Peer Zone-based Two-Level Link State Routing for Mobile Ad-Hoc Networks," to appear in IEEE JSAC issue on Ad-Hoc Networks, June, 1999. [9] 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. [10] Moy, J., "OSPF Version 2," INTERNET DRAFT STANDARD, RFC 2178, July 1997. [11] 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. [12] Ogier, R. "Efficient Routing Protocols for Packet-Radio Networks Based on Tree Sharing," MoMUC '99, November 1999. Haas, Pearlman, Samar Expires January 2003 [Page 9] INTERNET DRAFT The Zone Routing Protocol July 2002 [13] Park, V.D., and Corson, M.S., "A Highly Adaptive Distributed Routing Algorithm for Mobile Wireless Networks," IEEE INFOCOM'97, Kobe, Japan, 1997. [14] Pearlman, M.R. and Haas, Z.J., "Determining the Optimal Configuration for the Zone Routing Protocol," IEEE JSAC, August, 1999. [15] Pearlman, M.R. and Haas, Z.J., "Improving the Performance of of Query-Based Routing Protocols Through 'Diversity Injection'", IEEE WCNC'99, New Orleans, LA, Sept. 1999. [16] 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. [17] Perkins, C.E. and Royer, E.M., "Ad-Hoc On-Demand Distance Vector Routing," IEEE WMCSA'99, New Orleans, LA, Feb. 1999 [18] Ruppe, R., Griswald, S., Walsh, P. and Martin, R., "Near Term Digital Radio (NTDR) System," IEEE MILCOM'97, Monterey, CA, Nov. 1997. [19] Samar, P., Pearlman, M.R. and Haas, Z.J., "Hybrid Routing: The Pursuit of an Adaptable and Scalable Routing Framework for Ad Hoc Networks," in Handbook of Ad Hoc Wireless Networks, M. Ilyas, ed., CRC Press 2002. [20] Waitzman, D., Partridge, C., Deering, S.E., "Distance Vector Multicast Routing Protocol," RFC 1075, Nov. 1, 1988. Haas, Pearlman, Samar Expires January 2003 [Page 10] INTERNET DRAFT The Zone 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]