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]