Subject: [manet] SMF-11 review

From: Ulrich Herberg <[email-masked]>
Date: Wed, 30 Mar 2011 17:13:19 +0200

Hi,

as promised, my review of the last revision of SMF. As said in the
meeting, the draft has improved a lot in terms of readability and
consistency since -10. My remaining issues are a number of smaller
fixes, nothing that really changes the spec.

As in my previous review, my comments are enclosed by "UH> ================".

Network Working Group                                  J. Macker, editor
Internet-Draft                                                       NRL
Intended status: Experimental                            SMF Design Team
Expires: September 15, 2011                                IETF MANET WG
                                                          March 14, 2011

                    Simplified Multicast Forwarding
                        draft-ietf-manet-smf-11

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 defines
   techniques for multicast duplicate packet detection (DPD) to be
   applied in the forwarding process and includes maintenance and
   checking operations for both IPv4 and IPv6 protocol use.  SMF also
   specifies mechanisms for applying reduced relay sets to achieve more
   efficient multicast data distribution within a mesh topology versus
   simple flooding.
UH> ================
UH> simple or classic flooding?
UH> ================

The document describes interactions with other
   protocols and multiple deployment approaches.  Distributed algorithms
   for selecting reduced relay sets and related discussion are 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.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on September 15, 2011.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 1]

Internet-Draft                     SMF                        March 2011

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 2]

Internet-Draft                     SMF                        March 2011

Table of Contents

   1.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  5
   2.  Introduction and Scope . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Design Overview  . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  SMF Applicability  . . . . . . . . . . . . . . . . . . . . . .  8
   5.  SMF Packet Processing and Forwarding . . . . . . . . . . . . .  9
   6.  SMF Duplicate Packet Detection . . . . . . . . . . . . . . . . 11
     6.1.  IPv6 Duplicate Packet Detection  . . . . . . . . . . . . . 12
       6.1.1.  IPv6 SMF-DPD Header Option . . . . . . . . . . . . . . 12
       6.1.2.  IPv6 Identification-based DPD  . . . . . . . . . . . . 15
       6.1.3.  IPv6 Hash-based DPD  . . . . . . . . . . . . . . . . . 17
     6.2.  IPv4 Duplicate Packet Detection  . . . . . . . . . . . . . 18
       6.2.1.  IPv4 Identification-based DPD  . . . . . . . . . . . . 18
       6.2.2.  IPv4 Hash-based DPD  . . . . . . . . . . . . . . . . . 20
   7.  Relay Set Selection  . . . . . . . . . . . . . . . . . . . . . 20
     7.1.  Non-Reduced Relay Set Forwarding . . . . . . . . . . . . . 20
     7.2.  Reduced Relay Set Forwarding . . . . . . . . . . . . . . . 21
   8.  SMF Neighborhood Discovery Requirements  . . . . . . . . . . . 23
     8.1.  SMF Relay Algorithm TLV Types  . . . . . . . . . . . . . . 24
       8.1.1.  SMF Message TLV Type . . . . . . . . . . . . . . . . . 24
       8.1.2.  SMF Address Block TLV Type . . . . . . . . . . . . . . 25
   9.  SMF Border Gateway Considerations  . . . . . . . . . . . . . . 26
     9.1.  Forwarded Multicast Groups . . . . . . . . . . . . . . . . 27
     9.2.  Multicast Group Scoping  . . . . . . . . . . . . . . . . . 28
     9.3.  Interface with Exterior Multicast Routing Protocols  . . . 28
     9.4.  Multiple Border Routers  . . . . . . . . . . . . . . . . . 29
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 30
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 32
     11.1. IPv6 SMF-DPD Header Extension  . . . . . . . . . . . . . . 32
     11.2. SMF Type-Length-Value  . . . . . . . . . . . . . . . . . . 33
   12. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 34
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 34
     13.2. Informative References . . . . . . . . . . . . . . . . . . 35
   Appendix A.  Essential Connecting Dominating Set (E-CDS)
                Algorithm . . . . . . . . . . . . . . . . . . . . . . 36
     A.1.  E-CDS Relay Set Selection Overview . . . . . . . . . . . . 37
     A.2.  E-CDS Forwarding Rules . . . . . . . . . . . . . . . . . . 38
     A.3.  E-CDS Neighborhood Discovery Requirements  . . . . . . . . 38
     A.4.  E-CDS Selection Algorithm  . . . . . . . . . . . . . . . . 41
   Appendix B.  Source-based Multipoint Relay (S-MPR) . . . . . . . . 43
     B.1.  S-MPR Relay Set Selection Overview . . . . . . . . . . . . 43
     B.2.  S-MPR Forwarding Rules . . . . . . . . . . . . . . . . . . 44
     B.3.  S-MPR Neighborhood Discovery Requirements  . . . . . . . . 45
     B.4.  S-MPR Selection Algorithm  . . . . . . . . . . . . . . . . 47
   Appendix C.  Multipoint Relay Connected Dominating Set

Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 3]

Internet-Draft                     SMF                        March 2011

                (MPR-CDS) Algorithm . . . . . . . . . . . . . . . . . 48
     C.1.  MPR-CDS Relay Set Selection Overview . . . . . . . . . . . 48
     C.2.  MPR-CDS Forwarding Rules . . . . . . . . . . . . . . . . . 49
     C.3.  MPR-CDS Neighborhood Discovery Requirements  . . . . . . . 50
     C.4.  MPR-CDS Selection Algorithm  . . . . . . . . . . . . . . . 50
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51

Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 4]

Internet-Draft                     SMF                        March 2011

1.  Requirements Notation

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

2.  Introduction and Scope

   Unicast routing protocol designs for MANET and wireless mesh use
UH> ================
UH> is it designs or designed? not sure...
UH> ================

   often apply distributed algorithms to flood routing control plane
   messages within an interior wireless routing domain.
UH> ================
UH> "interior"? Is that different than just "routing domain", as used later?
UH> ================

   For example,
   algorithms specified within [RFC3626] and [RFC3684] provide
   distributed methods of dynamically electing reduced relay sets that
   attempt to efficiently flood routing control messages while
   maintaining a connected set under dynamic topological conditions.

   In one sense, Simplified Multicast Forwarding (SMF) extends the
   efficient flooding concept to the data forwarding plane.  Therefore,
   SMF provides an appropriate multicast forwarding capability for use
   cases where localized, efficient flooding is considered an effective
   design approach.  The baseline design is intended to provide a basic,
   best effort multicast forwarding capability that is constrained to
   operate within an interior MANET or wireless mesh routing domain.
UH> ================
UH> same comment as before, "interior [...] routing domain"?. The
difference between "MANET [...] routing domain" and "wireless mesh
routing domain" is not clear to me. Maybe just say "MANET routing
domain"?
UH> ================

An
   SMF routing domain is an instance of a SMF
UH> ================
UH> s/a SMF/an SMF/  ?
UH> ================

 routing protocol with
   common policies that is under a single network administration
   authority.
UH> ================
UH> I wonder whether that is always applicable. For example, I am not
quite sure that the FunkFeuer network is under a "single network
administration authority". Everybody is free to join, simply by
running the protocol.
UH> ================

The main design goals of this SMF specification are to
   adapt efficient relay sets in MANET type environments [RFC2501] and
   to define the needed IPv4 and IPv6 multicast duplicate packet
   detection (DPD) mechanisms to support multi-hop, packet forwarding.

2.1.  Terminology

UH> ================
UH> I suggest to change the title to "Terminology and Notations" and
add some text explaining the kind of notations (e.g. <TaggerId>) for
fields and variables, similar to RFC 5444
UH> ================

   The following abbreviations are used throughout this document:

Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 5]

Internet-Draft                     SMF                        March 2011

            +--------------+---------------------------------+
            | Abbreviation | Definition                      |
            +--------------+---------------------------------+
            | MANET        | Mobile Ad hoc Network           |
            | SMF          | Simplified Multicast Forwarding |
            | CF           | Classical Flooding              |
            | CDS          | Connected Dominating Set        |
            | MPR          | Multi-Point Relay               |
            | S-MPR        | Source-based MPR                |
            | MPR-CDS      | MPR-based CDS                   |
            | E-CDS        | Essential CDS                   |
            | NHDP         | Neighborhood Discovery Protocol |
            | SMF-DPD      | SMF-Duplicate Packet Detection  |
            | I-DPD        | Identification-based DPD        |
            | H-DPD        | Hash-based DPD                  |
            | HAV          | Hash-assist Value               |
            | FIB          | Forwarding Information Base     |
            | TLV          | type-length-value encoding      |
            | DoS          | Denial of Service               |
            +--------------+---------------------------------+

3.  Design Overview

   Figure 1 provides an overview of the logical SMF node
UH> ================
UH> At many places in the draft, the word "node" is still used,
instead of "router", as in other cases. I suggest to replace "node"
with "router" throughout the doc.
UH> ================

architecture,
   consisting of "Neighborhood Discovery", "Relay Set Selection" and
   "Forwarding Process" components.  Typically, relay set selection (or
   self-election) occurs based on dynamic input from a neighborhood
   discovery process.  SMF supports the case where neighborhood
   discovery and/or relay set selection information is obtained from a
   coexistent process (e.g., a lower layer mechanism or a unicast
   routing protocol using relay sets).  In some algorithm designs, 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 September 15, 2011    [Page 6]

Internet-Draft                     SMF                        March 2011

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

                      Figure 1: SMF Node Architecture

   There are certain IP multicast packets, defined later in this
   specification
UH> ================
UH> better: "defined in section XX of this specification"
UH> ================

, that are "non-forwardable" and these multicast packets
   will be ignored by the SMF forwarding engine.  The SMF forwarding
   engine MAY also work with policies and management interfaces to allow
   additional filtering control over which multicast packets are
   considered for potential SMF forwarding.  This interface would allow
   more refined dynamic forwarding control once such techniques are
   matured for MANET operation.  At present further discussion of
   dynamic control is left to future work.

   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),

UH> ================
UH> I prefer to use passive instead of "we...", i.e. "CF is defined as ... "
UH> ================

as the simplest
   case of SMF multicast forwarding.  With CF, each SMF router forwards
   each received multicast packet exactly once.  In this case, the need
   for any relay set selection or neighborhood topology information is
   eliminated at the expense of additional network overhead.  In CF
   mode, the SMF-DPD functionality is still required.  While SMF
   supports a CF mode of operation
UH> ================
UH> add comma
UH> ================

the use of more efficient relay set
   modes is RECOMMENDED to reduce contention and congestion caused by
   unnecessary packet retransmissions [NTSC99].

   An efficient, reduced relay set is realized by selecting and
   maintaining a subset of all possible routers in a MANET routing
   domain.  Known distributed relay set selection algorithms have
   demonstrated the ability to provide and maintain a dynamic connected
   set for forwarding multicast IP packets [MDC04].  A few such relay
   set selection algorithms are described in the Appendices of this

Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 7]

Internet-Draft                     SMF                        March 2011

   document and the basic designs borrow directly from previously
   documented IETF work.  SMF relay set configuration is extensible and
   additional relay set algorithms beyond those specified here can be
   accommodated in future work.

   Determining and maintaining an optimized set of forwarding nodes
   generally requires dynamic neighborhood topology information.
   Neighborhood topology discovery functions MAY be externally provided
   by a MANET unicast routing protocol or by using the MANET
   NeighborHood Discovery Protocol (NHDP) [RFC6130] running in
   concurrence with SMF.  Additionally, this specification allows
   alternative lower layer interfaces (radio router interface) to
   provide the necessary neighborhood information to aid in supporting
   more effective relay set election.  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 interactions are
   outlined later
UH> ================
UH> remove the word "later"
UH> ================

 in Section 7.  This document states specific
   requirements for neighborhood discovery with respect to the
   forwarding process and the relay set selection algorithms described
   herein.  For determining dynamic relay sets in the absence of other
   control interfaces, SMF relies on the MANET NHDP specification to
   assist in IP layer 2-hop neighborhood state discovery and maintenance
   for relay set election.  "SMF_TYPE" and "SMF_NBR_TYPE" Message and
   Address Block, respectfully,
UH> ================
UH> "respectively"?
UH> ================

TLV structures (per [RFC5444]) are
   defined for use with the NHDP protocol.  It is RECOMMENDED that all
   nodes performing SMF operation in conjunction with NHDP, include
   these TLV types in any NHDP HELLO messages generated.  This
   capability allows for nodes participating in SMF to be explicitly
   identified along with their respective dynamic relay set algorithm.

4.  SMF Applicability

   Within dynamic wireless routing topologies, maintaining traditional
   forwarding trees to support a multicast routing protocol is often not
   as effective as in wired networks due to the reduced reliability and
   increased dynamics of mesh topologies [MGL04] [GM99].  A basic packet
   forwarding service reaching all connected routers running the SMF
   protocol within a localized routing domain
UH> ================
UH> "localized routing domain"? is that the same as "interior routing
domain" or just "routing domain"?
UH> ================
may provide a useful group
   communication paradigm for various classes of applications.
   Applications that could take advantage of a simple multicast
   forwarding service include multimedia streaming, interactive group-
   based messaging and applications, peer-to-peer middleware
   multicasting, and multi-hop mobile discovery or registration
   services.  SMF is likely only appropriate for deployment in limited
   dynamic wireless routing domains so that the flooding process can be
   contained.  The limited SMF routing domains are further defined as

Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 8]

Internet-Draft                     SMF                        March 2011

   administratively scoped multicast forwarding domains in Section 9.2.

   Note again that Figure 1 provides a notional architecture for typical
   SMF-capable nodes.  A goal is that simple leaf nodes
UH> ================
UH> remove "simple"? I think that this is not quite clear what a
"leaf" node (/router) is in the context of the draft.
UH> ================

 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).  It is
   important that SMF deployments in localized edge network settings
UH> ================
UH> definition of "localized edge network settings"?
UH> ================

are
   able to connect and interoperate with existing standard multicast
   protocols operating within more conventional Internet
   infrastructures.  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].  Present experimental SMF implementations
   have demonstrated gateway functionality at MANET border routers
   operating with existing external IP multicast routing protocols
   [CDHM07],[DHS08],and

UH> ================
UH> space missing before "and" and before "[DHS08]"
UH> ================

[DHG09].  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.
UH> ================
UH> s/here/in this document/
UH> ================

5.  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 specific network
       interfaces.

   The purpose of intercepting outbound, locally-generated multicast
   packets is to apply any added packet marking needed to satisfy the
   DPD requirements so that proper forwarding may be conducted.  Note
   that for some system configurations the interception of outbound
   packets for this purpose is not necessary.
UH> ================
UH? such as? why?
UH> ================

   Inbound multicast packets are 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 IP multicast packets
   with destination addresses that are not node-local and link-local for
   IPv6 as defined in [RFC4291] and that are not within the local
   network control block as defined by [RFC5771]

   This will help support generic multi-hop multicast application needs
   or to distribute designated multicast traffic ingressing the SMF
   routing domain via border routers.  The multicast addresses to be
   forwarded should be maintained by an a priori list or a dynamic

Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 9]

Internet-Draft                     SMF                        March 2011

   forwarding information base (FIB) that MAY interact with future MANET
   dynamic group membership extensions or management functions.  There
   will also be a well-known multicast group for SMF.

UH> ================
UH> "will be"? should we write a document defining that and cite it here?
UH> ================

 This multicast
   group is specified to contain all routers within an SMF routing
   domain, so that packets transmitted to the multicast address
   associated with the group will be delivered to all connected routers
   running SMF.  Due the mobile nature of a MANET, routers running SMF
   may not be topologically connected at particular times.  For IPv6,
   the multicast address is specified to be "site-local".  The name of
   the multicast group is "SL-MANET-ROUTERS".  Minimally SMF MUST
   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 limit value in the IP header is greater than 1.
   SMF MUST forward all additional global scope addresses specified
   within the dynamic FIB or configured list as well.  In all cases, the
   following rules MUST be observed for SMF multicast forwarding:

   1.  IP multicast packets with TTL <= 1
UH> ================
UH> "TTL / hop limit"
UH> ================

MUST NOT be forwarded.
   2.  Link local IP multicast packets MUST NOT be forwarded.
   3.  Incoming IP multicast packets with an IP source address matching
       one of those of the local SMF router interface(s) MUST NOT be
       forwarded.
   4.  Received frames with the MAC source address matching any MAC
       address of the routers interfaces MUST NOT be forwarded.
   5.  Received packets for which SMF cannot reasonably ensure temporal
       DPD uniqueness

UH> ================
UH> Maybe "temporal uniqueness" should be defined before.
UH> ================

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

   Note that rule #3 is important because over some types of wireless
   interfaces, the originating SMF router may receive re-transmissions
   of its own packets when they are forwarded by adjacent routers.  This
   rule avoids unnecessary retransmission of locally-generated packets
   even when other forwarding decision rules would apply.

   An additional processing rule also needs to be considered based upon
   a potential security threat.
UH> ================
UH> Maybe it would be interesting to add a rule number 7 to the
previous list, which says something like "any further filtering can be
applied by extensions to this specification", similar to NHDP, which
allows to easily "hook in" extensions, e.g. for security?
UH> ================

As discussed further in Section 10,
   there may be concern in some SMF deployments that malicious nodes may
   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
UH> ================
UH> s/Hop Limit/hop limit/
UH> ================

) 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
UH> ================
UH> / hop limit. Or maybe, at first usage of "TTL", add a comment that
throughout the document, TTL is used both for TTL (in IPv4) and hop
limit (IPv6)
UH> ================

) through the SMF area.
UH> ================
UH> s/SMF area/SMF routing domain/
UH> ================

A
   RECOMMENDED approach to prevent this attack, when it is a concern,
   would be to cache temporal packet TTL values along with the per-
   packet DPD state (hash value(s) and/or identifier as described in

Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 10]

Internet-Draft                     SMF                        March 2011

   Section 6).  Then, if a subsequent matching (with respect to DPD)
   packet arrives with a larger TTL value than the packet that was
   previously forwarded, SMF should forward the new packet and update
   the TTL value cached with corresponding DPD state to the new, larger
   TTL value.  There may be temporal cases where SMF would unnecessarily
   forward some duplicate packets using this approach, but those cases
   are expected to be minimal and acceptable when compared with the
   potential threat of denied service.

   Once these criteria
UH> ================
UH> which criteria?
UH> ================

have been met, an SMF implementation MUST make a
   forwarding decision dependent upon the relay set selection algorithm
   in use.  One of the requirements of SMF is that it be configured to
   run a particular relay set selection algorithm when launched.  If the
   SMF implementation is using Classical Flooding (CF), the forwarding
   decision is implicit once DPD uniqueness is determined.  Otherwise, a
   forwarding decision depends upon the current interface-specific relay
   set state.  The descriptions of the relay set selection algorithms in
   the Appendices to this document specify the respective heuristics for
   multicast packet forwarding and specific DPD or other processing
   required to achieve correct SMF behavior in each case.  For example,
   one class of forwarding is based upon relay set election status and
   the packet's previous hop, while other classes designate the local
   SMF router as a forwarder for all neighboring nodes.

6.  SMF Duplicate Packet Detection

   Duplicate packet detection (DPD) is often a requirement in MANET or
   wireless mesh packet forwarding mechanisms because packets may be
   transmitted out the same physical interface upon which they arrived
   and nodes may also receive copies of previously-transmitted packets
   from other forwarding neighbors.  SMF operation requires DPD and
   implementations MUST provide mechanisms to detect and reduce the
   likelihood of forwarding duplicate multicast packets using temporal
   packet identification.  It is RECOMMENDED this be implemented by
   keeping a history of recently-processed multicast packets for
   comparison to incoming packets.  A DPD packet cache history SHOULD be
   kept long enough to span the maximum network traversal lifetime,
   MAX_PACKET_LIFETIME, of multicast packets being forwarded within an
   SMF routing domain.  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 as presented in Section 5.  For both IPv4 and IPv6, this
   document describes two basic multicast duplicate packet detection
   mechanisms: header content identification-based (I-DPD) and hash-
   based (H-DPD) duplicate detection.  I-DPD is a mechanism using
   specific packet headers, and option headers in the case of IPv6, in
   combination with flow state to estimate the temporal uniqueness of a

Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 11]

Internet-Draft                     SMF                        March 2011

   packet.  H-DPD uses hashing of the particular packet fields and
   payloads to provide an estimation of temporal uniqueness.

   Trade-offs of the two approaches to DPD merit different consideration
UH> ================
s/consideration/considerations/
UH> ================

   dependent upon the specific SMF deployment scenario.  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 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.  In general this involves keeping track of
   previously forwarded packets so that duplicates are not forwarded,
   but some relay techniques have additional considerations, such as
   discussed in Appendix B.2.

   Additional details of I-DPD and H-DPD processing and maintenance for
   different classes of packets are described in the following sections.

6.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 and each is covered
   in more detail in particular subsections:
   1.  the hop-by-hop SMF-DPD option header,
   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.

6.1.1.  IPv6 SMF-DPD Header Option

   The base IPv6 packet header does not contain a unique identifier
   suitable for DPD.  This section defines an IPv6 Hop-by-Hop Option

Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 12]

Internet-Draft                     SMF                        March 2011

   [RFC2460] to serve this purpose for IPv6 I-DPD.  Additionally, the
   header option provides a mechanism to guarantee non-collision of hash
   values for different packets when H-DPD is used.

   If this is the only hop-by-hop option present, the optional
   "TaggerId" field
UH> ================
UH> would be good to explain the use of the field here
UH> ================

(see below) is not included, and the size of the DPD
   packet identifier (sequence number) or hash token is 24 bits or less,

UH> ================
UH> why 24 bits or less?
UH> ================

   this will result in the addition of 8 bytes to the IPv6 packet header
   including the "Next Header", "Header Extension Length", SMF-DPD
   option fields, and padding.

       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 |
UH> ================
UH> why are these first 16 bits empty? maybe just remove them? same
for all following figures
UH> ================

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |H|  DPD Identifier Option Fields or Hash Assist Value  ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Fig. 2 - IPv6 SMF-DPD Hop-by-Hop Header Option

   "Option Type" = (Lower 5 bits pending IANA assignment, highest order
   MUST be 000).  By having these three bits be zero, this specification
   requires that nodes not recognizing this option type should skip over
   this option and continue processing the header and that the option
   must not change en route [RFC2460].

   "Opt. Data Len" = Length of option content (I.e., 1 + (<IdType> ?
   (<IdLen> + 1): 0) + Length(DPD ID)).
UH> ================
UH> I don't like that notation :-) <IdType> is not a "condition" (I
know, I am fan of Java more than C, which would allow such "dirty"
expressions ;-)
UH> I'd prefer using English to describe this.
UH> ================

   "H-bit" = a hash indicator bit value identifying DPD marking type. 0
   == sequence-based approach w/ optional taggerId
UH> ================
UH> s/taggerId/TaggerId/
UH> ================

and a tuple-based
   sequence number. 1 == indicates a hash assist value (HAV) field
   follows to aid in avoiding hash-based DPD collisions.

   When the "H-bit" is cleared (zero value), the SMF-DPD format to
   support I-DPD operation is specified as shown in Figure 2 and defines
   the extension header in accordance with [RFC2460].

Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 13]

Internet-Draft                     SMF                        March 2011

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

UH> ================
UH> it looks like TidType is 3.5 bits long. I know, it doesn't fit in
there... not sure there is a better way
UH> ================

       +-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               |            Identifier  ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 2: IPv6 SMF-DPD Header Option in I-DPD mode

   The "TidType" is
UH> ================
UH> maybe use the same style for these definitions as before, i.e.
with: "field" = definition...
UH> ================

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)  |
   +---------+-------+-------------------------------------------------+

                          Table 1: TaggerId Types

   This format allows a quick check of the "TidType" field to determine
   if a "TaggerId" field is present.  If the <TidType>

UH> ================
UH> is there a difference between the notation "TidType" and
<TidType>? See my comment to add a "notations" description to the
terminology section.
UH> ================

 is NULL, then the
   length of the DPD packet <Identifier> field corresponds to the
UH> ================
UH> remove "the"
UH> ================

 (<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
UH> ================
UH> taggerId or TaggerId?
UH> ================

:srcAddr:
   dstAddr> tuple.  When the "TaggerId" field is not present, then it is
   assumed the source host
UH> ================
UH> host? or router?
UH> ================

applied the SMF-DPD option and the
   <Identifier> can be considered unique in the context of the IPv6
   packet header <srcAddr:dstAddr> tuple.  IPv6 I-DPD operation details

Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 14]

Internet-Draft                     SMF                        March 2011

   are described in Section 6.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
UH> ================
UH> host? router?
UH> ================

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 hash values in the DPD
   cache.  This situation can be detected locally on the node by running
   the hash algorithm and checking the DPD cache.
UH> ================
UH> change . to ,
UH> ================

prior ingressing a
   previously unmarked packet or a locally sourced packet.  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 format of the SMF-DPD header option for H-DPD
   operation is given in Figure 3.

       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 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|    Hash Assist Value (HAV) ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 3: IPv6 SMF_DPD Header Option in H-DPD Mode

UH> ================
UH> There is an inconsistency throughout the document between SMF_DPD
and SMF-DPD
UH> ================

   The SMF-DPD option should be applied with a HAV
UH> ================
UH> s/a/an/
UH> ================

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

6.1.2.  IPv6 Identification-based DPD

   The following table summarizes the IPv6 I-DPD processing and
   forwarding decision approach.  Within the table '*' indicates an
   ignore field condition.
UH> ================
UH> describe what's an "ignore field condition"
UH> ================

Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 15]

Internet-Draft                     SMF                        March 2011

   +-------------+-----------+-----------+-----------------------------+
   | 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                  |
UH> ================
UH> adding horizontal lines between rows could make it easier to read
UH> ================

   | 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      |
   +-------------+-----------+-----------+-----------------------------+

                   Table 2: IPv6 I-DPD Processing Rules

   If the IPv6 multicast packet
UH> ================
UH> which? "a packet received on a router, considered for
forwarding..." or similar..
UH> ================

UH> ================
UH> The following would be easier to read, if it was an ennummeration, e.g.
  1. if the packet is an IPv6 fragement, then...
  2. else, if it is an...
UH> ================

 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>

UH> ================
UH> maybe write what the abbreviation SPI stands for and cite IPsec
UH> ================

   where the "IPsecType" is either AH or ESP [RFC4302].  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
UH> ================
UH> End systems sounds like hosts. Do you mean routers?
UH> ================

or ingressing SMF gateways are responsible for applying
   this option to support DPD.  The following table
UH> ================
UH> s/The following table/Table 3/
UH> ================

summarizes these
   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:]
UH> ================
UH> the notation <[taggerId:] is unclear. Also, it should be TaggerId
UH> ================

srcAddr:dstAddr>    | <SMF-DPD option     |
   | Packet    |                                 | header id>          |
   +-----------+---------------------------------+---------------------+

Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 16]

Internet-Draft                     SMF                        March 2011

              Table 3: IPv6 I-DPD Packet Identification Types

   "IPsecType" is either Authentication Header (AH) or Encapsulating
   Security Payload (ESP).
UH> ================
UH> That has been said only a few sentences before
UH> ================

   The "TaggerId" is an optional field of the IPv6 SMF-DPD header
   option.

6.1.3.  IPv6 Hash-based DPD

   A default hash-based DPD approach (H-DPD) for use by SMF is specified
   as follows.  An MD5 [RFC1321] hash
UH> ================
UH> hm, why fix to MD5 (deprecated)? couldn't we use a registry and
then list possible signature methods in the appendix?
UH> ================

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 least significant 64 bits of this
   digest 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>.  SMF ingress points (i.e., source hosts
UH> ================
UH> hosts / routers?
UH> ================

   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 6.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 process any included HAV
   values (see Section 6.1.1) in its hash calculation.

   If a packet results in a digest collision (i.e., by checking the
   H-DPD digest history) within the DPD cache kept by SMF forwarders,
   the packet should
UH> ================
UH> should or SHOULD?
UH> ================

be silently dropped.  If a digest collision is
   detected at an SMF ingress point the H-DPD option header is
   constructed with a randomly generated HAV.  A
UH> ================
UH> s/a/an/
UH> ================

HAV is recalculated as
   needed to produce a non-colliding hash value prior to forwarding.
   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 uses.  Future
   approaches and experimentation may discover designs
UH> ================
UH> s/designs/design/
UH> ================

 tradeoffs in hash
   robustness and efficiency worth considering.  Enhancements MAY
   include reducing the maximum payload length that is processed,
   determining shorter indexes, or applying more efficient hashing
   algorithms.  Use of the HAV functionality may allow for application
   of "lighter-weight" hashing techniques that might not have been

Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 17]

Internet-Draft                     SMF                        March 2011

   initially considered due to poor collision properties otherwise.
UH> ================
UH> I suggest use of registry in the appendix
UH> ================

   Such techniques could reduce packet processing overhead and memory
   requirements.

6.2.  IPv4 Duplicate Packet Detection

   This section describes the mechanisms and options for IPv4 DPD.  The
   IPv4 packet header [RFC0791] 16-bit "Identification" field MAY be
   used for DPD assistance, but practical 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.
UH> ================
UH> s/a/an/
UH> ================

   A specific SMF-DPD marking option is not specified for IPv4 since
   header options are not as tractable for end systems
UH> ================
UH> hosts / routers?
UH> ================

 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
UH> ================
UH> host? router?
UH> ================

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
UH> ================
UH> option header or options header?
UH> ================

, the
   interoperability constraints are looser than the IPv6 version and
   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.

6.2.1.  IPv4 Identification-based DPD

   The following table
UH> ================
UH> s/The following table/Table 4/
UH> ================

summarizes the IPv4 I-DPD processing approach
   once a packet has passed the basic forwardable criteria described in
   Section 5.  Within the table '*' indicates an ignore field condition.
   DF, MF, Fragment offset correspond to related fields and flags
   defined in [RFC0791].

Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 18]

Internet-Draft                     SMF                        March 2011

   +------+------+----------+---------+--------------------------------+
   | DF   | MF   | Fragment | IPsec   | IPv4 I-DPD Action              |
   | flag | flag | offset   |         |                                |
   +------+------+----------+---------+--------------------------------+
   | 1    | 1    | *        | *       | Invalid, Do Not Forward        |
   | 1    | 0    | nonzero  | *       | Invalid, Do Not Forward        |
   | *    | 0    | zero     | not     | Tuple I-DPD Check and Process  |
   |      |      |          | Present | for 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                     |
   +------+------+----------+---------+--------------------------------+

                   Table 4: IPv4 I-DPD Processing Rules

   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 [RFC4302].  Finally, for
   unfragmented, non-IPsec, IPv4 packets, the "Identification" field can
   be used for I-DPD purposes.  The "Identification"
UH> ================
UH> <Identification> or "Identification" (see comment same pages before)
UH> ================

 field can be
   considered unique in the context of the IPv4 <protocol:scrAddr:
   dstAddr> tuple.  The following table
UH> ================
UH> s/The following table/Table 5/
UH> ================

summarizes these packet
   identification types:

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

Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 19]

Internet-Draft                     SMF                        March 2011

   | Regular   | <protocol:srcAddr:dstAddr>      | <identification     |
   | Packet    |                                 | field>              |
   +-----------+---------------------------------+---------------------+

              Table 5: IPv4 I-DPD Packet Identification Types

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

   The limited size (16 bits) of the IPv4 header "Identification" field
   [RFC0791] may result in more frequent value field 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 10 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.

6.2.2.  IPv4 Hash-based DPD

   To ensure consistent IPv4 H-DPD operation among SMF nodes, a default
   hashing approach is specified.  This is similar to that specified
UH> ================
UH>+ " in section xx "
UH> ================

for IPv6, but the H-DPD header option with HAV is not considered.  SMF
   MUST perform an MD5 [RFC1321]
UH> ================
UH> same comment as before, maybe put a flexible hashing using a registry?
UH> ================

hash of the immutable header fields,
   option fields and data content of the IPv4 multicast packet resulting
   in a 128-bit digest.  The least significant 64 bits of this digest is
UH> ================
UH> s/is/are/
UH> ================

   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.

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

7.  Relay Set Selection
UH> ================
UH> Maybe add a sentence here before 7.1. It looks weird to have no
text between two headers.
UH> ================

7.1.  Non-Reduced Relay Set Forwarding

   SMF implementations MUST support CF as a basic forwarding mechanism
   when reduced relay set information is not available or not selected

Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 20]

Internet-Draft                     SMF                        March 2011

   for operation.  In CF mode, each node transmits a locally generated
   or newly received forwardable packet exactly once.  The DPD
   techniques described in Section 6 are critical to proper operation
   and prevent duplicate packet retransmissions by the same forwarding
   node.

7.2.  Reduced Relay Set Forwarding

   MANET reduced relay sets are often achieved by distributed algorithms
   that can dynamically calculate a topological connected dominating set
   (CDS).

   A goal of SMF is to apply reduced relay sets for more efficient
   multicast dissemination within dynamic topologies.  To accomplish
   this SMF MUST
UH> ================
UH>maybe: s/SMF/an SMF implementation/
UH> ================

support the ability to modify its multicast packet
   forwarding rules based upon relay set state received dynamically
   during operation.  In this way, SMF forwarding operates effectively
   as neighbor adjacencies or multicast forwarding policies within the
   topology change.

   In early SMF experimental prototyping, the relay set information has
   been derived from coexistent unicast routing control plane traffic
   flooding processes [MDC04].  From this experience, extra pruning
   considerations were sometimes required when utilizing a relay set
   from a separate routing protocol process.  As an example, relay sets
   formed for the unicast control plane flooding MAY include additional
   redundancy that may not be desired for multicast forwarding use
   (e.g., biconnected relay set).

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

   1.  Robustness to topological dynamics and mobility
   2.  Localized election or coordination of any relay sets
   3.  Reasonable minimization of CDS relay set size given above
       constraints
   4.  Heuristic support for preference or election metrics

   Some relay set algorithms meeting these criteria are described in the
   Appendices of this document.  Additional relay set selection
   algorithms may be specified in separate specifications in the future.
   Each Appendix subsection in this document can serve as a template for
   specifying additional relay algorithms.

   Figure 4 depicts a
UH> ================
UH> s/a/an/
UH> ================
 information flow diagram of possible relay set
   control options.  The SMF Relay Set State
UH> ================
UH>Relay Set or relay set (as later in the paragraph)?
UH> ================
represents the information
   base that is used by SMF in the forwarding decision process.  The
   relay set control option diagram demonstrates that the SMF relay set

Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 21]

Internet-Draft                     SMF                        March 2011

   state may be determined by fundamentally three different methods:
   independent operation with NHDP [RFC5444] input providing dynamic
   network neighborhood adjacency information that is then used by a
   particular relay set selection, slave operation with an existing
   unicast MANET routing protocol that is capable of providing CDS
   election information that can be used by SMF, and cross layer
   operation that may involve lower layer neighbor or link information.
   Other heuristics to influence and control election can come from
   network management or other interfaces as shown on the right
UH> ================
UH> + " of the figure"
UH> ================

.  Of
   course CF mode,
UH> ================
UH> move comma to right after "of course"?
UH> ================

simplifies the control and does not require other
   input but relies solely on DPD.

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

             Figure 4: SMF Reduced Relay Set Information Flow

   More discussion is provided on the three styles of SMF operation with
   reduced relay sets as illustrated in Figure 4 :
UH> ================
UH> remove blank after "4"
UH> ================

   1.  Independent operation: In this case, SMF operates independently
       from any unicast routing protocols.  To support reduced relay
       sets SMF MUST perform its own relay set selection using
       information gathered from signaling.  It is RECOMMENDED that an
       associated MANET NHDP process be use
UH> ================
UH> s/use/used/
UH> ================

for this signaling.  NHDP

Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 22]

Internet-Draft                     SMF                        March 2011

       messaging SHOULD be appended with additional [RFC5444] type-
       length-value (TLV) content to support SMF-specific requirements
       as discussed in [RFC6130] and for the applicable relay set
       algorithm described in the Appendices of this document or future
       specifications.  Unicast routing protocols may co-exist, even
       using the same NHDP process, but signaling that supports reduced
       relay set selection for SMF is independent of these protocols.
   2.  Operation with CDS-aware unicast routing protocol: In this case,
       a coexistent unicast routing protocol provides dynamic relay set
       state based upon its own control plane CDS or neighborhood
       discovery information.
   3.  Cross-layer Operation: In this case, SMF operates using
       neighborhood status and triggers from a cross-layer information
       base for dynamic relay set selection and maintenance (e.g., lower
       link layer).

8.  SMF Neighborhood Discovery Requirements

   This section defines the requirements for use of the MANET
   Neighborhood Discovery Protocol (NHDP) [RFC6130] to support SMF
   operation.  Note that basic CF forwarding requires no neighborhood
   topology knowledge since in this configured mode every SMF node
   relays all traffic.  Supporting more reduced SMF relay set operation
   requires the discovery and maintenance of dynamic neighborhood
   topology information.  The MANET NHDP protocol can be leveraged
UH> ================
UH> + "to"
UH> ================

   provide this necessary information, however there are SMF-specific
   requirements for related NHDP use.  This is the case for both
   "independent" SMF operation where NHDP is being used specifically to
   support SMF or when one NHDP instance is used for both for
UH> ================
UH> "is used for both for" (I am not a native speaker, but it seems weird...)
UH> ================

SMF and a
   coexistent MANET unicast routing protocol.

   NHDP HELLO messages and the resultant neighborhood information base
   are described separately within the NHDP specification.  To
   summarize, the NHDP protocol provides the following basic functions:

   1.  1-hop neighbor link sensing and bidirectionality checks of
       neighbor links,
   2.  2-hop neighborhood discovery including collection of 2-hop
       neighbors and connectivity information,
   3.  Collection and maintenance of the above information across
       multiple interfaces, and
   4.  A method for signaling SMF information throughout the 2-hop
       neighborhood through the use of TLV extensions.

   Appendices (A-C) of this document describe CDS-based relay set
   selection algorithms that can achieve efficient SMF operation, even
   in dynamic, mobile networks and each of the algorithms has been

Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 23]

Internet-Draft                     SMF                        March 2011

   initially experimented within a working SMF prototype [MDDA07].  When
   using these algorithms in conjunction with NHDP, a method verifying
   neighbor SMF operation is required in order to insure correct relay
   set selection.  NHDP along with SMF operation verification provides
   the necessary information required by these algorithms to conduct
   relay set selection.  Verification of SMF operation may be done
   administratively or through the use of the SMF relay algorithms TLVs
   defined in the following subsections.  Use of the SMF relay algorithm
   TLVs is RECOMMENDED when using NHDP for SMF neighborhood discovery.

   The following sub-sections specify some SMF-specific TLV types
   supporting general SMF operation or supporting the algorithms
   described in the Appendices.  The Appendices describing several relay
   set algorithms also specify any additional requirements for use with
   NHDP and reference the applicable TLV types as needed.

8.1.  SMF Relay Algorithm TLV Types

   This section specifies TLV types to be used within NHDP messages to
   identify the CDS relay set selection algorithm(s) in use.  Two TLV
   types are defined, one message TLV type and one address TLV type.

8.1.1.  SMF Message TLV Type

   The message TLV type denoted SMF_TYPE is used to identify the
   existence of an SMF instance operating in conjunction with NHDP.
   This message TLV type makes use of the extended type field as defined
   by [RFC5444] to convey the CDS relay set selection algorithm
   currently in use by the SMF message originator.  When NHDP is used to
   support SMF operation, the SMF_TYPE TLV, containing the extended type
   field with the appropriate value, SHOULD be included in NHDP_HELLO
   messages (HELLO messages as defined in [RFC6130].  This allows SMF
   nodes to learn when neighbors are configured to use NHDP for
   information exchange including algorithm type and related algorithm
   information.  This information can be used to take action, such as
   ignoring neighbor information using incompatible algorithms.  It is
   possible that SMF neighbors MAY be configured differently and still
   operate cooperatively, but these cases will vary dependent upon the
   algorithm types designated.

   This document defines the following Message TLV type as specified in
   Table 6 conforming to [RFC5444].  The TLV extended type field is used
   to contain the sender's "Relay Algorithm Type".  The interpretation
   of the "value" content of these TLVs is defined per "Relay Algorithm
   Type" and may contain algorithm specific information.

Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 24]

Internet-Draft                     SMF                        March 2011

          +---------------+----------------+--------------------+
          |               | TLV syntax     | Field Values       |
UH> ================
UH> s/syntax/Syntax/
UH> ================
          +---------------+----------------+--------------------+
          | type          | <tlv-type>     | SMF_TYPE           |
          | extended type | <tlv-type-ext> | <relayAlgorithmId> |
          | length        | <length>       | variable           |
          | value         | <value>        | variable           |
          +---------------+----------------+--------------------+

                       Table 6: SMF Type Message TLV

   In Table 6 <relayAlgorithmId> is an 8-bit field containing a number
   0-255 representing the "Relay Algorithm Type" of the originator
   address of the corresponding NHDP message.

   Possible values for the <relayAlgorithmId> are defined in Table 7.
   The table provides value assignments, future IANA assignment spaces,
   and an experimental space.  The experimental space use MUST NOT
   assume uniqueness and thus should not be used
UH> ================
UH> should not or SHOULD NOT
UH> ================

for general
   interoperable deployment prior to official IANA assignment.

   +-------------+--------------------+--------------------------------+
   |  Type Value |    Extended Type   |            Algorithm           |
   |             |        Value       |                                |
   +-------------+--------------------+--------------------------------+
   |   SMF_TYPE  |          0         |               CF               |
   |   SMF_TYPE  |          1         |              S-MPR             |
   |   SMF_TYPE  |          2         |              E-CDS             |
   |   SMF_TYPE  |          3         |             MPR-CDS            |
   |   SMF_TYPE  |        4-127       |  Future Assignment STD action  |
   |   SMF_TYPE  |       128-239      |     No STD action required     |
   |   SMF_TYPE  |       240-255      |       Experimental Space       |
   +-------------+--------------------+--------------------------------+

                 Table 7: SMF Relay Algorithm Type Values

   Acceptable <length> and <value> fields of an SMF_TYPE TLV are
   dependent on the extended type value (i.e. relay algorithm type).
   The appropriate algorithm type, as conveyed in the <tlv-type-ext>
   field, defines the meaning and format of its TLV <value> field.  For
   the algorithms defined by this document, see the appropriate appendix
   for the <value> field format.

8.1.2.  SMF Address Block TLV Type

   An address block TLV type, denoted SMF_NBR_TYPE (i.e., SMF neighbor
   relay algorithm) is specified in Table 8.  This TLV enables CDS relay
   algorithm operation and configuration to be shared among 2-hop

Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 25]

Internet-Draft                     SMF                        March 2011

   neighborhoods.  Some relay algorithms require two hop neighbor
   configuration in order to correctly select relay sets.  It is also
   useful when mixed relay algorithm operation is possible, some
   examples of mixed use is
UH> ================
UH> s/is/are/
UH> ================
outlined in the appendices.

   The message SMF_TYPE TLV
UH> ================
UH> I think in RFC5444 it is Message TLV and not message TLV.
(similiar for address.. etc).
UH> ================

and address block SMF_NBR_TYPE TLV types
   share a common format.

          +---------------+----------------+--------------------+
          |               | TLV syntax     | Field Values       |
          +---------------+----------------+--------------------+
          | type          | <tlv-type>     | SMF_NBR_TYPE       |
          | extended type | <tlv-type-ext> | <relayAlgorithmId> |
          | length        | <length>       | variable           |
          | value         | <value>        | variable           |
          +---------------+----------------+--------------------+

                    Table 8: SMF Type Address Block TLV

   <relayAlgorithmId> in Table 8 is an 8-bit unsigned integer field
   containing a number 0-255 representing the "Relay Algorithm Type"
   value that corresponds to any associated address in the address
   block.  Note that "Relay Algorithm Type" values for 2-hop neighbors
   can be conveyed in a single TLV or multiple value TLVs as described
   in [RFC5444].  It is expected that SMF nodes using NHDP construct
   address blocks with SMF_NBR_TYPE TLVs to advertise "Relay Algorithm
   Type" and to advertise neighbor algorithm values received in SMF_TYPE
   TLVs from those neighbors.

   Again values for the <relayAlgorithmId> are defined in Table 8.

   The interpretation of the "value" field of SMF_NBR_TYPE TLVs is
   defined per "Relay Algorithm Type" and may contain algorithm specific
   information.  See the appropriate appendix for definitions of value
   fields for the algorithms defined by this document.

9.  SMF Border Gateway Considerations

   It is expected that SMF will be used to provide simple forwarding of
   multicast traffic within a MANET or mesh routing topology.  A border
   router gateway approach should be used to allow interconnection of
   SMF areas
UH> ================
UH> SMF routing domain?
UH> ================

with networks using other multicast routing protocols, such
   as PIM.  It is important to note that there are many scenario-
   specific issues that should be addressed when discussing border
   multicast routers.  At the present time, experimental deployments of
   SMF and PIM border router approaches have been demonstrated[DHS08].
UH> ================
UH> missing blank before [DHS08]
UH> ================
   Some of the functionality border routers may need to address includes

Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 26]

Internet-Draft                     SMF                        March 2011

   the following:

   1.  Determining which multicast group traffic transits the border
       router whether entering or exiting the attached SMF routing
       domain.
   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.

   Each of these areas is discussed in more detail in the following
   subsections.  Note the behavior of SMF border routers is the same as
   that of non-border SMF nodes when forwarding packets on interfaces
   within the SMF routing domain.  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.

9.1.  Forwarded Multicast Groups

   Mechanisms for dynamically determining groups for forwarding into a
   MANET SMF routing domain is an evolving technology area.  Ideally,
   only groups for which there is active group membership should be
   injected into the SMF domain.  This can 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 other explicit, dynamic control of membership be
   provided.  Specification of such an IGMP/MLD proxy protocol is beyond
   the scope of this document.

   For outbound traffic, SMF border routers can perform duplicate packet
   detection and forward non-duplicate traffic that meets TTL/hop limit
   and scoping criteria and forward packet to interfaces external to the
   SMF routing domain.  Appropriate IP multicast routing (PIM, etc) on
   those interfaces can then make further forwarding decisions with
   respect to the multicast packet.  Note that the presence of multiple
   border routers associated with a MANET routing domain raises
   additional issues.  This is further discussed in Section 9.4 but
   further work is expected to be needed here.

Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 27]

Internet-Draft                     SMF                        March 2011

9.2.  Multicast Group Scoping

   Multicast scoping is used by network administrators to control the
   network routing domains reachable by multicast packets.  This is
   usually done by configuring external interfaces of border routers in
   the border of a routing domain to not forward multicast packets which
   must be kept within the routing region.
UH> ================
UH> routing domain?
UH> ================

  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 for the router interfaces as with any traditional multicast
   router.  However, for the case of TTL scoping it SHOULD be taken into
   account that the packet could traverse multiple hops within the MANET
   SMF routing domain before reaching the border router.  Thus, TTL
   thresholds SHOULD be selected carefully.

   For IPv6, multicast address spaces include information about the
   scope of the group.  Thus, border routers of an SMF routing domain
   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 domain be designated a site-scoped multicast domain.  Thus,
   all IPv6 site-scoped multicast packets in the range FF05::/16 SHOULD
   be kept within the MANET SMF routing domain 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
   routers, and given that existing scoping mechanisms are not designed
   to work with mobile routers, it is assumed that non-border routers
   running SMF will not stop forwarding multicast data packets of an
   appropriate site scoping.  That is, it is assumed that an SMF routing
   domain is a site-scoped multicast area.

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

Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 28]

Internet-Draft                     SMF                        March 2011

   sources and receivers to interoperate with border routers over the
   multihop MANET SMF routing domain as if they were directly connected
   to the router need to be defined.  The following issues need to be
   addressed:

   1.  A mechanism by which border routers gather membership information
   2.  A mechanism by which multicast sources are known by the border
       router
   3.  A mechanism for exchange of exterior routing protocol messages
       across the SMF routing domain if the SMF routing domain 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 9.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 an SMF routing domain but doing this robustly in a
   distributed wireless environment likely requires additional
   considerations outside the scope of this document.

   The need for the border router to receive traffic from recognized
   multicast sources within the SMF routing domain is important to
   potentially achieve interoperability 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 nodes
   can join the multicast tree.  In addition, if those sources are not
   advertised to other autonomous systems (AS) using Multicast Source
   Discovery Protocol (MSDP), receivers in those external networks are
   not able to join the multicast tree for that source.

9.4.  Multiple Border Routers

   An SMF domain
UH> ================
UH> routing domain?
UH> ================

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

   1.  Handling duplicate unmarked IPv4 or IPv6 (without IPsec
       encapsulation or DPD option) packets possibly injected by
       multiple border routers.

Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 29]

Internet-Draft                     SMF                        March 2011

   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.

   When multiple border routers are present they 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,
UH> ================
UH> routing region? Is there a difference between MANET routing domain
and SMF routing domain?
UH> ================

   there are two forwarding policies that SMF nodes running I-DPD may
   implement:

   1.  Redundantly forward the multicast flows (identified by <srcAddr:
       dstAddr>) from each border router, performing DPD processing on a
       <taggerID:dstAddr> or <taggerID:srcAddr:dstAddr> 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:dstAddr>) only for the selected
       "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.  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., <srcAddr::dstAddr>) state be maintained for the
   selected "Tagger ID".

   The deployment of H-DPD operation 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.

10.  Security Considerations

   Gratuitous use of option headers can cause problems in routers.
   Other IP routers external to an SMF routing domains
UH> ================
UH> s/domains/domain/
UH> ================

that might
   receive forwarded multicast should
UH> ================
UH> should or SHOULD?
UH> ================

 ignore SMF-specific header options
   when encountered.  The header options types are encoded appropriately
   to allow for this behavior.

Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 30]

Internet-Draft                     SMF                        March 2011

   Here we briefly discuss several SMF denial-of-service (DoS) attack
   scenarios and we provide some initial recommended mitigation
   strategies.
UH> ================
UH> I'd prefer to not use "we". (instead, "several SMF DoS attack
scenarios are discussed..." etc)
UH> ================

   A potential denial-of-service attack against SMF forwarding is
   possible when a malicious node has a form of wormhole access to
   multiple part of a network topology.  In the wireless ad hoc case, a
   directional antenna is one way to provide such a wormhole physically.
   If such a node can preview forwarded packets in one part of the
   network and forward modified versions to another part of the network
   it can perform the following attack.  The malicious 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 could block or limit the subsequent
   forwarding of later-arriving valid packets with correct TTL values.
   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 5 to mitigate
   this form of attack.

   Sequence-based packet identifiers are predictable and thus provide an
   opportunity for a DoS attack against forwarding.  Forwarding
   protocols that use DPD techniques, such as SMF, may be vulnerable to
   DoS attacks based on spoofing packets with apparently valid packet
   identifier fields.  In wireless environments, where SMF will most
   likely be used, the opportunity for such attacks may be more
   prevalent than in wired networks.  In the case of IPv4 packets,
   fragmented IP packets or packets with IPsec headers applied, the DPD
   "identifier portions" of potential future packets that might be
   forwarded is highly 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.

   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

Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 31]

Internet-Draft                     SMF                        March 2011

   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.

   The support of forwarding IPsec packets 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.

UH> ================
UH> maybe add something that the security considerations of the used
neighbor discovery mechanism (NHDP) also applies
UH> ================

11.  IANA Considerations

   This document raises multiple IANA Considerations.  These include the
   IPv6 SMF_DPD hop-by-hop Header Extension defined and multiple Type-
   Length-Value (TLV) constructs
UH> ================
UH> missing (
UH> ================
[RFC5444]) to be used with NHDP
   [RFC6130]operation
UH> ================
UH> missing blank
UH> ================

 as needed to support different forms of SMF
   operation.  There is one message TLV type and one address TLV type
   needed to be assigned for SMF purposes as discussed in Section 8.1.

   The value of the IPv6 SMF-DPD Hop-by-Hop Option Type is TBD (to be
   assigned).

   The SL-MANET-ROUTERS multicast address will be registered for both
   IPv4 and IPv6 multicast address spaces.

11.1.  IPv6 SMF-DPD Header Extension

   This document requests IANA assignment of the "SMF_DPD" hop-by-hop
   option type from the IANA "IPv6 Hop-by-Hop Options Option Type"
   registry (see Section 5.5 of [RFC2780]).

   The format of this new option type is described in Section 6.1.1.  A
   portion of the option data content is the taggger identifier type
   "TidType" that provides a context for the "TaggerId" that is
   optionally included to identify the node that added the SMF_DPD
   option to the packet.  This document defines a namespace for IPv6
   SMF_DPD Tagger Identifier Type values:
                        ietf:manet:smf:taggerIdTypes

   The values that can be assigned within the "ietf:manet:smf:
   taggerIdTypes" name-space are numeric indexes in the range [0, 7],
   boundaries included.  All assignment requests are granted on an "IETF
   Consensus" basis as defined in [RFC5226].

   This specification registers Tagger Identification Type values from
   Table 9 in the registry "ietf:manet:smf:taggerIdTypes":

Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 32]

Internet-Draft                     SMF                        March 2011

                   +----------+-------+---------------+
                   | Mnemonic | Value | Reference     |
                   +----------+-------+---------------+
                   |   NULL   |   0   | This document |
                   |  DEFAULT |   1   | This document |
                   |   IPv4   |   2   | This document |
                   |   IPv6   |   3   | This document |
                   |   ExtId  |   7   | This document |
                   +----------+-------+---------------+

                          Table 9: TaggerId Types

11.2.  SMF Type-Length-Value

   This document requests IANA assignment of one message "SMF_TYPE" TLV
   type and one address block "SMF_NBR_TYPE" TLV type from the [RFC6130]
   specific registry space.

   The common format of these new TLV types is described in Table 6 and
   Table 8.  Furthermore this document defines a namespace for algorithm
   ID types using the extended type TLV value field defined by
   [RFC5444].  Both SMF_TYPE and SMF_NBR_TYPE TLVs use this namespace.

               ietf:manet:packetbb:nhdp:smf:relayAlgorithmID

   The values that can be assigned within the "ietf:manet:packetbb:nhdp:
   smf:relayAlgorithmID" name-space are numeric indexes in the range [0,
   239], boundaries included.  Assignment requests for the [0-127] are
   granted on an "IETF Consensus" basis as defined in [RFC5226].
   Standards action is not required for assignment requests of the range
   [128-239].  Documents requesting relayAlgorithmId values SHOULD
   define value field uses contained by the SMF_TYPE:<relayAlgorithmId>
   and SMF_NBR_TYPE:<relayAlgorithmId> full type TLVs.

   This specification registers the following Relay Algorithm ID Type
   values shown in Table 10 in the registry "ietf:manet:packetbb:nhdp:
   smf:relayAlgorithmID
UH> ================
UH> missing "
UH> ================

                     +----------+-------+------------+
                     | Mnemonic | Value | Reference  |
                     +----------+-------+------------+
                     | CF       | 0     |            |
                     | S-MPR    | 1     | Appendix B |
                     | E-CDS    | 2     | Appendix A |
                     | MPR-CDS  | 3     | Appendix C |
                     +----------+-------+------------+

                 Table 10: Relay Set Algorithm Type Values

Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 33]

Internet-Draft                     SMF                        March 2011

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
   working group since the late 1990s.  There are obviously many
   contributors to past discussions and related draft documents within
   the working group 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 working group and borrows text and implementation ideas
   from the related individuals and activities.  Some of the direct
   contributors who have been involved in design, content editing,
   prototype implementation, major commenting, and core discussions are
   listed below in alphabetical order.  We appreciate all the input and
   feedback from the many community members and early implementation
   users we have heard from that are not on this list as well.

      Key contributors/authors in alphabetical order:
      Brian Adamson
      Teco Boot
      Ian Chakeres
      Thomas Clausen
      Justin Dean
      Brian Haberman
      Ulrich Herberg
      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.

13.  References

13.1.  Normative References

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

UH> ================
UH> is that required to be normative? Anyways, better cite the RFC
than the IETF proceedings (RFC5614)
UH> ================

   [MPR-CDS]  Adjih, C., Jacquet, P., and L. Viennot, "Computing
              Connected Dominating Sets with Multipoint Relays", Ad Hoc
              and Sensor Wireless Networks , January 2005.
UH> ================
UH> is that required to be normative?
UH> ================

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

Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 34]

Internet-Draft                     SMF                        March 2011

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

UH> ================
UH> if we use a code point instead, we would not need to cite MD5 (or
not normatively)
UH> ================

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

   [RFC2780]  Bradner, S., "IANA Allocation Guidelines For Values In the
              Internet Protocol and Related Headers", March 2000.
UH> ================
UH> add RFC 2780 before "March 2000", like for the other citations
UH> ================

   [RFC3626]  Clausen, T. and P. Jacquet, "Optimized Link State Routing
              Protocol", 2003.
UH> ================
UH> month and RFC number missing before 2003
UH> ================

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

   [RFC4302]  Kent, S., "IP Authentication Header", December 2005.
UH> ================
UH> RFC number missing before Dec. 2005
UH> ================

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC5444]  Clausen, T. and et al,
UH> ================
UH> and et al doesn't work :-) better cite all authors, like for the
other citations
UH> ================
"Generalized MANET Packet/Message
              Format", RFC 5444, February 2009.

   [RFC5771]  Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for
              IPv4 Multicast Address Assignment", RFC 5771, March 2010.

   [RFC6130]  Clausen, T. and et al, "MANET Neighborhood Discovery
              Protocol", RFC 6130, March 2011.
UH> ================
UH> The precise title is "Mobile Ad Hoc Network (MANET) Neighborhood
Discovery Protocol (NHDP)"
UH> ================

13.2.  Informative References

   [CDHM07]   Chakeres, I., Danilov, C., and T. Henderson, "Connecting
              MANET Multicast", IEEE MILCOM 2007 Proceedings , 2007.
UH> ================
UH> remove blank after Proceedings. similiarly, there are some blanks
too much in the following cites
UH> ================

   [DHG09]    Danilov, C., Henderson, T., and T. Goff, "Experiment and
              field demonstration of a 802.11-based ground-UAV mobile
              ad-hoc network", Proceedings of the 28th IEEE conference
              on Military Communications , 2009.

   [DHS08]    Danilov, C., Henderson, T., and T. Spagnolo, "MANET
              Multicast with Multiple Gateways", IEEE MILCOM 2008

Macker, editor & SMF Design Team  Expires September 15, 2011    [Page 35]

Internet-Draft                     SMF                        March 2011

              Proceedings , 2008.

   [GM99]     Garcia-Luna-Aceves, JJ. and E. Madruga, "The core-assisted
              mesh protocol", Selected Areas in Communications, IEEE
              Journal on  Volume 17, Issue 8, August 1999.

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

   [MGL04]    Mohapatra, P., Gui, C., and J. Li, "Group Communications
              in Mobile Ad hoc Networks", IEEE Computer Vol. 37, No. 2,
              February 2004.

   [NTSC99]   Ni, S., Tseng, Y., Chen, Y., and J. Sheu, "The Broadcast
              Storm Problem in Mobile Ad hoc Networks", Proceedings Of
              ACM Mobicom 99 , 1999.

   [RFC2501]  Macker, JP. and MS. Corson, "Mobile Ad hoc Networking
              (MANET): Routing Protocol Performance Issues and
              Evaluation Considerations", 1999.
UH> ================
UH> month and RFC number
UH> ================

   [RFC3684]  Ogier, R., Templin, F., and M. Lewis, "Topology
              Dissemination Based on Reverse-Path Forwarding", 2003.
UH> ================
UH> month and RFC number
UH> ================

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