[Docs] [txt|pdf|xml] [Tracker] [WG] [Email] [Diff1] [Diff2] [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
Intended status: Experimental                            SMF Design Team
Expires: May 20, 2008                                      IETF MANET WG
                                                       November 17, 2007


               Simplified Multicast Forwarding for MANET
                        draft-ietf-manet-smf-06

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 May 20, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).













Macker, editor & SMF Design Team  Expires May 20, 2008          [Page 1]


Internet-Draft                SMF for MANET                November 2007


Abstract

   This document describes a Simplified Multicast Forwarding (SMF)
   mechanism that provides basic IP multicast forwarding suitable for
   wireless mesh and mobile ad hoc network (MANET) use.  SMF specifies
   techniques for multicast duplicate packet detection (DPD) to assist
   the forwarding process.  SMF also specifies DPD maintenance and
   checking operations consistent with both IPv4 and IPv6.  SMF takes
   advantage of reduced relay sets for efficient MANET multicast
   forwarding within a mesh topology and the document describes protocol
   interaction with a number of approaches.  Candidate algorithms for
   selecting reduced relay sets and related discussion is provided in
   the Appendices.  Basic issues relating to the operation of multicast
   MANET border routers are discussed but ongoing work remains in this
   area beyond the scope of this document.


Table of Contents

   1.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  4
   2.  Introduction and Scope . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Abbreviations  . . . . . . . . . . . . . . . . . . . . . .  7
   3.  Applicability  . . . . . . . . . . . . . . . . . . . . . . . .  8
   4.  SMF Packet Processing and Forwarding . . . . . . . . . . . . .  9
   5.  SMF Duplicate Packet Detection . . . . . . . . . . . . . . . . 11
     5.1.  IPv6 Duplicate Packet Detection  . . . . . . . . . . . . . 12
       5.1.1.  IPv6 SMF-DPD Header Option . . . . . . . . . . . . . . 12
       5.1.2.  IPv6 Identification-based DPD Operation  . . . . . . . 14
       5.1.3.  IPv6 Hash-based DPD Operation  . . . . . . . . . . . . 16
     5.2.  IPv4 Duplicate Packet Detection  . . . . . . . . . . . . . 17
       5.2.1.  IPv4 Identification-based DPD Operation  . . . . . . . 18
       5.2.2.  IPv4 Hash-based DPD Operation  . . . . . . . . . . . . 19
     5.3.  Internal Hash Computation  . . . . . . . . . . . . . . . . 20
   6.  Reduced Relay Set Forwarding and Relay Selection Capability  . 21
   7.  SMF Neighborhood Discovery  Requirements . . . . . . . . . . . 23
     7.1.  SMF Relay Set Algorithm ID Message TLV . . . . . . . . . . 24
     7.2.  Router Priority Message TLV  . . . . . . . . . . . . . . . 24
     7.3.  Router Priority Address Block TLV  . . . . . . . . . . . . 25
   8.  SMF Border Gateway Considerations  . . . . . . . . . . . . . . 26
     8.1.  Forwarded Multicast Groups . . . . . . . . . . . . . . . . 26
     8.2.  Multicast Group Scoping  . . . . . . . . . . . . . . . . . 27
     8.3.  Interface with Exterior Multicast Routing Protocols  . . . 28
     8.4.  Multiple Border Routers  . . . . . . . . . . . . . . . . . 29
   9.  Non-SMF MANET Node Interaction . . . . . . . . . . . . . . . . 31
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 32
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 33
   12. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 34
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35



Macker, editor & SMF Design Team  Expires May 20, 2008          [Page 2]


Internet-Draft                SMF for MANET                November 2007


     13.1. Normative References . . . . . . . . . . . . . . . . . . . 35
     13.2. Informative References . . . . . . . . . . . . . . . . . . 35
   Appendix A.  Reduced Relay Set Forwarding Algorithms and
                Considerations  . . . . . . . . . . . . . . . . . . . 37
   Appendix B.  Source-based Multipoint Relay (S-MPR) . . . . . . . . 38
     B.1.  S-MPR Relay Set Selection  . . . . . . . . . . . . . . . . 38
     B.2.  S-MPR Forwarding Rules . . . . . . . . . . . . . . . . . . 38
     B.3.  S-MPR Neighborhood Discovery Requirements  . . . . . . . . 39
     B.4.  S-MPR Selection Algorithm  . . . . . . . . . . . . . . . . 39
       B.4.1.  MPR Node Selection Procedure . . . . . . . . . . . . . 40
   Appendix C.  Essential Connecting Dominating Set (E-CDS)
                Algorithm . . . . . . . . . . . . . . . . . . . . . . 41
     C.1.  E-CDS Relay Set Selection  . . . . . . . . . . . . . . . . 41
     C.2.  E-CDS Forwarding Rules . . . . . . . . . . . . . . . . . . 41
     C.3.  E-CDS Neighborhood Discovery Requirements  . . . . . . . . 42
     C.4.  E-CDS Selection Algorithm (2-Hop)  . . . . . . . . . . . . 43
   Appendix D.  Multipoint Relay Connected Dominating Set
                (MPR-CDS) Algorithm . . . . . . . . . . . . . . . . . 44
     D.1.  MPR-CDS Relay Set Selection  . . . . . . . . . . . . . . . 44
     D.2.  MPR-CDS Forwarding Rules . . . . . . . . . . . . . . . . . 44
     D.3.  MPR-CDS Neighborhood Discovery Requirements  . . . . . . . 45
     D.4.  MPR-CDS Selection Algorithm  . . . . . . . . . . . . . . . 45
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46
   Intellectual Property and Copyright Statements . . . . . . . . . . 47



























Macker, editor & SMF Design Team  Expires May 20, 2008          [Page 3]


Internet-Draft                SMF for MANET                November 2007


1.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].














































Macker, editor & SMF Design Team  Expires May 20, 2008          [Page 4]


Internet-Draft                SMF for MANET                November 2007


2.  Introduction and Scope

   MANET unicast routing protocol designs have demonstrated effective
   and efficient mechanisms to flood routing control plane packets
   throughout a wireless routing region.  For example, algorithms
   specified within [RFC3626]and [RFC3684] provide distributed methods
   of dynamically electing reduced relay sets that attempt to optimize
   control packet flooding of routing control packets amongst MANET
   routing peers.  Simplified Multicast Forwarding (SMF) extends the
   efficient flooding concept to the forwarding plane for IP multicast
   packets.  When localized, efficient flooding is deemed an effective
   technique, SMF provides an appropriate multicast forwarding
   capability.  The SMF baseline design limits the scope to basic, best
   effort multicast forwarding intended to be constrained within a MANET
   or wireless mesh routing region.  The main design goals of this SMF
   specification are to adapt efficient relay sets in MANET environments
   [RFC2901] and define the needed IPv4 and IPv6 multicast duplicate
   packet detection (DPD) mechanisms to support multi-hop, packet
   forwarding.  Figure 1 provides an overview of the logical SMF node
   architecture, consisting of "Neighborhood Discovery", "Relay Set
   Selection" and "Forwarding Process" components.  Typically, relay set
   selection (or self-election) will occur based on input from a
   neighborhood discovery process, and the forwarding process will be
   controlled by status based upon relay set selection.  Note the
   neighborhood discovery and/or relay set selection information MAY be
   obtained from a coexistent process (e.g., MANET unicast routing
   protocol using relay sets).  In some cases, the forwarding decision
   for a packet can also depend on previous hop or incoming interface
   information.  The asterisks (*) in Figure 1 mark the primitives and
   relationships needed by relay set algorithms requiring previous-hop
   packet forwarding knowledge.




















Macker, editor & SMF Design Team  Expires May 20, 2008          [Page 5]


Internet-Draft                SMF for MANET                November 2007


       ______________                _____________
      |              |              |             |
      | Neighborhood |              |  Relay Set  |
      |  Discovery   |------------->|  Selection  |
      |   Protocol   |   neighbor   |  Algorithm  |
      |______________|     info     |_____________|
             \                              /
              \                            /
       neighbor\                          /forwarding
         info*  \      ____________      /  status
                 \    |            |    /
                  `-->| Forwarding |<--'
                      |  Process   |
    ~~~~~~~~~~~~~~~~~>|____________|~~~~~~~~~~~~~~~~~>
    incoming packet,                 forwarded packets
    interface id, and
    previous hop*

           Fig. 1 - SMF Node Architecture

   Interoperable SMF implementations MUST use a common DPD approach and
   be able to process the header options defined in this document for
   IPv6 operation.  We define Classical Flooding (CF), as the simplest
   case of SMF multicast forwarding.  With CF, each SMF router forwards
   each received packet once.  In this case, the need for any relay set
   selection or neighborhood topology information is eliminated but DPD
   is still required.  While CF may be used, in general practice, a form
   of efficient relay set selection is RECOMMENDED.  An efficient,
   reduced relay set is realized by selecting a _subset_ of all possible
   SMF routers in a MANET routing region as the forwarding relay set.
   Known relay set selection algorithms have demonstrated the ability to
   provide and maintain a dynamic distribution mesh for forwarding user
   multicast data [MDC04].  A few such relay set selection algorithms
   are described in the Appendices of this document and the basic
   designs borrow directly from previous work.  Additional relay set
   algorithms or extensions may be specified in the future for use with
   SMF.

   Dynamic neighborhood topology information is needed to determine and
   maintain an optimized set of relay (forwarding) nodes.  Neighborhood
   topology discovery functions MAY be externally provided by a MANET
   unicast routing protocol or by using the MANET NeighborHood Discovery
   Protocol (NHDP) [NHDP] running in concurrence with SMF.
   Additionally, this specification does not preclude a lower protocol
   layer from providing necessary neighborhood information.
   Fundamentally, an SMF implementation SHOULD provide the ability for
   multicast forwarding state to be dynamically managed per operating
   network interface.  Some of the relay state maintenance options and



Macker, editor & SMF Design Team  Expires May 20, 2008          [Page 6]


Internet-Draft                SMF for MANET                November 2007


   interactions are outlined later in Section 6.  This document states
   specific requirements for neighborhood discovery with respect to the
   forwarding process and relay set selection algorithms described
   herein.  In the absence of a MANET unicast protocol or lower layer
   information interface, SMF relies on the MANET NHDP specification to
   assist in 2-hop neighborhood state discovery and maintenance for
   relay set election when not operating in a CF mode.

2.1.  Abbreviations

      MANET : Mobile Ad hoc Network

      SMF : Simplified Multicast Forwarding

      CF : Classical Flooding

      CDS : Connected Dominating Set

      MCDS : Minimum Connected Domination Set

      MPR : Multi-point Relay

      S-MPR: Source-based MPR

      CDS-MPR: CDS-based MPR

      E-CDS: Essential Connected Dominating Set

      DPD: Duplicate Packet Detection

      NHDP: Neighborhood Discovery Protocol

      I-DPD: Identification-based Duplicate Packet Detection

      H-DPD: Hash-based Duplicate Packet Detection

      HAV: Hash Assist Value

      FIB: Forwarding Information Base












Macker, editor & SMF Design Team  Expires May 20, 2008          [Page 7]


Internet-Draft                SMF for MANET                November 2007


3.  Applicability

   Within dynamic, mobile routing topologies, maintaining traditional
   forwarding trees to support a multicast routing protocol MAY not be
   sensible or needed.  A basic packet forwarding service that reaches
   all MANET SMF routers participating within a localized MANET routing
   region MAY provide a useful group communication mechanism for various
   classes of applications.  Applications that could take advantage of a
   simple multicast forwarding service within a MANET routing region
   include multimedia streaming, interactive group-based messaging and
   applications, peer-to-peer middleware multicasting, and multi-hop
   mobile discovery or registration services.

   Note again that Figure 1 provides a notional architecture for
   _typical_ MANET SMF-capable nodes.  However, a goal is that simple
   end-system (non-forwarding) wireless nodes may also participate in
   multicast traffic transmission and reception with standard IP network
   layer semantics (e.g., special or unnecessary encapsulation of IP
   packets should be avoided in this case).  A multicast border router
   or proxy mechanism MUST be used when deployed alongside more fixed-
   infrastructure IP multicast routing such Protocol Independent
   Multicast (PIM) variants [RFC3973] and [RFC4601].  With present
   experimental implementations, proxy methods have demonstrated gateway
   functionality at MANET border routers operating with external IP
   multicast routing protocols.  SMF may be extended or combined with
   other mechanisms to provide increased reliability and group specific
   filtering, but the details for this are not discussed here.
























Macker, editor & SMF Design Team  Expires May 20, 2008          [Page 8]


Internet-Draft                SMF for MANET                November 2007


4.  SMF Packet Processing and Forwarding

   The SMF Packet Processing and Forwarding actions are conducted with
   the following packet handling activities:

   1.  Processing of outbound, locally-generated multicast packets.

   2.  Reception and processing of inbound packets on a specific network
       interface(s).

   The purpose of intercepting outbound, locally-generated multicast
   packets is to enforce any of the DPD requirements described later so
   that proper forwarding may be conducted.

   Inbound multicast packets will be received by the SMF implementation
   and processed for possible forwarding.  This document does not
   presently support forwarding of directed broadcast addresses
   [RFC2644].  SMF implementations MUST be capable of forwarding packets
   for "global scope" multicast groups to support generic multicast
   application needs or to distribute designated multicast traffic that
   ingresses the MANET routing region via border routers.  The set of
   destination addresses to be forwarded will be maintained by an _a
   priori_ list or a dynamic forwarding information base (FIB) that may
   interact with future MANET dynamic group membership extensions.
   There will be a well-known multicast group for flooding to all SMF
   forwarders.  This multicast group is specified to contain all MANET
   SMF routers of a connected MANET routing region, so that packets
   transmitted to the multicast address associated with the group will
   be delivered to all connected SMF routers.  For IPv6, the multicast
   address is specified to be "site-local".  The name of the multicast
   group is "SL-MANET-ROUTERS".  Minimally SMF SHALL forward, as
   instructed by the relay set selection algorithm, unique (non-
   duplicate) packets received for this well-known group address when
   the TTL or hop count value in the IP header is greater than 1.  SMF
   SHALL forward all additional global scope addresses specified within
   the FIB as well.  In all cases, the following rules SHALL be observed
   for SMF multicast forwarding:

   1.  Multicast packets with TTL <= 1 MUST NOT be forwarded*.

   2.  Link local multicast packets MUST NOT be forwarded.

   3.  Incoming multicast packets with an IP source address matching one
       of those of the local SMF router interface(s) MUST NOT be
       forwarded.

   4.  Received packet frames with the MAC source address matching the
       local SMF router interface(s) MUST NOT be forwarded.



Macker, editor & SMF Design Team  Expires May 20, 2008          [Page 9]


Internet-Draft                SMF for MANET                November 2007


   5.  Received packets for which SMF cannot reasonably ensure temporal
       DPD uniqueness MUST NOT be forwarded.

   6.  When packets are forwarded, TTL or hop limit SHALL be decremented
       by one.

   Note that rule #3 is important because in wireless networks, the
   local SMF router may receive re-transmissions of its own packets when
   they are forwarded by neighboring nodes.  This rule avoids
   unnecessary retransmission of locally-generated packets even when
   other forwarding decision rules would apply.

   As mentioned in Section 10, there may be concern in some SMF
   deployments that bad-behaving nodes could conduct a denial-of-service
   attack by remotely "previewing" (e.g., via a directional receive
   antenna) packets that an SMF node would be forwarding and conduct a
   "pre-play" attack by transmitting the packet before the SMF node
   would otherwise receive it but with a reduced TTL (or Hop Limit)
   field value.  This form of attack could cause an SMF node to create a
   DPD entry that would block the proper forwarding of the valid packet
   (with correct TTL) through the SMF area.  A RECOMMENDED approach to
   prevent this attack, when it is a concern, would be to cache temporal
   packet TTL values along with the DPD state (hash value(s) and/or
   identifier).  Then, if a subsequent matching (with respect to DPD)
   packet arrives with a _larger_ TTL value than the packet that was
   previously forwarded, then SMF should forward the new packet _and_
   update the TTL cached with corresponding DPD state to the new, larger
   TTL value.  There may be some isolated, temporary cases where SMF may
   unnecessarily forward some duplicate packets using this approach, but
   those case are expected to be exceptional.

   Once these criteria have been met, an SMF implementation MUST examine
   a forwarding decision algorithm to determine the next steps in packet
   processing.  If the SMF implementation is operating in a classical
   flooding (CF) mode the forwarding decision is implicit after DPD
   uniqueness is determined.  Otherwise, a forwarding decision requires
   additional information, including interface specific relay set state.
   Relay set selection algorithms described later MAY be used to
   determine the local SMF router's status with respect to forwarding.
   Some algorithms control forwarding based on a relay set election and
   previous hop identifier (e.g.  S-MPR forwarding), while others
   designate the local SMF router as a forwarder of all neighbor packets
   based on the neighborhood topology (e.g.  Essential CDS (E-CDS) and
   MPR-CDS).  A specific SMF node within a deployment may perform
   redundant forwarding, but each forwarder MUST at a minimum support a
   distributed election process that ensures a consistent dynamic CDS.





Macker, editor & SMF Design Team  Expires May 20, 2008         [Page 10]


Internet-Draft                SMF for MANET                November 2007


5.  SMF Duplicate Packet Detection

   Duplicate packet detection (DPD) is a common requirement in MANET
   packet flooding because packets may be forwarded out the same
   physical interface upon which they arrived and nodes may also receive
   copies of previously-transmitted packets from other forwarding
   neighbors.  SMF implementations MUST detect and avoid forwarding
   duplicate multicast packets using a temporal packet identification
   scheme.  It is RECOMMENDED this be implemented by keeping a history
   of recently-processed multicast packets for comparison to incoming
   packets.  For both IPv4 and IPv6, this document describes two basic
   approaches to multicast duplicate packet detection: header content
   identification-based (I-DPD) and hash-based (H-DPD) duplicate
   detection.  The two approaches are described for experimental
   purposes.  Trade-offs of the two approaches to DPD may merit
   different consideration depending upon specific SMF deployment
   scenarios.  Because of the potential addition of a hop-by-hop option
   header with IPv6, SMF deployments MUST be configured to use a common
   mechanism and DPD algorithm.  The main difference between IPv4 and
   IPv6 SMF DPD specification is the avoidance of any additional header
   options or encapsulation in the IPv4 case.

   For each network interface, SMF implementations MUST maintain DPD
   packet state as needed to support the forwarding heuristics of the
   relay set algorithm used.  The specific requirements of several relay
   set selection algorithms and their forwarding rules are described in
   the Appendices of this document.  In general this involves keeping
   track of previously forwarded packets so that duplicates are not
   forwarded, but some relay techniques (e.g., S-MPR) may have
   additional considerations.

   For I-DPD, packets are identified using explicit identifiers from the
   IP header.  The specific identifier to use depends upon the IP
   protocol version and the type of packet.  For example, IPv4 provides
   an "Identification" field that may be used for DPD purposes, and
   packets that contain IPSec protocol headers also provide a suitable
   packet identifier.  These identifier fields are unique within the
   context of source address, destination address, protocol type, and/or
   other header fields depending upon the type of identifier used for
   DPD.  Similarly, for H-DPD, it is expected that packet hash values
   will be kept with respect to at least the source address to help
   ensure hash collision avoidance.  SMF implementations MUST maintain
   DPD history per the applicable packet flow context (e.g., <protocol:
   srcAddr:dstAddr> for DPD based upon IPv4 ID).  The details for I-DPD
   and H-DPD for different types of packets are described in the
   sections below.  In either case, this history SHOULD be kept long
   enough to span the maximum network traversal lifetime,
   MAX_PACKET_LIFETIME, of multicast packets being forwarded within an



Macker, editor & SMF Design Team  Expires May 20, 2008         [Page 11]


Internet-Draft                SMF for MANET                November 2007


   SMF operating area.  The required size of the DPD cache is governed
   by this timeout value and is also a function of the packet forwarding
   rates.  The DPD 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.

5.1.  IPv6 Duplicate Packet Detection

   This section describes the mechanisms and options for SMF IPv6 DPD.
   The core IPv6 packet header does not provide any explicit
   identification header field that can be exploited for I-DPD.  The
   following areas are described to support IPv6 DPD:

   1.  a hop-by-hop SMF-DPD option header (with supporting identifier or
       hash assistance value),

   2.  the use of IPv6 fragment header fields for I-DPD when they exist,

   3.  the use of IPSec sequencing for I-DPD when a non-fragmented,
       IPSec header is detected, and

   4.  an H-DPD approach assisted, as needed, by the SMF-DPD option
       header.

   SMF MUST provide a DPD marking module that can insert the hop-by-hop
   IPv6 header option defined in this section.  This process MUST come
   after any source-based fragmentation that may occur with IPv6.  As
   with IPv4, SMF IPv6 DPD is presently specified to allow either a
   packet hash or header identification method for DPD.  An SMF
   implementation MUST be configured to operate either in H-DPD or I-DPD
   mode and perform the appropriate routines outlined in the following
   sections.

5.1.1.  IPv6 SMF-DPD Header Option

   As previously mentioned, the base IPv6 packet header does not contain
   a unique identifier suitable for DPD.  This section defines an IPv6
   hop-by-hop header option to serve this purpose for IPv6 I-DPD.
   Additionally, the header option provides an opportunity to help
   guarantee non-collision of hash values for different packets when
   H-DPD is used.  This header option format supports both of these
   purposes.

   The first bit of the data field of the SMF-DPD option is the "H-bit"
   that determines the format of the data field.  Two different formats
   are supported.  When the "H-bit" is cleared (zero value), the SMF-DPD
   format to support I-DPD operation is specified as shown in Figure 5
   and defines the extension header in accordance with [RFC2460].



Macker, editor & SMF Design Team  Expires May 20, 2008         [Page 12]


Internet-Draft                SMF for MANET                November 2007


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     ...              |0|0|0| OptType | Opt. Data Len |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|TidTyp|TidLen|             TaggerId (optional) ...           |
      +-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               |            Identifier  ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Fig. 5 - IPv6 SMF-DPD Header Option in I-DPD mode
   The "TidType" is a 3-bit field indicating the presence and type of
   the optional "TaggerId" field.  The optional "TaggerId" is used to
   differentiate multiple ingressing border gateways that may commonly
   apply the SMF-DPD option header to packets from a particular source.
   This is provided for experimental purposes.  The following table
   lists the valid TaggerId types:

   +---------+-------+-------------------------------------------------+
   | Name    | Value | Purpose                                         |
   +---------+-------+-------------------------------------------------+
   | NULL    | 0     | Indicates no "taggerId" field is present.       |
   |         |       | "TidLen" MUST also be set to ZERO.              |
   |         |       |                                                 |
   | DEFAULT | 1     | A "TaggerId" of non-specific context is         |
   |         |       | present.  "TidLen + 1" defines the length of    |
   |         |       | the TaggerId field in bytes.                    |
   |         |       |                                                 |
   | IPv4    | 2     | A "TaggerId" representing an IPv4 address is    |
   |         |       | present.  The "TidLen" MUST be set to 3.        |
   |         |       |                                                 |
   | IPv6    | 3     | A "TaggerId" representing an IPv6 address is    |
   |         |       | present.  The "TidLen" MUST be set to 15.       |
   |         |       |                                                 |
   | ExtId   | 7     | RESERVED FOR FUTURE USE (possible extended ID)  |
   +---------+-------+-------------------------------------------------+

   This format allows a quick check of the "TidType" field to determine
   if a "TaggerId" field is present.  If the <TidType> is NULL, then the
   length of the DPD packet <Identifier> field corresponds to the (<Opt.
   Data Len> - 1).  If the <TidType> is non-NULL, then the length of the
   "TaggerId" field is equal to (<TidLen> - 1) and the remainder of the
   option data comprises the DPD packet <Identifier> field.  When the
   "TaggerId" field is present, the <Identifier> field can be considered
   a unique packet identifier in the context of the <taggerId:srcAddr:
   dstAddr> tuple.  When the "TaggerId" field is not present, then it is
   assumed the source host applied the SMF-DPD option and the
   <Identifier> can be considered unique in the context of the IPv6



Macker, editor & SMF Design Team  Expires May 20, 2008         [Page 13]


Internet-Draft                SMF for MANET                November 2007


   packet header <srcAddr:dstAddr> tuple.  Details on IPV6 I-DPD
   operation are described in Section 5.1.2.

   When the "H-bit" in the SMF-DPD option data is set, the data content
   value is interpreted as a Hash-Assist Value (HAV) used to facilitate
   H-DPD operation.  In this case, source hosts or ingressing gateways
   apply the SMF-DPD with a HAV only when required to differentiate the
   hash value of a new packet with respect to older packets in the
   current DPD history cache.  This helps to guarantee the uniqueness of
   generated hash values when H-DPD is used.  Additionally, this also
   avoids the added overhead of applying the SMF-DPD option header to
   every packet.  For many hash algorithms, it is expected that only
   sparse use of the SMF-DPD option may be required.  The following
   table illustrates the format of the SMF-DPD header option for H-DPD
   operation:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     ...              |0|0|0| OptType | Opt. Data Len |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|    Hash Assist Value (HAV) ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Fig. 6 - IPv6 SMF-DPD Header Option in H-DPD mode
   The SMF-DPD option should be applied with a HAV to produce a unique
   hash digest for packets within the context of the IPv6 packet header
   <srcAddr>.  The size of the HAV field is implied by the "Opt. Data
   Len".  The appropriate size of the field depends upon the collision
   properties of the specific hash algorithm used.  More details on IPv6
   H-DPD operation are provided in Section 5.1.3.

5.1.2.  IPv6 Identification-based DPD Operation

   The following table summarizes the IPv6 I-DPD processing approach.
   Within the table '*' indicates a don't care condition.















Macker, editor & SMF Design Team  Expires May 20, 2008         [Page 14]


Internet-Draft                SMF for MANET                November 2007


                        IPv6 I-DPD Processing Rules

   +-------------+-----------+-----------+-----------------------------+
   | IPv6        | IPv6      | IPv6      | SMF IPv6 I-DPD Mode Action  |
   | Fragment    | IPSEC     | I-DPD     |                             |
   | Header      | Header    | Header    |                             |
   +-------------+-----------+-----------+-----------------------------+
   | Present     | *         | *         | Use Fragment Header I-DPD   |
   |             |           |           | Check and Process for       |
   |             |           |           | Forwarding                  |
   |             |           |           |                             |
   | Not Present | Present   | *         | Use IPSEC Header I-DPD      |
   |             |           |           | Check and Process for       |
   |             |           |           | Forwarding                  |
   |             |           |           |                             |
   | Present     | *         | Present   | Invalid, do not Forward     |
   |             |           |           |                             |
   | Not Present | Present   | Present   | Invalid, do not Forward     |
   |             |           |           |                             |
   | Not Present | Not       | Not       | Add I-DPD Header,and        |
   |             | Present   | Present   | Process for Forwarding      |
   |             |           |           |                             |
   | Not Present | Not       | Present   | Use I-DPD Header Check and  |
   |             | Present   |           | Process for Forwarding      |
   +-------------+-----------+-----------+-----------------------------+

   If the IPv6 multicast packet is an IPv6 fragment, SMF MUST use the
   fragment extension header fields for packet identification.  This
   identifier can be considered unique in the context of the <srcAddr:
   dstAddr> of the IP packet.  If the packet is an unfragmented IPv6
   IPSEC packet, SMF MUST use IPSec fields for packet identification.
   The IPSec header <sequence> field can be considered a unique
   identifier in the context of the <IPSecType:srcAddr:dstAddr:SPI>
   where the "IPSecType" is either AH or ESP.  For unfragmented, non-
   IPSec, IPv6 packets, the use of the SMF DPD header option is
   necessary to support I-DPD operation.  The SMF DPD header option is
   applied in the context of the <srcAddr> of the IP packet.  End
   systems or ingressing SMF gateways are responsible for applying this
   option to support DPD.  The following table summarizes these packet
   identification types:











Macker, editor & SMF Design Team  Expires May 20, 2008         [Page 15]


Internet-Draft                SMF for MANET                November 2007


                 *IPv6 I-DPD Packet Identification Types*

   +-----------+---------------------------------+---------------------+
   | IPv6      | Packet DPD ID Context           | Packet DPD ID       |
   | Packet    |                                 |                     |
   | Type      |                                 |                     |
   +-----------+---------------------------------+---------------------+
   | Fragment  | <srcAddr:dstAddr>               | <fragmentOffset:id> |
   |           |                                 |                     |
   | IPSec     | <IPSecType:srcAddr:dstAddr:SPI> | <sequence>          |
   | Packet    |                                 |                     |
   |           |                                 |                     |
   | Regular   | <[taggerId:]srcAddr:dstAddr>    | <SMF-DPD option     |
   | Packet    |                                 | header id>          |
   +-----------+---------------------------------+---------------------+

   "IPSecType" is either Authentication Header (AH) or Encapsulating
   Security Payload (ESP).

   The "taggerId" is an optional feature of the IPv6 SMF-DPD header
   option.

5.1.3.  IPv6 Hash-based DPD Operation

   A default hash-based DPD approach (H-DPD) for use by SMF is specified
   as follows.  An MD5 [RFC1321] hash of the non-mutable header fields,
   options fields, and data content of the IPv6 multicast packet is used
   to produce a 128-bit digest.  The lower 64 bits of this digest
   (MD5_64) is used for SMF packet identification.  The approach for
   calculating this hash value SHOULD follow the same guidelines
   described for calculating the Integrity Check Value (ICV) described
   in [RFC4302] with respect to non-mutable fields.  This approach
   should have a reasonably low probability of digest collision when
   packet headers and content are varying.  MD5 is being applied in SMF
   only to provide a low probability of collision and is not being used
   for cryptographic or authentication purposes.  A history of the
   packet hash values SHOULD be maintained within the context of the
   IPv6 packet header <srcAddr>.  This history is used by forwarding SMF
   nodes (non-ingress points) to avoid forwarding duplicates.  SMF
   ingress points (i.e., source hosts or gateways) use this history to
   confirm that new packets are unique with respect to their hash value.
   The Hash-assist Value (HAV) field described in Section 5.1.1 is
   provided as a differentiating field when a digest collision would
   otherwise occur.  Note that the HAV is an immutable option field and
   SMF MUST use any included H-DPD hash assist value (HAV) option header
   (see Section 5.1.1) in its hash calculation.

   If a packet results in a digest collision (i.e., by checking the



Macker, editor & SMF Design Team  Expires May 20, 2008         [Page 16]


Internet-Draft                SMF for MANET                November 2007


   H-DPD digest history) within the limited history kept by SMF
   forwarders, the packet should be silently dropped.  If a digest
   collision is detected at an SMF ingress point (i.e., including SMF-
   aware sources), the H-DPD option header is applied with a HAV.  The
   packet is retested for collision and the HAV is re-applied as needed
   to produce a non-colliding hash value.  The multicast packet is then
   forwarded with the added IPv6 SMF-DPD header option.

   The MD5 indexing and IPv6 HAV approaches are specified at present for
   consistency and robustness to suit experimental application.  Future
   approaches and experimentation may discover designs tradeoffs in hash
   robustness and efficiency worth considering.  This MAY include
   reducing the maximum payload length that is processed, determining
   shorter indexes, or applying more efficient hashing algorithms.  Use
   of the HAV may allow for application of "lighter-weight" hashing
   techniques that might have been not considered due to poor collision
   properties otherwise.

5.2.  IPv4 Duplicate Packet Detection

   This section describes the mechanisms and options for IPv4 DPD.  The
   IPv4 packet header 16-bit "Identification" field MAY be used for DPD,
   but its limitations may require alternative approaches in some
   situations.  The following areas are described to support IPv4 DPD::

   1.  the use of IPv4 fragment header fields for I-DPD when they exist,

   2.  the use of IPSec sequencing for I-DPD when a non-fragmented IPv4
       IPSec packet is detected, and

   3.  a H-DPD approach.

   A specific SMF-DPD marking option is not specified for IPv4 since
   header options are not as tractable for end systems as for IPv6.
   IPv4 packets from a particular source are assumed to be marked with a
   temporally unique value in the "Identification" field of the packet
   header that can serve for SMF DPD purposes.  However, in present
   operating system networking kernels, the IPv4 header "Identification"
   value is not always generated properly, especially when the "don't
   fragment" (DF) bit is set.  The IPv4 I-DPD mode of this specification
   requires that IPv4 "Identification" fields are managed reasonably by
   source hosts and that temporally unique values are set within the
   context of the packet header <protocol:srcAddr:dstAddr> tuple.  If
   this is not expected during an SMF deployment, then it is RECOMMENDED
   that the H-DPD method be used as a more reliable approach.

   Since IPv4 SMF does not specify an options header, the
   interoperability constraints are looser than the IPv6 version and



Macker, editor & SMF Design Team  Expires May 20, 2008         [Page 17]


Internet-Draft                SMF for MANET                November 2007


   forwarders may be operate with mixed H-DPD and I-DPD modes as long as
   they consistently perform the appropriate DPD routines outlined in
   the following sections.  However, it is RECOMMENDED that a deployment
   be configured with a common mode for operational consistency.

5.2.1.  IPv4 Identification-based DPD Operation

   The following table summarizes the IPv4 I-DPD processing approach
   once a packet has passed the basic forwardable criteria described in
   earlier SMF sections.  Within the table '*' indicates a don't care
   condition.

   +----+----+----------+---------+------------------------------------+
   | df | mf | fragment | IPSEC   | IPv4 I-DPD Action                  |
   |    |    | offset   |         |                                    |
   +----+----+----------+---------+------------------------------------+
   | 1  | 1  | *        | *       | Invalid, Do Not Forward            |
   |    |    |          |         |                                    |
   | 1  | 0  | nonzero  | *       | Invalid, Do Not Forward            |
   |    |    |          |         |                                    |
   | *  | 0  | zero     | not     | Tuple I-DPD Check and Process for  |
   |    |    |          | Present | Forwarding                         |
   |    |    |          |         |                                    |
   | *  | 0  | zero     | Present | IPSEC enhanced Tuple I-DPD Check   |
   |    |    |          |         | and Process for Forwarding         |
   |    |    |          |         |                                    |
   | 0  | 0  | nonzero  | *       | Extended Fragment Offset Tuple     |
   |    |    |          |         | I-DPD Check and Process for        |
   |    |    |          |         | Forwarding                         |
   |    |    |          |         |                                    |
   | 0  | 1  | zero or  | *       | Extended Fragment Offset Tuple     |
   |    |    | nonzero  |         | I-DPD Check and Process for        |
   |    |    |          |         | Forwarding                         |
   +----+----+----------+---------+------------------------------------+

   For performance reasons, IPv4 network fragmentation and reassembly of
   multicast packets within wireless MANET networks should be minimized,
   yet SMF provides the forwarding of fragments when they occur.  If the
   IPv4 multicast packet is a fragment, SMF MUST use the fragmentation
   header fields for packet identification.  This identification can be
   considered temporally unique in the context of the <protocol:srcAddr:
   dstAddr> of the IPv4 packet.  If the packet is an unfragmented IPv4
   IPSEC packet, SMF MUST use IPSec fields for packet identification.
   The IPSec header <sequence> field can be considered a unique
   identifier in the context of the <IPSecType:srcAddr:dstAddr:SPI>
   where the "IPSecType" is either AH or ESP.  Finally, for
   unfragmented, non-IPSec, IPv4 packets, the "Identification" field can
   be used for I-DPD purposes.  The "Identification" field can be



Macker, editor & SMF Design Team  Expires May 20, 2008         [Page 18]


Internet-Draft                SMF for MANET                November 2007


   considered unique in the context of the IPv4 <protocol:scrAddr:
   dstAddr> tuple.  The following table summarizes these packet
   identification types:

                 *IPv4 I-DPD Packet Identification Types*

   +-----------+---------------------------------+---------------------+
   | IPv4      | Packet Identification Context   | Packet Identifier   |
   | Packet    |                                 |                     |
   | Type      |                                 |                     |
   +-----------+---------------------------------+---------------------+
   | Fragment  | <protocol:srcAddr:dstAddr>      | <fragmentOffset:id> |
   |           |                                 |                     |
   | IPSec     | <IPSecType:srcAddr:dstAddr:SPI> | <sequence>          |
   | Packet    |                                 |                     |
   |           |                                 |                     |
   | Regular   | <protocol:srcAddr:dstAddr>      | <id>                |
   | Packet    |                                 |                     |
   +-----------+---------------------------------+---------------------+

   "IPSecType" is either Authentication Header (AH) or Encapsulating
   Security Payload (ESP).

   The limited size (16 bits) of the IPv4 header "Identification" field
   may result in the value rapidly wrapping, particularly if a common
   sequence space is used by a source for multiple destinations.  If
   I-DPD operation is required, the use of the "internal hashing"
   technique described in Section 5.3 may mitigate this limitation of
   the IPv4 "Identification" field for SMF DPD.  In this case the
   "internal hash" value would be concatenated with the "Identification"
   value for I-DPD operation.

5.2.2.  IPv4 Hash-based DPD Operation

   To ensure consistent IPv4 H-DPD operation among SMF nodes, a default
   hashing approach is specified.  This is similar to that specified for
   IPv6, but the H-DPD header option with HAV is not considered.  SMF
   MUST perform an MD5 [RFC1321] hash of the immutable header fields,
   option fields and data content of the IPv4 multicast packet resulting
   in a 128-bit digest.  The lower 64 bits of this digest (MD5_64) is
   used for SMF packet identification.  The approach for calculating the
   hash value SHOULD follow the same guidelines described for
   calculating the Integrity Check Value (ICV) described in [RFC4302]
   with respect to non-mutable fields.  A history of the packet hash
   values SHOULD be maintained in the context of <protocol:srcAddr:
   dstAddr>.  The context for IPv4 is more specific than that of IPv6
   since the SMF-DPD HAV cannot be employed to mitigate hash collisions.




Macker, editor & SMF Design Team  Expires May 20, 2008         [Page 19]


Internet-Draft                SMF for MANET                November 2007


   The MD5 hash is specified at present for consistency and robustness.
   Future approaches and experimentation may discover designs tradeoffs
   in hash robustness and efficiency worth considering for future
   versions of SMF.  This MAY include reducing the packet payload length
   that is processed, determining shorter indexes, or applying a more
   efficient hashing algorithm.

5.3.  Internal Hash Computation

   Forwarding protocols that use DPD techniques, such as SMF, may be
   vulnerable to denial-of-service (DoS) attacks based on spoofing
   packets with apparently valid packet identifier fields.  Such a
   consideration is pointed out in Section 10.  In wireless environments
   where SMF will most likely be used, the opportunity for badly-
   behaving nodes to conduct such attacks is more prevalent than in
   wired networks.  In the case of IPv4 packets, fragmented IP packets
   or packets with IPSec headers applied, the DPD "identifier" of
   potential future packets that might be forwarded is very predictable
   and easily subject to denial-of-service attacks against forwarding.
   A RECOMMENDED technique to counter this concern is for SMF
   implementations to generate an "internal" hash value that is
   concatenated with the explicit I-DPD packet identifier to form a
   unique identifier that is a function of the packet content as well as
   the visible identifier.  SMF implementations could seed their hash
   generation with a random value to make it unlikely that an external
   observer could guess how to spoof packets used in a denial-of-service
   attack against forwarding.  Since the hash computation and state is
   kept completely internal to SMF nodes, the cryptographic properties
   of this hashing would not need to be extensive and thus possibly of
   low complexity.  Experimental implementations may determine that a
   lightweight hash of even only portions of packets may suffice to
   serve this purpose.

   For IPv4 I-DPD based on the limited 16-bit "Identification" field, it
   is possible that use of this "internal hash" technique may also
   enhance I-DPD performance in cases where the IPv4 "Identification"
   field may wrap quickly due to the source supporting high data rate
   flows.

   While H-DPD is not as readily susceptible to this form of DoS attack,
   it is possible that a sophisticated adversary could use side
   information to construct spoofing packets to mislead forwarders using
   a well-known hash algorithm.  Thus, similarly, a separate "internal"
   hash value could be concatenated with the well-known hash value to
   alleviate this security concern.






Macker, editor & SMF Design Team  Expires May 20, 2008         [Page 20]


Internet-Draft                SMF for MANET                November 2007


6.  Reduced Relay Set Forwarding and Relay Selection Capability

   SMF MUST support CF-based forwarding as a basic forwarding mechanism
   when reduced relay set information is not available or not selected
   for operation.  In CF mode, each node transmits a locally generated
   or newly received packet exactly once.  The DPD techniques described
   in Section 5 are critical to proper operation and prevent duplicate
   packet retransmissions by the same forwarding node.

   A goal of SMF is to apply reduced relay sets for more efficient
   multicast dissemination within dynamic topologies.  To accomplish
   this SMF MUST support the ability to modify its multicast packet
   forwarding rules based upon relay set state received dynamically
   during operation.  In this way, SMF forwarding can continue to
   operate effectively as neighbor adjacencies or multicast forwarding
   policies within the topology change.

   In early SMF experimental deployments, the relay set information has
   been derived from a coexistent unicast MANET protocol calculation of
   a reduced relay set for control plane traffic.  From this experience,
   extra pruning considerations are sometimes required when utilizing a
   relay set from a independent routing protocol process, since a relay
   set formed for the unicast control plane flooding MAY include a more
   redundant set of nodes than desired for multicast forwarding use
   (e.g., biconnected control plane CDS meshes).

   Here is a recommended criteria list for relay set selection algorithm
   candidates:

   1.  Robustness to topological dynamics and mobility

   2.  Localized election or coordination of any relay sets

   3.  Heuristic support for preference or election metrics (Better
       enables scenario-specific management of relay set)

   Some relay set algorithms meeting these criteria are described in the
   Appendices of this document.  Different algorithms may be more
   suitable for different MANET routing types or deployments.
   Additional relay set selection algorithms may be specified in
   separate specifications in the future.  The Appendices in this
   document can serve as a template for the content of such potential
   future specifications.

   Figure 7 depicts a state information diagram of possible relay set
   control options.  There are basically three style of SMF operation
   with reduced relay sets as follows.




Macker, editor & SMF Design Team  Expires May 20, 2008         [Page 21]


Internet-Draft                SMF for MANET                November 2007


   1.  Unicast dependent operation with a coexisting MANET unicast
       routing protocol in which the relay set state is derived from the
       unicast control plane CDS information.

   2.  Unicast independent operation in which SMF performs its own Relay
       Set Selection and derives dynamic neighborhood information from a
       MANET NHDP process.  In this case, additional TLV definitions for
       related CDS collection SHOULD be used as discussed in Section 7.

   3.  Possible crosslayer implementation that uses L2 neighborhood
       information and possible triggers to assist the dynamic relay set
       selection and maintenance process.



                        Possible L2 Trigger/Information
                                      |
                                      |
 ______________                _______v_____         __________________
|    MANET     |              |             |       |                  |
| Neighborhood |              |  Relay Set  |       | Other Heuristics |
|  Discovery   |------------->|  Selection  |<------| (Preference,etc) |
|   Protocol   |   neighbor   |  Algorithm  |       |                  |
|______________|     info     |_____________|       |__________________|
       \                              /
        \                            /
 neighbor\                          / Dynamic Relay
   info*  \      ____________      /    Set Status
           \    |    SMF     |    / (State, {neighbor info})
            `-->| Relay Set  |<--'
                |   State    |
             -->|____________|
            /
           /
 ______________
|  Coexistent  |
|    MANET     |
|   Unicast    |
|   Process    |
|______________|


        Fig. 7 - SMF Relay Set Control Options








Macker, editor & SMF Design Team  Expires May 20, 2008         [Page 22]


Internet-Draft                SMF for MANET                November 2007


7.  SMF Neighborhood Discovery  Requirements

   In absence of a compatible, coexisting unicast routing protocol or
   lower layer protocol providing neighborhood topology information
   sufficient for relay set selection, this section defines the issues
   and additional requirements for a MANET Neighborhood Discovery
   Protocol (NHDP) that MAY be used by SMF nodes.

   With respect to neighborhood topology knowledge and/or discovery,
   there are three basic modes of SMF operation:

   1.  Classical Flooding (CF) mode: with no requirements for discovery
       or knowledge of neighborhood topology,

   2.  External CDS control mode: an external process dynamically
       determines the local SMF relay status (e.g., SMF prototypes have
       leveraged neighborhood topology information collected by MANET
       unicast routing protocol instantiations), and

   3.  Independent CDS control mode: SMF uses the MANET Neighborhood
       Discovery Protocol (NHDP) [NHDP] to collect localized link
       information required for the various CDS algorithm modes
       discussed in the Appendices.

   Core NHDP messages and the neighborhood information base are
   described separately within the NHDP specification (IETF work in
   progress).  In this mode, SMF uses and relies upon an implementation
   of NHDP.  The NHDP protocol provides the following basic functions:

   1.  1-hop Neighbor link sensing: maintaining neighbor lists and
       performing bidirectionality checks of neighbor links

   2.  2-hop Neighborhood Discovery: collecting 2-hop bidirectional
       neighborhood information and any information relevant to relay
       set election

   3.  The collection and maintenance of the above information across
       multiple interfaces.

   4.  Relay Set Signaling: signal relay set selection to neighbor nodes
       if the relay set algorithm requires such information

   The Appendices discuss a set of implemented SMF CDS approaches that
   may be needed by an NHDP implementation to support each approach.
   The following subsections define TLVs consistent with [PacketBB]that
   SHOULD be used when deploying SMF in Independent CDS control mode.





Macker, editor & SMF Design Team  Expires May 20, 2008         [Page 23]


Internet-Draft                SMF for MANET                November 2007


7.1.  SMF Relay Set Algorithm ID Message TLV

   The following TLV, SMF_RELAYALG_ID, is used within NHDP messages to
   provide an indicator of the operating relay set selection algorithm.
   When NHDP messages are used by SMF for independent CDS control mode a
   SMF_RELAYALG_ID TLV SHOULD be included.  Nodes receiving a NHDP
   message with a SMF_RELAYALG_ID value differing from its own type the
   entire message SHOULD NOT be used for relay set processing.

   type=SMF_RELAYALG_ID, length=1 byte, value = <id>

   <id> is an 8 bit value identifying the present relay algorithm of the
   SMF node represented by the originator address of the NHDP message.

   Values are defined in Table 6.  The table provides present value
   assignments, future IANA reserved space, and an experimental space.
   Experimental space use MUST not assume uniqueness properties and
   should be used only for experimentation prior to any IANA
   assignment..

     +---------------------+----------------------------------------+
     |        Value        |                Algorithm               |
     +---------------------+----------------------------------------+
     |          0          |                  S-MPR                 |
     |                     |                                        |
     |          1          |                  E-CDS                 |
     |                     |                                        |
     |          2          |                 MPR-CDS                |
     |                     |                                        |
     |        3-127        |     Reserved for Future Assignment     |
     |                     |                                        |
     |       128-255       |           Experimental Space           |
     +---------------------+----------------------------------------+

                                  Table 6

7.2.  Router Priority Message TLV

   For some relay set election operations, a value of Router Priority
   (RtrPri) must be given or assumed for each address with the two-hop
   neighborhood which is consistent for all nodes.  More specific
   discussions are provided in the Appendices.

   The following TLV communicates router priority values among 1-hop
   router neighbors.

   type=SMF_RTR_PRI, length=1 byte, value = <priority>




Macker, editor & SMF Design Team  Expires May 20, 2008         [Page 24]


Internet-Draft                SMF for MANET                November 2007


   <priority> is an 8 bit field which contains a number 0-255 which
   represents RtrPri value of the node represented by the originator
   address of the NHDP message.

   Message TLVs of type SMF_RTR_PRI SHOULD only be used within NHDP
   messages.

7.3.  Router Priority Address Block TLV

   For some relay set election operations, a value of Router Priority
   (RtrPri) must be given or assumed for each address with the two-hop
   neighborhood that is consistent for all nodes.  More specific
   discussions are provided in the Appendices.

   The following TLV is defined to support the communication of router
   priority values between 2-hop router neighbors.  When generating
   address block TLV router priority messages the RtrPri values included
   MUST be consistent with advertised values contained within previously
   received router priority message TLVs.

   type=SMF_RTR_PRI, length=<num_addresses> bytes, value = <priorities>

   <num_addresses> is the number of addresses which the TLV applies to.
   This value MUST be consistent with the TLV semantics, length, and
   index fields.

   <priorities> is a single or multivalue field containing a <priority>
   value field for each node represented by the address(es) the TLV
   applies to.

   +---------------------+-------+-------------------------------------+
   |       Mnemonic      | Value | Description                         |
   +---------------------+-------+-------------------------------------+
   |   SMF_ALGORITHM_ID  |  TBD  | A message TLV which contains the an |
   |                     |       | id value representing the algorithm |
   |                     |       | being used by the originator        |
   |                     |       | address in the NHDP message         |
   |                     |       |                                     |
   | SMF_ROUTER_PRIORITY |  TBD  | A message TLV or address block TLV  |
   |                     |       | which contains a router priority    |
   |                     |       | value for each node represented by  |
   |                     |       | the associated address(es).         |
   +---------------------+-------+-------------------------------------+

                                  Table 7






Macker, editor & SMF Design Team  Expires May 20, 2008         [Page 25]


Internet-Draft                SMF for MANET                November 2007


8.  SMF Border Gateway Considerations

   It is expected that SMF will be used to provide simple forwarding of
   multicast traffic _within_ a MANET mesh routing topology.  A border
   router approach should be used to allow interconnection of SMF areas
   with networks using other multicast routing protocols (e.g., PIM).
   It is important to note that there are many scenario-specific issues
   that should be addressed when discussing border routers.  At the
   present time, experimental deployments of SMF and PIM border router
   approaches are being used.

   Some of the functionality border routers may need to address include
   the following:

   1.  Determining which multicast groups should transit the border
       router whether entering or exiting the attached MANET routing
       region(s).

   2.  Enforcement of TTL threshold or other scoping policies.

   3.  Any marking or labeling to enable DPD on ingressing packets.

   4.  Interface with exterior multicast routing protocols.

   5.  Possible operation with multiple border routers (presently beyond
       scope of this document).

   6.  Provisions for participating non-SMF nodes.

   Note the behavior of border router SMF nodes is the same as that of
   non-border SMF nodes when forwarding packets on interfaces within the
   MANET routing region.  Packets that are passed outbound to interfaces
   operating fixed-infrastructure multicast routing protocols SHOULD be
   evaluated for duplicate packet status since present standard
   multicast forwarding mechanisms do not usually perform this function.

8.1.  Forwarded Multicast Groups

   Determining which groups should be forwarded into a MANET SMF routing
   region is an evolving technology area.  Ideally, only groups for
   which there is active group membership should be injected into the
   SMF domain.  This might be accomplished by providing an IPv4 Internet
   Group Membership Protocol (IGMP) or IPV6 Multicast Listener Discovery
   (MLD) proxy protocol so that MANET SMF nodes can inform attached
   border routers (and hence multicast networks) of their current group
   membership status.  For specific systems and services it may be
   possible to statically configure group membership joins in border
   routers, but it is RECOMMENDED that some form of IGMP/MLD proxy or



Macker, editor & SMF Design Team  Expires May 20, 2008         [Page 26]


Internet-Draft                SMF for MANET                November 2007


   other explicit, dynamic control of membership be provided.
   Specification of such an IGMP/MLD proxy protocol is beyond the scope
   of this document.

   Outbound traffic is less problematic.  SMF border routers can perform
   duplicate packet detection and forward non-duplicate traffic that
   meets TTL/hop limit and scoping criteria to other interfaces.
   Appropriate IP multicast routing (PIM, etc) on those interfaces can
   then make further forwarding decisions with respect to the given
   traffic and its MANET source address.  Note that the presence of
   multiple border routers associated with a MANET routing region may
   create some additional issues.  This is further discussed in
   Section 8.4.

8.2.  Multicast Group Scoping

   Multicast scoping is used by network administrators to control the
   network routing regions which are reached by multicast packets.  This
   is usually done by configuring external interfaces of border routers
   in the border of an routing region to not forward multicast packets
   which must be kept within the routing region.  This is commonly done
   based on TTL of messages or the basis of group addresses.  These
   schemes are known respectively as:

   1.  TTL scoping.

   2.  Administrative scoping.

   For IPv4, network administrators can configure border routers with
   the appropriate TTL thresholds or administratively scoped multicast
   groups in the router's interfaces as with any traditional multicast
   router.  However, for the case of TTL scoping it must be taken into
   account that the packet could traverse multiple hops within the MANET
   SMF routing region before reaching the border router.  Thus, TTL
   thresholds must be selected carefully.

   For IPv6, multicast address spaces include information about the
   scope of the group.  Thus, border routers of an SMF routing region
   know if they must forward a packet based on the IPv6 multicast group
   address.  For the case of IPv6, it is RECOMMENDED that a MANET SMF
   routing region be designated a site.  Thus, all IPv6 multicast
   packets in the range FF05::/16 SHOULD be kept within the MANET SMF
   routing region by border routers.  IPv6 packets in any other wider
   range scopes (i.e.  FF08::/16, FF0B::/16 and FF0E::16) MAY traverse
   border routers unless other restrictions different from the scope
   applies.

   Given that scoping of multicast packets is performed at the border



Macker, editor & SMF Design Team  Expires May 20, 2008         [Page 27]


Internet-Draft                SMF for MANET                November 2007


   routers, and given that existing scoping mechanisms are not designed
   to work with mobile routers, it is assumed that non-border SMF
   routers will not stop forwarding multicast data packets because of
   their scope.  That is, it is assumed that the entire MANET SMF
   routing region is a non-divisible scoping area except in the case of
   link-local addresses that are not forwarded by SMF.

8.3.  Interface with Exterior Multicast Routing Protocols

   The traditional operation of multicast routing protocols is tightly
   integrated with the group membership function.  Leaf routers are
   configured to periodically gather group membership information, while
   intermediate routers conspire to create multicast trees connecting
   routers with directly-connected multicast sources and routers with
   active multicast receivers.  In the concrete case of SMF, border
   routers can be considered leaf routers.  Mechanisms for multicast
   sources and receivers to interoperate with border routers over the
   multihop MANET SMF routing region as if they were directly connected
   to the router need to be defined.  The following issues need to be
   addressed:

   1.  Mechanism by which border routers gather membership information.

   2.  Mechanism by which multicast sources are known by the border
       router.

   3.  Exchange of exterior routing protocol messages across the MANET
       routing region if the MANET routing region is to provide transit
       connectivity for multicast traffic.

   It is beyond the scope of this document to address implementation
   solutions to these issues.  As described in Section 8.1, IGMP/MLD
   proxy mechanisms can be deployed to address some of these issues.
   Similarly, exterior routing protocol messages could be tunneled or
   conveyed across the MANET routing region.  But, because MANET routing
   regions are multi-hop and potentially unreliable, as opposed to the
   single-hop LAN interconnection that neighboring IP Multicast routers
   might typically enjoy, additional provisions may be required to
   achieve successful operation.

   The need for the border router to receive traffic from recognized
   multicast sources within the MANET SMF routing region is important to
   achieve a smooth interworking with existing routing protocols.  For
   instance, PIM-S requires routers with locally attached multicast
   sources to register them to the Rendezvous Point (RP) so that other
   people can join the multicast tree.  In addition, if those sources
   are not advertised to other autonomous systems (AS) using MSDP,
   receivers in those external networks are not able to join the



Macker, editor & SMF Design Team  Expires May 20, 2008         [Page 28]


Internet-Draft                SMF for MANET                November 2007


   multicast tree for that source.

8.4.  Multiple Border Routers

   A MANET might be deployed with multiple participating nodes having
   connectivity to external (to the MANET), fixed-infrastructure
   networks.  Allowing multiple nodes to forward multicast traffic to/
   from the MANET routing region can be beneficial since it can increase
   reliability, and provide better service.  For example, if the MANET
   routing region were to fragment with different MANET nodes
   maintaining connectivity to different border routers, multicast
   service could still continue successfully.  But, the case of multiple
   border routers connecting a MANET routing region to external networks
   presents several challenges for SMF:

   1.  Detection/hash collision/sequencing of duplicate unmarked IPv4 or
       IPv6 (without IPSec encapsulation or DPD option) packets possibly
       injected by multiple border routers.

   2.  Source-based relay algorithms handling of duplicate traffic
       injected by multiple border routers.

   3.  Determination of which border router(s) will forward outbound
       multicast traffic.

   4.  Additional challenges with interfaces to exterior multicast
       routing protocols.

   One of the most obvious issues is when multiple border routers are
   present and may be alternatively (due to route changes) or
   simultaneously injecting common traffic into the MANET routing region
   that has not been previously marked for SMF DPD.  Different border
   routers would not be able to implicitly synchronize sequencing of
   injected traffic since they may not receive exactly the same messages
   due to packet losses.  For IPv6 I-DPD operation, the optional
   "TaggerId" field described for the SMF-DPD header option can be used
   to mitigate this issue.  When multiple border routers are injecting a
   flow into a MANET routing region, there are two forwarding policies
   that SMF DPD-S nodes may implement:

   1.  Redundantly forward the multicast flows (identified by
       <sourceAddress:destinationAddress>) from each border router,
       performing DPD processing on a <taggerID:destinationAddress> or
       <taggerID:sourceAddress:destinationAddress> basis, or

   2.  Use some basis to select the flow of one tagger (border router)
       over the others and forward packets for applicable flows
       (identified by <sourceAddress:destinationAddress>) only for that



Macker, editor & SMF Design Team  Expires May 20, 2008         [Page 29]


Internet-Draft                SMF for MANET                November 2007


       "Tagger ID" until timeout or some other criteria to favor another
       tagger occurs.

   It is RECOMMENDED that the first approach be used in the case of
   I-DPD operation unless the SMF system is specifically designed to
   implement the second option.  Additional specification may be
   required to describe an interoperable forwarding policy based on this
   second option.  Note that the implementation of the second option
   requires that per-flow (i.e., <sourceAddress::destinationAddress>)
   state be maintained for the selected "Tagger ID".

   The deployment of a H-DPD operational mode may alleviate DPD
   resolution when ingressing traffic comes from multiple border
   routers.  Non-colliding hash indexes (those not requiring the H-DPD
   options header in IPv6) should be resolved effectively.




































Macker, editor & SMF Design Team  Expires May 20, 2008         [Page 30]


Internet-Draft                SMF for MANET                November 2007


9.  Non-SMF MANET Node Interaction

   There may be scenarios in which some neighboring wireless MANET node
   is not running SMF and/or conduct forwarding, but is interested in
   receiving multicast data.  For example, a MANET service might be
   deployed that is accessible to wireless edge devices that does not
   participate in MANET routing and/or SMF forwarding operation.  These
   devices include:

   1.  Devices that opportunistically receive multicast traffic due to
       proximity with SMF relays (possibly with asymmetric IP
       connectivity e.g., sensor network device).

   2.  Devices that participate in NHDP (directly or via routing
       protocol signaling) but do not forward traffic.

   Note there is no guarantee of traffic delivery with category 1 above,
   but the election heuristics shown in Figure 2 may be adjusted via
   management to better support such devices.  It is RECOMMENDED that
   nodes participate in NHDP when possible.  Such devices may also
   transmit multicast traffic, but it is important to note that SMF
   routing regions using source-specific relay set algorithms such as
   (S-MPR) may not forward such traffic.  These devices SHOULD also
   listen for any IGMP/MLD Queries that are provided and transmit IGMP/
   MLD Reports for groups they have joined per usual IP Multicast
   operation.  While it is not in the scope of this document, IGMP/MLD
   proxy mechanisms may be in place to convey group membership
   information to any border routers or intermediate systems providing
   IP Multicast routing functions.






















Macker, editor & SMF Design Team  Expires May 20, 2008         [Page 31]


Internet-Draft                SMF for MANET                November 2007


10.  Security Considerations

   Gratuitous use of option headers can cause problems in routers.
   Routers outside of MANET routing regions should ignore SMF-specific
   header options if encountered.  The header options types are encoded
   appropriately for this behavior.

   Sequence-based packet identifiers are predictable and thus provide an
   opportunity for a denial-of-service attack against forwarding.  The
   use of the "internal hashing" as described in Section 5.3 for the
   I-DPD operation helps to mitigate denial-of-service attacks on
   predictable packet identifiers.  In this case, spoofed packets MAY be
   forwarded but the additional internal history identifier will protect
   against false collision events that may result from a predictive
   denial-of-service attack.

   Another potential denial-of-service attack against SMF forwarding is
   possible when a bad-behaving node has a form of "wormhole" access
   (via a directional antenna, etc) to preview packets before a
   particular SMF node would receive them.  The bad-behaving node could
   reduce the TTL or Hop Limit of the packet and transmit it to the SMF
   node causing it to forward the packet with a limited TTL (or even
   drop it) and make a DPD entry that would block forwarding of the
   subsequently-arriving valid packet with appropriate TTL value.  This
   would be a relatively low-cost, high-payoff attack that would be hard
   to detect and thus attractive to potential attackers.  An approach of
   caching TTL information with DPD state and taking appropriate
   forwarding actions is identified in Section 4 to mitigate this form
   of attack.

   The support of forwarding non-fragmented IPSEC datagrams without
   further modification for both IPv4 and IPv6 is supported by this
   specification.

   Authentication mechanisms to identify the source of IPv6 option
   headers should be considered to reduce vulnerability to a variety of
   attacks.














Macker, editor & SMF Design Team  Expires May 20, 2008         [Page 32]


Internet-Draft                SMF for MANET                November 2007


11.  IANA Considerations

   There are number of discussions within this SMF specification that
   will be subject to IANA registration and consideration.  The IPv6
   SMF-DPD hop-by-hop Header Extension being defined within this
   document MUST have an IANA registry established upon publication of
   the first RFC.  Additionally, well-known site-scoped multicast
   addresses intended as default forwardable addresses by the SMF
   forwarding process for both IPv4 and IPv6 should be registered and
   defined by the first RFC published.  Also, SMF specific TLV types and
   definitions MUST be registered in the context of packetbb and NHDP
   use.







































Macker, editor & SMF Design Team  Expires May 20, 2008         [Page 33]


Internet-Draft                SMF for MANET                November 2007


12.  Acknowledgments

   Many of the concepts and mechanisms used and adopted by SMF resulted
   from many years of discussion and related work within the MANET WG
   since the late 1990s.  There are obviously many contributors to past
   discussions and related draft documents within the WG that have
   influenced the development of SMF concepts that deserve
   acknowledgment.  In particular, the document is largely a direct
   product of the earlier SMF design team within the IETF MANET WG and
   borrows text and implementation ideas from the related individuals.
   Some of the contributors who have been involved in design, content
   editing, prototype implementation, and core discussions are listed
   below in alphabetical order.  We appreciate input from many others we
   may have missed in this list as well.

      Design contributors in alphabetical order:

      Brian Adamson

      Teco Boot

      Ian Chakeres

      Thomas Clausen

      Justin Dean

      Brian Haberman

      Charles Perkins

      Pedro Ruiz

      Fred Templin

      Maoyu Wang

   The RFC text was produced using Marshall Rose's xml2rfc tool and Bill
   Fenner's XMLmind add-ons.












Macker, editor & SMF Design Team  Expires May 20, 2008         [Page 34]


Internet-Draft                SMF for MANET                November 2007


13.  References

13.1.  Normative References

   [E-CDS]    Ogier, R., "MANET Extension of OSPF Using CDS Flooding",
              Proceedings of the 62nd IETF , March 2005.

   [MPR-CDS]  Adjih, C., Jacquet, P., and L. Viennot, "Computing
              Connected Dominating Sets with Multipoint Relays", Ad Hoc
              and Sensor Wireless Networks , January 2005.

   [NHDP]     Clausen, T. and et al, "Neighborhood Discovery Protocol",
              draft-ietf-manet-ndp-00, Work in progress , July 2006.

   [OLSRv2]   Clausen, T. and et al, "Optimized Link State Routing
              Protocol version 2", draft-ietf-manet-olsrv2-00, Work in
              progress , March 2006.

   [PacketBB]
              Clausen, T. and et al, "Generalized MANET Packet/Message
              Format", draft-ietf-manet-packetbb-00, Work in progress ,
              March 2006.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981.

   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
              April 1992.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC2644]  Senie, D., "Changing the Default for Directed Broadcasts
              in Routers", BCP 34, RFC 2644, August 1999.

   [RFC3626]  Clausen, T. and P. Jacquet, "Optimized Link State Routing
              Protocol", 2003.

   [RFC4302]  Kent, S., "IP Authentication Header", December 2005.

13.2.  Informative References

   [GJ79]     Garey, M. and D. Johnson, "Computers and Intractability: A
              Guide to the Theory of NP-Completeness.", Freeman and
              Company , 1979.



Macker, editor & SMF Design Team  Expires May 20, 2008         [Page 35]


Internet-Draft                SMF for MANET                November 2007


   [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.

   [MDDA07]   Macker, J., Downard, I., Dean, J., and R. Adamson,
              "Evaluation of distributed cover set algorithms in mobile
              ad hoc network for simplified multicast forwarding", ACM
              SIGMOBILE Mobile Computing and Communications Review
               Volume 11 ,  Issue 3  (July 2007), July 2007.

   [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.

   [RFC2901]  Macker, JP. and MS. Corson, "Mobile Ad hoc Networking
              (MANET): Routing Protocol Performance Issues and
              Evaluation Considerations", 1999.

   [RFC3684]  Ogier, R., Templin, F., and M. Lewis, "Topology
              Dissemination Based on Reverse-Path Forwarding", 2003.

   [RFC3973]  Adams, A., Nicholas, J., and W. Siadak, "Protocol
              Independent Multicast - Dense Mode (PIM-DM): Protocol
              Specification (Revised)", RFC 3973, January 2005.

   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
              Protocol Specification (Revised)", RFC 4601, August 2006.

   [WC02]     Williams, B. and T. Camp, "Comparison of Broadcasting
              Techniques for Mobile Ad hoc Networks", Proceedings of ACM
              Mobihoc 2002 , 2002.















Macker, editor & SMF Design Team  Expires May 20, 2008         [Page 36]


Internet-Draft                SMF for MANET                November 2007


Appendix A.  Reduced Relay Set Forwarding Algorithms and Considerations

   This Appendix discusses candidate SMF reduced relay set algorithms
   that have been used in practice.  Basic algorithm operation is
   described along with related issues (e.g., TLV use).

   The following definitions are used to describe algorithm operation
   within sections to follow.

      node : A MANET router operating SMF.

      n_0 : The node performing the SMF algorithm computation.

      N_1 : A set of 1-hop neighbors of n_0.  Initially set to all 1-hop
      neighbors.

      N_2 : A set of 2-hop neighbors reachable by n_0, excluding n_0 and
      all nodes in N_1.  Initially set to all 2-hop neighbors excluding
      n_0 and all nodes in N_1.

      N_2(y) : The subset of N_2 nodes which are 1-hop neighbors of node
      y, where node y is in N_1.

      N_1(z) : The subset of N_1 nodes which are 1-hop neighbors of node
      z, where z is in N_2.

      RtrPri : an expression of router priority.  In the case of a
      RtrPri value tie, higher address values are equivalent to a higher
      priority value result.

      rp_max_1 : The node with the largest RtrPri of N_1.

      MPRs : The subset of N_1 which have been selected by n_0 to
      forward packets from n_0.

      MPR-Selectors : The subset of N_1 for whom n_0 has been selected
      to forward packets.














Macker, editor & SMF Design Team  Expires May 20, 2008         [Page 37]


Internet-Draft                SMF for MANET                November 2007


Appendix B.  Source-based Multipoint Relay (S-MPR)

   The source-based multipoint relay (S-MPR) set selection algorithm
   enables individual nodes, using two-hop topology information, to
   select relays from their set of neighboring nodes.  Relays are
   selected so that a nodes two-hop neighbor set is covered.  This
   distributed technique has been shown to approximate selection of a
   minimal connected dominating set (MCDS) in [JLMV02].  Individual
   nodes must collect two-hop neighborhood information from neighbors,
   determine an appropriate current relay set, and inform selected
   neighbors of their relay status.  The Optimized Link State Routing
   (OLSR) protocol has used this algorithm and protocol for relay of
   link state updates and other control information [RFC3626] and it has
   been demonstrated operationally in dynamic network environments.

B.1.  S-MPR Relay Set Selection

   If SMF is operating S-MPR relay set election is operating with
   independent CDS control, the election algorithm and TLVs defined
   within [OLSRv2] SHOULD be used.  In this case, NHDP messages SHOULD
   also include a message TLV of type SMF_RELAYALG_ID specifying S-MPR
   relay election.

   With S-MPR, a node's status as a relay is with respect to neighboring
   nodes who have selected it (i.e., its "selectors".)  This requires
   nodes to inform neighbors of who they have selected as forwarders.
   These relaying nodes must have previous-hop knowledge of packets
   received to make forwarding decisions.  Additionally, it is important
   that relay nodes forward packets for only those nodes identified as
   symmetric, one-hop neighbors to maintain correctness.  The selection
   of relays does not result in a common set among neighboring nodes, so
   relays MUST mark in their duplicate table packets from non-selector,
   symmetric, one-hop neighbors (for a given interface) and not forward
   subsequent duplicates of that packet if received on that interface.
   Deviation here can result in unnecessary, repeated packet forwarding
   throughout the network, or incomplete flooding.  When multiple
   interfaces are present, the S-MPR SMF forwarder must keep independent
   state for each interface with regards to duplicate packets.  In these
   respects, flooding for SMF based on the S-MPR algorithm is more
   complex than previous hop independent relay set selection algorithms,
   yet S-MPR is a known technique that has significant experimental and
   operational experience and may have other performance advantages.

B.2.  S-MPR Forwarding Rules

   1.  Upon reception of a packet, it is checked against the incoming
       interfaces duplicate table.  If a duplicate exists no further
       action is taken.



Macker, editor & SMF Design Team  Expires May 20, 2008         [Page 38]


Internet-Draft                SMF for MANET                November 2007


   2.  Once uniqueness is verified and if the previous-hop transmitter
       is a one-hop symmetric neighbor, the packet is added to the
       duplicate table of the incoming interface.  If the previous-hop
       transmitter is not a one-hop symmetric neighbor the packet SHOULD
       NOT be forwarded and SHOULD NOT be added to the duplicat table.

   3.  If the previous-hop transmitter has selected the current node, on
       the incoming interface, as an MPR, the packet is forwarded out
       all interfaces.  If the node is not an MPR for the previous-hop,
       on the incoming interface, no further action is taken.

   4.  Any packet sourced or forwarded through a node is added to the
       duplicate tables of all of the nodes interfaces.

   Basic S-MPR relay forwarding will not forward packets in which the
   previous hop is not known through the neighbor discovery mechanism,
   therefore nodes not participating in neighbor discovery and relay set
   selection will not be able to source multicast packets into the MANET
   and have SMF forward them.  Correct S-MPR relay behavior will occur
   with the introduction of repeaters (non SMF participant nodes that
   relay multicast packets using duplicate detection and CF) but the
   repeaters will be dead ends with regards to S-MPR SMF forwarding.
   SMF participant nodes may not provide extra forwarding, forwarding
   packets which are not selected by the algorithm, as this can break
   network wide S-MPR flooding.

B.3.  S-MPR Neighborhood Discovery Requirements

   S-MPR election operation requires 2-hop neighbor knowledge as
   provided by the NHDP protocol [NHDP] or as available from external
   sources.  MPRs are dynamically selected by each node and selections
   MUST be advertised and dynamically updated within NHDP or equivalent
   protocol.  In this mode, the MPR specific TLVs defined in OLSRv2
   [OLSRv2] are also required to be implemented by NHDP.

B.4.  S-MPR Selection Algorithm

   1.  1.  Calculate N_1(z) for all nodes z in N_2.

   2.  2.  Calculate N_2(y) for all nodes y in N_1.

   3.  3.  For each z in N_2 where |N_1(z)| is equal to 1, select the
       node in N_1(z) as an MPR by using Appendix B.4.1.

   4.  4.  While N_2 is not empty select the node y, with the largest
       |N_2(y)|, as MPR by using Appendix B.4.1.





Macker, editor & SMF Design Team  Expires May 20, 2008         [Page 39]


Internet-Draft                SMF for MANET                November 2007


   5.  5.  Restore N_1 and N_2.

   6.  6.  Node n_0 shares its MPRs with N_1.

   7.  7.  Each node in n_0's MPRs set add n_0 to their MPR-Selectors
       set.

   8.  8.  Nodes forward all unique multicast packets which are first
       received from a node in their MPR-Selectors set.

B.4.1.  MPR Node Selection Procedure

   1.  Add n to the MPRs set.

   2.  Remove node n from N_1.

   3.  For each y in N_2(n), remove y from N_2.

   4.  Calculate N_1(z) for all nodes z in N_2

   5.  Calculate N_2(y) for all nodes y in N_1.






























Macker, editor & SMF Design Team  Expires May 20, 2008         [Page 40]


Internet-Draft                SMF for MANET                November 2007


Appendix C.  Essential Connecting Dominating Set (E-CDS) Algorithm

   The "Essential Connected Dominating Set" (E-CDS) algorithm [E-CDS]
   allows nodes to use two-hop topology information to dynamically elect
   _themselves_ as relay nodes to form an efficient (for flooding) CDS.
   Its forwarding rules within SMF are non-dependent upon previous hop
   information.  Semantics for multiple interface support are simplified
   as compared to S-MPR as only one duplicate table is required.
   Packets which are received from non-symmetric neighbors may be
   forwarded without compromising flooding efficiency or algorithm
   correctness.  The E-CDS based relay set selection algorithm is based
   upon Richard Ogier's original summary within [E-CDS].  E-CDS was
   originally discussed in the context of forming partial adjacencies
   and efficient flooding for MANET OSPF extensions work but its core
   algorithm is applied here.

   If SMF is operating E-CDS relay set election with independent CDS
   control, NHDP messages SHOULD also include a message TLV of type
   SMF_RELAYALG_ID specifying E-CDS relay election.

C.1.  E-CDS Relay Set Selection

   E-CDS requires two-hop neighbor information collected through NHDP or
   other process.  Each router has a Router Identifier (that may be
   represented by an interface address) and Router Priority
   value(RtrPri).  The Router Priority value may be dynamic and may
   represent such metrics as node degree.  The fundamental election
   steps are as follows:

   1.  If an SMF node has a higher (Router Priority, Router ID) than all
       of its symmetric neighbors, it elects itself to the relay set.

   2.  Else, if there does not exist a path from neighbor j with largest
       (Router Priority, Router ID) to some other neighbor, via
       neighbors with larger values of (Router Priority, Router ID),
       then it elects itself to the relay set.

   The basic form of E-CDS described and applied within this
   specification does not at present define redundant relay set election
   but such capability is supported by the basic E-CDS design.

C.2.  E-CDS Forwarding Rules

   Upon electing itself as an E-CDS relay set forwarder, SMF nodes
   perform DPD functions and forward all ranges of non-duplicative
   multicast traffic allowed by the present forwarding policy.
   Knowledge of a packets previous hop is not needed for forwarding
   decisions when using E-CDS.



Macker, editor & SMF Design Team  Expires May 20, 2008         [Page 41]


Internet-Draft                SMF for MANET                November 2007


   1.  Upon reception of a packet, it is checked against the duplicate
       table.  If a duplicate exists no further action is taken.  E-CDS
       and all other shared relay selection algorithms only require one
       duplicate table for all interfaces of which the algorithm covers.

   2.  Once uniqueness is verified, the packet is added to the duplicate
       table.

   3.  A unique packet is forwarded out all interfaces if the local node
       has selected itself as a relay node according to the E-CDS
       algorithm.

   4.  Any packet sourced or forwarded through a node is added to the
       duplicate table.

   Using E-CDS relay forwarding, nodes which are not participating in
   neighbor discovery and relay set selection will have directly
   injected multicast packets forwarded by SMF if they are received at a
   relay node.  Correct E-CDS relay behavior will occur with the
   introduction of repeaters (non SMF participant nodes which relay
   multicast packets using duplicate detection) and these repeaters can
   be used to connect otherwise separate SMF relay sets.  SMF
   participant nodes may provide extra forwarding, becoming a relay node
   when not selected by the E-CDS algorithm, without breaking correct
   flooding throughout the network.

C.3.  E-CDS Neighborhood Discovery Requirements

   Two-hop knowledge is needed during the election process, but unlike
   the MPR method, E-CDS is a self-electing algorithm.  For E-CDS
   operation, some value of RtrPri must be given or assumed for each
   address with the two-hop neighborhood which is consistent for all
   nodes.  If RtrPri is a non-default value it MUST be shared with all
   immediate neighbor and 2-hop neighbor nodes.  To support this the
   SMF_RTR_PRI TLVs MAY be used to transmit RtrPri for each address
   within a NHDP message.  If a NHDP message originator does not provide
   a RtrPri value for given address(es) using the SMF_RTR_PRI TLVs, a
   default value RTRPRI_DEFAULT = 128 should be assumed.

   Local determination of a node RtrPri value can be done in multiple
   ways as described in the [E-CDS].  An early experimental deployment
   of an SMF prototype and E-CDS has used node degree as the default
   priority value computed during neighbor discovery, yet it is still
   unclear if this is the best method.  Nonetheless, this is recommended
   as the default mode on all SMF nodes to enable interoperability.






Macker, editor & SMF Design Team  Expires May 20, 2008         [Page 42]


Internet-Draft                SMF for MANET                November 2007


C.4.  E-CDS Selection Algorithm (2-Hop)

   1.  If |N_1| < 2 than n_0 does not select itself as a forwarder and
       no further steps need to be taken

   2.  If n_0 has a larger value of RtrPri than all nodes in N_1 and
       N_2, then n_0 selects itself as a forwarder for all nodes.
       Unless otherwise set, n_0 should assume a default RtrPri of 128.
       RtrPri ties should be broken by comparing addresses.

   3.  If there does not exist a path from r_max_1 to every other node
       in N_1 and N_2 using only N_1 and N_2 nodes that have RtrPri
       larger than n_0's, then n_0 selects itself as a forwarder for all
       nodes.





































Macker, editor & SMF Design Team  Expires May 20, 2008         [Page 43]


Internet-Draft                SMF for MANET                November 2007


Appendix D.  Multipoint Relay Connected Dominating Set (MPR-CDS)
             Algorithm

   The MPR-CDS algorithm is an extension to the basic MPR election
   algorithm and results in a shared relay set that forms a CDS.  Its
   forwarding rules within SMF are non-dependent upon previous hop
   information similar to E-CDS.  An overview of the MPR-CDS selection
   algorithm is provided in [MPR-CDS].

   If SMF is operating MPR-CDS relay set election with independent CDS
   control, NHDP messages SHOULD also include a message TLV of type
   SMF_RELAYALG_ID specifying MPR-CDS relay election.

D.1.  MPR-CDS Relay Set Selection

   The basic requirements for election are similar to the basic MPR
   algorithm with the addition that some node ordering knowledge is
   required.  This is similar to the E-CDS requirement and can be based
   upon node IP address or some other unique router identifier.  The
   rules for election are as follows:

      A node decides it is in the relay set if:

   1.  n_0 has a larger RtrPri than all of N_1 (Rule 1)

   2.  or n_0 is an MPR of rp_max_1 (Rule 2)

D.2.  MPR-CDS Forwarding Rules

   MPR-CDS forms a shared relay set so the forwarding rules do not
   require previous previous hop information for making forwarding
   decisions.  Upon election as a MPR-CDS relay set forwarder, SMF nodes
   perform DPD functions and forward all ranges of multicast traffic
   allowed.

   1.  Upon reception of a packet, it is checked against the duplicate
       table.  If a duplicate exists no further action is taken.  E-CDS
       and all other shared relay selection algorithms only require one
       duplicate table for all interfaces.

   2.  Once uniqueness is verified, the packet is added to the duplicate
       table.

   3.  A unique packet is forwarded out all interfaces if the local node
       has selected itself as a relay node according to the MPR-CDS
       algorithm.





Macker, editor & SMF Design Team  Expires May 20, 2008         [Page 44]


Internet-Draft                SMF for MANET                November 2007


   4.  Any packet sourced or forwarded through a node is added to the
       duplicate table.

   Correct MPR-CDS relay behavior will occur with the introduction of
   repeaters (non SMF participant nodes which relay multicast packets
   using duplicate detection) and these repeaters can be used to connect
   otherwise separate SMF relay sets.  SMF participant nodes may provide
   extra forwarding, becoming a relay node when not selected by the MPR-
   CDS algorithm, without breaking correct flooding throughout the
   network.

D.3.  MPR-CDS Neighborhood Discovery Requirements

   MPR-CDS election operation requires 2-hop neighbor knowledge as
   provided by the NHDP protocol [NHDP] or as available from external
   sources.  MPR-CDS require the MPR specific TLVs defined in OLSRv2
   [OLSRv2] and MAY use SMF_RTR_PRI message TLVs to convey router
   priority values.

D.4.  MPR-CDS Selection Algorithm

   1.  Perform steps 1-7 of Appendix B.4.

   2.  If n_0 RtrPri value is greater than rp_max_1's RtrPri value, and
       |MPR-Selectors| > 0, then n_0 selects itself as a forwarder for
       all nodes.

   3.  If rp_max_1 is in the MPR-Selectors set, then n_0 selects itself
       as a forwarder for all nodes.






















Macker, editor & SMF Design Team  Expires May 20, 2008         [Page 45]


Internet-Draft                SMF for MANET                November 2007


Authors' Addresses

   Joseph Macker
   NRL
   Washington, DC  20375
   USA

   Email: macker@itd.nrl.navy.mil


   SMF Design Team
   IETF MANET WG

   Email: manet@ietf.org





































Macker, editor & SMF Design Team  Expires May 20, 2008         [Page 46]


Internet-Draft                SMF for MANET                November 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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.

   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, THE IETF TRUST 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.


Intellectual Property

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Macker, editor & SMF Design Team  Expires May 20, 2008         [Page 47]


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