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]