[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 RFC 6621

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/