Mobile Ad Hoc and OSPF Working F. Baker Groups M. Chandra Internet-Draft R. White Expires: March 23, 2004 Cisco Systems J. Macker NRL T. Henderson Boeing Phantom Works E. Baccelli INRIA September 23, 2003 Problem Statement for OSPF Extensions for Mobile Ad Hoc Routing draft-baker-manet-ospf-problem-statement-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. This Internet-Draft will expire on March 23, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract In ad hoc networks containing or contained within larger IP networks, many of the capabilities of a routing protocol such as OSPF are desirable. This document poses the issues that need to be addressed to make OSPF work well in a network containing both traditional LANs and WANs and also radio network topologies. Baker, et al. Expires March 23, 2004 [Page 1] Internet-Draft Problem Statement September 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Network Design Requirements . . . . . . . . . . . . . . . . 3 1.2 Why layer 3? . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3 Mobile Ad Hoc Network Issues . . . . . . . . . . . . . . . . 4 1.4 Combining Manet and traditional wired networks . . . . . . . 5 2. Specific Changes Required . . . . . . . . . . . . . . . . . 6 2.1 Ad Hoc Networks . . . . . . . . . . . . . . . . . . . . . . 6 2.2 Radio network adaptation . . . . . . . . . . . . . . . . . . 6 2.3 Relay traffic minimization . . . . . . . . . . . . . . . . . 7 2.4 Limited transmission operation . . . . . . . . . . . . . . . 8 2.5 Addressing power issues . . . . . . . . . . . . . . . . . . 8 2.6 Low Probability of Detection/Intercept . . . . . . . . . . . 8 2.7 Scaling to large numbers of immediate neighbors . . . . . . 9 2.8 Scaling for rapid movement . . . . . . . . . . . . . . . . . 9 2.9 IPv4 and IPv6 Routing . . . . . . . . . . . . . . . . . . . 10 2.10 Reliable vs Unreliable Flooding . . . . . . . . . . . . . . 11 2.11 Area hierarchy . . . . . . . . . . . . . . . . . . . . . . . 12 3. Security Considerations . . . . . . . . . . . . . . . . . . 13 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 Normative References . . . . . . . . . . . . . . . . . . . . 15 Informative References . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . 19 Baker, et al. Expires March 23, 2004 [Page 2] Internet-Draft Problem Statement September 2003 1. Introduction RFC 2501 [2], entitled "Mobile Ad hoc Networking (Manet): Routing Protocol Performance Issues and Evaluation Considerations," gives a good overview of the requirements of a Mobile Ad Hoc Network. It describes the various issues and requirements that need to be addressed in such a network, and has led to the development of a number of routing protocols [9][10][11][12][13][14][15][16][17][18][19][20]. These protocols specifically address networks in which the only, or the primary, communication vehicle is the radio link. In ad hoc networks containing or contained within larger IP networks, many of the capabilities of a routing protocol such as OSPF are desirable and arguably necessary. This document poses the issues that need to be addressed to make OSPF work well in a network containing both traditional LANs and WANs and also radio network topologies. It would do so by adding capabilities appropriate to a radio interface, without altering OSPF behavior on other interfaces. 1.1 Network Design Requirements In the author's collective experience, however, Manet networks are not often isolated networks, such as existing Manet routing protocols address. Rather Manet networks often consist of vehicles containing racks with equipment and an internal LAN, or vehicles or robots accompanying groups of people connected to them via wireless LAN technologies and interconnected with other such groups. Such vehicles and mobile groups of people are often interspersed with field offices that are essentially stationary, and are connected to a larger Internet via standard WAN technologies such as satellite links, optical fiber, or virtual and circuit switched networks. In addition, the Manet technology is often being added to an existing network that is already deployed and uses technologies such as OSPFv2 [1] to interconnect them. If this is the case, we reason that the best approach to adding Manet capabilities is not to create a separate protocol for use in the wireless domain, which requires the management of route leakage between the routing domains, but to extend the existing protocol to address the needs of radio interfaces. Since the protocol is more generalized, it is likely to not be as well adapted to the radio environment as a purpose-built protocol. However, if the adaptation is sufficiently loose, the difference may not be operationally important. Baker, et al. Expires March 23, 2004 [Page 3] Internet-Draft Problem Statement September 2003 1.2 Why layer 3? An alternate design approach is to use a Manet routing protocol below the IP layer (layer-2), using an underlying link layer that appears to the network layer to be a single hop, broadcast-capable network, and then running a broadcast interface type at the layer-3 routing protocol. This does not eliminate routing. It performs the routing using a different protocol at a different layer, ties the network design to that link later, and causes us to run two routing protocols where one might suffice. This approach generally leads to redundant traffic (e.g., neighbor discovery operating at two layers) unless non-standard changes to the layer-3 implementation are made to capitalize on information obtained at layer-2. In addition, stressful mobility scenarios may undermine the ability of layer-2 to sufficiently emulate a full mesh network capability at all times, perhaps leading to problems in electing Designated Routers such as described in Section 2.3. 1.3 Mobile Ad Hoc Network Issues RFC 2501 [2], in section 3, lists a number of important points about Manet networks. They have dynamic topologies, which is to say that a routing system's list of neighboring hosts and routers changes from time to time. They are often bandwidth-constrained, both because the medium is shared with other nodes and because of limitations of the technology. They are also often power-constrained - a computer carried by a person in the field is running on its battery, and the simple act of transmission can be a major power drain. They also enjoy limited security: even if locked in a room, their radio - or the heat of their silicon - can be a beacon identifying their location or the frequency with which they transmit. From the perspective of adapting an existing routing protocol, this has specific implications. If transmissions consume power, unnecessary transmission is something to be avoided. As a result, if there are several ways that a peer might receive an important message (including multicast applications and the distribution of routing information), selecting one will consume less power from the network - and selecting the one that uses the least power will have the least impact - than allowing duplicates. If the network is bandwidth-constrained, limiting transmissions also preserves bandwidth for other uses, and routing in ways that maximize available bandwidth (traffic engineering) is helpful. Security threats need to be actively addressed, and in regions of rapid network change, or during periods of rapid network change, the transmissions and computation loads need to be minimized. These are often issues that have been deemed unimportant in protocols designed for fixed usage. Baker, et al. Expires March 23, 2004 [Page 4] Internet-Draft Problem Statement September 2003 1.4 Combining Manet and traditional wired networks The existing Internet Standard OSPF routing protocol design is one of the most widely deployed IGP routing technologies in the Internet. With the coming advent of pervasive wireless networking, additions to the present state-of-the-art protocols are needed to improve operational support in dynamic, wireless environments. Historic OSPF engineering efforts within the open standards community have not been concentrating on operations in dynamic, wireless environments. An area of Internet Standards work that has been concentrating on routing protocols for use in more dynamic, wireless networks is the Mobile Ad Hoc Networking (Manet) Working Group. Manet technology efforts to-date have developed protocol mechanisms for typical wireless interface support and for improving the effectiveness of distributed routing in the face of increased mobility and/or dynamics. It is envisioned that at this point in time, with present design lessons learned, a protocol engineering effort can use building blocks from both OSPF and Manet designs. The adaptation of both OSPFv2 and OSPFv3 has been considered. By extending and building off an OSPF framework, the probability of successful transition and interoperability within more heterogeneous networks may be greatly improved. The envisioned Manet interface extensions will provide both and interface type and protocol mechanisms appropriate for dynamic, wireless operation. The engineering modifications required for OSPFv2 [1] and OSPFv3 [3] are differ slightly in detail but approaches and issues have been outlined in several early proposals. Baker, et al. Expires March 23, 2004 [Page 5] Internet-Draft Problem Statement September 2003 2. Specific Changes Required Having elected to use OSPF in a manet network, we must realize that it has a number of issues that make it undesirable; these need to be corrected before we can efficiently use it. 2.1 Ad Hoc Networks Before we consider mobility, consider an ad hoc network such as a large scale wireless network. On a small scale, one might simply employ IEEE 802.11. This breaks down, however, in any case where one would choose layer 3 routing over 802.1 bridging, which includes network management concerns, scaling concerns, and administrative boundaries. In any radio-based network, every radio (and therefore every router) has a slightly different set of neighbors. As such, there is no obvious way to aggregate neighbor sets in the way one does for LANs. Even among routers that are physically near each other, differences in radio connectivity can be marked, with some radios having good reception from only a few neighbors and others reaching many. Consider the case of a variety of routers distributed around a valley several miles long. Nodes at one end are unlikely to be able to communicate with nodes at the other end due to distance, and nodes on the valley floor will have connectivity limited by vegetation and rock formations in addition to distance. But nodes high on the valley walls will be less limited by such structures. Therefore, the best routes from one end of the valley to another are likely to utilize intermediates along the walls of the valley or atop hills or towers within the valley. If one such node happens to overlook a large cluster of nodes on the valley floor, it may have a large number of routing neighbors, while another router that is off in the woods may have very few, or none at all. Neighbor relationships depend, obviously, on the many signal characteristics that affect wireless, and are neither readily predicted nor aggregated. Mobility compounds these issues, as it means that careful pointing of antennae is a pointless exercise, and continually changes neighbor relationships. 2.2 Radio network adaptation There may also be other forms of radio adaptations called for, such as the use of directional radios. In this project, we do not propose to handle truly unidirectional links, although links may behave in a unidirectional manner for brief periods of time. Baker, et al. Expires March 23, 2004 [Page 6] Internet-Draft Problem Statement September 2003 2.3 Relay traffic minimization While flooding optimizations are present in OSPF [1][3], such as Designated Router (DR) election, many of these were built under the assumption of a multi-access network. However, wireless networks are often not truly multi-access, as it cannot be assumed that two-way connectivity exists between all nodes on the same Layer 2 link. In some environments, a group of nodes that share the same logical segment may not be directly visible to each other; some of the possible causes are the following: low signal strength, long distance separation, environmental disruptions, partial VC meshing, etc. Note that in these networks, a logical segment refers to the local flooding domain dynamically determined by transmission radius. Therefore, optimizations such as DR election will not perform correctly in MANET networks. Without any further optimizations in link state flooding, OSPF may not be able to operate in a highly dynamic environment in which links are constantly being formed and broken due to the amount of control traffic that is generated. Some nodes (the ones not able to directly reach the sender) may never be able to synchronize their link state databases. To solve the synchronization issues encountered in these environments, a mechanism is needed through which all the nodes on the same logical segment can receive the routing information, regardless of the state of their adjacency to the source. Another component that will influence the scalability and convergence characteristics of OSPF [1][3], in a MANET environment is how much information needs to be flooded throughout the network. The ideal solution is that each node will receive a particular LSA exactly once; this is, however, difficult to accomplish. A more realistic version of the requirement is that no more than the minimum number of systems necessary relay an LSA; simplistically, if a network consists of two overlapping regions and there is a router within the overlap that neighbors with everyone, it would be nice if only and exactly that router relayed LSAs. The same applies to acknowledgements: it would be nice to minimize the transmission of LSA acknowledgements, which in several cases in OSPF are unicast in an exponential way. Controlling the amount of information on the link has increased importance in this environment due to the potential transmission costs and resource availability in general. For example, further flooding a routing update that only results in a redundant transmission (a routing update that has already been received by nodes within transmission range of the sender) is a waste of resources. For nodes operating on limited power supplies, this will directly impact the longevity of the node. Moreover, redundant transmissions unnecessarily contribute to the interference and packet Baker, et al. Expires March 23, 2004 [Page 7] Internet-Draft Problem Statement September 2003 collisions on the link. Note that these points also apply to the reliable acknowledgement mechanism in link state flooding in OSPF. Optimized protocol designs must balance a tradeoff between algorithm complexity and ensuring that every node in the network receives all of the routing information. 2.4 Limited transmission operation If minimizing relays is important, then minimizing traffic origination is also important. A special case of this is described in Extending OSPF to Support Demand Circuits [7], which allows a node to generate an LSA once and then assume that it is in everyone's LSA database until withdrawn; examples of use might be for prefix LSA's that are associated with the router in a vehicle. The mechanism also allows for state maintenance in the absence of HELLO messages. The behavior of this mechanism requires exploration in manet environments, however, and may need modification. 2.5 Addressing power issues Power management can be a matter of great concern in ad hoc, and especially mobile ad hoc, networks. Simply, it takes more power to do something than to do nothing, and it takes especially more power to transmit than it does to receive. Units that rely on batteries or other stored power sources are the hardest hit by this. From a routing perspective, these devices may well set a policy that they are willing to relay messages on their radio interfaces, but not very willing (they will accept the role if no other path can be calculated, which they might advertise via their selection of metric), or may decide that they are unwilling to do so under any circumstances (which they might advertise by an attribute on a neighbor relationship). In view of this, it is important to be able to calculate routes according to that type of policy. Note the careful wording of "relay messages on their radio interfaces". They may also have LAN interfaces (if they are the router for an equipment van) and be willing to relay traffic from radio interfaces on which they are not exchanging even keep-alive traffic to non-radio neighbors at times that their radio interfaces are incommunicado. Equipment with generated power, of course, do not generally have this concern. 2.6 Low Probability of Detection/Intercept Baker, et al. Expires March 23, 2004 [Page 8] Internet-Draft Problem Statement September 2003 A matter that may be considered to be related to either traffic minimization or power is the desire for location privacy from triangulation. In certain applications, this is an important characteristic. The matter is generally addressed in three ways simultaneously: minimizing transmissions, minimizing transmission power, and using radio technologies designed to be difficult to detect such as spread-spectrum or ultra-wideband signaling. 2.7 Scaling to large numbers of immediate neighbors While the number of immediately adjacent neighbors is controlled by the number of interfaces available on a physical device in traditional wired networks running OSPF, the number of interfaces does not limit the number of adjacent neighbors a device may have in a MANET environment. Further, only a small, limited number of devices in a traditional, wired environment run a routing protocol, while most devices within a MANET environment will be likely to run routing protocols. These two factors combine to cause the likely number of peers a router is adjacent with much higher and less predictable than a traditional wired network. Because of this, any protocol which is used in a MANET environment must prove itself able to provide support for very large numbers of adjacencies, and gracefully reduce functionality as its ability to support new neighbors is exhausted. 2.8 Scaling for rapid movement In a MANET, a communication link between a pair of nodes is a function of their variable link quality, including signal strength and bandwidth, and mobility. Routing paths thus vary based on environment and mobility, and the resulting network topology. In such networks, the topology may be stable for periods of time, and then suddenly become unpredictable and change rapidly. During periods of rapid change, the network should not thrash due to excessive overhead in establishing new adjacencies and tearing down old ones frequently. The effect of rapid topology change is even more pronounced in dense or large networks. Modifications in neighbor establishment, topology summarization, and LSA flooding are required in OSPF in order to effectively support rapid mobility. Currently, upon initialization and the establishment of new neighbor relationships in OSPF, a node must synchronize its link state database with its newly discovered peers. In a dynamic MANET environment with the absence of a DR in OSPF, if a node requests a database exchange and undergoes a full exchange with each of its peers simultaneously, it will significantly impact protocol scalability. Moreover, the node may be requesting and receiving Baker, et al. Expires March 23, 2004 [Page 9] Internet-Draft Problem Statement September 2003 redundant information from each of the peers with which it is synchronizing. On the other hand, if the node embarks on the database exchange with each of its peers in a serial fashion, it will significantly impact network convergence. If neighbor relationships are changing rapidly, the time invested to become FULL with a peer as defined in OSPF [1][3] must be minimized, thereby maximizing the chance that the database exchange process will complete. Otherwise, the time and resources expended will be wasted as the exchange process is terminated due to nodal mobility that renders a neighbor relationship defunct. In addition, peers should introduce a notion of neighbor stability, i.e., link stability, before embarking on the database exchange process to further reduce the possibility of a premature exchange process termination. In conventional OSPF networks, techniques of summarization and limiting the flooding scope of topology changes, e.g., OSPF areas, allow for scalability. These techniques rely on analyzing the topology in order to determine effective locations in the network where summarization should be applied to maximize the benefit. In a MANET environment, which is characterized by its dynamic topology changes that are sometimes rapid, some other mechanism is necessary since it is not possible to manually analyze the topology and determine summarization points. One of the main goals of a new summarization technique in MANET should be to efficiently scope the propagation of topology information such that rapid mobility or change in one part of the network need not be disseminated throughout the network. In addition, summarizing network advertisements should reduce the amount of routing control information that a node must process, and the summarization technique should dynamically limit the scope of the link state information propagation. Note that the issues raised in Section 2.3 for minimizing overhead due to routing control traffic are also applicable for achieving scalability due to rapid nodal mobility. 2.9 IPv4 and IPv6 Routing Networks deployed in the coming decade can expect to involve both IPv4 and IPv6 routing. While some protocols, notably IS-IS and BGP4+, routinely support multiple address families simultaneously, OSPF has historically chosen a "ships in the night" model, which is to say, a model in which parallel routing protocols are used for different network layers, and information is not leaked between them. There are good reasons for this: especially when deploying a new protocol, a new service can be tested and modified without affecting existing Baker, et al. Expires March 23, 2004 [Page 10] Internet-Draft Problem Statement September 2003 service using a different address family. In mobile ad hoc networks, however, running two protocols in parallel has a heavy impact when the network changes: when one device approaches or departs from another, the neighbor relationships change in both protocols, the LSAs are changed in both protocols, and the SPF calculation must occur in both protocols. This has the effect of compounding a problem which is already difficult in various ways. This can be achieved in several ways, of course. If the entire network is IPv4 and only the endpoints are IPv6, IPv6/IPv4 tunneling is an option, and several such approaches exist. At least one contemplated network is IPv6-only in the core and has IPv4 endpoints; this would require IPv4/IPv6 tunneling. There is an argument for various NAT alternatives that attempt to translate between IPv4 and IPv6. But the simplest approach to coexistence in the network is to simply route both styles of prefixes. As such, we argue that in mobile ad hoc networks carrying both IPv4 and IPv6 traffic, it would be good for a single routing protocol to calculate one set of routes and decorate those routes with both IPv4 and IPv6 prefixes. 2.10 Reliable vs Unreliable Flooding As currently designed, OSPF routers will each repeat a new LSA to each of their neighbors, perhaps using multicast transmissions, and each neighbor will acknowledge using unicast trsansmissions. Total transmissions triggered by a sequence number increment (such as happens to every LSA twice per MaxAge interval) is therefore on the order of the product of the number of nodes in the network and the average number of neighbor relationships a node has, which may be as large as the square of the number of nodes in the network (see Section 2.3). Several approaches have been suggested for minimizing transmissions during LSA flooding. TBRPF [16], for example, has routing nodes flood to their neighbors only the LSAs necessary for them to calculate routes through themselves, on the assumption that other LSAs will arrive at their peers by other routes if they are really needed. OLSR [15] carefully selects a subset of routing nodes to flood traffic through. Both of these use unacknowledged flooding, on the theory that most messages do get through, there is usually some redundancy in LSA flooding, and in any event the probability of losing two updates sequentially is very low. The problems with unreliable flooding is in the assumptions it makes. It addresses the probability of loss by frequently retransmitting Baker, et al. Expires March 23, 2004 [Page 11] Internet-Draft Problem Statement September 2003 LSAs in normal practice. If large areas are envisioned (it has been suggested that as many as 8000 nodes might exist in a single area), this has limited scalability. If the retransmission interval LSAs is left as in present OSPF (on the order of 30-60 minutes), the consequences of losing even a single LSA can be great. On the other hand, exponential explosions of transmissions, such as found in OSPF's current design, can be prohibitively chatty. For radio interfaces, with their specific requirements, this issue will require careful consideration. 2.11 Area hierarchy No present Manet protocol provides a counterpart to OSPF administrative areas. Some [15][20], however, provide a form of dynamic clustering. It is not obvious that the hierarchical area model (area zero interconnects any two other areas) directly fits proposed Manet deployments. Rather, a model that permits areas to exchange summary LSAs at any boundary may be preferable. This comes with its own problems, though, as witness the complexity of NSSA LSA configuration. Baker, et al. Expires March 23, 2004 [Page 12] Internet-Draft Problem Statement September 2003 3. Security Considerations As a problem statement, this note imposes no new security requirements on manet network routing that are not known from RFC 2501 [2]. Those problems can, however, be extreme. RFC 2501's Security Considerations read: Mobile wireless networks are generally more prone to physical security threats than are fixed, hardwired networks. Existing link-level security techniques (e.g. encryption) are often applied within wireless networks to reduce these threats. Absent link-level encryption, at the network layer, the most pressing issue is one of inter-router authentication prior to the exchange of network control information. Several levels of authentication ranging from no security (always an option) and simple shared-key approaches, to full public key infrastructure-based authentication mechanisms will be explored by the group. As an adjunct to the working groups efforts, several optional authentication modes may be standardized for use in MANETs. Note, however, that the issues that routing in a wireless network are very vulnerable to attack, and appropriate layer 3 and higher security issues need to be taken seriously. Baker, et al. Expires March 23, 2004 [Page 13] Internet-Draft Problem Statement September 2003 4. Acknowledgements Initial comments were received by Alvaro Retana, Abhay Roy, Philippe Jacquet, Tom Clausen, Jae Kim, and Phillip Spagnolo. Baker, et al. Expires March 23, 2004 [Page 14] Internet-Draft Problem Statement September 2003 Normative References [1] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [2] Corson, M. and J. Macker, "Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations", RFC 2501, January 1999. [3] Coltun, R., Ferguson, D. and J. Moy, "OSPF for IPv6", RFC 2740, December 1999. [4] Perkins, C., Belding-Royer, E. and S. Das, "Ad hoc On-Demand Distance Vector (AODV) Routing", RFC 3561, July 2003. Baker, et al. Expires March 23, 2004 [Page 15] Internet-Draft Problem Statement September 2003 Informative References [5] deSouza, O. and M. Rodrigues, "Guidelines for Running OSPF Over Frame Relay Networks", RFC 1586, March 1994. [6] Varadhan, K., Hares, S. and Y. Rekhter, "BGP4/IDRP for IP---OSPF Interaction", RFC 1745, December 1994. [7] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, April 1995. [8] Murphy, S., Badger, M. and B. Wellington, "OSPF with Digital Signatures", RFC 2154, June 1997. [9] Zinin, A., Lindem, A. and D. Yeung, "Alternative Implementations of OSPF Area Border Routers", RFC 3509, April 2003. [10] Perkins, C., "IP Flooding in Ad hoc Mobile Networks", draft-ietf-manet-bcast-00 (work in progress), November 2001. [11] Johnson, D., "The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks (DSR)", draft-ietf-manet-dsr-09 (work in progress), April 2003. [12] Gerla, M., "Fisheye State Routing Protocol (FSR) for Ad Hoc Networks", draft-ietf-manet-fsr-03 (work in progress), June 2002. [13] Gerla, M., "Landmark Routing Protocol (LANMAR) for Large Scale Ad Hoc Networks", draft-ietf-manet-lanmar-05 (work in progress), November 2002. [14] Lee, S. and Y. Yi, "On-Demand Multicast Routing Protocol (ODMRP) for Ad-Hoc Networks", draft-ietf-manet-odmrp-04 (work in progress), November 2002. [15] Clausen, T. and P. Jacquet, "Optimized Link State Routing Protocol", draft-ietf-manet-olsr-11 (work in progress), July 2003. [16] Ogier, R., Lewis, M. and F. Templin, "Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)", draft-ietf-manet-tbrpf-10 (work in progress), July 2003. [17] Haas, Z., Pearlman, M. and P. Samar, "The Bordercast Resolution Protocol (BRP) for Ad Hoc Networks", draft-ietf-manet-zone-brp-02 (work in progress), July 2002. Baker, et al. Expires March 23, 2004 [Page 16] Internet-Draft Problem Statement September 2003 [18] Haas, Z., Pearlman, M. and P. Samar, "The Intrazone Routing Protocol (IARP) for Ad Hoc Networks", draft-ietf-manet-zone-iarp-02 (work in progress), July 2002. [19] Haas, Z., Pearlman, M. and P. Samar, "The Interzone Routing Protocol (IERP) for Ad Hoc Networks", draft-ietf-manet-zone-ierp-02 (work in progress), July 2002. [20] Haas, Z., Pearlman, M. and P. Samar, "The Zone Routing Protocol (ZRP) for Ad Hoc Networks", draft-ietf-manet-zone-zrp-04 (work in progress), August 2002. Authors' Addresses Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara, California 93117 USA Phone: +1-408-526-4257 Fax: +1-413-473-2403 EMail: fred@cisco.com Madhavi W. Chandra Cisco Systems 7025 Kit Creek Road P.O. Box 14987 Research Triangle Park, North Carolina 27709-4987 USA Phone: +1-919-392-8387 EMail: mchandra@cisco.com Russ White Cisco Systems 7025 Kit Creek Road P.O. Box 14987 Research Triangle Park, North Carolina 27709-4987 USA Phone: +1-919-392-3139 EMail: ruwhite@cisco.com Baker, et al. Expires March 23, 2004 [Page 17] Internet-Draft Problem Statement September 2003 Joe Macker NRL 4555 Overlook Ave Washington, D.C., 20895 USA Phone: +1-202-767-2002 Fax: +1-202-767-1191 EMail: jmacker@acm.org Tom Henderson Boeing Phantom Works P.O. Box 3707, MC 3W-51 Seattle, Washington 98124 USA Phone: +1-253-657-2158 Fax: +1-253-657-8903 EMail: thomas.r.henderson@boeing.com Emmanuel Baccelli INRIA Projet HIPERCOM, Domaine de Voluceau, Rocquencourt - B.P. 105 Le Chesnay Cedex, 78153 France Phone: +33-139-635-511 Ext. 6003 Fax: +33-139-635-566 EMail: emmanuel.baccelli@inria.fr Baker, et al. Expires March 23, 2004 [Page 18] Internet-Draft Problem Statement September 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Baker, et al. Expires March 23, 2004 [Page 19] Internet-Draft Problem Statement September 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Baker, et al. Expires March 23, 2004 [Page 20]