Subject: [manet] SMF review (long version)

From: Ulrich Herberg <[email-masked]>
Date: Sat, 31 Jul 2010 13:55:29 +0200

Here is the detailed review of SMF:

Detailed comments: (starting with "UH> ", always immediately following
the concerned sentence or paragraph)
============

1.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].
UH> ================
UH> There is an errata to RFC2119: "NOT RECOMMENDED" has been added.
UH> ================

2.  Introduction and Scope

   Unicast routing protocol designs for MANET and wireless mesh use have
   demonstrated efficient mechanisms to flood routing control plane
   messages within a wireless routing area.
UH> ================
UH> "have demonstrated" may require a citation
UH> ================

   For example, algorithms
   specified within [RFC3626] and [RFC3684] provide distributed methods
   of dynamically electing reduced relay sets that attempt to optimize
   flooding of routing control messages while maintaining a connected
   set.  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 deemed effective.  The
   baseline design is intended to provide a basic, best effort multicast
   forwarding capability that is constrained to operate within a MANET
   or wireless mesh routing region.  The main design goals of this SMF
   specification are to adapt efficient relay sets in MANET type
   environments [RFC2901] and to define the needed IPv4 and IPv6
   multicast duplicate packet detection (DPD) mechanisms to support
   multi-hop, packet forwarding.  Figure 1 provides an overview of the
   logical SMF node architecture, consisting of "Neighborhood
   Discovery", "Relay Set Selection" and "Forwarding Process"
   components.  Typically, relay set selection (or self-election) will
   occur based on input from a neighborhood discovery process, and the
   forwarding process will often be determined by dynamic relay set
   selection.  Note the neighborhood discovery and/or relay set
   selection information MAY

UH> ================
UH> This is an introduction section. I am not sure it is a good place
to start the specification itself by using RFC2119 terminology. That
applies several times throughout the introduction.
UH> ================

   be obtained from a coexistent process
   (e.g., a lower layer mechanism or a unicast routing protocol using
   relay sets).  In some cases, the forwarding decision for a packet can
   also depend on previous hop or incoming interface information.  The
   asterisks (*) in Figure 1 mark the primitives and relationships
   needed by relay set algorithms requiring previous-hop packet
   forwarding knowledge.

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

                ______________                _____________
               |              |              |             |
               | 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

   Interoperable SMF implementations MUST use a common DPD approach and
   be able to process the header options defined in this document for
   IPv6 operation.  We define Classical Flooding (CF), as the simplest
   case of SMF multicast forwarding.  With CF, each SMF router forwards
   each received forwardable multicast packet exactly once.
UH> ================
UH> Where is "forwardable" defined? Throughout the document, the word
"packet" is used. Maybe replace it with "IP datagram"?
UH> ================

   In this
   case, the need for any relay set selection or neighborhood topology
   information is eliminated but DPD functionality is still required.
   While SMF supports a CF mode of operation 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_
UH> ================
UH> underscores around subset seem unnecessary
UH> ================

   of all possible SMF routers in a MANET routing region.
UH> ================
UH> Throughout the document, different terms are used for presumably
the same intention: MANET routing domain, SMF routing area, MANET SMF
routing domain, SMF routing domain,... None of these is defined.
UH> Also, I would replace "SMF routers" by "routers running the SMF protocol"
UH> ================

   Known relay
   set selection algorithms have already demonstrated the ability to
   provide and maintain a dynamic connected set for forwarding user
   multicast data [MDC04].  A few such relay set selection algorithms
   are described in the Appendices of this document and the basic
   designs borrow directly from 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
UH> ================
UH> Throughout the document, node/router is inconsistent. An
applicability section would be nice. Does SMF run on hosts, routers,
both? There, one could mention that it is limited to IP (but supports
both IPv4 and IPv6).
UH> ================
   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) [NHDP] running in concurrence
   with SMF.  Additionally, this specification allows alternative
   processes that may be deemed more effective (e.g., lower layer

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

   wireless interface)
UH> ================
UH> The sentence is unclear... is reads as if a wireless interface was
a process.
UH> ================

   to provide the necessary neighborhood information
   to support 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
   in Section 6.  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 an existing MANET unicast
   protocol or lower layer interface
UH> ================
UH> In the absence of a ""? Is that a network interface?
UH> ================

   , SMF relies on the MANET NHDP
   specification to assist in IP layer 2-hop neighborhood state
   discovery and maintenance for relay set election.  A "SMF_RELAY_ALG"
   Message TLV type (per [RFC5444])
UH> ================
UH> It could be useful to briefly give an overview of RFC5444 before;
or define which terms of RFC5444 are used within this spec.
UH> ================

   is defined for use with the NHDP
   protocol.  It is RECOMMENDED that all nodes performing SMF operation
   include this TLV type in their NHDP_HELLO
UH> ================
UH> NHDP_HELLO is not defined. Maybe "HELLO message as defined in [NHDP]" or so.
UH> ================

   messages when operating
   with NHDP.  This capability allows for nodes participating in SMF to
   be explicitly identified along with their respective dynamic relay
   set algorithm.

2.1.  Abbreviations

   The following abbreviations are used throughout this document:

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

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

3.  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 MANET SMF routers
   participating within a localized routing region
UH> ================
UH> What is a "localized routing region"?
UH> ================

   may provide a useful
   group communication paradigm for various classes of applications.
   Applications that could take advantage of a simple multicast
   forwarding service within a MANET routing region include multimedia
   streaming, interactive group-based messaging and applications, peer-
   to-peer middleware multicasting, and multi-hop mobile discovery or
   registration services.  SMF is appropriate for deployment in limited
   dynamic wireless routing areas
UH> ================
UH> What is a "limited dynamic wireless routing area"?
UH> ================

   so that the flooding process can be
   contained.

   Note again that Figure 1 provides a notional architecture for typical
   SMF-capable nodes.  However,
UH> ================
UH> Remove "however"?
UH> ================

   a goal is that simple end-system (non-
   forwarding) wireless nodes
UH> ================
UH> A "node" (router? host?) is not wireless. It can have several
wired/wireless interfaces.
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 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].  With present
   experimental SMF implementations, proxy methods have demonstrated
UH> ================
UH> "have demonstrated" --> citation
UH> ================

   gateway functionality at MANET border routers operating with existing
   external IP multicast routing protocols.  SMF may be extended or
   combined with other mechanisms to provide increased reliability and
   group specific filtering, but the details for this are not discussed
   here.

4.  SMF Packet Processing and Forwarding

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

   1.  Processing of outbound, locally-generated multicast packets.
   2.  Reception and processing of inbound packets on a specific network
       interface(s).
UH> ================
UH> wrong plural: "a" ... "interfaces"
UH> ================

   The purpose of intercepting outbound, locally-generated multicast
   packets is to apply any added packet marking needed to satisfy the

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

   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.

   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 "global scope"
   multicast packets
UH> ================
UH> What is a "global scope multicast packet"? Maybe an "IP datagram
whose destination address is a global IP address as specified in
RFC2373?"
UH> ================

   to support generic multicast application needs or
   to distribute designated multicast traffic ingressing the MANET
   routing region via border routers
UH> ================
UH> Are "MANET border routers" defined somewhere?
UH> ================

   .  The multicast addresses to be
   forwarded will be maintained by an a priori list or a dynamic
   forwarding information base (FIB) that MAY interact with future MANET
   dynamic group membership extensions or management functions.  There
   will also be a well-known multicast group for flooding to all SMF
   forwarders
UH> ================
UH> Has "SMF forwarder" been defined somewhere?
UH> ================

   .  This multicast group is specified to contain all MANET
   SMF routers of a connected MANET routing region
UH> ================
UH> Where is "connected MANET routing region" defined?
UH> ================

   , so that packets
   transmitted to the multicast address associated with the group will
   be delivered to all connected SMF routers.
UH> ================
UH> Where is "connected SMF routers" defined?
UH> ================

   For IPv6, the multicast
   address is specified to be "site-local".  The name of the multicast
   group is "SL-MANET-ROUTERS".
UH> ================
UH> I would move this to the end of the spec. (IANA considerations)
UH> ================

   Minimally SMF SHALL
UH> ================
UH> This is the only section in this spec that used "SHALL" instead of
"MUST". I would stick with "MUST".
UH> ================

   forward, as
   instructed by the relay set selection algorithm, unique (non-
   duplicate) packets received for this well-known group address when
   the TTL or hop count value
UH> ================
UH> s/hop count/hop limit/
UH> ================

   in the IP header is greater than 1.  SMF
   SHALL forward all additional global scope addresses specified within
   the dynamic FIB or configured list as well.  In all cases, the
   following rules SHALL be observed for SMF multicast forwarding:

   1.  Multicast packets with TTL <= 1 MUST NOT be forwarded.
UH> ================
UH> Unclear definition of "Multicast packet"; better use "IP datagram
with multicast destination address" or the like... similar for item 2.
UH> ================
   2.  Link local multicast packets MUST NOT be forwarded.
   3.  Incoming multicast packets with an IP source address matching one
       of those of the local SMF router interface(s) MUST NOT be
       forwarded.
   4.  Received packet frames with the MAC source address matching the
       local SMF router interface(s) MUST NOT be forwarded.
UH> ================
UH> Has IP fragmentation been mentioned before? Are these IP frames?
Then they don't have a MAC address (only the L2 frame surrounding the
IP frame has one). Do all L2 frames have MAC addresses (there may be
strange non-IEEE-NICs used in a MANET). The case of several interfaces
is unclear (better detail it like "Received frames with the MAC source
address matching any MAC address of any of the routers' interfaces..."
or the like.)
UH> ================

   5.  Received packets for which SMF cannot reasonably ensure temporal
       DPD uniqueness MUST NOT be forwarded.
UH> ================
UH> Is that explained anywhere in detail? What das "reasonably" mean?
What does "temporal uniqueness" mean? Does that mean that the DPD
explained later in the spec is performed at this moment? (5.)
UH> ================

   6.  When packets are forwarded, TTL or hop limit SHALL be decremented
       by one.
UH> ================
UH> I like this ordered list of actions. But it is not consequently
used throughout the doc. It would be very nice throughout the whole
document to know in what order to do what action.
I suggest: s/SHALL/MUST/
UH> ================

   Note that rule #3 is important because in wireless networks,
UH> ================
UH> What is a "wireless network"? Maybe you mean something like "a
network consisting of mobile routers with at least one wireless
interface participating in the same routing domain...." (well, has to
be thought about...)
UH> ================

   the
   local SMF router
UH> ================
UH> What is the "local" SMF router? That should be defined (as it is
done in OLSRv2, for example)
UH> ================

   may receive re-transmissions of its own packets when
   they are forwarded by neighboring nodes.
UH> ================
UH> Is "neighboring nodes" defined? Is that NHDP terminology?
UH> ================

   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> In the list above, when would this rule be applied?
UH> ================

   As discussed further in Section 10,

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

   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) field value.  This form of attack could cause an SMF
   node to create a DPD entry that would block the proper forwarding of
   the valid packet (with correct TTL) through the SMF area.  A
   RECOMMENDED approach to prevent this attack, when it is a concern,
   would be to cache temporal packet TTL values along with the DPD state
   (hash value(s) and/or identifier).  Then, if a subsequent matching
   packet (with respect to DPD) arrives with a larger TTL value than the
   packet that was previously forwarded, SMF should forward the new
   packet and update the TTL 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 have been met, an SMF implementation MUST make a
   forwarding decision dependent upon the relay set selection algorithm
   in use.  If the SMF implementation is using Classical Flooding (CF),
   the forwarding decision is implicit once DPD uniqueness is
   determined.
UH> ================
UH> How is it determined? (specification needed here)
UH> ================

   Otherwise, a forwarding decision depends upon the
   current interface-specific relay set state.  The descriptions of the
   relay set selection algorithms in the Appendices
UH> ================
UH> Which section in the Appendices?
UH> ================

   to this document
   specify the respective heuristics for multicast packet forwarding and
   specific DPD or other processing required to achieve correct SMF
   behavior.  For example, one class of forwarding is based upon relay
   set election status and the packet's previous hop forwarder
UH> ================
UH> Does that also apply if the previous hop is not a forwarder but a
packet originator?
UH> ================

   , while
   other classes designate the local SMF router as a forwarder for all
   neighboring nodes.

UH> ================
UH> Not sure this whole section about this security aspect belongs
here (it's not core spec). Maybe move it to the "Security
Considerations" section at the end? Or another draft? I am not sure
here...
UH> ================

5.  SMF Duplicate Packet Detection

   Duplicate packet detection (DPD) is a common requirement in MANET
UH> ================
UH> "common requirement" may require citations
UH> ================

   or
   wireless mesh packet forwarding 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 implementations MUST detect and avoid
   forwarding duplicate multicast packets using temporal packet
   identification.
UH> ================
UH> Where is "temporal packet identification" defined?
UH> ================

   It is RECOMMENDED this be implemented by keeping a
   history of recently-processed multicast packets
UH> ================
UH> "multicast packets" should be defined
UH> ================

   for comparison to
   incoming packets.  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.  The two approaches are described for experimental

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

   purposes.  Trade-offs of the two approaches to DPD merit different
   consideration 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.
UH> ================
UH> I would prefer to have a precise specification of the
informationen bases that are required (as it is done, for example, in
OLSRv2)
UH> ================

   The specific requirements of several relay
   set selection algorithms and their forwarding rules are described in
   the Appendices of this document.  In general this involves keeping
   track of previously forwarded packets so that duplicates are not
   forwarded, but some relay techniques may have additional
   considerations.

   For I-DPD, packets are identified using explicit identifiers from the
   IP header.
UH> ================
UH> I-DPD has not been defined until now. This is a major problem of
the following paragraphs. I would prefer to have an introduction to
different DPDs that are defined in the spec, then a specification of
each in detail. This is mixed up in the following pages.
UH> The sentence "identified using [...] identifiers" sounds like a tautology
UH> ================

   The specific identifier to use depends upon the IP
   protocol version and the type of packet.
UH> ================
UH> What "type of packet"? IP datagram type? Where is that defined?
UH> ================

   For example, IPv4 [RFC0791]
   provides an "Identification" field that may assist a DPD mechanism,
   and packets that contain IPSec protocol headers also provide suitable
   packet identifiers.  Fragmented packets also provide additional
   identifiers that need to be considered.  These identifier fields are
   unique within the context of source address, destination address,
   protocol type, and/or other header fields depending upon the type of
   identifier used for DPD.  Similarly,
UH> ================
UH> "Similarly" to what?
UH> ================

   for H-DPD,
UH> ================
UH> H-DPD has not been introduced nor defined before
UH> ================

   it is expected that
   packet hash values will be kept with respect to at least the source
   address to help ensure hash collision avoidance.
UH> ================
UH> "at least"? what else?
UH> ================

   SMF implementations
   MUST maintain DPD history per the applicable packet flow context
   (e.g., <protocol:srcAddr:dstAddr>
UH> ================
UH> Has this notation been defined before? <...:...:..>
UH> remove "the" before applicable packet flow
UH> ================

   for DPD based upon IPv4 ID).  The
   details for I-DPD and H-DPD for different types of packets are
   described in the sections below.  In either case, this history SHOULD
   be kept long enough to span the maximum network traversal lifetime,
   MAX_PACKET_LIFETIME, of multicast packets being forwarded within an
   SMF operating area.
UH> ================
UH> What is an "SMF operating area"? Definition needed
UH> ================

   The required size of the DPD cache is governed
   by this timeout value and is also a function of the packet forwarding
   rates.
UH> ================
UH> How is this "function of the packet forwarding rate" defined?
UH> ================

   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.
UH> ================
UH> This whole section is too detailed for a specification and too
vague for an introducation to I-DPD/H-DPD. A good overview of both
would be better instead.
UH> ================

5.1.  IPv6 Duplicate Packet Detection

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

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

   1.  a hop-by-hop SMF-DPD option header (with supporting identifier or
       hash assistance value),
   2.  the use of IPv6 fragment header fields for I-DPD when they exist,
   3.  the use of IPSec sequencing for I-DPD when a non-fragmented,
       IPSec header is detected, and
   4.  an H-DPD approach assisted, as needed, by the SMF-DPD option
       header.
UH> ================
UH> It should be made clear that these 4 points are explained in the
following subsections in more detail.
UH> The list mixes up I-DPD and H-DPD. I would prefer to have that
more seperated.
UH> ================

   SMF MUST provide a DPD marking module that can insert the hop-by-hop
   IPv6 header option defined in this section.
UH> ================
UH> At what point of time is that done? (see previous ordered list of
actions when a message is considered for forwarding in section 4)
UH> ================

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

5.1.1.  IPv6 SMF-DPD Header Option

   As previously mentioned
UH> ================
UH> where? which section?
UH> ================

   , the base IPv6 packet header does not contain
   a unique identifier suitable for DPD.  This section defines an IPv6
   Hop-by-Hop Option
UH> ================
UH> citation of IPv6 Hop-by-Hop Option spec.
UH> ================
   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.  The value of the IPv6 SMF DPD Hop-by-Hop Option Type is TBD.
UH> ================
UH> Move that to the IANA Considerations section at the end of the spec.
UH> ================

   The first bit of the data field of the SMF-DPD option is the "H-bit"
   that determines the format of the Option Data content.  Two different
   formats are supported.  When the "H-bit" is cleared (zero value), the
   SMF-DPD format to support I-DPD operation is specified as shown in
   Figure 2 and defines the extension header in accordance with
   [RFC2460].
UH> ================
UH> Is that flexible enough, just two options for H-DPD and I-DPD?
Maybe there will be a future x-DPD which cannot be used then.
UH> ================

        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> I would only print the bytes contained in the header option..
e.g., the first 16 bits could be omitted
UH> ================

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |0|TidTyp|TidLen|             TaggerId (optional) ...           |
       +-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               |            Identifier  ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 2: IPv6 SMF-DPD Header Option in I-DPD mode
UH> ================
UH> This section talks about the general header option for both I-DPD
and H-DPD. So I would not put an example for I-DPD here, but rather in
the next subsection. Here should be a general header option with the
H-bit clearly visible
UH> ================

   The "TidType" is a 3-bit field indicating the presence and type of
   the optional "TaggerId" field.  The optional "TaggerId" is used to
   differentiate multiple ingressing border gateways that may commonly
   apply the SMF-DPD option header to packets from a particular source.

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

   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> is NULL, then the
   length of the DPD packet <Identifier> field corresponds to the (<Opt.
   Data Len> - 1).  If the <TidType> is non-NULL, then the length of the
   "TaggerId" field is equal to (<TidLen> - 1) and the remainder of the
   option data comprises the DPD packet <Identifier> field.  When the
   "TaggerId" field is present, the <Identifier> field can be considered
   a unique packet identifier in the context of the <taggerId:srcAddr:
   dstAddr> tuple.  When the "TaggerId" field is not present, then it is
   assumed the source host applied the SMF-DPD option and the
   <Identifier> can be considered unique in the context of the IPv6
   packet header <srcAddr:dstAddr> tuple.  IPV6 I-DPD operation details
   are described in Section 5.1.2.
UH> ================
UH> s/IPV6/IPv6/
UH> ================

   When the "H-bit" in the SMF-DPD option data is set, the data content
   value is interpreted as a Hash-Assist Value (HAV) used to facilitate
   H-DPD operation.  In this case, source hosts or ingressing gateways
   apply the SMF-DPD with a HAV only when required to differentiate the
   hash value of a new packet with respect to older packets in the
   current DPD history cache.
UH> ================
UH> Define what is an "old" packet and what is a "new" packet. Is the
history cache data structure somewhere defined?
UH> ================

   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.

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

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     ...              |0|0|0| OptType | Opt. Data Len |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|    Hash Assist Value (HAV) ...
UH> ================
UH> Should the first bit in the second line (H-bit) be 1, instead of 0?
UH> ================
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 3: IPv6 SMF_DPD Header Option in H-DPD Mode
UH> ================
UH> The I-D mixes up SMF-DPD, SMF_DPD, SMF DPD. Should be consistent
UH> ================

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

5.1.2.  IPv6 Identification-based DPD

   The following table summarizes the IPv6 I-DPD processing approach.
   Within the table '*' indicates a don't care condition.
UH> ================
UH> Define what a "don't care condition" is. Maybe use more scientific terms.
UH> ================

   +-------------+-----------+-----------+-----------------------------+
   | IPv6        | IPv6      | IPv6      | SMF IPv6 I-DPD Mode Action  |
   | Fragment    | IPSec     | I-DPD     |                             |
   | Header      | Header    | Header    |                             |
   +-------------+-----------+-----------+-----------------------------+
   | Present     | *         | *         | Use Fragment Header I-DPD   |
   |             |           |           | Check and Process for       |
   |             |           |           | Forwarding                  |
   | Not Present | Present   | *         | Use IPSec Header I-DPD      |
   |             |           |           | Check and Process for       |
   |             |           |           | Forwarding                  |
   | Present     | *         | Present   | Invalid, do not Forward     |
   | Not Present | Present   | Present   | Invalid, do not Forward     |
   | Not Present | Not       | Not       | Add I-DPD Header,and        |
   |             | Present   | Present   | Process for Forwarding      |
   | Not Present | Not       | Present   | Use I-DPD Header Check and  |
   |             | Present   |           | Process for Forwarding      |
   +-------------+-----------+-----------+-----------------------------+
UH> ================
UH> Is the table explained anywhere? The column headers should be
explained. I would add a horizontal line after each row to make it
more readable.
UH> ================

                   Table 2: IPv6 I-DPD Processing Rules

   If the IPv6 multicast packet is an IPv6 fragment, SMF MUST use the
   fragment extension header fields for packet identification.  This
   identifier can be considered unique in the context of the <srcAddr:
   dstAddr> of the IP packet.  If the packet is an unfragmented IPv6
   IPSec packet, SMF MUST use IPSec fields for packet identification.

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

   The IPSec header <sequence> field
UH> ================
UH> cite where that is specified
UH> ================
   can be considered a unique
   identifier in the context of the <IPSecType:srcAddr:dstAddr:SPI>
UH> ================
UH> Where is SPI defined? Cite.
UH> ================
   where the "IPSecType" is either AH or ESP.  For unfragmented, non-
   IPSec, IPv6 packets, the use of the SMF DPD header option is
   necessary to support I-DPD operation.  The SMF DPD header option is
   applied in the context of the <srcAddr> of the IP packet.  End
   systems or ingressing SMF gateways are responsible for applying this
   option to support DPD.  The following table summarizes these packet
   identification types:

   +-----------+---------------------------------+---------------------+
   | IPv6      | Packet DPD ID Context           | Packet DPD ID       |
   | Packet    |                                 |                     |
   | Type      |                                 |                     |
   +-----------+---------------------------------+---------------------+
   | Fragment  | <srcAddr:dstAddr>               | <fragmentOffset:id> |
   | IPSec     | <IPSecType:srcAddr:dstAddr:SPI> | <sequence>          |
   | Packet    |                                 |                     |
   | Regular   | <[taggerId:]srcAddr:dstAddr>    | <SMF-DPD option     |
   | Packet    |                                 | header id>          |
UH> ================
UH> I wonder whether for regular packets in IPv4, the whole mechanism
will work if very similar packets (e.g. beacons) are sent in a very
short time interval. Couldn't we use a timestamp header option of IPv4
or something? I fear that just using the taggerId, src and dest is not
enough. And this is probably, at the time of writing, the most
predominant traffic type.
UH> ================
   +-----------+---------------------------------+---------------------+

              Table 3: IPv6 I-DPD Packet Identification Types

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

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

5.1.3.  IPv6 Hash-based DPD

   A default hash-based DPD approach (H-DPD) for use by SMF is specified
   as follows.  An MD5 [RFC1321] hash of the non-mutable header fields,
   options fields, and data content of the IPv6 multicast packet is used
   to produce a 128-bit digest.
UH> ================
UH> Maybe consider using a code-point for MD5. Maybe it makes sense to
be more flexible here. MD5 is already considered deprecated (I know,
it may not be relevant here because it is not used for cryptographical
integrity checks). Couldn't one also use other checksums (e.g. use the
CRC checksum from upper layers, if available?)
UH> ================

   The lower 64 bits
UH> ================
UH> "lower" in what order? most-significant bit first?
UH> ================
   of this digest
   (MD5_64)
UH> ================
UH> Is that a known term, "MD5_64"? or is it defined here?
UH> ================
   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>
UH> ================
UH> "packet header" + field + "<srcAddr>"
UH> ================
   .  This history is used by forwarding SMF
   nodes (non-ingress points)
UH> ================
UH> has "non-ingress point" be defined before?
UH> ================

   to avoid forwarding duplicates.  SMF
   ingress points (i.e., source hosts or gateways) use this history to

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

   confirm that new packets are unique with respect to their hash value.
   The Hash-assist Value (HAV) field described in Section 5.1.1 is
   provided as a differentiating field when a digest collision would
   otherwise occur.  Note that the HAV is an immutable option field and
   SMF MUST use any included H-DPD hash assist value (HAV) option header
   (see Section 5.1.1) in its hash calculation.

   If a packet results in a digest collision (i.e., by checking the
   H-DPD digest history) within the limited history kept
UH> ================
UH> the "limited history" is not defined before. It's unclear how long
to keep entries. It wasn't even mentioned before that entries are
purged after a predefined time.
UH> ================

   by SMF
   forwarders, the packet should be silently dropped.  If a digest
   collision is detected at an SMF ingress point (i.e., including SMF-
   aware sources)
UH> ================
UH> What is an "SMF-aware source"? How would it know?
UH> ================
   , the H-DPD option header is applied with a HAV.  The
   packet is retested for collision and the HAV is re-applied as needed
UH> ================
UH> What does "re-applied as needed" mean?
UH> ================

   to produce a non-colliding hash value.  The multicast packet is then
   forwarded with the added IPv6 SMF-DPD header option.

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

5.2.  IPv4 Duplicate Packet Detection

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

   1.  the use of IPv4 fragment header fields for I-DPD when they exist,
   2.  the use of IPSec sequencing for I-DPD when a non-fragmented IPv4
       IPSec packet is detected, and
   3.  a H-DPD approach.
   A specific SMF-DPD marking option is not specified for IPv4 since
   header options are not as tractable for end systems as for IPv6.
   IPv4 packets from a particular source are assumed to be marked with a
   temporally unique value in the "Identification" field of the packet
   header that can serve for SMF DPD purposes.  However, in present
   operating system networking kernels, the IPv4 header "Identification"
   value is not always generated properly, especially when the "don't
   fragment" (DF) bit is set.  The IPv4 I-DPD mode of this specification
   requires that IPv4 "Identification" fields are managed reasonably by

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

   source hosts and that temporally unique values are set within the
   context of the packet header <protocol:srcAddr:dstAddr> tuple.  If
   this is not expected during an SMF deployment, then it is RECOMMENDED
   that the H-DPD method be used as a more reliable approach.

   Since IPv4 SMF does not specify an options header, the
   interoperability constraints are looser than the IPv6 version and
   forwarders may be operate with mixed H-DPD and I-DPD modes as long as
   they consistently perform the appropriate DPD routines outlined in
   the following sections.  However, it is RECOMMENDED that a deployment
   be configured with a common mode for operational consistency.

5.2.1.  IPv4 Identification-based DPD

   The following table summarizes the IPv4 I-DPD processing approach
   once a packet has passed the basic forwardable criteria described in
   earlier SMF sections.
UH> ================
UH> Cite in which sections
UH> ================

   Within the table '*' indicates a don't care
   condition.

   +----+----+----------+---------+------------------------------------+
   | df | mf | fragment | IPSec   | IPv4 I-DPD Action                  |
   |    |    | offset   |         |                                    |
   +----+----+----------+---------+------------------------------------+
   | 1  | 1  | *        | *       | Invalid, Do Not Forward            |
   | 1  | 0  | nonzero  | *       | Invalid, Do Not Forward            |
   | *  | 0  | zero     | not     | Tuple I-DPD Check and Process for  |
   |    |    |          | Present | Forwarding                         |
   | *  | 0  | zero     | Present | IPSec enhanced Tuple I-DPD Check   |
   |    |    |          |         | and Process for Forwarding         |
   | 0  | 0  | nonzero  | *       | Extended Fragment Offset Tuple     |
   |    |    |          |         | I-DPD Check and Process for        |
   |    |    |          |         | Forwarding                         |
   | 0  | 1  | zero or  | *       | Extended Fragment Offset Tuple     |
   |    |    | nonzero  |         | I-DPD Check and Process for        |
   |    |    |          |         | Forwarding                         |
   +----+----+----------+---------+------------------------------------+
UH> ================
UH> The table headers should be explained (what is "df", "mf", fragment offset.)
UH> s/fragment/Fragment/
UH> ================

                   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

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

   identifier in the context of the <IPSecType:srcAddr:dstAddr:SPI>
   where the "IPSecType" is either AH or ESP.
UH> ================
UH> Does one take AH or ESP if both are available?
UH> ================

   Finally, for
   unfragmented, non-IPSec, IPv4 packets, the "Identification" field can
   be used for I-DPD purposes.  The "Identification" field can be
   considered unique in the context of the IPv4 <protocol:scrAddr:
   dstAddr> tuple.  The following table 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    |                                 |                     |
   | Regular   | <protocol:srcAddr:dstAddr>      | <id>                |
UH> ================
UH> Has <id> been defined before?
UH> ================

   | Packet    |                                 |                     |
   +-----------+---------------------------------+---------------------+

              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
   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 5.3 may mitigate this limitation of
   the IPv4 "Identification" field for SMF DPD.  In this case the
   "internal hash" value would be concatenated with the "Identification"
   value for I-DPD operation.

5.2.2.  IPv4 Hash-based DPD

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

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

   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.

5.3.  Internal Hash Computation Considerations
UH> ================
UH> I am not sure this belongs here (see previous comment on
security). Maybe to Security Considerations or extra document...
UH> ================

   Forwarding protocols that use DPD techniques, such as SMF, may be
   vulnerable to denial-of-service (DoS) attacks based on spoofing
   packets with apparently valid packet identifier fields.  Such a
   consideration is pointed out in Section 10.  In wireless
   environments, where SMF will most likely be used
UH> ================
UH> It is an assumption, where SMF will be most likely used.
UH> ================

   , the opportunity for
   such attacks is more prevalent than in wired networks.  In the case
   of IPv4 packets, fragmented IP packets or packets with IPSec headers
   applied, the DPD "identifier 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.
UH> ================
UH> Is there any proof or analysis how/whether that works?
UH> ================

   For IPv4 I-DPD based on the limited 16-bit IP header "Identification"
   field, it is possible that use of this "internal hash" technique may
   also enhance I-DPD performance in cases where the IPv4
   "Identification" field may frequently wrap due to sources supporting
   high data rate flows.
UH> ================
UH> It is "possible" that it improves performance? That sounds a bit vague.
UH> ================

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

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

6.  Reduced Relay Set Forwarding and Relay Selection Capability

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

UH> ================
UH> CF mode should be defined in the spec in a seperate section.
UH> ================

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

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

   In early SMF experimental deployments,
UH> ================
UH> Which?
UH> ================

   the relay set information has
   been derived from coexistent unicast routing control plane traffic
   flooding processes.  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 CDS mesh for control plane purposes).
UH> ================
UH> "biconnected CDS mesh for control plane purposes" - definition?
CDS has not been used before.
UH> ================

   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 (Better
       enables scenario-specific management of relay set)
UH> ================
UH> What does "Better enables scenario-specific management of relay set" mean?
UH> ================

   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.
   The Appendices
UH> ================
UH> Which exact section?
UH> ================
   in this document can serve as a template for the
   content of such potential future specifications.

   Figure 4 depicts a state information diagram of possible relay set
   control options.

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

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

                  Figure 4: SMF Relay Set Control Options

UH> ================
UH> This picture is never explained.
UH> ================

   There are basically three styles of SMF operation with reduced relay
   sets:

   1.  Independent operation: In this case, SMF performs its own relay
       set selection using information from an associated MANET NHDP
       process.  In this case, NHDP messaging SHOULD be appended with
       additional [RFC5444] type-length-value (TLV) content to support
       SMF-specific requirements as discussed in Section 7 and for the
       applicable relay set algorithm described in the Appendices of
       this document or future specifications.
UH> ================
UH> I thought that NHDP is just an example that can be used in
independent operation. If it is the only possibly one, that should be
defined clearly.
UH> ================
   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.  If it is desired that the SMF data plane
       forwarding use a different relay set selection algorithm than
       used for the routing protocol control plane, then the routing
       protocol NHDP instance
UH> ================
UH> I am not quite sure that I understand the difference between the
"independent" NHDP and the "routing protocol NHDP instance". For me,
it is simply NHDP. The routing protocol may use the information from
NHDP, so does SMF.
UH> ================

       (if applicable) SHOULD append its messages
       with the appropriate SMF-specific TLV content (see Section 7 and
       the relay set algorithm Appendices).

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

   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) .
UH> ================
UH> s/Operation/operation/
UH> s/) ./)./
UH> ================

7.  SMF Neighborhood Discovery Requirements

   This section defines the requirements for use of the MANET
   Neighborhood Discovery Protocol (NHDP) [NHDP] 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
   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 SMF and a
   coexistent MANET unicast routing protocol.

   Core NHDP messages
UH> ================
UH> You mean NHDP HELLO messages? What is a "core" message?
UH> ================

   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

   The Appendices
UH> ================
UH> Which precise sections?
UH> ================
   of this document describe a set of CDS-based relay set
   selection algorithms that can be used to achieve efficient SMF
   operation, even in dynamic, mobile networks[MDDA07].
UH> ================
UH> blank missing before [MDDA07]
UH> ================

   When using
   these algorithms in conjunction with NHDP, a method verifying
   neighbor SMF operation is required in order to insure correct relay
   set selection.  The core NHDP specification
UH> ================
UH> s/The core NHDP specification/[NHDP]/
UH> ================
   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 this document.
UH> ================
UH> Defined where? In which section?
UH> ================

   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

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

   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 wit
UH> ================
UH> s/wit/with/
UH> ================

   NHDP and reference the applicable TLV types as needed.

7.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.
UH> ================
UH> I would move that to the end of the document (IANA Considerations)
UH> ================

7.1.1.  SMF Message TLV Type

   The SMF message TLV type denoted SMF_TYPE is used to identify the
   existence of an SMF instance operating in conjunction with NHDP.
   This message type
UH> ================
UH> You mean "TLV type"?
UH> ================
   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
UH> ================
UH> NHDP_HELLO message has never been defined. It would be "HELLO
message as defined in [NHDP]"
UH> ================
   messages
   generated.  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 typeTable 6
UH> ================
UH>typeTable 6 ("as specified in Table 6")
UH> ================
   conforming to [RFC5444].  Extended type field values communicate
   "Relay Algorithm Type" to other 1-hop SMF neighbors and value fields
   may contain algorithm specific information.
UH> ================
UH> s/may/MAY/ ?
UH> ================

       +---------------+---------------------+--------------------+
       |               | packetBB TLV syntax | Field Values       |
       +---------------+---------------------+--------------------+
       | type          | <tlv-type>          | SMF_TYPE           |
       | extended type | <tlv-type-ext>      | <relayAlgorithmid> |
       | length        | <length>            | variable           |
       | value         | <value>             | variable           |
UH> ================
UH> What to put as TLV value?
UH> It should be made clear that all the terms in the 2nd column are
defined in [RFC5444]
UH> ================
       +---------------+---------------------+--------------------+

                       Table 6: SMF Type Message TLV

   In Table 6 <relayAlgorithmId> is an 8-bit field
UH> ================
UH>"8-bit unsigned integer field"
UH> ================
   containing a number
   0-255 representing the "Relay Algorithm Type" of the originator
   address of the corresponding NHDP message.
UH> ================
UH> The originator address may not be set in HELLO messages.
UH> ================

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

   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 for general
   interoperable deployment prior to official IANA assignment.

     +---------------------+----------------------------------------+
     | Extended Type Value |                Algorithm               |
     +---------------------+----------------------------------------+
     |          0          |                   CF                   |
     |          1          |                  S-MPR                 |
     |          2          |                  E-CDS                 |
     |          3          |                 MPR-CDS                |
UH> ================
UH> Has "S-MPR, E-CDS, MPR-CDS" been defined before?
UH> ================
     |        4-127        |    Future Assignment with STD action   |
     |       128-239       |         No STD action required         |
     |       240-255       |           Experimental Space           |
     +---------------------+----------------------------------------+

                 Table 7: SMF Relay Algorithm Type Values

   Acceptable <length> and <value> fields of an SMF_TYPE TLV are
   extended type dependent.  The appropriate algorithm type, as conveyed
   in the <tlv-type-ext> field, defines the meaning and format of its
   TLV <value> field.  For algorithms defined by this document see the
   appropriate appendix for the <value> field format.
UH> ================
UH> Cite precise sections in the appendix.
UH> ================

7.1.2.  SMF Address Block TLV Type

   An address block TLV type, denoted SMF_NBR_TYPE (i.e., SMF neighbor
   relay algorithm)
UH> ================
UH> + "as specified in "
UH> ================
   Table 8, is specified so that CDS relay algorithm
   operation and configuration can be shared among 2-hop 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.
UH> ================
UH> When is that possible? Always? Are there conditions?
UH> ================

   The message SMF_TYPE TLV and address block SMF_NBR_TYPE TLV types
   share a common format.
UH> ================
UH> "Common format" in which sense? What is common?
UH> ================

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

       +---------------+---------------------+--------------------+
       |               | packetBB TLV syntax | Field Values       |
       +---------------+---------------------+--------------------+
       | type          | <tlv-type>          | SMF_NBR_RELAY_ALG  |
       | extended type | <tlv-type-ext>      | <relayAlgorithmid> |
       | length        | <length>            | variable           |
       | value         | <value>             | variable           |
       +---------------+---------------------+--------------------+

                    Table 8: SMF Type Address Block TLV

   <relayAlgorithmId> in Table 7
UH> ================
UH> Isn't that Table 8?
UH> ================
   is an 8-bit field containing a number
   0-255 representing the "Relay Algorithm Type" value that corresponds
   to any indicated address
UH> ================
UH> Should be "associated" address
UH> ================
   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 7.
UH> ================
UH> Table 8
UH> ================

   Value length and value content
UH> ================
UH> "Length and content" instead of "Value length and value content"?
UH> ================
   of an SMF_NBR_TYPE TLV is defined by
   the appropriate algorithm type contained in the extended type field.
   See appropriate the appendix for definitions of value fields for
   algorithms defined by this document.

8.  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 approach
UH> ================
UH> Definition of "border router approach"?
UH> ================
   should be used to allow interconnection of SMF areas
   with networks using other multicast routing protocols (e.g., PIM).
   It is important to note that there are many scenario-specific issues
   that should be addressed when discussing border routers.  At the
   present time, experimental deployments of SMF and PIM border router
   approaches have been demonstrated.  Some of the functionality border
   routers may need to address includes the following:

   1.  Determining which multicast group traffic transits the border
       router whether entering or exiting the attached MANET routing
       region(s).
   2.  Enforcement of TTL threshold or other scoping policies.
   3.  Any marking or labeling to enable DPD on ingressing packets.

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

   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.
UH> ================
UH> Should be made clear that these 6 points are explained in sections later
UH> ================

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

8.1.  Forwarded Multicast Groups

   Mechanisms for dynamically determining groups for forwarding into a
   MANET SMF routing region is an evolving technology area.  Ideally,
   only groups for which there is active group membership should be
   injected into the SMF domain.  This 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.

   Outbound traffic is less problematic.
UH> ================
UH> Less problematic than what?
UH> ================

   SMF border routers can perform
   duplicate packet detection and forward non-duplicate traffic that
   meets TTL/hop limit and scoping criteria to other interfaces.
UH> ================
UH> Other interfaces than what?
UH> ================

   Appropriate IP multicast routing (PIM, etc) on those interfaces
UH> ================
UH> Which are "those" interfaces?
UH> ================

   can
   then make further forwarding decisions with respect to the given
   traffic destination and potentially its
UH> ================
UH> "its"... whose source address?
UH> ================
   source addresses.  Note that
   the presence of multiple border routers associated with a MANET
   routing region raises additional issues.  This is further discussed
   in Section 8.4 but further work is expected to be needed here.

8.2.  Multicast Group Scoping

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

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

   1.  TTL scoping.
UH> ================
UH> + hop limit?
UH> ================

   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 region 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 region
   know if they must forward a packet based on the IPv6 multicast group
   address.  For the case of IPv6, it is RECOMMENDED that a MANET SMF
   routing region be designated a site.
UH> ================
UH> That is a bit vague. "designated a site" (note that unicast
site-scope IPv6 addresses are deprecated). I would change that to
"site-scope multicast addresses SHOULD be used as destination of IPv6
datagrams".
UH> ================

   Thus, all IPv6 multicast
   packets in the range FF05::/16 SHOULD be kept within the MANET SMF
   routing region by border routers.  IPv6 packets in any other wider
   range scopes (i.e.  FF08::/16, FF0B::/16 and FF0E::16) MAY traverse
   border routers unless other restrictions different from the scope
   applies.

   Given that scoping of multicast packets is performed at the border
   routers, and given that existing scoping mechanisms are not designed
   to work with mobile routers, it is assumed that non-border SMF
   routers will not stop forwarding multicast data packets of an
   appropriate site scoping.  That is, it is assumed that an SMF routing
   region is a site scoped area.

8.3.  Interface with Exterior Multicast Routing Protocols

   The traditional operation of multicast routing protocols is tightly
   integrated with the group membership function.
UH> ================
UH> Add citation?
UH> ================

   Leaf routers
UH> ================
UH> Definition of "lead router"?
UH> ================
   are
   configured to periodically gather group membership information, while
   intermediate routers conspire to create multicast trees connecting
   routers with directly-connected multicast sources and routers with
   active multicast receivers.  In the concrete case of SMF, border
   routers can be considered leaf routers.  Mechanisms for multicast
   sources and receivers to interoperate with border routers over the
   multihop MANET SMF routing region as if they were directly connected
   to the router need to be defined.
UH> ================
UH> But aren't they directly "connected" (whatever that means) with
the border routers?
UH> ================
   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

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

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

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

   The need for the border router to receive traffic from recognized
   multicast sources within the MANET SMF routing region is important to
   achieve a smooth interworking
UH> ================
UH> What does "smooth interworking" mean?
UH> ================
   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 MSDP,
UH> ================
UH> MSDP has not been cited. Nor was PIM-S.
UH> ================
   receivers in
   those external networks are not able to join the multicast tree for
   that source.

8.4.  Multiple Border Routers

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

   1.  Detection/hash collision/sequencing
UH> ================
UH> Better make a real sentence out of these two /
UH> ================

   of duplicate unmarked IPv4 or
       IPv6 (without IPSec encapsulation or DPD option) packets possibly
       injected by multiple border routers.
   2.  Source-based relay algorithms handling of duplicate traffic
       injected by multiple border routers.
   3.  Determination of which border router(s) will forward outbound
       multicast traffic.
   4.  Additional challenges with interfaces to exterior multicast
       routing protocols.

   One of the most obvious issues
UH> ================
UH> Not scientific language
UH> ================

   is when multiple border routers are

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

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

   1.  Redundantly forward the multicast flows (identified by
       <sourceAddress:destinationAddress>) from each border router,
       performing DPD processing on a <taggerID:destinationAddress> or
       <taggerID:sourceAddress:destinationAddress> basis, or
   2.  Use some basis to select the flow of one tagger (border router)
       over the others and forward packets for applicable flows
       (identified by <sourceAddress:destinationAddress>) only for that
       "Tagger ID" until timeout or some other criteria to favor another
       tagger occurs.
   It is RECOMMENDED that the first approach be used in the case of
   I-DPD operation unless the SMF system
UH> ================
UH> Definition of "SMF system"?
UH> ================

   is specifically designed to
   implement the second option.  Additional specification may be
   required to describe an interoperable forwarding policy based on this
   second option.  Note that the implementation of the second option
   requires that per-flow (i.e., <sourceAddress::destinationAddress>)
   state be maintained for the selected "Tagger ID".

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

9.  Non-SMF MANET Node Interaction

   There may be scenarios in which some neighboring wireless MANET node
   are not running SMF and/or not forwarding, but are interested in
   receiving multicast data.  For example, a MANET service
UH> ================
UH> Definition of "MANET service"?
UH> ================

   might be
   deployed that is accessible to wireless edge devices
UH> ================
UH> Definition of "wireless edge devices"?
UH> ================

   that do not
   participate in MANET routing, NHDP, and/or SMF forwarding operation.
   These devices include:

   1.  Devices that opportunistically receive multicast traffic due to
       proximity with SMF relays (possibly with asymmetric IP
       connectivity
UH> ================
UH> Definition of "asymmetric IP connectivity"?
UH> ================

       e.g., sensor network device).

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

   2.  Devices that participate in NHDP (directly or via routing
       protocol signaling)
UH> ================
UH> I don't understand the difference between "directly" and "via
routing protocol signaling". A routers runs or runs not NHDP. Other
processes (SMF, unicast routing protocol, etc.) can use that
information.
UH> ================
       but do not forward traffic.

   Note there is no guarantee of traffic delivery with category 1 above,
   but the election heuristics shown in Figure 4 MAY be adjusted via
   management to better support such devices.  However, it is
   RECOMMENDED that nodes participate in NHDP when possible.
UH> ================
UH> This previous sentence alone would certainly make the NHDP authors
happy, but this cannot apply for all nodes. ;-)
UH> ================

   Such devices
UH> ================
UH> Which devices?
UH> ================

   may also transmit multicast traffic, but it is important to
   note that SMF routing regions using source-specific relay set
   algorithms such as (S-MPR) may not forward such traffic.  These
   devices SHOULD also listen for any IGMP/MLD Queries that are provided
   and transmit IGMP/MLD Reports
UH> ================
UH> Definition of "IGMP Queries, IGMP Reports"?
UH> ================

   for groups they have joined per usual
   IP Multicast operation.  While it is not in the scope of this
   document, IGMP/MLD proxy mechanisms may be in place to convey group
   membership information to any border routers or intermediate systems
   providing IP Multicast routing functions.

10.  Security Considerations

   Gratuitous use of option headers can cause problems in routers.
   Routers outside of MANET routing regions
UH> ================
UH> Definition of "routers outside of MANET routing region"?
UH> ================

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

   Several SMF DoS scenarios have been described throughout the document
   and recommended mitigation strategies have been presented.  Here we
   summarize a few of these areas for reference.

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

   Another potential denial-of-service attack against SMF forwarding is
   possible when a malicious node has a form of "wormhole" access (via a
   directional antenna, etc)
UH> ================
UH> Definition of whormhole? sounds for me like a "normal" link with
lower RTTs/delays...
UH> ================

   to preview packets before a particular SMF
   node would receive them.  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 would block forwarding of the subsequently-arriving
   valid packet with appropriate TTL value.  This would be a relatively
   low-cost, high-payoff attack that would be hard to detect and thus
   attractive to potential attackers.  An approach of caching TTL

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

   information with DPD state and taking appropriate forwarding actions
   is identified in Section 4 to mitigate this form of attack.

   The support of forwarding IPSec datagrams without further
   modification for both IPv4 and IPv6 is supported by this
   specification.

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

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 (see [RFC5444]) used to extend NHDP
   operation as needed to support different forms of SMF operation.

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 5.1.1.  A
   portion of the option data content is the "taggerIdType" that
   provides a context for the "taggerId" that is optionally included to
   identify the intermediate system
UH> ================
UH> Definition of "intermediate system"? Difference to "intermediate router"?
UH> ================

   that added the SMF_DPD option to the
   packet.  This document defines a name-space for IPv6 SMF_DPD Tagger
   Identifier Types:
                        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 a "IETF
UH> ================
UH> s/a IETF/an IETF/
UH> ================

   Consensus" basis as defined in [RFC2434].

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

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

                   +----------+-------+---------------+
                   | 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 an IANA assignment one message "SMF_TYPE" TLV
   value and one address block "SMF_NBR_TYPE" TLV value
UH> ================
UH> TLV value or TLV type?
UH> ================
   from the [NHDP]
   specific registry space.

   The format of this new TLV type 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 a "IETF Consensus"
UH> ================
UH> s/a IETF/an IETF/
UH> ================
   basis as defined in [RFC2434].
   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

                   +----------+-------+---------------+
                   | Mnemonic | Value | Reference     |
                   +----------+-------+---------------+
                   | CF       | 0     | This document |
                   | 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 7, 2010    [Page 32]

Internet-Draft                     SMF                        March 2010

12.  Acknowledgments

   Many of the concepts and mechanisms used and adopted by SMF resulted
   from many years of discussion and related work within the MANET WG
   since the late 1990s.  There are obviously many contributors to past
   discussions and related draft documents within the WG that have
   influenced the development of SMF concepts that deserve
   acknowledgment.  In particular, the document is largely a direct
   product of the earlier SMF design team within the IETF MANET WG and
   borrows text and implementation ideas from the related individuals
   and activities.  Some of the driect
UH> ================
UH>s/driect/direct/
UH> ================
   contributors who have been
   involved in design, content editing, prototype implementation, 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
      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.

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

   [NHDP]     Clausen, T. and et al, "MANET Neighborhood Discovery
              Protocol", draft-ietf-manet-nhdp-11, Work in progress ,
UH> ================
UH> Several times in citations there are additional blanks (e.g. here
before the comma). NHDP is in version 14 now
UH> ================

              October 2009.

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

   [OLSRv2]   Clausen, T. and et al, "Optimized Link State Routing
              Protocol version 2", draft-ietf-manet-olsrv2-10, Work in
              progress , September 2009.
UH> ================
UH> OLSRv2-11. Is OLSR and OLSRv2 really normative?
UH> ================

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

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

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

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

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

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

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

   [RFC5444]  Clausen, T. and et al,
UH> ================
UH> and et al is double double...
UH> ================

   "Generalized MANET Packet/Message
              Format", RFC 5444, February 2009.

13.2.  Informative References

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

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

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

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

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

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

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

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

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

UH> ================
UH> Start this section with an overview before mentioning examples of it
UH> ================

   The "Essential Connected Dominating Set" (E-CDS) algorithm [E-CDS]
   allows nodes to use 2-hop neighborhood topology information to
   dynamically perform relay self election to form a CDS.  Its packet
   forwarding rules are not dependent upon previous hop knowledge.
   Additionally, E-CDS SMF forwarders can be easily mixed without
   problems with CF SMF forwarders, even those not participating in
   NHDP.  Another benefit is that packets opportunistically received
   from non-symmetric neighbors may be forwarded without compromising
   flooding efficiency or correctness.  Furthermore, multicast sources
   not participating in NHDP may freely inject their traffic and any
   neighboring E-CDS relays will properly forward the traffic.  The
   E-CDS based relay set selection algorithm is based upon the summary
   within [E-CDS].  E-CDS was originally discussed in the context of
   forming partial adjacencies and efficient flooding for MANET OSPF
   extensions work and the core algorithm is applied here for SMF.

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

   It is RECOMMENDED that the SMF_TYPE:E-CDS message TLV
UH> ================
UH> as defined where?
UH> ================
   be included in
   NHDP_HELLO messages that are generated by nodes conducting E-CDS SMF
   operation.  It is also RECOMMENDED that the SMF_NBR_TYPE:E-CDS
   address block TLV be used to advertise neighbor nodes that are also
   conducting E-CDS SMF operation.

A.1.  E-CDS Relay Set Selection Overview

   The E-CDS relay set selection requires 2-hop neighborhood information
   collected through NHDP or another process.  Relay nodes, in E-CDS SMF
   selection, are "self-elected" using a router identifier (Router ID)
   and an optional nodal metric, referred to here as "Router Priority"
   for all 1-hop and 2-hop neighbors.  To ensure proper relay set self-
   election, the Router ID and Router Priority MUST be consistent among
   nodes participating
UH> ================
UH> How is that done in detail?
UH> ================

   and it is RECOMMENDED that NHDP be used to share
   this information.
UH> ================
UH> how?
UH> ================

   The Router ID is a logical identification that
   MUST be consistent across interoperating SMF neighborhoods and it is
   RECOMMENDED to be chosen as the largest interface address advertised
   by NHDP.
UH> ================
UH> What is a "largest address"? Addresses are not typically ordered.
UH> ================

   The E-CDS self-election process can be summarized as
   follows:

   1.  If an SMF node has a higher ordinal (Router Priority, Router ID)
UH> ================
UH> Is "highest ordinal" clear enough?
UH> ================
       than all of its symmetric neighbors, it elects itself to act as a
       forwarder for all received multicast packets,
   2.  Else, if there does not exist a path from neighbor "j"
UH> ================
UH> "j" is never used. Can be omitted
UH> ================
   with
       largest (Router Priority, Router ID) to any other neighbor, _via_
       neighbors with larger values of (Router Priority, Router ID),
       then it elects itself to the relay set.

   The basic form of E-CDS described and applied within this
   specification does not provide for redundant relay set election
   (e.g., bi-connected) but such capability is supported by the basic
   E-CDS design.

A.2.  E-CDS Forwarding Rules

   With E-CDS, any SMF node that has selected itself as a relay performs
   DPD and forwards all non-duplicative multicast traffic allowed by the
   present forwarding policy.  Packet previous hop knowledge is not
   needed for forwarding decisions when using E-CDS.

   1.  Upon packet reception, DPD is performed.  Note E-CDS requires a
       single duplicate table for the set of interfaces associated with
       the relay set selection.
   2.  If the packet is a duplicate, no further action is taken.
   3.  If the packet is non-duplicative:

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

       A.  A DPD entry is made for the packet identifier
       B.  The packet is forwarded out all interfaces associated with
           the relay set selection

   As previously mentioned, even packets sourced (or relayed) by nodes
   not participating in NHDP and/or the E-CDS relay set selection may be
   forwarded by E-CDS forwarders without problem.  A particular
   deployment MAY choose to not forward packets from sources or relays
   that have been not explicitly identified via NHDP or other means as
   operating as part of a different relay set algorithm (e.g.  S-MPR) to
   allow coexistent deployments to operate correctly.
UH> ================
UH> But the source may be further away than 2-hops (and thus not be
contained in NHDP information)
UH> ================

   Also, E-CDS relay
   set selection may be configured to be influenced by statically-
   configured CF relays that are identified via NHDP or other means.

A.3.  E-CDS Neighborhood Discovery Requirements

   It is possible to perform E-CDS relay set selection without
   modification of NHDP, basing the self-election process exclusively on
   the Router IDs (interface addresses)
UH> ================
UH> Router ID != interface addresses
UH> ================
   of participating SMF nodes.
   However steps MUST be taken to insure that all NHDP instances
UH> ================
UH> So there can be several NHDP instances? How would that work with
SMF? Which one to consider?
UH> ================
   not
   using SMF_TYPE:E-CDS full type message TLVs are in fact running SMF
   E-CDS, otherwise incorrect forwarding may occur.  Furthermore, it has
   been shown
UH> ================
UH> "it has been shown" where? Citation
UH> ================
   that use of a "Router Priority" metric as part of the
   selection process can result in improved performance in certain
   cases.  Note that SMF nodes with higher "Router Priority" values will
   tend to
UH> ================
UH> "tend to"? That's not very precise
UH> ================
   be favored as relays over other nodes.  Thus, preferred
   relays MAY be administratively configured to be selected when
   possible.  Additionally, other metrics (e.g. nodal degree, energy
   capacity, etc) may also be taken into account in constructing a
   "Router Priority" value.  When using "Router Priority" with multiple
   interfaces all interfaces on a node MUST use and advertise a common
   "Router Priority" value.
UH> ================
UH> Which value is that?
UH> ================

   To share a node's "Router Priority" with its 1-hop neighbors the
   SMF_TYPE:E-CDS message TLV's <value> field is defined as shown in
   Table 11.

               +---------------+---------+-----------------+
               | Length(bytes) | Value   | Router Priority |
               +---------------+---------+-----------------+
               | 0             | N/A     | 64              |
               | 1             | <value> | 0-127           |
               +---------------+---------+-----------------+

                    Table 11: E-CDS Message TLV Values

   Where <value> is a one byte bit field
UH> ================
UH> "one octet long bit field"
UH> ================
   which is defined as:

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

   bit 0: is reserved and SHOULD be set to 0.
UH> ================
UH> Is bit 0 the "leftmost"/most significant?
UH> ================

   bit 1-7: contain the priority value, 0-127,
UH> ================
UH> i.e. "unsigned"!
UH> ================
   which is associated with
   the originator address.

   Combinations of value field lengths and values other than specified
   here are NOT permitted and SHOULD be ignored.  Below is an example
   SMF_TYPE:E-CDS message TLV

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     ...              |   SMF_TYPE    |1|0|0|1|0|0|   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     E-CDS     |0|0|0|0|0|0|0|1|R|  priority   |     ...       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 5: E-CDS Message TLV Example

   To convey "Router Priority" values among 2-hop neighborhoods the
   SMF_NBR_TYPE:E-CDS address block TLV's <value> field is defined thus:

   +---------------+--------+----------+-------------------------------+
   | Length(bytes) | # Addr | Value    | Router Priority               |
   +---------------+--------+----------+-------------------------------+
   | 0             | Any    | N/A      | 64                            |
   | 1             | Any    | <value>  | <value> is for all addresses  |
   | N             | N      | <value>* | Each address gets its own     |
   |               |        |          | <value>                       |
   +---------------+--------+----------+-------------------------------+
UH> ================
UH> mention multi-value TLVs as defined in RFC5444
UH> ================

                 Table 12: E-CDS Address Block TLV Values

   Where <value> is a one byte bit field which is defined as:

   bit 0: is reserved and SHOULD be set to 0.

   bit 1-7: contain a priority value, 0-127, which is associated with
   the appropriate address.
UH> ================
UH> should be "address(es)" for multi-value TLVs
UH> ================

   Combinations of value field lengths and # of addresses other than
   specified here are NOT permitted and SHOULD be ignored.  A default
   technique of using nodal degree (i.e. count of 1-hop neighbors) is
   RECOMMENDED for the value field of these TLV types.  Below are two
   example SMF_NBR_TYPE:E-CDS address block TLVs.

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

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     ...              | SMF_NBR_TYPE  |1|0|0|1|0|0|   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     E-CDS     |0|0|0|0|0|0|0|1|R|  priority   |     ...       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 6: E-CDS Address Block TLV Example 1

   This
UH> ================
UH> s/This/The/
UH> ================
   single value example TLV
UH> ================
UH> + "depicted in figure 6"
UH> ================
   specifies that all address(es)
   contained in the address block are running SMF using the E-CDS
   algorithm and all address(es) share the value field and therefore the
   same priority value.
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     ...              | SMF_NBR_TYPE  |1|0|1|1|0|1|   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     E-CDS     |  index-start  |   index-end   |    length     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |R|  priority0  |R|  priority1  |      ...      |R|  priorityn  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 7: E-CDS Address Block TLV Example 2

   This example multivalue TLV
UH> ================
UH> + "depicted in figure 7"
UH> ================
   specifies that address(es) contained in
   the address block from index-start to index-end inclusive are running
   SMF using the E-CDS algorithm.  Each address is associated with its
   own value byte and therefore their
UH> ================
UH> s/their/its/
UH> ================
   own priority value.

A.4.  E-CDS Selection Algorithm

   This section describes an algorithm for E-CDS relay selection (self-
   election).  The algorithm described uses 2-hop information.  Note it
   is possible to extend this algorithm to use k-hop information with
   added computational complexity and mechanisms for sharing k-hop
   topology information that are not described in this document or
   wihtin the NHDP specification.  It should also be noted that this
   algorithm does not impose the "hop limit" bound described in [E-CDS]
   when performing the path search that is used for relay selection.
   However, the algorithm below could be easily augmented to accommodate
   this additional criteria.
UH> ================
UH> s/criteria/criterion/
UH> ================

   In normal operation,
UH> ================
UH> What is "normal operation"? Whould would be the opposite?
UH> ================

   it is not expected
   that the "hop limit" bound will provide significant benefit.

   The tuple of "Router Priority" and "Router ID" is used in E-CDS relay
   set selection.  Precedence is given to the "Router Priority" portion
   and the "Router ID" value is used as a tie-breaker.  The evaluation

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

   of this tuple is referred to as "RtrPri(n)" in the description below
   where "n" references a specific node.  Note it is possible that the
   "Router Priority" portion may be optional and the evaluation of
   "RtrPri()" be solely based upon the unique "Router ID".  Since there
   MUST NOT be any duplicate "Router ID" values among SMF nodes, a
   comparison of RtrPri(n) between any two nodes will always be an
   inequality.  The use of nodal degree for calculating "Router
   Priority" is RECOMMENDED as default and the largest IP address
   associated across interfaces advertised by NHDP MUST be used as the
   "Router ID".  NHDP provides
UH> ================
UH> "provide" how?
UH> ================

   all interface address throughout the
   2-hop neighborhood so explicity conveying a "Router ID" is not
   necessary.  The following steps describe a basic algorithm for
   conducting E-CDS relay selection for a node "n0":
   1.  Initialize the set "N1" to include all 1-hop neighbors of "n0".
UH> ================
UH> Does N1 contain the originator addresses of the neighbors? Or
their interface addresses? Or both?
UH> ================

   2.  If "N1" has less than 2 members, then "n0" does not elect itself
       as a relay and no further steps are taken.
   3.  Initialize the set "N2" to include all 2-hop neighbors, excluding
       "n0" and any nodes in "N1".
   4.  If "RtrPri(n0)" is greater than that of all nodes in the union of
       "N1" and "N2", then "n0" selects itself as a relay and no further
       steps are taken.
   5.  Initialize all nodes in the union of "N1" and "N2" as
       "unvisited".
   6.  Find the node "n1_Max" that has the largest "RtrPri()" of all
       nodes in "N1"
   7.  Initialize queue "Q" to contain "n1_Max", marking "n1_Max" as
       "visited"
   8.  While node queue "Q" is not empty, remove node "x" from the head
       of "Q", and for each 1-hop neighbor "n" of node "x" (excluding
       "n0") that is not marked "visited"
       A.  Mark node "n" as "visited"
       B.  If "RtrPri(n)" is greater than "RtrPri(n0), append "n" to "Q"
   9.  If any node in "N1" remains "unvisited", then "n0" selects itself
       as a relay.  Otherwise "n0" does not act as an relay.
UH> ================
UH> s/an/a/
UH> ================

   Note these steps are re-evaluated upon neighborhood status changes.
   Steps 5 through 8 of this procedure describe an approach to a path
   search.  The purpose of this path search is to determine if paths
   exist from the 1-hop neighbor with maximum "RtrPri()" to all other
   1-hop neighbors without traversing an intermediate node with a
   ""RtrPri()"
UH> ================
UH> s/""/"/
UH> ================

   value less than "RtrPri(n0)".  These steps comprise a
   breadth-first traversal that evaluates only paths that meet that
   criteria.  If all 1-hop neighbors of "n0" are "visited" during this
   traversal, then the path search has succeeded and node "n0" does not
   need to provide relay.  It can be assumed that other nodes will
   provide relay operation to ensure SMF connectivity.

   It is possible to extend this algorithm to consider neighboring SMF
   nodes that are known to be statically configured for CF (always

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

   relaying).  The modification to the above algorithm is to process
   such nodes as having a maximum possible "Router Priority" value.  It
   is expected that nodes configured for CF and participating in NHDP
   would indicate this with use of the SMF_TYPE:CF and SMF_NBR_TYPE:CF
   TLV types in their NHDP_HELLO message and address blocks,
   respectively.

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

   The source-based multipoint relay (S-MPR) set selection algorithm
   enables individual nodes, using two-hop topology information, to
   select relays from their set of neighboring nodes.  Relays are
   selected so that forwarding to the node's complete two-hop neighbor
   set is covered.  This distributed relay set selection technique has
   been shown to approximate a minimal connected dominating set (MCDS)
   in [JLMV02].  Individual nodes must collect two-hop neighborhood
   information from neighbors, determine an appropriate current relay
   set, and inform selected neighbors of their relay status.  Note that
   since each node picks its neighboring relays independently, S-MPR
   forwarders depend upon previous hop information (e.g, source MAC
   address) to operate correctly.  The Optimized Link State Routing
   (OLSR) protocol has used this algorithm and protocol for relay of
   link state updates and other control information [RFC3626] and it has
   been demonstrated operationally in dynamic network environments.

   It is RECOMMENDED that the SMF_TYPE:S-MPR message TLV be included in
   NHDP_HELLO messages that are generated by nodes conducting S-MPR SMF
   operation.  It is also RECOMMENDED that the SMF_NBR_TYPE:S-MPR
   address block TLV be used to specifiy which neighbor nodes are
   conducting S-MPR SMF operation.

B.1.  S-MPR Relay Set Selection Overview

   A RECOMMENDED algorithm for S-MPR set selection is described in the
   [OLSRv2] specification.  As this algorithm has had considerable use
   to support the OLSR control plane, it is expected to perform
   adequately to support data plane multicast traffic.  To summarize,
   the S-MPR algorithm uses bi-directional 1-hop and 2-hop neighborhood
   information collected via NHDP to select, from a node's 1-hop
   neighbors, a set of relays that will cover the node's entire 2-hop
   neighbor set upon forwarding.  The algorithm described uses a
   "greedy" heuristic of first picking the 1-hop neighbor who will cover
   the most 2-hop neighbors.  Then, excluding those 2-hop neighbors that
   have been covered, additional relays from its 1-hop neighbor set are
   iteratively selected until the entire 2-hop neighborhood is covered.
   Note that 1-hop neighbors also identified as 2-hop neighbors are
   considered as 1-hop neighbors only.  This is only a partial

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

   description of the S-MPR algorithm.  The [RFC3626] specification
   provides a complete description including the use of a "WILLINGNESS"
   metric, termed here "Router Priority", that can be used to influence
   S-MPR forwarder selection.

   NHDP_HELLO messages supporting S-MPR forwarding operation SHOULD use
   the TLVs defined in Section 7.1 using the S-MPR extended type.  The
   value field of an address block TLV which has a full type value of
   SMF_NBR_TYPE:S-MPR is defined in Table 14 such that signaling of
   multi point relay (MPR)
UH> ================
UH> You have talked about relays before but never used the term MPR.
Should be defined before, or never used.
UH> ================

   selections to 1-hop neighbors is possible.
   The value field of a message block TLV which has a full type value of
   SMF_TYPE:S-MPR is defined in Table 13 such that signaling of "Router
   Priority" (described as "WILLINGNESS" in [OLSRv2]) to 1-hop neighbors
   is possible.  It is important to note that S-MPR forwarding is
   dependent upon the previous hop of an incoming packet.  A S-MPR
UH> ================
UH> s/A/An/
UH> ================
   node
   MUST forward packets only for neighbors which have explicitly
   selected it as a relay (i.e., its "selectors").  There are also some
   additional requirements for duplicate packet detection to support
   S-MPR SMF operation that are described below.

   For multiple interface operation, MPR selection SHOULD be conducted
   on a per-interface basis.  However, it is possible to economize MPR
   selection among multiple interfaces by selecting common MPRs to the
   extent possible.  It is important to note that the S-MPR forwarding
   rules described in [OLSRv2] assume per-interface MPR selection (i.e.
   MPRs are _not_ selected in the context of all interfaces).  This is
   consistent with the MPR selection heuristics described in [RFC3626].
   Other source-based approaches may be possible, but would require
   alternative selection and forwarding rules to be specified.

B.2.  S-MPR Forwarding Rules

   An S-MPR relay MUST only forward packets for neighbors that have
   explicitly selected it as a forwarder.
UH> ================
UH> Selected it as "forwarder"? Or "relay"? Or "MPR"?
UH> ================
   The source-based forwarding
   technique also stipulates some additional duplicate packet detection
   operations.  For multiple network interfaces, independent DPD state
   MUST be maintained for each separate interface.  The following table
   provides the procedure for S-MPR packet forwarding given the arrival
   of a packet on a given interface, denoted <srcIface>.  There are
   three possible actions, depending upon the previous-hop transmitter:

   1.  If the previous-hop transmitter has selected the current node as
       a relay,
       A.  The packet identifier is checked against the DPD state for
           each possible outbound interface, including the <srcIface>.
       B.  If the packet is not a duplicate for an outbound interface,
           the packet is forwarded via that interface
UH> ================
UH> "that" interface? which interface?
UH> ================

           and a DPD entry is
           made for the given packet identifier for the interface.

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

       C.  If the packet is a duplicate, no action is taken for that
           interface.
   2.  Else, if the previous-hop transmitter is a 1-hop symmetric
       neighbor,
       A.  A DPD entry is made
UH> ================
UH> s/is made/is added/
UH> ================

       for that packet for the <srcIface>, but
           the packet is not forwarded.
   3.  Otherwise, no action is taken.

   Case number two in the above table is non-intuitive, but important to
   ensure correctness of S-MPR SMF operation.  The selection of source-
   based relays does not result in a common set among neighboring nodes,
   so relays MUST mark in their DPD state, packets received from non-
   selector, symmetric, one-hop neighbors (for a given interface) and
   not forward subsequent duplicates of that packet if received on that
   interface.  Deviation here can result in unnecessary, repeated packet
   forwarding throughout the network, or incomplete flooding.
UH> ================
UH> Maybe use a similar processed-/received-/forwarded set as in OLSRv2?
UH> ================

   Nodes not participating in neighborhood discovery and relay set
   selection will not be able to source multicast packets into the area
   and have SMF forward them, unlike E-CDS or MPR-CDS where forwarding
   may occur dependent on topology.  Correct S-MPR relay behavior will
   occur with the introduction of repeaters (non-NHDP/SMF participants
   that relay multicast packets using duplicate detection and CF) but
   the repeaters will not efficiently contribute to S-MPR forwarding as
   these nodes will not be identified as neighbors (symmetric or
   otherwise) in the S-MPR forwarding process.  NHDP/SMF participants
   MUST NOT provide extra forwarding, forwarding packets which are not
   selected by the algorithm, as this can disrupt network-wide S-MPR
   flooding, resulting in incomplete or inefficient flooding.

B.3.  S-MPR Neighborhood Discovery Requirements

   Nodes may optionally signal "Router Priority" or "WILLINGNESS"
UH> ================
UH> Which one? Router Priority _or_ WILLINGNESS?
UH> ================
   to
   become MPR nodes for their one hop neighbors by using the SMF_TYPE:S-
   MPR message block TLV value field defined as such:

               +---------------+---------+-----------------+
               | Length(bytes) | Value   | Router Priority |
               +---------------+---------+-----------------+
               | 0             | N/A     | 64              |
               | 1             | <value> | 0-127           |
               +---------------+---------+-----------------+

                    Table 13: S-MPR Message TLV Values

   Where <value> is a one byte bit field
UH> ================
UH> "one octet long bit field"
UH> ================
   which is defined as:

   bit 0: is reserved and SHOULD be set to 0.

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

   bit 1-7: contain the priority value, 0-127, which is associated with
   the originator address.
UH> ================
UH> Originator address of what? Of the message?
UH> ================

   Router priority values for S-MPR work similarly to "WILLINGNESS"
   values as described in [OLSRv2] with value 0 indicating a node will
   NEVER forward and value 127 indicating a node will ALWAYS forward.
UH> ================
UH> That seems wrong. Willingness does not mean with which percentage
a router forwards messages. It indicates how likely it will be
selected as MPR (but once it is selected as MPR, it will forward ALL
messages)
UH> ================

   Combinations of value field lengths and values other than specified
   here are NOT permitted and SHOULD be ignored.  Below is an example
   SMF_TYPE:S-MPR message TLV.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     ...              | SMF_NBR_TYPE  |1|0|0|1|0|0|   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     S-MPR     |0|0|0|0|0|0|0|1|R|  priority   |     ...       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 8: S-MPR Message TLV Example

   S-MPR election operation requires 2-hop neighbor knowledge as
   provided by the NHDP protocol [NHDP] or from external sources.  MPRs
   are dynamically selected by each node and selections MUST be
   advertised and dynamically updated within NHDP or an equivalent
   protocol or mechanism.  For NHDP use, the SMF_NBR_TYPE:S-MPR address
   block TLV value field is defined as such:

   +---------------+--------+----------+-------------------------------+
   | Length(bytes) | # Addr | Value    | Meaning                       |
   +---------------+--------+----------+-------------------------------+
   | 0             | Any    | N/A      | Addresses are NOT MPRs        |
UH> ================
UH> A router can be MPR, but not an address (that appears several
times in the following text)
UH> ================

   | 1             | Any    | <value>  | <value> is for all addresses  |
   | N             | N      | <value>* | Each address gets its own     |
   |               |        |          | <value>                       |
   +---------------+--------+----------+-------------------------------+

                 Table 14: E-CDS Address Block TLV Values
UH> ================
UH> s/E-CDS/S-MPR/
UH> ================

   Where <value> is a one byte field whcih is defined as:
UH> ================
UH> s/whcih/which/
UH> ================

   bit 0: Is the M bit which when set indicates MPR selection of
   associated address(es) by the originator node of the NHDP HELLO
   message.  When unset indicates the originator of the NHDP HELLO
   message has not selected the relevant address as an MPR.
UH> ================
UH> What is a "relevant address"?
UH> ================

   bit 1-7: are reserved and SHOULD be set to 0.

   Combinations of value field lengths and # of addresses other than

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

   specified here are NOT permitted and SHOULD be ignored.  All bits,
   excepting the leftmost bit, are RESERVED and SHOULD be set to 0.
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     ...              | SMF_NBR_TYPE  |1|1|0|1|0|0|   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     S-MPR     |  start-index  |0|0|0|0|0|0|0|1|M|  reserved   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 9: S-MPR Address Block TLV Example 1

   This single index example TLV
UH> ================
UH> "as depicted in figure 9"
UH> ================
   indicates that the address specified by
   the <start-index> field is running SMF using S-MPR and has been
   selected by the originator of the NHDP HELLO message as an MPR
   forwarder if the M bit is set.  Multivalue TLVs may also be used to
   specify MPR selection status of multiple addresses using only one
   TLV.  See Figure 7 for an example on how this may be done.

B.4.  S-MPR Selection Algorithm

   This section describes a basic algorithm for the S-MPR selection
   process.  Note that the selection is with respect to a specific
   interface of the node performing selection and other node interfaces
   referenced are reachable from this reference node interface.  This is
   consistent with the S-MPR forwarding rules described above.  When
   multiple interfaces per node are used, it is possible to enhance the
   overall selection process across multiple interfaces such that common
   nodes are selected as MPRs for each interface to avoid unnecessary
   inefficiencies in flooding.  This is described further in [OLSRv2].
   The following steps describe a basic algorithm for conducting S-MPR
   selection for a node interface "n0":

   1.  Initialize the set "MPR" to empty.
   2.  Initialize the set "N1" to include all 1-hop neighbors of "n0".
   3.  Initialize the set "N2" to include all 2-hop neighbors, excluding
       "n0" and any nodes in "N1".  Nodes which are only reachable via
       "N1" nodes
UH> ================
UH> add "and" between N1 and nodes?
UH> ================

       with router priority values of NEVER are also
       excluded.
   4.  For each interface "y" in "N1", initialize a set "N2(y)" to
UH> ================
UH> N1 contains "1-hop neighbors" (I assume originator addresses or
so... unclear as in step 2). But not interface. Maybe it could contain
interface addresses, but not interfaces
UH> ================

       include any interfaces in "N2" that are 1-hop neighbors of "y".
   5.  For each interface "x" in "N1" with a router priority value of
       "ALWAYS" (or using CF relay algorithm), select "x" as a MPR:
       A.  Add "x" to the set "MPR" and remove "x" from "N1".
       B.  For each interface "z" in "N2(x)", remove "z" from "N2"
       C.  For each interface "y" in "N1", remove any interfaces in
           "N2(x)" from "N2(y)"

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

   6.  For each interface "z" in "N2", initialize the set "N1(z)" to
       include any interfaces in "N1" that are 1-hop neighbors of "z".
   7.  For each interface "x" in "N2" where "N1(x)" has only one member,
       select "x" as a MPR:
       A.  Add "x" to the set "MPR" and remove "x" from "N1".
       B.  For each interface "z" in "N2(x)", remove "z" from "N2" and
           delete "N1(z)"
       C.  For each interface "y" in "N1", remove any interfaces in
           "N2(x)" from "N2(y)"
   8.  While "N2" is not empty, select the interface "x" in "N1" with
       the largest router priority which has the number of members in
       "N_2(x)" as a MPR:
       A.  Add "x" to the set "MPR" and remove "x" from "N1".
       B.  For each interface "z" in "N2(x)", remove "z" from "N2"
       C.  For each interface "y" in "N1", remove any interfaces in
           "N2(x)" from "N2(y)"

   After the set of nodes "MPR" is selected, node "n_0" must signal its
   selections to its neighbors.  With NHDP, this is done by using the
   MPR address block TLV to mark selected neighbor addresses in
   NHDP_HELLO messages.  Neighbors MUST record their MPR selection
   status and the previous hop address (e.g., link or MAC layer) of the
   selector.  Note these steps are re-evaluated upon neighborhood status
   changes.

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

   The MPR-CDS algorithm is an extension to the basic S-MPR election
   algorithm that results in a shared (non source-specific) SMF CDS.
   Thus its forwarding rules are not dependent upon previous hop
   information similar to E-CDS.  An overview of the MPR-CDS selection
   algorithm is provided in [MPR-CDS].

   It is RECOMMENDED that the SMF_RELAY_ALG message TLV be included in
   NHDP_HELLO messages that are generated by nodes conducting MPR-CDS
   SMF operation.

C.1.  MPR-CDS Relay Set Selection Overview

   The MPR-CDS relay set selection process is based upon the MPR
   selection process of the S-MPR algorithm with the added refinement of
   a distributed technique for subsequently down-selecting to a common
   reduced, shared relay set.  A node ordering (or "prioritization")
   metric is used as part of this down-selection process Like
UH> ================
UH> s/Like/like/
UH> ================
   the E-CDS
   algorithm, this metric can be based upon node address or some other
   unique router identifier ("Router ID")
UH> ================
UH> Where is that router ID defined? It's not typically used in MANET protocols
UH> ================
   as well as an additional

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

   "Router Priority" measure, if desired.  The process for MPR-CDS relay
   selection is as follows:
   1.  First, MPR selection per the S-MPR algorithm is conducted, with
       selectors informing their MPRs (via NHDP) of their selection.
   2.  Then, the following rules are used on a distributed basis by
       selected nodes to possibly unselect themselves and thus jointly
       establish a common set of shared SMF relays:
       A.  If a selected node has a larger "RtrPri()" than all of its
           1-hop symmetric neighbors, then it acts as a relay for all
           multicast traffic, regardless of the previous hop
       B.  Else, if the 1-hop symmetric neighbor with the largest
           "RtrPri()" value has selected the node, then it also acts as
           a relay for all multicast traffic, regardless of the previous
           hop.
       C.  Otherwise, it unselects itself as a relay and does not
           forward any traffic unless changes occur that require re-
           evaluation of the above steps.

   This technique shares many of the desirable properties of the E-CDS
   technique with regards to compatibility with multicast sources not
   participating in NHDP and the opportunity for statically-configure CF
   nodes to be present, regardless of their participation in NHDP.

C.2.  MPR-CDS Forwarding Rules

   The forwarding rules for MPR-CDS are common with those of E-CDS.  Any
   SMF node that has selected itself as a relay performs DPD and forward
UH> ================
UH> s/forward/forwards/
UH> ================

   all non-duplicative multicast traffic allowed by the present
   forwarding policy.  Packet previous hop knowledge is not needed for
   forwarding decisions when using MPR-CDS.

   1.  Upon packet reception, DPD is performed.  Note MPR-CDS require
       one duplicate table for the set of interfaces associated with the
       relay set selection.
   2.  If the packet is a duplicate, no further action is taken.
   3.  If the packet is non-duplicative:
       A.  A DPD entry is made
UH> ================
UH> s/is made/is added/
UH> ================

       for the packet identifier
       B.  The packet is forwarded out all interfaces associated with
           the relay set selection

   As previously mentioned, even packets sourced (or relayed) by nodes
   not participating in NHDP and/or the MPR-CDS relay set selection may
   be forwarded by E-CDS
UH> ================
UH> I thought this section is about MPR-CDS, and not E-CDS?
UH> ================
   forwarders without problem.  A particular
   deployment MAY choose to not forward packets from sources or relays
   that have been explicitly identified via NHDP or other means as
   operating as part of a different relay set algorithm (e.g.  S-MPR) to
   allow coexistent deployments to operate correctly.  Also, MPR-CDS
   relay set selection may be configured to be influenced by statically-

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

   configured CF relays that are identified via NHDP or other means.
UH> ================
UH> How would that work?
UH> ================

<SNIP>