Network Working Group J. Macker, editor
Internet-Draft NRL
Expires: December 3, 2005 SMF. Design Team
IETF
June 2005
Simplified Multicast Forwarding for MANET
draft-ietf-manet-smf-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 December 3, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes the Simplified Multicast Forwarding (SMF)
protocol that provides a basic IP multicast forwarding capability
within mobile ad-hoc networks. While it supports edge
interoperability with a conventional IP multicast infrastructure, SMF
is designed to have limited applicability as a forwarding mechanism
for multiple hop multicast packets within MANET routing areas. SMF
uses a simplified forwarding mechanism that delivers multicast
Macker, editor & Design Team Expires December 3, 2005 [Page 1]
Internet-Draft SMF for MANET June 2005
packets to all MANET multicast receivers within a MANET routing area.
The core design does not use group and membership specific
information in favor of reduced complexity and state maintenance
within the mobile topology region. The design accounts for the
unique nature and behavior of MANET interfaces and takes advantage of
particular efficient relay set algorithms previously designed and
applied in the MANET routing designs.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Overview of Applicability . . . . . . . . . . . . . . . . 3
2. SMF Design Considerations . . . . . . . . . . . . . . . . . . 5
2.1 Previous Related Work . . . . . . . . . . . . . . . . . . 6
2.2 Core Requirements of an SMF Implementation . . . . . . . . 6
3. SMF Packet Processing and Forwarding . . . . . . . . . . . . . 7
4. SMF Duplicate Packet Detection . . . . . . . . . . . . . . . . 9
4.1 SMF IPv4 Duplicate Packet Detection . . . . . . . . . . . 10
4.2 SMF IPv6 Duplicate Packet Detection . . . . . . . . . . . 11
4.3 IPv6 SMF-DPD Header Option Format . . . . . . . . . . . . 11
5. Efficient Relay Set Mechanisms . . . . . . . . . . . . . . . . 12
5.1 MPR Forwarding Operation . . . . . . . . . . . . . . . . . 12
5.2 E-CDS Forwarding Operation . . . . . . . . . . . . . . . . 13
6. SMF Multicast Border Gateway Considerations . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1 Normative References . . . . . . . . . . . . . . . . . . . 17
9.2 Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . 19
Macker, editor & Design Team Expires December 3, 2005 [Page 2]
Internet-Draft SMF for MANET June 2005
1. Introduction
Design and implementation progress has been made in developing and
implementing more efficient ways to flood control packets within
MANET wireless routing protocol designs. Example algorithms within
[RFC3626] and [RFC3684] specify distributed methods of dynamically
electing reduced relay sets for the purposes of optimized flooding of
specific control packets to all MANET nodes.
In this document, we specify the Simplified Multicast Forwarding
(SMF) protocol. The main purpose of SMF is to adapt efficient
flooding designs in MANET environments and apply such design
mechanisms at the native multicast IP forwarding level. SMF makes a
simple form of multicast forwarding available to user space data
flows within a MANET routing area. This is applicable when efficient
flooding is sufficient as compared to full, group and membership-
based multicast routing. The SMF baseline design limits its scope to
basic best effort multicast forwarding and its applicability is
intended to be constrained within a MANET routing area.
A multicast border gateway mechanism or configuration approach is
needed to interoperate with other IP multicast routing in the wired
world (e.g., PIM gateway). Although SMF may be extended or combined
with other protocol layers to provide increased reliability and group
specific forwarding state those methods will be discussed in other
documents.
1.1 Terminology
MANET : Mobile Ad hoc Networks
SMF : Simplified Multicast Forwarding
CF : Classical Flooding
CDS : Connected Dominating Set
MPR : Multi-point Relay
1.2 Overview of Applicability
A basic packet forwarding service that reaches all destinations
participating within a MANET environment can be a useful generic
routing mechanism for an application layer. While the design
requirements for such a forwarding mechanism are similar to those
often needed in the control plane by many MANET unicast routing
protocol layers, it is desirable to provide a more generic forwarding
Macker, editor & Design Team Expires December 3, 2005 [Page 3]
Internet-Draft SMF for MANET June 2005
function for use by other applications. There are a number of
application areas that could take advantage of a simple, broadcast-
type delivery service within a MANET routing region (e.g., multimedia
streaming, peer-to-peer middleware multicasting, MANET auto-
configuration, and discovery services).
Macker, editor & Design Team Expires December 3, 2005 [Page 4]
Internet-Draft SMF for MANET June 2005
2. SMF Design Considerations
The simplest design often conceived and adapted for MANET packet
flooding is something we designate as the classical flooding (CF)
algorithm. In CF, each participating forwarder node is required to
rebroadcast packets intended for dissemination once and only once.
This approach is extremely simple and generally only requires some
means of duplicate packet detection and a basic forwarding mechanism.
However, it is well known that using CF results in a significant
number of redundant transmissions often referred to as the broadcast
storm problem [NTSC99]. For example, reducing unnecessary channel
contention within a MANET significantly improves network performance.
Unlike wired network hardware, direct contention and interference is
experienced beyond the single hop physical interface. Therefore,
reducing the number of required relay nodes is an important design
goal for this environment. Unfortunately, reducing the number of
relay nodes in a MANET environment may also decrease the robustness
of overall packet delivery. There exists an interdependent design
trade-off between relay efficiency and delivery robustness that is
scenario and system dependent and should be considered carefully in
any pragmatic design. If needed, additional reliability mechanisms
MAY be considered for use with reduced relay sets. A design goal of
SMF is support CF-based forwarding and to support reduced relay set
algorithms for increased efficiency.
At a theoretical level, work in the area of minimizing packet
forwarders, or relay node sets, is often related to basic graph
theory problems. In graph theory, a dominating set (DS) for a graph
is a set of vertices whose neighbors, along with themselves,
constitute all the vertices in the graph. A connected DS (CDS) is a
DS forming a connected graph. A minimum CDS (MCDS) is a set such
that the number of vertices is the minimum required to form a CDS.
Finding a small dominating set is one of the most fundamental
problems of traditional graph theory and is in theory often related
to the problem of optimizing flooding algorithms in MANETs. Finding
an MCDS in a given graph is known to be NP-hard [GJ79]. Beyond these
basic static graph theoretic issues, MANET protocol designs require
more distributed and dynamic operation. To better explain the design
requirement, we formulated the following characteristics desired of
an effective MANET flooding algorithm solution for use in SMF:
1. A resultant cover set that is small compared to the total number
of nodes as the network scales in size and density.
2. A robust approach somewhat resilient to network mobility and link
dynamics.
Macker, editor & Design Team Expires December 3, 2005 [Page 5]
Internet-Draft SMF for MANET June 2005
3. A cover set election/maintenance mechanism that is lightweight,
distributed, and adaptive in nature.
2.1 Previous Related Work
Previous novel work on MANET flooding and reduced relay set
mechanisms has been done and this document borrows and builds off of
previous work accomplished. In [WC02], a broad taxonomy of flooding
algorithms for use in MANET environments was presented and the work
examined performance issues related to various approaches. Other
important work has developed distributed mechanisms that select and
maintain reduced relay node sets. As we have already mentioned, the
design trade-offs are further complicated by wireless contention,
topological classes, and mobility scenarios as considerations. In
addition, implementation of IP multicast forwarding based upon these
flooding algorithms raises additional design trade-offs and issues.
This includes maintenance of protocol state, duplicate packet
detection mechanisms, and any possible protocol signaling support
required by a mechanism.
2.2 Core Requirements of an SMF Implementation
Here we outline the core requirements being targeted by the SMF
specification. SMF is being designed to support both IPv4 and IPv6
MANET multicast forwarding capability. The fundamental requirements
of the SMF implementation are:
The SMF protocol MUST be capable of processing and potentially
forwarding multicast packets both generated locally on a MANET
node and those received on an active MANET interface.
SMF MUST ignore multicast packets intended for link-local use.
SMF MUST support a MANET duplicate packet detection scheme as
defined in this document (see Section 4).
SMF MUST support the ability to modify its forwarding status based
upon relay set information that is received dynamically during
operation.
SMF SHOULD support alternative relay set approaches. These
mechanisms are defined separately but some basic interface
functionality is defined here.
Macker, editor & Design Team Expires December 3, 2005 [Page 6]
Internet-Draft SMF for MANET June 2005
3. SMF Packet Processing and Forwarding
The SMF Packet Processing and Forwarding actions are conducted by two
possible packet handling activities:
1. Interception of outbound, locally-generated multicast packets.
2. Reception of inbound packets on a specific network interface(s).
In the case that sequence-based duplicate packet detection (see
Section 4) is used, the purpose of intercepting outbound, locally-
generated multicast packets would be to apply resequencing of the
IPv4 ID header field or add options headers as needed (e.g. IPv6).
In the case that resequencing is deemed necessary, it is RECOMMENDED
that sequence numbering be applied such that a sequence number space
per <sourceAddress::destinationAddress> duple is used. While, for
strict SMF purposes where no distinct routing for different IP
multicast address destinations occurs, it might be sufficient to use
sequence number spaces aggregated across all IP multicast
destinations (or across all IP destinations for a source as is the
default implementation of the IPv4 ID field in many operating
systems), the possibility that different destinations may be routed
differently suggests "per source/destination" numbering be used. It
should be noted that the default global IPv4 ID sequence space may be
sufficient for some SMF deployments and interception of outbound
packets may not be required. And, in other cases, such as when IPSec
headers have been applied to packets, other sequence information
(perhaps even "per flow") may be available for the SMF process to
leverage.
Inbound multicast packets will be received by the SMF implementation
and processed for possible forwarding. While an SMF implementation
may be designed to forward only specific IP multicast groups, SMF
SHOULD in general, be capable of forwarding all groups with the
following exceptions:
1. Multicast packets with TTL <= 1 MUST NOT be forwarded.
2. IPv6 Link Local multicast packets MUST NOT be forwarded
regardless of TTL.
3. Multicast packets with an IP source address matching one of those
of the local host interface(s) MUST NOT be forwarded.
4. MAC frames with MAC source address matching the local host
interface(s) MUST NOT be forwarded.
Note that exception #3 is important because in wireless networks, a
Macker, editor & Design Team Expires December 3, 2005 [Page 7]
Internet-Draft SMF for MANET June 2005
local host may receive re-transmissions of its own packets when they
are forwarded by neighboring nodes. This exception avoids
unnecessary retransmission of locally-generated packets even when
other forwarding decision rules would apply.
Once these criteria have been met, the implementation should
reference a forwarding decision algorithm, possibly in concert with
duplicate packet detection, to determine the next step in packet
processing. The forwarding behavior may be implicit if the SMF
implementation is configured to perform classic flooding (CF) of IP
multicast packets. Otherwise, the forwarding behavior may require
additional decision input. Neighborhood discovery protocols coupled
with the Multi-Point Relay (MPR) or other Connected Dominating Set
(CDS) selection algorithms described in Section 5 MAY be used to
determine the local host's status with respect to forwarding. For
example, some algorithms may require a forwarding decision be based
upon the previous hop (e.g. MPR forwarding), while others may
designate a forwarder of all received packets (or at least those
generated by known neighbors) within a 1-hop neighborhood broadcast
topology (e.g. E-CDS).
Duplicate packet detection is the most challenging and complex
portion of the SMF forwarding process and thus, it is RECOMMENDED as
a final step when possible. In general detection of received
duplicate packets to avoid forwarding the same packet multiple times
is necessary. However, in some cases (e.g., MPR), duplicate
detection of some non-forwarded packets is also needed to maintain
efficient forwarding. Details on different duplicate packet
detection and forwarding rules for CF, MPR, and E-CDS algorithms are
given later (TBD). The details for these classes of algorithms may
also apply to other similar algorithms.
Macker, editor & Design Team Expires December 3, 2005 [Page 8]
Internet-Draft SMF for MANET June 2005
4. SMF Duplicate Packet Detection
An important routing design difference between MANET interfaces and
many wired network interfaces is that forwarding out the same
physical interface a packet arrived on is normal operation. This
operation is often disallowed or discouraged in wired multicast
routing designs to avoid looping. Because of this MANET interface
characteristic, a fairly common requirement in MANET packet flooding
is that of duplicate packet detection. While this requires increased
per packet processing, it is deemed necessary in MANET-specific
multicasting. This section describes a basic SMF duplicate packet
detection mechanism and some alternative operational options as
considerations.
Detecting duplicate packets is fundamentally important in a MANET
packet flooding process. SMF SHOULD implement explicit detection of
duplicate multicast packets by a temporal packet identification
scheme. This is typically implemented by keeping a history of
previous received and forwarded packet identifiers for comparison
against recently forwarded multicast packets. Implementations SHOULD
also timeout stale histories for <sourceAddress::destinationAddress>
entries where new, non-duplicate packets have not been recently
received. Of course, the duplicate packet detection mechanism SHOULD
avoid keeping unnecessary state for packet flows such as those that
are locally generated or link local destinations that would not be
considered for forwarding.
There are various possible approaches to packet identification.
Possibilities include unique markings within packet header fields,
such as packet sequence numbering, or application of hash algorithms
or similar techniques to compactly and uniquely describe the history
of recently received packets. This document focuses on describing
simple, sequence-based schemes that can be accomplished without
additional (non-IP) encapsulation of packets and/or their content.
While hash-type approaches may be supportable by this specification,
early examination of these approaches indicated that computation
complexity may be prohibitive for per-packet processing on many
candidate MANET platforms (e.g., PDAs). Additionally, the
unavoidable "cache-miss" rates, while low for some traffic scenarios,
result in the potential penalty of false duplicate detection (and
thus packet loss) rather than the more benign penalty of additional
computation cycles as associated with most applications of hashing.
Additional packet encapsulation is also desired to be avoided so that
non-forwarding edge nodes within a MANET area may receive flooded
content without any additional software beyond that of a typical IP
stack.
Macker, editor & Design Team Expires December 3, 2005 [Page 9]
Internet-Draft SMF for MANET June 2005
4.1 SMF IPv4 Duplicate Packet Detection
The following section describes a sequence-based mechanism and
options for SMF IPv4 duplicate detection. IPv4 multicast packets
from a particular source are assumed to be marked with a temporally
unique identification number in the IPv4 header using the ID field
[RFC0791]. Unfortunately, in present operating system networking
kernels, this identification number (ID) for the IP header is not
always generated or applied in a consistent manner. In order to
build a working implementation without encapsulating packets, SMF
SHOULD provide a sequence generation and marking module that can
maintain and set a monotonically increasing IP ID field for locally-
generated multicast packets with independent sequence number spaces
applied on a <sourceAddress::destinationAddress> basis. When needed
on a local system or at a specific gateway this process will also
recalculate and replace a proper IP header checksum for the
formulated header.
Note that the presence of IPSec for candidate packet flows may
present the opportunity to leverage the additional, perhaps more
consistent, sequencing information of the IPSec header for unique
packet identification. To perform duplicate detection, SMF will
check the IPSec header's "sequence" field, in the context of the
packet's <sourceAddress::destinationAddress::security parameter index
(SPI)> tuple against a cache history of received packet identifiers.
The IPSec security association identifier is added to the
<sourceAddress::destinationAddress> tuple since IPSec sequencing is
be applied on a "per flow" basis, rather than just a source/
destination basis.
In general a packet is not forwarded if a duplicate entry is found.
If a duplicate is not found it will add a new identification entry to
the duplicate detection cache and send the packet on to the
forwarding process. Note some forwarding algorithms may require that
duplicates are marked when received from neighbor nodes, even when
forwarding isn't applicable. Multiple interface semantics may also
add some additional considerations to the forwarding process
depending upon the algorithm.
Although the use of the IPv4 ID field may be useful and practical for
some near-term usage, its adoption for widespread packet duplication
detection has some disadvantages. The main disadvantage is that the
use and interpretation of the field is known to be non-consistent
across operating systems. The ID field is also of limited size and
may provide less robust detection for high bandwidth applications
since 16-bit sequence wrap-around may occur relatively frequently if
it is not possible to achieve "per source/destination" sequencing.
As an alternative, the use of a header extension or encapsulated
Macker, editor & Design Team Expires December 3, 2005 [Page 10]
Internet-Draft SMF for MANET June 2005
header in future implementations may provide more flexibility and
consistency (see Section 4.3). Another advantage of using a header
extension (or other encapsulation, if determined absolutely
necessary) is that it would be possible for MANET gateway nodes to
assess whether packets entering a MANET area have already been
properly sequenced to avoid unnecessary re-injection of packets from
networks adjacent to the MANET area. We leave these design
alternatives to be further defined and discussed in future work. A
basic sequencing and marking design similar to the one we formulate
here can be easily adapted to work with future approaches or can be
bypassed when not needed.
4.2 SMF IPv6 Duplicate Packet Detection
The following section describes the mechanism and options for SMF
IPv6 duplicate detection. The core IPv6 header does not provide an
explicit identification header option such as the IPv4 ID field that
we can exploit for DPD. SMF defines two methods for IPv6use: a hop-
by-hop (HBH) DPD options header and the use of IPSec sequencing when
an IPSec header is present. SMF MUST provide a DPD "sequence"
marking module that can insert the HBH IPv6 header option defined for
locally generated MANET multicast. If the packet is not IPSEC
encapsulated, SMF will evaluate the DPD "sequence" in the context of
the packet's <sourceAddress::destinationAddress> tuple from the IPv6
header against a cached history of received IPv6 packet identifiers.
The use of IPSec may prevent the intermediate addition of a hop-by-
hop options header. Fortunately, IPSec headers are sequenced on a
<sourceAddress::destinationAddress::security parameter index (SPI)>
basis. The SPI field identifies the security association (SA) to
which the header applies. Thus, if the packet is IPSec encapsulated,
SMF MUST use the context of the <sourceAddress::destinationAddress::
SPI> and leverage the <ESP_seq_number> or <AH_seq_number> from the
IPv6 IPSec header as a packet identification method.
In either case, if a duplicate is not found SMF will add a new
identification entry to the duplicate detection cache and send the
packet on to the forwarding process. In general, the packet is not
considered a candidate for forwarding if a duplicate is detected.
But multiple interface semantics may add some additional
considerations to the forwarding process depending upon the
forwarding algorithm.
4.3 IPv6 SMF-DPD Header Option Format
(TBD)
Macker, editor & Design Team Expires December 3, 2005 [Page 11]
Internet-Draft SMF for MANET June 2005
5. Efficient Relay Set Mechanisms
As mentioned SMF MUST support CF-based forwarding as a baseline
forwarding mechanism when optimized relay set information is not
available. In CF mode, each node transmits a locally generated or
newly received packet exactly once. No additional information is
required for SMF to perform this function. The duplicate detection
technique mentioned in the previous section is critical to proper
operation and avoiding any "storms" of duplicate packet
retransmissions.
In the core requirements section, it was stated that SMF MUST support
the ability to adapt its forwarding status based upon relay set
information that is received dynamically during operation. In this
way SMF can provide an enhanced capability beyond CF flooding and
will reduce the level of contention and congestion within the MANET
multicast area. In this section we define control mechanisms and
interface primitives that allow SMF to support a variety of different
relay set algorithms and approaches.
5.1 MPR Forwarding Operation
There has been significant MANET work and experience in using the
concept of the multi-point relay (MPR) as defined in [RFC3626] for
providing efficient MANET flooding. The MPR flooding mechanism is
based upon the well-known MPR technique and specifies that only
selected MPRs are to retransmit packets received from upstream
selector nodes. It is well-known that source-specific MPRs compose a
connected dominating set and using S-MPR can significantly reduce
redundant retransmission of packets, especially in dense network
neighborhoods [JLMV02]. An implementation disadvantage of S-MPR is
that previous hop identification is required to make a proper
forwarding decision. This previous hop filtering requirement adds
some additional state and complexity to the design, but such
algorithm types should be supportable by SMF. Without some
encapsulation method, the previous hop in an IP forwarding process is
only identified by the MAC source address. To work with MPR type
algorithm the SMF protocol MUST obtain an MPR selector list of MAC
addresses and the current one-hop neighbor list. The selector list
provides the previous hop upstream neighbors for which the SMF node
has been selected as an MPR. The one-hop neighbor list is required
to provide discrimination of transmissions from nearby nodes which,
for whatever reason (e.g. poor or intermittent link quality) were not
considered neighbors in the MPR selection process. In the MPR
forwarding process, if a non-duplicate packet arrives from a
selector, the SMF node would perform forwarding for that packet. The
SMF node SHOULD not forward packets from non-selectors, although it
MUST mark duplicate detection state for packets received from valid,
Macker, editor & Design Team Expires December 3, 2005 [Page 12]
Internet-Draft SMF for MANET June 2005
symmetric one-hop neighbors. This additional provision avoids
unnecessary redundant (possibly significant) forwarding of traffic
back across portions of the network when MPR selection by neighboring
nodes results in differing MPR sets. An early prototype
implementation of such a MPR-based SMF capability was documented in
[MDC04]. For multiple interface implementations of MPR-based SMF,
additional state must be kept with respect to which incoming
interface(s) on which packets in the duplicate detection history
arrived. This will be further addressed in future revisions of this
document and is TBD for now.
5.2 E-CDS Forwarding Operation
More recently there has been interest in adapting alternative CDS
algorithms for MANET flooding that do not have the previous hop
dependency of the MPR algorithm. Algorithms such as an extended-CDS
(E-CDS) algorithm based upon [E-CDS] provide distributed, dynamic
election of reduced relay sets creating shared, non-source-specific
distribution trees. If elected as a forwarder in E-CDS, the SMF node
MUST forward any non-duplicate, received multicast traffic. There is
no need for an explicit previous network hop identifier or selector
list as in the case of MPR forwarding. Here, this type of algorithm
may simplify the forwarding and processing requirements per packet.
This issue will be further examined in experimentation.
Macker, editor & Design Team Expires December 3, 2005 [Page 13]
Internet-Draft SMF for MANET June 2005
6. SMF Multicast Border Gateway Considerations
TBD
Macker, editor & Design Team Expires December 3, 2005 [Page 14]
Internet-Draft SMF for MANET June 2005
7. Security Considerations
Gratuitous use of option headers can cause problems in routers.
Routers outside of MANET routing areas should ignore SMF header
options if encountered.
Authentication mechanisms to identify the source of an option header
should be considered to reduce vulnerability to a variety of attacks.
Additional security considerations TBD.
Macker, editor & Design Team Expires December 3, 2005 [Page 15]
Internet-Draft SMF for MANET June 2005
8. Acknowledgments
Many of the concepts and mechanisms used and adopted by SMF resulted
from many years of discussion of related work within the MANET
Working Group. There are obviously many people that have contributed
to past side discussions and related draft documents within the IETF.
In particular, the document is largely a group product of an SMF
design team within the IETF MANET Working Group.
SMF Design Team Contributors
Thomas Clausen
Charles Perkins
Brian Adamson
Justin Dean
Ian Chakeres
Chris Dearlove
Emmanual Baccelli
Et al
The RFC text was produced using Marshall Rose's xml2rfc tool.
Macker, editor & Design Team Expires December 3, 2005 [Page 16]
Internet-Draft SMF for MANET June 2005
9. References
9.1 Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
9.2 Informative References
[E-CDS] Ogier, R., "MANET Extension of OSPF Using CDS Flooding",
Proceedings of the 62nd IETF , March 2005.
[GJ79] Garey, M. and D. Johnson, "Computers and Intractability: A
Guide to the Theory of NP-Completeness.", Freeman and
Company , 1979.
[JLMV02] Jacquet, P., Laouiti, V., Minet, P., and L. Viennot,
"Performance of multipoint relaying in ad hoc mobile
routing protocols", Networking , 2002.
[MDC04] Macker, J., Dean, J., and W. Chao, "Simplified Multicast
Forwarding in Mobile Ad hoc Networks", IEEE MILCOM 2004
Proceedings , 2004.
[NTSC99] Ni, S., Tseng, Y., Chen, Y., and J. Sheu, "The Broadcast
Storm Problem in Mobile Ad hoc Networks", Proceedings Of
ACM Mobicom 99 , 1999.
[RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing
Protocol", 2003.
[RFC3684] Ogier, R., Templin, F., and M. Lewis, "Topology
Dissemination Based on Reverse-Path Forwarding", 2003.
[WC02] Williams, B. and T. Camp, "Comparison of Broadcasting
Techniques for Mobile Ad hoc Networks", Proceedings of ACM
Mobihoc 2002 , 2002.
Macker, editor & Design Team Expires December 3, 2005 [Page 17]
Internet-Draft SMF for MANET June 2005
Authors' Addresses
Joseph Macker
NRL
Code 5522
Washington, DC 20375
USA
Email: macker@itd.nrl.navy.mil
SMF Design Team
IETF
Email:
Macker, editor & Design Team Expires December 3, 2005 [Page 18]
Internet-Draft SMF for MANET June 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Macker, editor & Design Team Expires December 3, 2005 [Page 19]
