One document matched: draft-ietf-manet-smf-14.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- automatically generated by xml2rfc v1.36 on 2011-06-27T15:47:46Z -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes"?>
<rfc category="exp" docName="draft-ietf-manet-smf-14" ipr="pre5378Trust200902">
<front>
<title abbrev="SMF">Simplified Multicast Forwarding</title>
<author fullname="Joseph Macker" initials="J" surname="Macker, editor">
<organization>NRL</organization>
<address>
<postal>
<street></street>
<city>Washington</city>
<region>DC</region>
<country>USA</country>
<code>20375</code>
</postal>
<email>macker@itd.nrl.navy.mil</email>
</address>
</author>
<date day="6" month="March" year="2012" />
<abstract>
<t>This document describes a Simplified Multicast Forwarding (SMF)
mechanism that provides basic Internet Protocol (IP) multicast
forwarding suitable for limited wireless mesh and mobile ad hoc network
(MANET) use. It is mainly applicable in situations where efficient
flooding represents an acceptable engineering design trade-off. It
defines techniques for multicast duplicate packet detection (DPD), to be
applied in the forwarding process, for both IPv4 and IPv6 protocol use.
This document also specifies optional mechanisms for using reduced relay
sets to achieve more efficient multicast data distribution within a mesh
topology as compared to classic flooding. Interactions with other
protocols, such as use of information provided by concurrently running
unicast routing protocols, or interaction with other multicast
protocols, as well as multiple deployment approaches are also described.
Distributed algorithms for selecting reduced relay sets and related
discussion are provided in the appendices. Basic issues relating to the
operation of multicast MANET border routers are discussed, but ongoing
work remains in this area, and is beyond the scope of this document.</t>
</abstract>
</front>
<middle>
<section title="Introduction and Scope">
<t>Unicast routing protocols, designed for MANET and wireless mesh use,
often apply distributed algorithms to flood routing control plane
messages within a MANET routing domain. For example, algorithms
specified within <xref target="RFC3626"></xref> and <xref
target="RFC3684"></xref> provide distributed methods of dynamically
electing reduced relay sets that attempt to efficiently flood routing
control messages while maintaining a connected set under dynamic
topological conditions.</t>
<t>Simplified Multicast Forwarding (SMF) extends the efficient flooding
concept to the data forwarding plane, providing an appropriate multicast
forwarding capability for use cases where localized, efficient flooding
is considered an effective design approach. The baseline design is
intended to provide a basic, best effort multicast forwarding capability
that is constrained to operate within a single MANET routing domain.</t>
<t>An SMF routing domain is an instance of an SMF routing protocol with
common policies, under a single network administration authority. The
main design goals of this document are to:</t>
<t><list style="symbols">
<t>adapt efficient relay sets in MANET environments <xref
target="RFC2501"></xref>;</t>
<t>define the needed IPv4 and IPv6 multicast duplicate packet
detection (DPD) mechanisms to support multi-hop, packet
forwarding.</t>
</list></t>
</section>
<section title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in <xref
target="RFC2119"></xref>.</t>
<t>The terms introduced in <xref target="RFC5444"></xref>, including
"packet", "message", "TLV Block", "TLV", and "address" are to be
interpreted as described therein.</t>
<t>The following abbreviations are used throughout this document:</t>
<texttable>
<ttcol>Abbreviation</ttcol>
<ttcol align="left">Definition</ttcol>
<c>MANET</c>
<c>Mobile Ad hoc Network</c>
<c>SMF</c>
<c>Simplified Multicast Forwarding</c>
<c>CF</c>
<c>Classic Flooding</c>
<c>CDS</c>
<c>Connected Dominating Set</c>
<c>MPR</c>
<c>Multi-Point Relay</c>
<c>S-MPR</c>
<c>Source-based MPR</c>
<c>MPR-CDS</c>
<c>MPR-based CDS</c>
<c>E-CDS</c>
<c>Essential CDS</c>
<c>NHDP</c>
<c>Neighborhood Discovery Protocol</c>
<c>DPD</c>
<c>Duplicate Packet Detection</c>
<c>I-DPD</c>
<c>Identification-based DPD</c>
<c>H-DPD</c>
<c>Hash-based DPD</c>
<c>HAV</c>
<c>Hash-assist Value</c>
<c>FIB</c>
<c>Forwarding Information Base</c>
<c>TLV</c>
<c>type-length-value encoding</c>
<c>DoS</c>
<c>Denial of Service</c>
<c>SMF Router</c>
<c>A MANET Router, implementing the protocol specified in this
document</c>
<c>SMF Routing Domain</c>
<c>A MANET Routing Domain wherein the protocol, specified in this
document, is operating</c>
</texttable>
</section>
<section title="Applicability Statement">
<t>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 <xref target="MGL04"></xref> <xref
target="GM99"></xref>. A basic packet forwarding service reaching all
connected routers running the SMF protocol within a MANET routing domain
may provide a useful group communication paradigm for various classes of
applications, for example multimedia streaming, interactive group-based
messaging and applications, peer-to-peer middleware multicasting, and
multi-hop mobile discovery or registration services. SMF is likely only
appropriate for deployment in limited dynamic MANET routing domains so
that the flooding process can be contained, further defined as
administratively scoped multicast forwarding domains in <xref
target="scoping"></xref>.</t>
<t>A design goal is that hosts 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). SMF deployments are able to connect and
interoperate with existing standard multicast protocols operating within
more conventional Internet infrastructures. To this end, 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 <xref target="RFC3973"></xref> and <xref
target="RFC4601"></xref>. Experimental SMF implementations and
deployments have demonstrated gateway functionality at MANET border
routers operating with existing external IP multicast routing protocols
<xref target="CDHM07"></xref>, <xref target="DHS08"></xref>,and <xref
target="DHG09"></xref>. SMF may be extended or combined with other
mechanisms to provide increased reliability and group specific
filtering; the details for this are out of scope for this document.</t>
<t>This document does not presently support forwarding of packets with
directed broadcast addresses as a destination <xref
target="RFC2644"></xref>.</t>
</section>
<section anchor="Overview" title="Overview and Functioning">
<t><xref target="smfNodeArchitecture"></xref> provides an overview of
the logical SMF router architecture, consisting of "Neighborhood
Discovery", "Relay Set Selection" and "Forwarding Process" components.
Typically, relay set selection (or self-election) occurs based on
dynamic input from a neighborhood discovery process. SMF supports the
case where neighborhood discovery and/or relay set selection information
is obtained from a coexistent process (e.g., a lower layer mechanism or
a unicast routing protocol using relay sets). In some algorithm designs,
the forwarding decision for a packet can also depend on previous hop or
incoming interface information. The asterisks (*) in <xref
target="smfNodeArchitecture"></xref> mark the primitives and
relationships, needed by relay set algorithms requiring previous-hop
packet forwarding knowledge.</t>
<figure align="center" anchor="smfNodeArchitecture"
title="SMF router Architecture">
<artwork><![CDATA[ ______________ _____________
| | | |
| Neighborhood | | Relay Set |
| Discovery |------------->| Selection |
| | neighbor | Algorithm |
|______________| info |_____________|
\ /
\ /
neighbor\ /forwarding
info* \ ____________ / status
\ | | /
`-->| Forwarding |<--'
| Process |
~~~~~~~~~~~~~~~~~>|____________|~~~~~~~~~~~~~~~~~>
incoming packet, forwarded packets
interface id*, and
previous hop*]]></artwork>
</figure>
<t></t>
<t>Certain IP multicast packets, defined in <xref
target="scoping"></xref> and <xref target="Forwarding"></xref>, are
"non-forwardable". These multicast packets MUST be ignored by the SMF
forwarding engine. The SMF forwarding engine MAY also work with policies
and management interfaces to allow additional filtering control over
which multicast packets are considered for potential SMF forwarding.
This interface would allow more refined dynamic forwarding control once
such techniques are matured for MANET operation. At present, further
discussion of dynamic control is left to future work.</t>
<t>Interoperable SMF implementations MUST use compatible DPD approaches
and be able to process the header options defined in this document for
IPv6 operation.</t>
<t>Classic Flooding (CF) is defined as the simplest case of SMF
multicast forwarding. With CF, all SMF routers forward each received
multicast packet exactly once. In this case, the need for any relay set
selection or neighborhood topology information is eliminated, at the
expense of additional network overhead incurring from unnecessary packet
retransmissions. With CF, the SMF DPD functionality is still required.
While SMF supports CF as a mode of operation, the use of more efficient
relay set modes is RECOMMENDED in order to reduce contention and
congestion caused by unnecessary packet retransmissions <xref
target="NTSC99"></xref>.</t>
<t>An efficient, reduced relay set is constructed by selecting and
updating, as needed, a subset of all possible routers in a MANET routing
domain to act as SMF forwarders. Known distributed relay set selection
algorithms have demonstrated the ability to provide and maintain a
dynamic connected set for forwarding multicast IP packets <xref
target="MDC04"></xref>. 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.</t>
<t>Determining and maintaining an optimized set of relays generally
requires dynamic neighborhood topology information. Neighborhood
topology discovery functions MAY be provided by a MANET unicast routing
protocol or by using the MANET NeighborHood Discovery Protocol (NHDP)
<xref target="RFC6130"></xref>, operating concurrently with SMF. This
specification also allows alternative lower layer interfaces (e.g.,
radio router interface) to provide the necessary neighborhood
information to aid in supporting more effective relay set election. An
SMF implementation SHOULD provide the ability for multicast forwarding
state to be dynamically managed per operating network interface. The
relay state maintenance options and interactions are outlined in <xref
target="Relays"></xref>. This document states specific requirements for
neighborhood discovery with respect to the forwarding process and the
relay set selection algorithms described herein. For determining dynamic
relay sets in the absence of other control protocols, SMF relies on NHDP
to assist in IP layer 2-hop neighborhood discovery and maintenance for
relay set election. "SMF_TYPE" and "SMF_NBR_TYPE" Message and Address
Block TLV structures (per <xref target="RFC5444"></xref>) are defined by
this document for use with NHDP to carry SMF-specific information. It is
RECOMMENDED that all routers performing SMF operation in conjunction
with NHDP include these TLV types in any NHDP HELLO messages generated.
This capability allows for routers participating in SMF to be explicitly
identified along with their respective dynamic relay set algorithm
configuration.</t>
</section>
<section anchor="Forwarding" title="SMF Packet Processing and Forwarding">
<t>The SMF Packet Processing and Forwarding actions are conducted with
the following packet handling activities:</t>
<t><list style="numbers">
<t>Processing of outbound, locally-generated multicast packets.</t>
<t>Reception and processing of inbound packets on specific network
interfaces.</t>
</list></t>
<t>The purpose of intercepting outbound, locally-generated multicast
packets is to apply any added packet marking needed to satisfy the DPD
requirements so that proper forwarding may be conducted. Note that for
some system configurations the interception of outbound packets for this
purpose is not necessary.</t>
<t>Inbound multicast packets are received by the SMF implementation and
processed for possible forwarding. SMF implementations MUST be capable
of forwarding IP multicast packets with destination addresses that are
not router-local and link-local for IPv6, as defined in <xref
target="RFC4291"></xref>, and that are not within the local network
control block as defined by <xref target="RFC5771"></xref>.</t>
<t>This will support generic multi-hop multicast application needs or
distribute designated multicast traffic ingressing the SMF routing
domain via border routers. The multicast addresses to be forwarded
should be maintained by an a priori list or a dynamic forwarding
information base (FIB) that MAY interact with future MANET dynamic group
membership extensions or management functions.</t>
<t>The SL-MANET-ROUTERS multicast group is defined to contain all
routers within an SMF routing domain, so that packets transmitted to the
multicast address associated with the group will be attempted delivered
to all connected routers running SMF. Due to the mobile nature of a
MANET, routers running SMF may not be topologically connected at
particular times. For IPv6, SL-MANET-ROUTERS is specified to be
"site-local". Minimally, SMF MUST forward, as instructed by the relay
set selection algorithm, unique (non-duplicate) packets received for
SL-MANET-ROUTERS when the TTL/hop-limit or hop limit value in the IP
header is greater than 1. SMF MUST forward all additional global scope
multicast addresses specified within the dynamic FIB or configured list
as well. In all cases, the following rules MUST be observed for SMF
multicast forwarding:</t>
<t><list style="numbers">
<t>Any IP packets not addressed to an IP multicast address MUST NOT
be forwarded by the SMF forwarding engine</t>
<t>IP multicast packets with TTL/hop-limit <= 1 MUST NOT be
forwarded.</t>
<t>Link local IP multicast packets MUST NOT be forwarded.</t>
<t>Incoming IP multicast packets with an IP source address matching
one of those of the local SMF router interface(s) MUST NOT be
forwarded.</t>
<t>Received frames with the MAC source address matching any MAC
address of the router's interfaces MUST NOT be forwarded.</t>
<t>Received packets for which SMF cannot reasonably ensure temporal
DPD uniqueness MUST NOT be forwarded.</t>
<t>Prior to being forwarded, the TTL/hop-limit of the forwarded
packet MUST be decremented by one.</t>
</list></t>
<t>Note that rule #4 is important because over some types of wireless
interfaces, the originating SMF router may receive re-transmissions of
its own packets when they are forwarded by adjacent routers. This rule
avoids unnecessary retransmission of locally-generated packets even when
other forwarding decision rules would apply.</t>
<t>An additional processing rule also needs to be considered based upon
a potential security threat. As discussed in <xref
target="Security"></xref>, there is a potential DoS attack that can be
conducted by remotely "previewing" (e.g., via a directional receive
antenna) packets that an SMF router would be forwarding and conduct a
"pre-play" attack by transmitting the packet before the SMF router would
otherwise receive it but with a reduced TTL/hop-limit field value. This
form of attack can cause an SMF router to create a DPD entry that would
block the proper forwarding of the valid packet (with correct
TTL/hop-limit) through the SMF routing domain. A RECOMMENDED approach to
prevent this attack, when it is a concern, would be to cache temporal
packet TTL/hop-limit values along with the per-packet DPD state (hash
value(s) and/or identifier as described in <xref target="DPD"></xref>).
Then, if a subsequent matching (with respect to DPD) packet arrives with
a larger TTL/hop-limit value than the packet that was previously
forwarded, SMF should forward the new packet and update the
TTL/hop-limit value cached with corresponding DPD state to the new,
larger TTL/hop-limit 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.</t>
<t>Once the SMF multicast forwarding rules have been applied, an SMF
implementation MUST make a forwarding decision dependent upon the relay
set selection algorithm in use. If the SMF implementation is using
Classic Flooding (CF), the forwarding decision is implicit once DPD
uniqueness is determined. Otherwise, a forwarding decision depends upon
the current interface-specific relay set state. The descriptions of the
relay set selection algorithms in the Appendices to this document
specify the respective heuristics for multicast packet forwarding and
specific DPD or other processing required to achieve correct SMF
behavior in each case. For example, one class of forwarding is based
upon relay set election status and the packet's previous hop, while
other classes designate the local SMF router as a forwarder for all
neighboring routers.</t>
</section>
<section anchor="DPD" title="SMF Duplicate Packet Detection">
<t>Duplicate packet detection (DPD) is often a requirement in MANET or
wireless mesh packet forwarding mechanisms because packets may be
transmitted out via the same physical interface as the one over which
they were received. Routers may also receive multiple copies of the same
packets from different neighbors or interfaces. SMF operation requires
DPD and implementations MUST provide mechanisms to detect and reduce the
likelihood of forwarding duplicate multicast packets using temporal
packet identification. It is RECOMMENDED this be implemented by keeping
a history of recently-processed multicast packets for comparison with
incoming packets. A DPD packet cache history SHOULD be kept long enough
so as to span the maximum network traversal lifetime,
MAX_PACKET_LIFETIME, of multicast packets being forwarded within an SMF
routing domain. The DPD mechanism SHOULD avoid keeping unnecessary state
for packet flows such as those that are locally-generated or link-local
destinations that would not be considered for forwarding, as presented
in <xref target="Forwarding"></xref>.</t>
<t>For IPv4 and IPv6, both, this document describes two basic multicast
duplicate packet detection mechanisms: header content
identification-based (I-DPD) and hash-based (H-DPD) duplicate detection.
I-DPD is a mechanism using specific packet headers, and option headers
in the case of IPv6, in combination with flow state to estimate the
temporal uniqueness of a packet. H-DPD uses hashing over header fields
and payload of a multicast packet, in order to provide an estimation of
temporal uniqueness.</t>
<t>Trade-offs of the two approaches to DPD merit different
considerations dependent upon the specific SMF deployment scenario.</t>
<t>Because of the potential addition of a hop-by-hop option header with
IPv6, all SMF routers in the same SMF deployments MUST be configured so
as 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 for IPv4.</t>
<t>For each network interface, SMF implementations MUST maintain DPD
packet state as needed to support the forwarding heuristics of the relay
set algorithm used. In general, this involves keeping track of
previously forwarded packets so that duplicates are not forwarded, but
some relay techniques have additional considerations, such as discussed
in <xref target="smprForwarding"></xref>.</t>
<t>Additional details of I-DPD and H-DPD processing and maintenance for
different classes of packets are described in the following.</t>
<section anchor="DPDv6" title="IPv6 Duplicate Packet Detection">
<t>This section describes the mechanisms and options for SMF IPv6 DPD.
The base IPv6 packet header does not provide any explicit packet
identification header field that can be exploited for I-DPD. The
following options are therefore described, to support IPv6 DPD:<list
style="numbers">
<t>a hop-by-hop SMF_DPD option header, defined in this document
(<xref target="Opt-DPD"></xref>),</t>
<t>the use of IPv6 fragment header fields for I-DPD, if one is
present (<xref target="I-DPDv6"></xref>),</t>
<t>the use of IPsec sequencing for I-DPD when a non-fragmented,
IPsec header is detected (<xref target="I-DPDv6"></xref>), and</t>
<t>an H-DPD approach assisted, as needed, by the SMF_DPD option
header (<xref target="H-DPDv6"></xref>).</t>
</list></t>
<t>SMF MUST provide a DPD marking module that can insert the
hop-by-hop IPv6 header option, defined <xref target="Opt-DPD"></xref>.
This module MUST be invoked after any source-based fragmentation that
may occur with IPv6, so as to ensure that all fragments are suitably
marked. 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 corresponding tasks, outlined in <xref
target="Opt-DPD"></xref> and <xref target="H-DPDv6"></xref>.</t>
<section anchor="Opt-DPD" title="IPv6 SMF_DPD Header Option">
<t>This section defines an IPv6 Hop-by-Hop Option <xref
target="RFC2460"></xref>, SMF_DPD, to serve the purpose of unique
packet identification for IPv6 I-DPD. Additionally, the SMF_DPD
header option provides a mechanism to guarantee non-collision of
hash values for different packets when H-DPD is used.</t>
<t>If this is the only hop-by-hop option present, the optional
"TaggerId" field (see below) is not included, and the size of the
DPD packet identifier (sequence number) or hash token is 24 bits or
less, this will result in the addition of 8 bytes to the IPv6 packet
header including the "Next Header", "Header Extension Length",
SMF_DPD option fields, and padding.</t>
<figure title="IPv6 SMF_DPD Hop-by-Hop Header Option">
<preamble></preamble>
<artwork><![CDATA[ 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| SMF_DPD | Opt. Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|H| DPD Identifier Option Fields or Hash Assist Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure>
<t>"Option Type" = (Lower 5 bits pending IANA assignment, highest
order MUST be 000). By having these three bits be zero, this
specification requires that routers not recognizing this option type
should skip over this option and continue processing the header and
that the option must not change en route <xref
target="RFC2460"></xref>.</t>
<t>"Opt. Data Len" = Length of option content (I.e., 1 +
(<IdType> ? (<IdLen> + 1): 0) + Length(DPD ID)).</t>
<t>"H-bit" = a hash indicator bit value identifying DPD marking
type. 0 == sequence-based approach with optional TaggerId and a
tuple-based sequence number. 1 == indicates a hash assist value
(HAV) field follows to aid in avoiding hash-based DPD
collisions.</t>
<t>When the "H-bit" is cleared (zero value), the SMF_DPD format to
support I-DPD operation is specified as shown in <xref
target="idpdHeaderOption"></xref> and defines the extension header
in accordance with <xref target="RFC2460"></xref>.</t>
<figure align="center" anchor="idpdHeaderOption"
title="IPv6 SMF_DPD Header Option in I-DPD mode">
<artwork><![CDATA[ 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|TidTy| TidLen| TaggerId (optional) ... |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<t>"TidTy" = a 3-bit field indicating the presence and type of the
optional "TaggerId" field. "TidLen" = a 4-bit field indicating the
length (in octets) of the following TaggerId field. "TaggerId" = a
field, is used to differentiate multiple ingressing border gateways
that may commonly apply the SMF_DPD option header to packets from a
particular source. <xref target="TaggerId"></xref> lists the
TaggerId types, used in this document:</t>
<texttable anchor="TaggerId" title="TaggerId Types">
<preamble></preamble>
<ttcol>Name</ttcol>
<ttcol>Purpose</ttcol>
<c>NULL</c>
<c>Indicates no "TaggerId" field is present. "TidLen" MUST also be
set to ZERO.</c>
<c>DEFAULT</c>
<c>A "TaggerId" of non-specific context is present. "TidLen + 1"
defines the length of the TaggerId field in bytes.</c>
<c>IPv4</c>
<c>A "TaggerId" representing an IPv4 address is present. The
"TidLen" MUST be set to 3.</c>
<c>IPv6</c>
<c>A "TaggerId" representing an IPv6 address is present. The
"TidLen" MUST be set to 15.</c>
</texttable>
<t>This format allows a quick check of the "TidTy" field to
determine if a "TaggerId" field is present. If "TidTy" is NULL, then
the length of the DPD packet <Identifier> field corresponds to
(<Opt. Data Len> - 1). If the <TidTy> 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 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 <xref target="I-DPDv6"></xref>.</t>
<t>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, the source or ingressing
gateways apply the SMF_DPD with an HAV only when required to
differentiate the hash value of a new packet with respect to hash
values in the DPD cache. This situation can be detected locally on
the router by running the hash algorithm and checking the DPD cache,
prior to ingressing a previously unmarked packet or a locally
sourced packet. This helps to guarantee the uniqueness of generated
hash values when H-DPD is used. Additionally, this also avoids the
added overhead of applying the SMF_DPD option header to every
packet. For many hash algorithms, it is expected that only sparse
use of the SMF_DPD option may be required. The format of the SMF_DPD
header option for H-DPD operation is given in <xref
target="hdpdHeader"></xref>.</t>
<t></t>
<figure anchor="hdpdHeader"
title="IPv6 SMF_DPD Header Option in H-DPD Mode">
<artwork><![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... |0|0|0| OptType | Opt. Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Hash Assist Value (HAV) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<t>The SMF_DPD option should be applied with an 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 <xref
target="H-DPDv6"></xref>.</t>
</section>
<section anchor="I-DPDv6" title="IPv6 Identification-based DPD">
<t><xref target="IPv6IDPDProcess"></xref> summarizes the IPv6 I-DPD
processing and forwarding decision approach. Within the table '*'
indicates an ignore field condition.</t>
<texttable anchor="IPv6IDPDProcess"
title="IPv6 I-DPD Processing Rules">
<preamble></preamble>
<ttcol>IPv6 Fragment Header</ttcol>
<ttcol>IPv6 IPsec Header</ttcol>
<ttcol>IPv6 I-DPD Header</ttcol>
<ttcol>SMF IPv6 I-DPD Mode Action</ttcol>
<c>Present</c>
<c>*</c>
<c>Not Present</c>
<c>Use Fragment Header I-DPD Check and Process for Forwarding</c>
<c>Not Present</c>
<c>Present</c>
<c>Not Present</c>
<c>Use IPsec Header I-DPD Check and Process for Forwarding</c>
<c>Present</c>
<c>*</c>
<c>Present</c>
<c>Invalid, do not Forward</c>
<c>Not Present</c>
<c>Present</c>
<c>Present</c>
<c>Invalid, do not Forward</c>
<c>Not Present</c>
<c>Not Present</c>
<c>Not Present</c>
<c>Add I-DPD Header,and Process for Forwarding</c>
<c>Not Present</c>
<c>Not Present</c>
<c>Present</c>
<c>Use I-DPD Header Check and Process for Forwarding</c>
</texttable>
<t><list style="numbers">
<t>If a received 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.</t>
<t>If the packet is an unfragmented IPv6 IPsec packet, SMF MUST
use IPsec fields for packet identification. The IPsec header
<sequence> field can be considered a unique identifier in
the context of the <IPsecType:srcAddr:dstAddr:SPI> where
the "IPsecType" is either AH or ESP <xref
target="RFC4302"></xref>.</t>
<t>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. hosts or ingressing SMF
gateways are responsible for applying this option to support
DPD. <xref target="IPv6IDPDId"></xref> summarizes these packet
identification types:</t>
</list></t>
<texttable anchor="IPv6IDPDId"
title="IPv6 I-DPD Packet Identification Types">
<preamble></preamble>
<ttcol>IPv6 Packet Type</ttcol>
<ttcol>Packet DPD ID Context</ttcol>
<ttcol>Packet DPD ID</ttcol>
<c>Fragment</c>
<c><srcAddr:dstAddr></c>
<c><fragmentOffset:id></c>
<c>IPsec Packet</c>
<c><IPsecType:srcAddr:dstAddr:SPI></c>
<c><sequence></c>
<c>Regular Packet</c>
<c><[TaggerId:]srcAddr:dstAddr></c>
<c><SMF_DPD option header id></c>
</texttable>
<t>"IPsecType" is either Authentication Header (AH) or Encapsulating
Security Payload (ESP).</t>
<t>The "TaggerId" is an optional field of the IPv6 SMF_DPD header
option.</t>
</section>
<section anchor="H-DPDv6" title="IPv6 Hash-based DPD">
<t>A default hash-based DPD approach (H-DPD) for use by SMF is
specified as follows. An SHA-1 <xref target="RFC3174"></xref> hash
of the non-mutable header fields, options fields, and data content
of the IPv6 multicast packet is used to produce a 160-bit digest.
The approach for calculating this hash value SHOULD follow the same
guidelines described for calculating the Integrity Check Value (ICV)
described in <xref target="RFC4302"></xref> with respect to
non-mutable fields. This approach should have a reasonably low
probability of digest collision when packet headers and content are
varying. SHA-1 is being applied in SMF only to provide a low
probability of collision and is not being used for cryptographic or
authentication purposes. A history of the packet hash values SHOULD
be maintained within the context of the IPv6 packet header
<srcAddr>. SMF ingress points (i.e., source hosts or gateways)
use this history to confirm that new packets are unique with respect
to their hash value. The Hash-assist Value (HAV) field described in
<xref target="Opt-DPD"></xref> is provided as a differentiating
field when a digest collision would otherwise occur. Note that the
HAV is an immutable option field and SMF MUST process any included
HAV values (see <xref target="Opt-DPD"></xref>) in its hash
calculation.</t>
<t>If a packet results in a digest collision (i.e., by checking the
H-DPD digest history) within the DPD cache kept by SMF forwarders,
the packet SHOULD be silently dropped. If a digest collision is
detected at an SMF ingress point the H-DPD option header is
constructed with a randomly generated HAV. A HAV is recalculated as
needed to produce a non-colliding hash value prior to forwarding.
The multicast packet is then forwarded with the added IPv6 SMF_DPD
header option. A common hash approach MUST be used by SMF routers
for the applied HAV to consistently avoid hash collision and thus
inadvertent packet drops.</t>
<t>The SHA-1 indexing and IPv6 HAV approaches are specified at
present for consistency and robustness to suit experimental uses.
Future approaches and experimentation may discover design tradeoffs
in hash robustness and efficiency worth considering. Enhancements
MAY include reducing the maximum payload length that is processed,
determining shorter indexes, or applying more efficient hashing
algorithms. Use of the HAV functionality may allow for application
of "lighter-weight" hashing techniques that might not have been
initially considered due to poor collision properties otherwise.
Such techniques could reduce packet processing overhead and memory
requirements.</t>
</section>
</section>
<section anchor="DPDv4" title="IPv4 Duplicate Packet Detection">
<t>This section describes the mechanisms and options for IPv4 DPD. The
following areas are described to support IPv4 DPD:</t>
<t><list style="numbers">
<t>the use of IPv4 fragment header fields for I-DPD when they
exist (<xref target="IPv4-I-DPD"></xref>),</t>
<t>the use of IPsec sequencing for I-DPD when a non-fragmented
IPv4 IPsec packet is detected (<xref target="IPv4-I-DPD"></xref>),
and</t>
<t>an H-DPD approach(<xref target="IPv4-H-DPD"></xref>) when
neither of the above cases can be applied.</t>
</list></t>
<t>Although the IPv4 datagram has a 16-bit Identification (ID) field
as specified in <xref target="RFC0791"></xref>, it cannot be relied
upon for DPD purposes due to common computer operating system
implementation practices and the reasons described in the <xref
target="I-D.ietf-intarea-ipv4-id-update">updated specification of the
IPv4 ID Field</xref>. An SMF IPv4 DPD marking option like the IPv6
SMF_DPD option header is not specified since IPv4 header options are
not as tractable for hosts as they are for IPv6. However, when IPsec
is applied or IPv4 packets have been fragmented, the I-DPD approach
can be applied reliably using the corresponding packet identifier
fields described in <xref target="IPv4-I-DPD"></xref> below. For the
general IPv4 case (non-IPsec and non-fragmented packets), the H-DPD
approach of <xref target="IPv4-H-DPD"></xref> is RECOMMENDED.</t>
<t>Since IPv4 SMF does not specify an option 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.</t>
<section anchor="IPv4-I-DPD" title="IPv4 Identification-based DPD">
<t><xref target="IPv4IDPDProcess"></xref> summarizes the IPv4 I-DPD
processing approach once a packet has passed the basic forwardable
criteria described in <xref target="Forwarding"></xref>. To
summarize, for IPv4, I-DPD is applicable only for packets which have
been fragmented or have IPsec applied. Within the table '*'
indicates an ignore field condition. DF, MF, Fragment offset
correspond to related fields and flags defined in <xref
target="RFC0791"></xref>.</t>
<texttable anchor="IPv4IDPDProcess"
title="IPv4 I-DPD Processing Rules">
<ttcol>DF flag</ttcol>
<ttcol>MF flag</ttcol>
<ttcol>Fragment offset</ttcol>
<ttcol>IPsec</ttcol>
<ttcol>IPv4 I-DPD Action</ttcol>
<c>1</c>
<c>1</c>
<c>*</c>
<c>*</c>
<c>Invalid, Do Not Forward</c>
<c>1</c>
<c>0</c>
<c>nonzero</c>
<c>*</c>
<c>Invalid, Do Not Forward</c>
<c>*</c>
<c>0</c>
<c>zero</c>
<c>not Present</c>
<c>Use H-DPD check instead</c>
<c>*</c>
<c>0</c>
<c>zero</c>
<c>Present</c>
<c>IPsec enhanced Tuple I-DPD Check and Process for Forwarding</c>
<c>0</c>
<c>0</c>
<c>nonzero</c>
<c>*</c>
<c>Extended Fragment Offset Tuple I-DPD Check and Process for
Forwarding</c>
<c>0</c>
<c>1</c>
<c>zero or nonzero</c>
<c>*</c>
<c>Extended Fragment Offset Tuple I-DPD Check and Process for
Forwarding</c>
</texttable>
<t>For performance reasons, IPv4 network fragmentation and
reassembly of multicast packets within wireless MANET networks
should be minimized, yet SMF provides the forwarding of fragments
when they occur. If the IPv4 multicast packet is a fragment, SMF
MUST use the fragmentation header fields for packet identification.
This identification can be considered temporally unique in the
context of the <protocol:srcAddr:dstAddr> of the IPv4 packet.
If the packet is an unfragmented IPv4 IPsec packet, SMF MUST use
IPsec fields for packet identification. The IPsec header
<sequence> field can be considered a unique identifier in the
context of the <IPsecType:srcAddr:dstAddr:SPI> where the
"IPsecType" is either AH or ESP <xref target="RFC4302"></xref>.
<xref target="IPv4IDPDId"></xref> summarizes these packet
identification types:</t>
<texttable anchor="IPv4IDPDId"
title="IPv4 I-DPD Packet Identification Types">
<ttcol>IPv4 Packet Type</ttcol>
<ttcol>Packet Identification Context</ttcol>
<ttcol>Packet Identifier</ttcol>
<c>Fragment</c>
<c><protocol:srcAddr:dstAddr></c>
<c><fragmentOffset:id></c>
<c>IPsec Packet</c>
<c><IPsecType:srcAddr:dstAddr:SPI></c>
<c><sequence></c>
</texttable>
<t>"IPsecType" is either Authentication Header (AH) or Encapsulating
Security Payload (ESP).</t>
</section>
<section anchor="IPv4-H-DPD" title="IPv4 Hash-based DPD">
<t>The hashing technique here is similar to that specified for IPv6
in <xref target="H-DPDv6"></xref>, but the H-DPD header option with
HAV is not considered. To ensure consistent IPv4 H-DPD operation
among SMF routers, a default hashing approach is specified. A common
DPD hashing algorithm for an SMF routing area is RECOMMENDED because
colliding hash values for different packets result in a "false
positive" duplicate packet detection and valid packets may be
dropped with a small probability based on the hashing technique
used. Since the "hash assist value" approach is not available for
IPv4, use of a common hashing approach minimizes the hash collision
packet drop probability over multiple hops of forwarding.</t>
<t>SMF MUST perform an SHA-1 <xref target="RFC3174"></xref> hash of
the immutable header fields, option fields and data content of the
IPv4 multicast packet resulting in a 160-bit digest. The approach
for calculating the hash value SHOULD follow the same guidelines
described for calculating the Integrity Check Value (ICV) described
in <xref target="RFC4302"></xref> with respect to non-mutable
fields. A history of the packet hash values SHOULD be maintained in
the context of <protocol:srcAddr:dstAddr>. The context for
IPv4 is more specific than that of IPv6 since the SMF_DPD HAV cannot
be employed to mitigate hash collisions. A RECOMMENDED
implementation detail for IPv4 H-DPD is to concatenate the 16-bit
IPv4 ID value with the computed hash value as an extended DPD hash
value that may provide reduced hash collisions in the cases where
the IPv4 ID field is being set by host operating systems or
gateways. When this approach is taken, the use of the supplemental
"internal hash" technique as described in <xref
target="Security"></xref> is RECOMMENDED as a security measure.</t>
<t>The SHA-1 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.</t>
</section>
</section>
</section>
<!-- End of Duplicate Packet Detection Section -->
<!-- Beginning of Relay Set Section -->
<section anchor="Relays" title="Relay Set Selection">
<t>SMF is flexible in its support of different reduced relay set
mechanism for efficient flooding, the constraints imposed hereon being
detailed in this section.</t>
<section anchor="CFRelays" title="Non-Reduced Relay Set Forwarding">
<t>SMF implementations MUST support CF as a basic forwarding mechanism
when reduced relay set information is not available or not selected
for operation. In CF mode, each router transmits a packet once that
has passed the SMF forwarding rules. The DPD techniques described in
<xref target="DPD"></xref> are critical to proper operation and
prevent duplicate packet retransmissions by the same relays.</t>
</section>
<section title="Reduced Relay Set Forwarding">
<t>MANET reduced relay sets are often achieved by distributed
algorithms that can dynamically calculate a topological connected
dominating set (CDS).</t>
<t>A goal of SMF is to apply reduced relay sets for more efficient
multicast dissemination within dynamic topologies. To accomplish this
an SMF implementation MUST support the ability to modify its multicast
packet forwarding rules based upon relay set state received
dynamically during operation. In this way, SMF operates effectively as
neighbor adjacencies or multicast forwarding policies within the
topology change.</t>
<t>In early SMF experimental prototyping, the relay set information
has been derived from coexistent unicast routing control plane traffic
flooding processes <xref target="MDC04"></xref>. From this experience,
extra pruning considerations were sometimes required when utilizing a
relay set from a separate routing protocol process. As an example,
relay sets formed for the unicast control plane flooding MAY include
additional redundancy that may not be desired for multicast forwarding
use (e.g., biconnected relay set).</t>
<t>Here is a recommended criteria list for SMF relay set selection
algorithm candidates:</t>
<t><list style="numbers">
<t>Robustness to topological dynamics and mobility</t>
<t>Localized election or coordination of any relay sets</t>
<t>Reasonable minimization of CDS relay set size given above
constraints</t>
<t>Heuristic support for preference or election metrics</t>
</list></t>
<t>Some relay set algorithms meeting these criteria are described in
the Appendices of this document. Additional relay set selection
algorithms may be specified in separate specifications in the future.
Each Appendix subsection in this document can serve as a template for
specifying additional relay algorithms.</t>
<t><xref target="smfControlOptions"></xref> depicts an information
flow diagram of possible relay set control options. The SMF Relay Set
State represents the information base that is used by SMF in the
forwarding decision process. The relay set control option diagram
demonstrates that the SMF relay set state may be determined by
fundamentally three different methods:</t>
<t><list style="symbols">
<t>Independent operation with NHDP <xref target="RFC6130"></xref>
input providing dynamic network neighborhood adjacency
information, used by a particular relay set selection
algorithm.</t>
<t>Slave operation with an existing unicast MANET routing
protocol, capable of providing CDS election information for use by
SMF.</t>
<t>Cross layer operation that may involve L2 triggers /
Information describing neighbors or links.</t>
</list></t>
<t>Other heuristics to influence and control election can come from
network management or other interfaces as shown on the right of <xref
target="smfControlOptions"></xref>. CF mode simplifies the control and
does not require other input but relies solely on DPD.</t>
<figure align="center" anchor="smfControlOptions"
title="SMF Reduced Relay Set Information Flow">
<artwork><![CDATA[
Possible L2 Trigger/Information
|
|
______________ ______v_____ __________________
| MANET | | | | |
| Neighborhood | | Relay Set | | Other Heuristics |
| Discovery |----------->| Selection |<------| (Preference,etc) |
| Protocol | neighbor | Algorithm | | Net Management |
|______________| info |____________| |__________________|
\ /
\ /
neighbor\ / Dynamic Relay
info* \ ____________ / Set Status
\ | SMF | / (State, {neighbor info})
`-->| Relay Set |<--'
| State |
-->|____________|
/
/
______________
| Coexistent |
| MANET |
| Unicast |
| Process |
|______________|]]></artwork>
</figure>
<t>More discussion is provided on the three styles of SMF operation
with reduced relay sets as illustrated in <xref
target="smfControlOptions"></xref>:</t>
<t><list style="numbers">
<t>Independent operation: In this case, SMF operates independently
from any unicast routing protocols. To support reduced relay sets
SMF MUST perform its own relay set selection using information
gathered from signaling. It is RECOMMENDED that an associated NHDP
process be used for this signaling. NHDP messaging SHOULD be
appended with additional <xref target="RFC5444"></xref>
type-length-value (TLV) content to support SMF-specific
requirements as discussed in <xref target="RFC6130"></xref> and
for the applicable relay set algorithm described in the Appendices
of this document or future specifications. Unicast routing
protocols may co-exist, even using the same NHDP process, but
signaling that supports reduced relay set selection for SMF is
independent of these protocols.</t>
<t>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.</t>
<t>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).</t>
</list></t>
</section>
</section>
<!-- End of Relay Set Section -->
<!-- Begin Neighborhood Discovery Section -->
<section anchor="Neighborhood"
title="SMF Neighborhood Discovery Requirements">
<t>This section defines the requirements for use of the <xref
target="RFC6130">MANET Neighborhood Discovery Protocol (NHDP)</xref> to
support SMF operation. Note that basic CF forwarding requires no
neighborhood topology knowledge since in this configured mode every SMF
router relays all traffic. Supporting more reduced SMF relay set
operation requires the discovery and maintenance of dynamic neighborhood
topology information. NHDP can be used to provide this necessary
information, however there are SMF-specific requirements for 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, both, for SMF and a coexistent MANET unicast routing protocol.</t>
<t>NHDP HELLO messages and the resultant neighborhood information base
are described separately within the NHDP specification. To summarize,
NHDP provides the following basic functions:</t>
<t><list style="numbers">
<t>1-hop neighbor link sensing and bidirectionality checks of
neighbor links,</t>
<t>2-hop neighborhood discovery including collection of 2-hop
neighbors and connectivity information,</t>
<t>Collection and maintenance of the above information across
multiple interfaces, and</t>
<t>A method for signaling SMF information throughout the 2-hop
neighborhood through the use of TLV extensions.</t>
</list></t>
<t>Appendices (A-C) of this document describe CDS-based relay set
selection algorithms that can achieve efficient SMF operation, even in
dynamic, mobile networks and each of the algorithms has been initially
experimented within a working SMF prototype <xref target="MDDA07">
</xref>. When using these algorithms in conjunction with NHDP, a method
verifying neighbor SMF operation is required in order to insure correct
relay set selection. NHDP along with SMF operation verification provides
the necessary information required by these algorithms to conduct relay
set selection. Verification of SMF operation may be done
administratively or through the use of the SMF relay algorithms TLVs
defined in the following subsections. Use of the SMF relay algorithm
TLVs is RECOMMENDED when using NHDP for SMF neighborhood discovery.</t>
<t><xref target="SMFTLVs"></xref> specifies SMF-specific TLV types,
supporting general SMF operation or supporting the algorithms described
in the Appendices. The Appendices describing several relay set
algorithms also specify any additional requirements for use with NHDP
and reference the applicable TLV types as needed.</t>
<section anchor="SMFTLVs" title="SMF Relay Algorithm TLV Types">
<t>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 Block TLV
type.</t>
<section title="SMF Message TLV Type">
<t>The Message TLV type denoted SMF_TYPE is used to identify the
existence of an SMF instance operating in conjunction with NHDP.
This Message TLV type makes use of the extended type field as
defined by <xref target="RFC5444"></xref> to convey the CDS relay
set selection algorithm currently in use by the SMF message
originator. When NHDP is used to support SMF operation, the SMF_TYPE
TLV, containing the extended type field with the appropriate value,
SHOULD be included in NHDP_HELLO messages (HELLO messages as defined
in <xref target="RFC6130"></xref>). This allows SMF routers 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.</t>
<t>This document defines a Message TLV type as specified in <xref
target="smfType_Message"></xref> conforming to <xref
target="RFC5444"></xref>. The TLV extended type field is used to
contain the sender's "Relay Algorithm Type". The interpretation of
the "value" content of these TLVs is defined per "Relay Algorithm
Type" and may contain algorithm specific information.</t>
<texttable anchor="smfType_Message" title="SMF Type Message TLV">
<preamble></preamble>
<ttcol></ttcol>
<ttcol>TLV Syntax</ttcol>
<ttcol>Field Values</ttcol>
<c>type</c>
<c><tlv-type></c>
<c>SMF_TYPE</c>
<c>extended type</c>
<c><tlv-type-ext></c>
<c><relayAlgorithmId></c>
<c>length</c>
<c><length></c>
<c>variable</c>
<c>value</c>
<c><value></c>
<c>variable</c>
</texttable>
<t>In <xref target="smfType_Message"></xref>
<relayAlgorithmId> is an 8-bit field containing a number 0-255
representing the "Relay Algorithm Type" of the originator address of
the corresponding NHDP message.</t>
<t>Values for the <relayAlgorithmId> are defined in <xref
target="IdTLVValues"></xref>. 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.</t>
<texttable anchor="IdTLVValues"
title="SMF Relay Algorithm Type Values">
<ttcol align="center" width="20%">Type Value</ttcol>
<ttcol align="center" width="30%">Extended Type Value</ttcol>
<ttcol align="center" width="50%">Algorithm</ttcol>
<c>SMF_TYPE</c>
<c>0</c>
<c>CF</c>
<c>SMF_TYPE</c>
<c>1</c>
<c>S-MPR</c>
<c>SMF_TYPE</c>
<c>2</c>
<c>E-CDS</c>
<c>SMF_TYPE</c>
<c>3</c>
<c>MPR-CDS</c>
<c>SMF_TYPE</c>
<c>4-127</c>
<c>Future Assignment STD action</c>
<c>SMF_TYPE</c>
<c>128-239</c>
<c>No STD action required</c>
<c>SMF_TYPE</c>
<c>240-255</c>
<c>Experimental Space</c>
</texttable>
<t>Acceptable <length> and <value> fields of an SMF_TYPE
TLV are dependent on the extended type value (i.e. relay algorithm
type). The appropriate algorithm type, as conveyed in the
<tlv-type-ext> field, defines the meaning and format of its
TLV <value> field. For the algorithms defined by this
document, see the appropriate appendix for the <value> field
format.</t>
</section>
<section title="SMF Address Block TLV Type">
<t>An address block TLV type, denoted SMF_NBR_TYPE (i.e., SMF
neighbor relay algorithm) is specified in <xref
target="smfType_Addr"></xref>. This TLV enables CDS relay algorithm
operation and configuration to 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, some examples of mixed use
are outlined in the Appendices.</t>
<t>The message SMF_TYPE TLV and address block SMF_NBR_TYPE TLV types
share a common format.</t>
<texttable anchor="smfType_Addr" title="SMF Type Address Block TLV">
<preamble></preamble>
<ttcol></ttcol>
<ttcol>TLV syntax</ttcol>
<ttcol>Field Values</ttcol>
<c>type</c>
<c><tlv-type></c>
<c>SMF_NBR_TYPE</c>
<c>extended type</c>
<c><tlv-type-ext></c>
<c><relayAlgorithmId></c>
<c>length</c>
<c><length></c>
<c>variable</c>
<c>value</c>
<c><value></c>
<c>variable</c>
</texttable>
<t><relayAlgorithmId> in <xref target="smfType_Addr"></xref>
is an 8-bit unsigned integer field containing a number 0-255
representing the "Relay Algorithm Type" value that corresponds to
any associated address in the address block. Note that "Relay
Algorithm Type" values for 2-hop neighbors can be conveyed in a
single TLV or multiple value TLVs as described in <xref
target="RFC5444"></xref>. It is expected that SMF routers 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.</t>
<t>Again values for the <relayAlgorithmId> are defined in
<xref target="IdTLVValues"></xref>.</t>
<t>The interpretation of the "value" field of SMF_NBR_TYPE TLVs is
defined per "Relay Algorithm Type" and may contain algorithm
specific information. See the appropriate appendix for definitions
of value fields for the algorithms defined by this document.</t>
</section>
</section>
</section>
<!-- End of Neighborhood Discovery Requirements Section -->
<section anchor="Gateways" title="SMF Border Gateway Considerations">
<t>It is expected that SMF will be used to provide simple forwarding of
multicast traffic within a MANET or mesh routing topology. A border
router gateway approach should be used to allow interconnection of SMF
routing domains with networks using other multicast routing protocols,
such as PIM. It is important to note that there are many
scenario-specific issues that should be addressed when discussing border
multicast routers. At the present time, experimental deployments of SMF
and PIM border router approaches have been demonstrated <xref
target="DHS08"></xref>. Some of the functionality border routers may
need to address includes the following:</t>
<t><list style="numbers">
<t>Determining which multicast group traffic transits the border
router whether entering or exiting the attached SMF routing
domain.</t>
<t>Enforcement of TTL/hop-limit threshold or other scoping
policies.</t>
<t>Any marking or labeling to enable DPD on ingressing packets.</t>
<t>Interface with exterior multicast routing protocols.</t>
<t>Possible operation with multiple border routers (presently beyond
scope of this document).</t>
<t>Provisions for participating non-SMF devices (routers or
hosts).</t>
</list></t>
<t>Each of these areas is discussed in more detail in the following
subsections. Note the behavior of SMF border routers is the same as that
of non-border SMF routers when forwarding packets on interfaces within
the SMF routing domain. Packets that are passed outbound to interfaces
operating fixed-infrastructure multicast routing protocols SHOULD be
evaluated for duplicate packet status since present standard multicast
forwarding mechanisms do not usually perform this function.</t>
<section anchor="ForwardedGroups" title="Forwarded Multicast Groups">
<t>Mechanisms for dynamically determining groups for forwarding into a
MANET SMF routing domain is an evolving technology area. Ideally, only
traffic 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 routers 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.</t>
<t>For outbound traffic, SMF border routers perform duplicate packet
detection and forward non-duplicate traffic that meets TTL/hop limit
and scoping criteria to interfaces external to the SMF routing domain.
Appropriate IP multicast routing (e.g., PIM-based solutions) on those
interfaces can make further forwarding decisions with respect to the
multicast packet. Note that the presence of multiple border routers
associated with a MANET routing domain raises additional issues. This
is further discussed in <xref target="MultipleGateways"></xref> but
further work is expected to be needed here.</t>
</section>
<section anchor="scoping" title="Multicast Group Scoping">
<t>Multicast scoping is used by network administrators to control the
network routing domains reachable by multicast packets. This is
usually done by configuring external interfaces of border routers in
the border of a routing domain to not forward multicast packets which
must be kept within the SMF routing domain. This is commonly done
based on TTL/hop-limit of messages or by using adminstratively scoped
group addresses. These schemes are known respectively as:</t>
<t><list style="numbers">
<t>TTL scoping.</t>
<t>Administrative scoping.</t>
</list></t>
<t>For IPv4, network administrators can configure border routers with
the appropriate TTL/hop-limit thresholds or administratively scoped
multicast groups for the router interfaces as with any traditional
multicast router. However, for the case of TTL/hop-limit scoping it
SHOULD be taken into account that the packet could traverse multiple
hops within the MANET SMF routing domain before reaching the border
router. Thus, TTL thresholds SHOULD be selected carefully.</t>
<t>For IPv6, multicast address spaces include information about the
scope of the group. Thus, border routers of an SMF routing domain know
if they must forward a packet based on the IPv6 multicast group
address. For the case of IPv6, it is RECOMMENDED that a MANET SMF
routing domain be designated a site-scoped multicast domain. Thus, all
IPv6 site-scoped multicast packets in the range FF05::/16 SHOULD be
kept within the MANET SMF routing domain by border routers. IPv6
packets in any other wider range scopes (i.e. FF08::/16, FF0B::/16 and
FF0E::16) MAY traverse border routers unless other restrictions
different from the scope applies.</t>
<t>Given that scoping of multicast packets is performed at the border
routers, and given that existing scoping mechanisms are not designed
to work with mobile routers, it is assumed that non-border routers
running SMF will not stop forwarding multicast data packets of an
appropriate site scoping. That is, it is assumed that an SMF routing
domain is a site-scoped multicast area.</t>
</section>
<section title="Interface with Exterior Multicast Routing Protocols">
<t>The traditional operation of multicast routing protocols is tightly
integrated with the group membership function. Leaf routers are
configured to periodically gather group membership information, while
intermediate routers conspire to create multicast trees connecting
routers with directly-connected multicast sources and routers with
active multicast receivers. In the concrete case of SMF, border
routers can be considered leaf routers. Mechanisms for multicast
sources and receivers to interoperate with border routers over the
multihop MANET SMF routing domain as if they were directly connected
to the router need to be defined. The following issues need to be
addressed:</t>
<t><list style="numbers">
<t>A mechanism by which border routers gather membership
information</t>
<t>A mechanism by which multicast sources are known by the border
router</t>
<t>A mechanism for exchange of exterior routing protocol messages
across the SMF routing domain if the SMF routing domain is to
provide transit connectivity for multicast traffic.</t>
</list></t>
<t>It is beyond the scope of this document to address implementation
solutions to these issues. As described in <xref
target="ForwardedGroups"></xref>, IGMP/MLD proxy mechanisms can
address some of these issues. Similarly, exterior routing protocol
messages could be tunneled or conveyed across an SMF routing domain
but doing this robustly in a distributed wireless environment likely
requires additional considerations outside the scope of this
document.</t>
<t>The need for the border router to receive traffic from recognized
multicast sources within the SMF routing domain is important to
achieve interoperability with some existing routing protocols. For
instance, PIM-S requires routers with locally attached multicast
sources to register them to the Rendezvous Point (RP) so that routers
can join the multicast tree. In addition, if those sources are not
advertised to other autonomous systems (AS) using Multicast Source
Discovery Protocol (MSDP), receivers in those external networks are
not able to join the multicast tree for that source.</t>
</section>
<section anchor="MultipleGateways" title="Multiple Border Routers">
<t>An SMF routing domain might be deployed with multiple participating
routers having connectivity to external, fixed-infrastructure
networks. Allowing multiple routers to forward multicast traffic
to/from the SMF routing domain can be beneficial since it can increase
reliability, and provide better service. For example, if the SMF
routing domain were to fragment with different SMF routers maintaining
connectivity to different border routers, multicast service could
still continue successfully. But, the case of multiple border routers
connecting an SMF routing domain to external networks presents several
challenges for SMF:</t>
<t><list style="numbers">
<t>Handling duplicate unmarked IPv4 or IPv6 (without IPsec
encapsulation or DPD option) packets possibly injected by multiple
border routers.</t>
<t>Source-based relay algorithms handling of duplicate traffic
injected by multiple border routers.</t>
<t>Determination of which border router(s) will forward outbound
multicast traffic.</t>
<t>Additional challenges with interfaces to exterior multicast
routing protocols.</t>
</list></t>
<t>When multiple border routers are present they may be alternatively
(due to route changes) or simultaneously injecting common traffic into
the SMF routing domain that has not been previously marked for IPv6
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 an SMF routing domain, there are two
forwarding policies that SMF routers running I-DPD may implement:</t>
<t><list style="numbers">
<t>Redundantly forward the multicast flows (identified by
<srcAddr:dstAddr>) from each border router, performing DPD
processing on a <TaggerID:dstAddr> or
<TaggerID:srcAddr:dstAddr> basis, or</t>
<t>Use some basis to select the flow of one tagger (border router)
over the others and forward packets for applicable flows
(identified by <sourceAddress:dstAddr>) only for the
selected "Tagger ID" until timeout or some other criteria to favor
another tagger occurs.</t>
</list></t>
<t>It is RECOMMENDED that the first approach be used in the case of
I-DPD operation. Additional specification may be required to describe
an interoperable forwarding policy based on this second option. Note
that the implementation of the second option requires that per-flow
(i.e., <srcAddr::dstAddr>) state be maintained for the selected
"Tagger ID".</t>
<t>The deployment of H-DPD operation may alleviate DPD resolution when
ingressing traffic comes from multiple border routers. Non-colliding
hash indexes (those not requiring the H-DPD options header in IPv6)
should be resolved effectively.</t>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>Gratuitous use of option headers can cause problems in routers. Other
IP routers external to an SMF routing domain that might receive
forwarded multicast SHOULD ignore SMF-specific IPv6 header options when
encountered. The header options types are encoded appropriately to allow
for this behavior.</t>
<t>This section briefly discusses several SMF denial-of-service (DoS)
attack scenarios and we provide some initial recommended mitigation
strategies.</t>
<t>A potential denial-of-service attack against SMF forwarding is
possible when a malicious router has a form of wormhole access to
non-adjacent parts of a network topology. In the wireless ad hoc case, a
directional antenna is one way to provide such a wormhole physically. If
such a router can preview forwarded packets in a non-adjacent part of
the network and forward modified versions to another part of the network
it can perform the following attack. The malicious router could reduce
the TTL/hop-limit or Hop Limit of the packet and transmit it to the SMF
router causing it to forward the packet with a limited TTL/hop-limit (or
even drop it) and make a DPD entry that could block or limit the
subsequent forwarding of later-arriving valid packets with correct
TTL/hop-limit values. This would be a relatively low-cost, high-payoff
attack that would be hard to detect and thus attractive to potential
attackers. An approach of caching TTL/hop-limit information with DPD
state and taking appropriate forwarding actions is identified in <xref
target="Forwarding"></xref> to mitigate this form of attack.</t>
<t>Sequence-based packet identifiers are predictable and thus provide an
opportunity for a DoS attack against forwarding. Forwarding protocols
that use DPD techniques, such as SMF, may be vulnerable to DoS attacks
based on spoofing packets with apparently valid packet identifier
fields. In wireless environments, where SMF will most likely be used,
the opportunity for such attacks may be more prevalent than in wired
networks. In the case of IPv4 packets, fragmented IP packets or packets
with IPsec headers applied, the DPD "identifier portions" of potential
future packets that might be forwarded is highly predictable and easily
subject to DoS 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 routers, 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.</t>
<t>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.</t>
<t>The support of forwarding IPsec packets without further modification
for both IPv4 and IPv6 is supported by this specification.</t>
<t>Authentication mechanisms to identify the source of IPv6 option
headers should be considered to reduce vulnerability to a variety of
attacks.</t>
<t>Furthermore, when the MANET Neighborhood Discovery Protocol <xref
target="RFC6130"></xref> is used, the security considerations described
there also applies.</t>
</section>
<section title="IANA Considerations">
<t>This document defines one IPv6 Hop-by-Hop Option, a type for which
which must be allocated from the IPv6 "Destination Options and
Hop-by-Hop Options" registry of <xref target="RFC2780"></xref>.</t>
<t>This document creates one registry for recording TaggerId types,
(TidTy).</t>
<t>This document requests registration of one well-known multicast
address from each of the IPv4 and IPv6 multicast address spaces.</t>
<t>This document defines one Message TLV, a type for which must be
allocated from the "Message TLV Types" registry of <xref
target="RFC5444"></xref>.</t>
<t>Finally, this document defines one Address Block TLV, a type for
which must be allocated from the "Address Block TLV Types" registry of
<xref target="RFC5444"></xref>.</t>
<section title="IPv6 SMF_DPD Header Extension Option Type">
<t>IANA is requested to allocate an IPv6 Option Type from the IPv6
"Destination Options and Hop-by-Hop Options" registry of <xref
target="RFC2780"></xref>, as specified in <xref
target="hop-by-hop-allocation"></xref>.</t>
<texttable anchor="hop-by-hop-allocation"
title="IPv6 Option Type Allocation">
<ttcol align="center">Mnemonic</ttcol>
<ttcol align="center">act</ttcol>
<ttcol align="center">chg</ttcol>
<ttcol align="center">rest</ttcol>
<ttcol>Description</ttcol>
<ttcol>Reference</ttcol>
<c>SMF_DPD</c>
<c>00</c>
<c>0</c>
<c>TBD</c>
<c>Multicast Duplicate Packet Detection (DPD)</c>
<c>This Document</c>
</texttable>
</section>
<section title="TaggerId Types (TidTy)">
<t>A portion of the option data content in the SMF_DPD is the Taggger
Identifier Type (TidTy), that provides a context for the optionally
included "TaggerId".</t>
<t>IANA is requested to create a registry for recording TaggerId Types
(TidTy), with initial assignments and allocation policies, as
specified in <xref target="TaggerIdTypes"></xref>.</t>
<texttable anchor="TaggerIdTypes" title="TaggerId Types">
<ttcol align="center">Mnemonic</ttcol>
<ttcol align="center">Type</ttcol>
<ttcol>Description</ttcol>
<ttcol>Reference</ttcol>
<c>NULL</c>
<c>0</c>
<c>No "TaggerId" field is present</c>
<c>This document</c>
<c>DEFAULT</c>
<c>1</c>
<c>A "TaggerId" of non-specific context is present</c>
<c>This document</c>
<c>IPv4</c>
<c>2</c>
<c>A "TaggerId" representing an IPv4 address is present</c>
<c>This document</c>
<c>IPv6</c>
<c>3</c>
<c>A "TaggerId" representing an IPv6 address is present</c>
<c>This document</c>
<c></c>
<c>4-6</c>
<c></c>
<c>Unassigned (IETF Review)</c>
<c>ExtId</c>
<c>7</c>
<c></c>
<c>Unassigned (Expert Review)</c>
</texttable>
<t>For allocation of unassigned values 4-6, IETF Review is
required.</t>
<t>For allocation of unassigned value 7, Expert Review is required,
with the following specific guidelines to the Expert: this value is
intended for use in case a future development of this specification
requires extending the type space (e.g. by way of providing a pointer
to a subsequent field).</t>
</section>
<section title="Well-known Multicast Address">
<t>IANA is requested to allocate an IPv4 multicast address
"SL-MANET-ROUTERS" from the "Internetwork Control Block (224.0.1/24)"
sub-registry of the "IPv4 Multicast Address" registry.</t>
<t>IANA is requested to allocate an IPv6 multicast address
"SL-MANET-ROUTERS" from the "Site-Local Scope Multicast Addresses"
sub-sub-registry of the "Fixed Scope Multicast Addresses" sub-registry
of the "INTERNET PROTOCOL VERSION 6 MULTICAST ADDRESSES" registry.</t>
</section>
<section title="SMF Type-Length-Values">
<section title="Expert Review for created Type Extension Registries">
<t>Creation of Address Block TLV Types and Message TLV Types in
registries of <xref target="RFC5444"></xref>, and hence in the HELLO
message specific registries of <xref target="RFC6130"></xref>,
entails creation of corresponding Type Extension registries for each
such type. For such Type Extension registries, where an Expert
Review is required, the designated expert SHOULD take the same
general recommendations into consideration as are specified by <xref
target="RFC5444"></xref>.</t>
</section>
<section title="SMF Message TLV Type (SMF_TYPE)">
<t>This document defines one Message TLV Type, "SMF_TYPE", which
must be allocated from the "HELLO Message-Type-specific Message TLV
Types" registry, defined in <xref target="RFC6130"></xref>.</t>
<t>This will create a new Type Extension registry, with initial
assignments as specified in <xref
target="SMF_TYPE-extension"></xref>.</t>
<texttable anchor="SMF_TYPE-extension"
title="SMF_TYPE Message TLV Type Extension Registry">
<ttcol align="center">Name</ttcol>
<ttcol align="center">Type</ttcol>
<ttcol align="center">Type Extension</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Allocation Policy</ttcol>
<c>SMF_TYPE</c>
<c>TBD2</c>
<c>0-255</c>
<c>Specifies relay algorithm supported by the SMF router,
originating the HELLO message, according to <xref
target="SMFRelayAlgorithmRegistry"></xref>.</c>
<c><xref target="SMFRelayAlgorithmRegistry"></xref></c>
</texttable>
<t></t>
</section>
<section title="SMF Address Block TLV Type (SMF_NBR_TYPE)">
<t>This document defines one Address Block TLV Type, "SMF_NBR_TYPE",
which must be allocated from the "HELLO Message-Type-specific
Address Block TLV Types" registry, defined in <xref
target="RFC6130"></xref>.</t>
<t>This will create a new Type Extension registry, with initial
assignments as specified in <xref
target="SMF_NBR_TYPE-extension"></xref>.</t>
<texttable anchor="SMF_NBR_TYPE-extension"
title="SMF_NBR_TYPE Address Block TLV Type Extension Registry">
<ttcol align="center">Name</ttcol>
<ttcol align="center">Type</ttcol>
<ttcol align="center">Type Extension</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Allocation Policy</ttcol>
<c>SMF_NBR_TYPE</c>
<c>TBD2</c>
<c>0-255</c>
<c>Specifies relay algorithm supported by the SMF router
corresponding to the advertised address, according to <xref
target="SMFRelayAlgorithmRegistry"></xref>.</c>
<c><xref target="SMFRelayAlgorithmRegistry"></xref></c>
</texttable>
<t></t>
</section>
<section anchor="SMFRelayAlgorithmRegistry"
title="SMF Relay Algorithm ID Registry">
<t>Types for the Type Extension Registries for the SMF_TYPE Message
TLV and the SMF_NBR_TYPE Address Block TLV are unified in this
single SMF Relay Algorithm ID Registry, defined in this section.</t>
<t>IANA is requested to create a registry for recording Relay
Algorithm Identifiers, with initial assignments and allocation
policies as specified in <xref target="RelaySetTypes"></xref>.</t>
<texttable anchor="RelaySetTypes"
title="Relay Set Algorithm Type Values">
<ttcol>Name</ttcol>
<ttcol>Value</ttcol>
<ttcol>Description</ttcol>
<ttcol>Allocation Policy</ttcol>
<c>CF</c>
<c>0</c>
<c><xref target="Overview"></xref></c>
<c></c>
<c>S-MPR</c>
<c>1</c>
<c><xref target="smprAppendix"></xref></c>
<c></c>
<c>E-CDS</c>
<c>2</c>
<c><xref target="ecdsAppendix"></xref></c>
<c></c>
<c>MPR-CDS</c>
<c>3</c>
<c><xref target="mprcdsAppendix"></xref></c>
<c></c>
<c></c>
<c>4-127</c>
<c>Unassigned</c>
<c>Expert Review</c>
<c></c>
<c>128-255</c>
<c>Unassigned</c>
<c>Experimental Use</c>
</texttable>
<t>A specification requesting an allocation from the 4-127 range
from the SMF Relay Algorithm ID Registry MUST specify the
interpretation of the <value> field (if any).</t>
</section>
</section>
</section>
<section title="Acknowledgments">
<t>Many of the concepts and mechanisms used and adopted by SMF resulted
over several years of discussion and related work within the MANET
working group since the late 1990s. There are obviously many
contributors to past discussions and related draft documents within the
working group that have influenced the development of SMF concepts and
they deserve acknowledgment. In particular, the document is largely a
direct product of the earlier SMF design team within the IETF MANET
working group and borrows text and implementation ideas from the related
individuals and activities. Some of the direct contributors who have
been involved in design, content editing, prototype implementation,
major commenting, and core discussions are listed below in alphabetical
order. We appreciate all the input and feedback from the many community
members and early implementation users we have heard from that are not
on this list as well.</t>
<t><list style="empty">
<t>Some core contributors/authors in alphabetical order:</t>
<t>Brian Adamson</t>
<t>Teco Boot</t>
<t>Ian Chakeres</t>
<t>Thomas Clausen</t>
<t>Justin Dean</t>
<t>Brian Haberman</t>
<t>Ulrich Herberg</t>
<t>Charles Perkins</t>
<t>Pedro Ruiz</t>
<t>Fred Templin</t>
<t>Maoyu Wang</t>
</list></t>
<t>The RFC text was produced using Marshall Rose's xml2rfc tool and Bill
Fenner's XMLmind add-ons.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.0791"?>
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.2460"?>
<?rfc include="reference.RFC.2644"?>
<?rfc include="reference.RFC.3626"?>
<?rfc include="reference.RFC.5614"?>
<?rfc include="reference.RFC.5444"?>
<?rfc include="reference.RFC.6130"?>
<reference anchor="MPR-CDS">
<front>
<title>Computing Connected Dominating Sets with Multipoint
Relays</title>
<author fullname="Cedrid Adjih" initials="C" surname="Adjih">
<organization>INRIA</organization>
</author>
<author fullname="Phillipe Jacquet" initials="P" surname="Jacquet">
<organization>INRIA</organization>
</author>
<author fullname="Laurent Viennot" initials="L" surname="Viennot">
<organization>INRIA</organization>
</author>
<date month="January" year="2005" />
</front>
<seriesInfo name="Ad Hoc and Sensor Wireless Networks" value="" />
</reference>
<?rfc include="reference.RFC.4302"?>
<?rfc include="reference.RFC.2780"?>
<?rfc include="reference.RFC.3174"?>
<?rfc include="reference.RFC.5226"?>
<?rfc include="reference.RFC.4291"?>
<?rfc include="reference.RFC.5771"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.2501"?>
<?rfc include="reference.I-D.ietf-intarea-ipv4-id-update"?>
<?rfc include="reference.RFC.3973"?>
<?rfc include="reference.RFC.4601"?>
<?rfc include="reference.RFC.3684"?>
<reference anchor="NTSC99">
<front>
<title>The Broadcast Storm Problem in Mobile Ad hoc Networks</title>
<author initials="S" surname="Ni">
<organization></organization>
</author>
<author initials="Y" surname="Tseng">
<organization></organization>
</author>
<author initials="Y" surname="Chen">
<organization></organization>
</author>
<author initials="J" surname="Sheu">
<organization></organization>
</author>
<date year="1999" />
</front>
<seriesInfo name="Proceedings Of ACM Mobicom 99" value="" />
</reference>
<reference anchor="MGL04">
<front>
<title>Group Communications in Mobile Ad hoc Networks</title>
<author fullname="Prasant Mohapatra" initials="P"
surname="Mohapatra">
<organization>University of California, Davis</organization>
</author>
<author fullname="Chao Gui" initials="C" surname="Gui">
<organization>University of California, Davis</organization>
</author>
<author fullname="Jian Li" initials="J" surname="Li">
<organization>University of California, Davis</organization>
</author>
<date month="February" year="2004" />
</front>
<seriesInfo name="IEEE Computer" value="Vol. 37, No. 2" />
</reference>
<reference anchor="GM99">
<front>
<title>The core-assisted mesh protocol</title>
<author fullname="J.J. Garcia-Luna-Aceves" initials="JJ"
surname="Garcia-Luna-Aceves">
<organization>University of California, Santa Cruz</organization>
</author>
<author fullname="E.L. Madruga" initials="E" surname="Madruga">
<organization>University of California, Santa Cruz</organization>
</author>
<date month="August" year="1999" />
</front>
<seriesInfo name="Selected Areas in Communications, IEEE Journal on "
value="Volume 17, Issue 8" />
</reference>
<reference anchor="MDDA07">
<front>
<title>Evaluation of distributed cover set algorithms in mobile ad
hoc network for simplified multicast forwarding</title>
<author initials="J" surname="Macker">
<organization></organization>
</author>
<author initials="I" surname="Downard">
<organization></organization>
</author>
<author initials="J" surname="Dean">
<organization></organization>
</author>
<author initials="R.B." surname="Adamson">
<organization></organization>
</author>
<date day="1" month="July" year="2007" />
</front>
<seriesInfo name="ACM SIGMOBILE Mobile Computing and Communications Review "
value="Volume 11 , Issue 3" />
</reference>
<reference anchor="JLMV02">
<front>
<title>Performance of multipoint relaying in ad hoc mobile routing
protocols</title>
<author initials="P" surname="Jacquet">
<organization></organization>
</author>
<author initials="V" surname="Laouiti">
<organization></organization>
</author>
<author initials="P" surname="Minet">
<organization></organization>
</author>
<author initials="L" surname="Viennot">
<organization></organization>
</author>
<date year="2002" />
</front>
<seriesInfo name="Networking" value="" />
</reference>
<reference anchor="MDC04">
<front>
<title>Simplified Multicast Forwarding in Mobile Ad hoc
Networks</title>
<author initials="J" surname="Macker">
<organization></organization>
</author>
<author initials="J" surname="Dean">
<organization></organization>
</author>
<author initials="W" surname="Chao">
<organization></organization>
</author>
<date year="2004" />
</front>
<seriesInfo name="IEEE MILCOM 2004 Proceedings" value="" />
</reference>
<reference anchor="CDHM07">
<front>
<title>Connecting MANET Multicast</title>
<author fullname="Chakeres" initials="I" surname="Chakeres">
<organization></organization>
</author>
<author fullname="Danilov" initials="C" surname="Danilov">
<organization></organization>
</author>
<author fullname="Henderson" initials="T" surname="Henderson">
<organization></organization>
</author>
<date year="2007" />
</front>
<seriesInfo name="IEEE MILCOM 2007 Proceedings" value="" />
</reference>
<reference anchor="DHS08">
<front>
<title>MANET Multicast with Multiple Gateways</title>
<author fullname="Danilov" initials="C" surname="Danilov">
<organization></organization>
</author>
<author fullname="Henderson" initials="T" surname="Henderson">
<organization></organization>
</author>
<author fullname="Spagnolo" initials="T" surname="Spagnolo">
<organization></organization>
</author>
<date year="2008" />
</front>
<seriesInfo name="IEEE MILCOM 2008 Proceedings" value="" />
</reference>
<reference anchor="DHG09">
<front>
<title>Experiment and field demonstration of a 802.11-based
ground-UAV mobile ad-hoc network</title>
<author fullname="Danilov" initials="C" surname="Danilov">
<organization></organization>
</author>
<author fullname="Henderson" initials="T" surname="Henderson">
<organization></organization>
</author>
<author fullname="Goff" initials="T" surname="Goff">
<organization></organization>
</author>
<date year="2009" />
</front>
<seriesInfo name="Proceedings of the 28th IEEE conference on Military Communications"
value="" />
</reference>
</references>
<section anchor="ecdsAppendix"
title="Essential Connecting Dominating Set (E-CDS) Algorithm">
<t>The "Essential Connected Dominating Set" (E-CDS) algorithm <xref
target="RFC5614"></xref> forms a single CDS mesh for the SMF operating
region. It allows routers 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 <xref target="RFC5614"></xref>. 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.</t>
<t>It is RECOMMENDED that the SMF_TYPE:E-CDS Message TLV be included in
NHDP_HELLO messages that are generated by routers conducting E-CDS SMF
operation. It is also RECOMMENDED that the SMF_NBR_TYPE:E-CDS address
block TLV be used to advertise neighbor routers that are also conducting
E-CDS SMF operation.</t>
<section title="E-CDS Relay Set Selection Overview">
<t>The E-CDS relay set selection requires 2-hop neighborhood
information collected through NHDP or another process. Relay routers,
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 participating routers. It is RECOMMENDED that NHDP be
used to share Router ID and Router Priority through the use of
SMF_TYPE:E-CDS TLVs as described in this appendix. The Router ID is a
logical identification that MUST be consistent across interoperating
SMF neighborhoods and it is RECOMMENDED to be chosen as the
numerically largest address contained in a routers "Neighbor Address
List" as defined in NHDP. The E-CDS self-election process can be
summarized as follows:</t>
<t><list style="numbers">
<t>If an SMF router has a higher ordinal (Router Priority, Router
ID) than all of its symmetric neighbors, it elects itself to act
as a forwarder for all received multicast packets,</t>
<t>Else, if there does not exist a path from the neighbor 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.</t>
</list></t>
<t>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.</t>
</section>
<section title="E-CDS Forwarding Rules">
<t>With E-CDS, any SMF router 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.</t>
<t><list style="numbers">
<t>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.</t>
<t>If the packet is a duplicate, no further action is taken.</t>
<t>If the packet is non-duplicative:<list style="letters">
<t>A DPD entry is made for the packet identifier</t>
<t>The packet is forwarded out all interfaces associated with
the relay set selection</t>
</list></t>
</list></t>
<t>As previously mentioned, even packets sourced (or relayed) by
routers 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 previous hop routers
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. 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.</t>
</section>
<section title="E-CDS Neighborhood Discovery Requirements">
<t>It is possible to perform E-CDS relay set selection without
modification of NHDP, basing the self-election process exclusively on
the "Neighbor Address List" of participating SMF routers. For example
by setting the "Router Priority" to a default value and selecting the
"Router ID" as the numerically largest address contained in the
"Neighbor Address List". However steps MUST be taken to insure that
all NHDP enabled routers not using SMF_TYPE:E-CDS full type Message
TLVs are in fact running SMF E-CDS with the same methods for selecting
"Router Priority" and "Router ID", otherwise incorrect forwarding may
occur. Note that SMF routers with higher "Router Priority" values will
be favored as relays over routers with lower "Router Priority". 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 router MUST use and advertise
a common "Router Priority" value. A routers “Router
Priority” value may be administratively or algorithmically
selected. The method of selection does not need to be the same among
different routers.</t>
<t>E-CDS relay set selection may be configured to be influenced by
statically configured CF relays that are identified via NHDP or other
means. Nodes advertising CF through NHDP may be considered E-CDS SMF
routers with maximal "Router Priority".</t>
<t>To share a router's "Router Priority" with its 1-hop neighbors the
SMF_TYPE:E-CDS Message TLV's <value> field is defined as shown
in <xref target="ecdsMsgTLVValueDef"></xref>.</t>
<texttable anchor="ecdsMsgTLVValueDef"
title="E-CDS Message TLV Values">
<ttcol>Length(bytes)</ttcol>
<ttcol>Value</ttcol>
<ttcol>Router Priority</ttcol>
<c>0</c>
<c>N/A</c>
<c>64</c>
<c>1</c>
<c><value></c>
<c>0-127</c>
</texttable>
<t>Where <value> is a one octet long bit field which is defined
as:</t>
<t>bit 0: the leftmost bit is reserved and SHOULD be set to 0.</t>
<t>bit 1-7: contain the unsigned "Router Priority" value, 0-127, which
is associated with the "Neighbor Address List".</t>
<t>Combinations of value field lengths and values other than specified
here are NOT permitted and SHOULD be ignored. <xref
target="ecdsMsgTLVExample"></xref> shows an example SMF_TYPE:E-CDS
Message TLV</t>
<t><figure anchor="ecdsMsgTLVExample"
title="E-CDS Message TLV Example">
<artwork><![CDATA[ 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 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>To convey "Router Priority" values among 2-hop
neighborhoods the SMF_NBR_TYPE:E-CDS address block TLV's <value>
field is used. Multi-index and multi-value TLV layouts as defined in
<xref target="RFC5444"></xref> are supported. SMF_NBR_TYPE:E-CDS value
fields are defined thus:</t>
<texttable anchor="ecdsAddrTLVValueDef"
title="E-CDS Address Block TLV Values">
<ttcol>Length(bytes)</ttcol>
<ttcol># Addr</ttcol>
<ttcol>Value</ttcol>
<ttcol>Router Priority</ttcol>
<c>0</c>
<c>Any</c>
<c>N/A</c>
<c>64</c>
<c>1</c>
<c>Any</c>
<c><value></c>
<c><value> is for all addresses</c>
<c>N</c>
<c>N</c>
<c><value>*</c>
<c>Each address gets its own <value></c>
</texttable>
<t>Where <value> is a one byte bit field which is defined
as:</t>
<t>bit 0: the leftmost bit is reserved and SHOULD be set to 0.</t>
<t>bit 1-7: contain the unsigned "Router Priority" value, 0-127, which
is associated with the appropriate address(es).</t>
<t>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.</t>
<t><figure anchor="ecdsAddrTLVExample1"
title="E-CDS Address Block TLV Example 1">
<artwork><![CDATA[ 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 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>The single value example TLV, depicted in <xref
target="ecdsAddrTLVExample1"></xref> , 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 "Router Priority". <figure anchor="ecdsAddrTLVExample2"
title="E-CDS Address Block TLV Example 2">
<artwork><![CDATA[ 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>The example multivalued TLV, depicted in <xref
target="ecdsAddrTLVExample2"></xref>, 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 its own "Router Priority".</t>
</section>
<section title="E-CDS Selection Algorithm">
<t>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 within
the NHDP specification. It should also be noted that this algorithm
does not impose the "hop limit" bound described in <xref
target="RFC5614"></xref> when performing the path search that is used
for relay selection. However, the algorithm below could be easily
augmented to accommodate this additional criterion. It is not expected
that the "hop limit" bound will provide significant benefit to the
algorithm defined in this appendix.</t>
<t>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 of this tuple is referred to as "RtrPri(n)" in the
description below where "n" references a specific router. 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
routers, a comparison of RtrPri(n) between any two routers will always
be an inequality. The use of nodal degree for calculating "Router
Priority" is RECOMMENDED as default and the largest IP address in the
"Neighbor Address List" as advertised by NHDP MUST be used as the
"Router ID". NHDP provides all interface address throughout the 2-hop
neighborhood through HELLO messages, so explicitly conveying a "Router
ID" is not necessary. The following steps describe a basic algorithm
for conducting E-CDS relay selection for a router "n0": <list
style="numbers">
<t>Initialize the set "N1" with tuples ("Router Priority", "Router
ID", "Neighbor Address List") for each 1-hop neighbor of "n0".</t>
<t>If "N1" has less than 2 tuples, then "n0" does not elect itself
as a relay and no further steps are taken.</t>
<t>Initialize the set "N2" with tuples ("Router Priority", "Router
ID", "2-hop address") for each "2-hop address" of "n0", where
"2-hop address" is defined in NHDP.</t>
<t>If "RtrPri(n0)" is greater than that of all tuples in the union
of "N1" and "N2", then "n0" selects itself as a relay and no
further steps are taken.</t>
<t>Initialize all tuples in the union of "N1" and "N2" as
"unvisited".</t>
<t>Find the tuple "n1_Max" that has the largest "RtrPri()" of all
tuples in "N1"</t>
<t>Initialize queue "Q" to contain "n1_Max", marking "n1_Max" as
"visited"</t>
<t>While router queue "Q" is not empty, remove router "x" from the
head of "Q", and for each 1-hop neighbor "n" of router "x"
(excluding "n0") that is not marked "visited"<list style="letters">
<t>Mark router "n" as "visited"</t>
<t>If "RtrPri(n)" is greater than "RtrPri(n0), append "n" to
"Q"</t>
</list></t>
<t>If any tuple in "N1" remains "unvisited", then "n0" selects
itself as a relay. Otherwise "n0" does not act as a relay.</t>
</list>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 router with a
"RtrPri()" 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 router "n0" does not
need to provide relay. It can be assumed that other routers will
provide relay operation to ensure SMF connectivity.</t>
<t>It is possible to extend this algorithm to consider neighboring SMF
routers that are known to be statically configured for CF (always
relaying). The modification to the above algorithm is to process such
routers as having a maximum possible "Router Priority" value. It is
expected that routers 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.</t>
</section>
</section>
<section anchor="smprAppendix"
title="Source-based Multipoint Relay (S-MPR)">
<t>The source-based multipoint relay (S-MPR) set selection algorithm
enables individual routers, using two-hop topology information, to
select relays from their set of neighboring routers. Relays are selected
so that forwarding to the router'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 <xref
target="JLMV02"></xref>. Individual routers 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 router 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 <xref target="RFC3626"></xref> and
it has been demonstrated operationally in dynamic network
environments.</t>
<t>It is RECOMMENDED that the SMF_TYPE:S-MPR Message TLV be included in
NHDP_HELLO messages that are generated by routers conducting S-MPR SMF
operation. It is also RECOMMENDED that the SMF_NBR_TYPE:S-MPR address
block TLV be used to specify which neighbor routers are conducting S-MPR
SMF operation.</t>
<section title="S-MPR Relay Set Selection Overview">
<t>The S-MPR algorithm uses bi-directional 1-hop and 2-hop
neighborhood information collected via NHDP to select, from a router's
1-hop neighbors, a set of relays that will cover the router'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.</t>
<t>NHDP HELLO messages supporting S-MPR forwarding operation SHOULD
use the TLVs defined in <xref target="SMFTLVs"></xref> 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 <xref
target="smprAddrTLVValueDef"></xref> such that signaling of MPR
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 <xref target="smprMsgTLVValueDef"></xref> such that
signaling of "Router Priority" (described as "WILLINGNESS" in <xref
target="RFC3626"></xref>) 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. An S-MPR router MUST forward packets only
for neighbors which have explicitly selected it as a multi-point 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.</t>
<t>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.</t>
</section>
<section anchor="smprForwarding" title="S-MPR Forwarding Rules">
<t>An S-MPR SMF router MUST only forward packets for neighbors that
have explicitly selected it as an MPR. 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 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:</t>
<t><list style="numbers">
<t>If the previous-hop transmitter has selected the current router
as an MPR,<list style="letters">
<t>The packet identifier is checked against the DPD state for
each possible outbound interface, including the
<srcIface>.</t>
<t>If the packet is not a duplicate for an outbound interface,
the packet is forwarded on that interface and a DPD entry is
made for the given packet identifier for the interface.</t>
<t>If the packet is a duplicate, no action is taken for that
interface.</t>
</list></t>
<t>Else, if the previous-hop transmitter is a 1-hop symmetric
neighbor,<list style="letters">
<t>A DPD entry is added for that packet for the
<srcIface>, but the packet is not forwarded.</t>
</list></t>
<t>Otherwise, no action is taken.</t>
</list></t>
<t>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
routers, 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.</t>
<t>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
routers 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. The result is that
non S-MPR SMF routers will be unable to source multicast packets and
have them forwarded by other S-MPR SMF routers.</t>
</section>
<section title="S-MPR Neighborhood Discovery Requirements">
<t>Nodes may optionally signal a "Router Priority" value to their one
hop neighbors by using the SMF_TYPE:S-MPR message block TLV value
field. If the value field is omitted, a default "Router Priority"
value of 64 is to be assumed. This is summarized here:</t>
<texttable anchor="smprMsgTLVValueDef"
title="S-MPR Message TLV Values">
<ttcol>Length(bytes)</ttcol>
<ttcol>Value</ttcol>
<ttcol>Router Priority</ttcol>
<c>0</c>
<c>N/A</c>
<c>64</c>
<c>1</c>
<c><value></c>
<c>0-127</c>
</texttable>
<t>Where <value> is a one octet long bit field defined as:</t>
<t>bit 0: the leftmost bit is reserved and SHOULD be set to 0.</t>
<t>bit 1-7: contain the "Router Priority" value, 0-127, which is
associated with the "Neighbor Address List".</t>
<t>"Router Priority" values for S-MPR are interpreted in the same
fashion as "WILLINGNESS" (<xref target="RFC3626"></xref>)with value 0
indicating a router will NEVER forward and value 127 indicating a
router will ALWAYS forward. Values 1-126 indicate how likely a S-MPR
SMF router will be selected as an MPR by a neighboring SMF router,
with higher values increasing the likelihood. 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.</t>
<t><figure anchor="smprMsgTLVExample"
title="S-MPR Message TLV Example">
<artwork><![CDATA[ 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| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S-MPR |0|0|0|0|0|0|0|1|R| priority | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure></t>
<t>S-MPR election operation requires 2-hop neighbor knowledge as
provided by NHDP <xref target="RFC6130"></xref> or from external
sources. MPRs are dynamically selected by each router 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:</t>
<texttable anchor="smprAddrTLVValueDef"
title="S-MPR Address Block TLV Values">
<ttcol>Length(bytes)</ttcol>
<ttcol># Addr</ttcol>
<ttcol>Value</ttcol>
<ttcol>Meaning</ttcol>
<c>0</c>
<c>Any</c>
<c>N/A</c>
<c>NOT MPRs</c>
<c>1</c>
<c>Any</c>
<c><value></c>
<c><value> is for all addresses</c>
<c>N</c>
<c>N</c>
<c><value>*</c>
<c>Each address gets its own <value></c>
</texttable>
<t>Where <value>, if present, is a one octet bit field defined
as:</t>
<t>bit 0: The leftmost bit is the M bit. When set indicates MPR
selection of the relevant interface, represented by the associated
address(es), by the originator router of the NHDP HELLO message. When
unset, indicates the originator router of the NHDP HELLO message has
not selected the relevant interfaces, represented by the associated
address(es), as its MPR.</t>
<t>bit 1-7: are reserved and SHOULD be set to 0.</t>
<t>Combinations of value field lengths and number of addresses other
than specified here are NOT permitted and SHOULD be ignored. All bits,
excepting the leftmost bit, are RESERVED and SHOULD be set to 0.</t>
<figure anchor="smprAddrTLVExample1"
title="S-MPR Address Block TLV Example">
<artwork><![CDATA[ 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<t>The single index TLV example, depicted in <xref
target="smprAddrTLVExample1"></xref>, 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. Multivalued TLVs may also be
used to specify MPR selection status of multiple addresses using only
one TLV. See <xref target="ecdsAddrTLVExample2"></xref> for a similar
example on how this may be done.</t>
</section>
<section anchor="smprAlgorithm" title="S-MPR Selection Algorithm">
<t>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 router performing selection and other router
interfaces referenced are reachable from this reference router
interface. This is consistent with the S-MPR forwarding rules
described above. When multiple interfaces per router are used, it is
possible to enhance the overall selection process across multiple
interfaces such that common routers are selected as MPRs for each
interface to avoid unnecessary inefficiencies in flooding. The
following steps describe a basic algorithm for conducting S-MPR
selection for a router interface "n0":</t>
<t><list style="numbers">
<t>Initialize the set "MPR" to empty.</t>
<t>Initialize the set "N1" to include all 1-hop neighbors of
"n0".</t>
<t>Initialize the set "N2" to include all 2-hop neighbors,
excluding "n0" and any routers in "N1". Nodes which are only
reachable via "N1" routers with router priority values of NEVER
are also excluded.</t>
<t>For each interface "y" in "N1", initialize a set "N2(y)" to
include any interfaces in "N2" that are 1-hop neighbors of
"y".</t>
<t>For each interface "x" in "N1" with a router priority value of
"ALWAYS" (or using CF relay algorithm), select "x" as a MPR:<list
style="letters">
<t>Add "x" to the set "MPR" and remove "x" from "N1".</t>
<t>For each interface "z" in "N2(x)", remove "z" from "N2"</t>
<t>For each interface "y" in "N1", remove any interfaces in
"N2(x)" from "N2(y)"</t>
</list></t>
<t>For each interface "z" in "N2", initialize the set "N1(z)" to
include any interfaces in "N1" that are 1-hop neighbors of
"z".</t>
<t>For each interface "x" in "N2" where "N1(x)" has only one
member, select "x" as a MPR:<list style="letters">
<t>Add "x" to the set "MPR" and remove "x" from "N1".</t>
<t>For each interface "z" in "N2(x)", remove "z" from "N2" and
delete "N1(z)"</t>
<t>For each interface "y" in "N1", remove any interfaces in
"N2(x)" from "N2(y)"</t>
</list></t>
<t>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:<list style="letters">
<t>Add "x" to the set "MPR" and remove "x" from "N1".</t>
<t>For each interface "z" in "N2(x)", remove "z" from "N2"</t>
<t>For each interface "y" in "N1", remove any interfaces in
"N2(x)" from "N2(y)"</t>
</list></t>
</list></t>
<t>After the set of routers "MPR" is selected, router "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.</t>
</section>
</section>
<section anchor="mprcdsAppendix"
title="Multipoint Relay Connected Dominating Set (MPR-CDS) Algorithm">
<t>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 <xref target="MPR-CDS"></xref>.</t>
<t>It is RECOMMENDED that the SMF_TYPE Message TLV be included in
NHDP_HELLO messages that are generated by routers conducting MPR-CDS SMF
operation.</t>
<section title="MPR-CDS Relay Set Selection Overview">
<t>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 router ordering (or "prioritization")
metric is used as part of this down-selection process like the E-CDS
algorithm, this metric can be based upon router address(es) or some
other unique router identifier (e.g. "Router ID" based on largest
address contained within the "Neighbor Address List") as well as an
additional "Router Priority" measure, if desired. The process for
MPR-CDS relay selection is as follows:<list style="numbers">
<t>First, MPR selection per the S-MPR algorithm is conducted, with
selectors informing their MPRs (via NHDP) of their selection.</t>
<t>Then, the following rules are used on a distributed basis by
selected routers to possibly deselect themselves and thus jointly
establish a common set of shared SMF relays:<list style="letters">
<t>If a selected router 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</t>
<t>Else, if the 1-hop symmetric neighbor with the largest
"RtrPri()" value has selected the router, then it also acts as
a relay for all multicast traffic, regardless of the previous
hop.</t>
<t>Otherwise, it deselects itself as a relay and does not
forward any traffic unless changes occur that require
re-evaluation of the above steps.</t>
</list></t>
</list></t>
<t>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
routers to be present, regardless of their participation in NHDP.</t>
</section>
<section title="MPR-CDS Forwarding Rules">
<t>The forwarding rules for MPR-CDS are common with those of E-CDS.
Any SMF router 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 MPR-CDS.</t>
<t><list style="numbers">
<t>Upon packet reception, DPD is performed. Note MPR-CDS require
one duplicate table for the set of interfaces associated with the
relay set selection.</t>
<t>If the packet is a duplicate, no further action is taken.</t>
<t>If the packet is non-duplicative:<list style="letters">
<t>A DPD entry is added for the packet identifier</t>
<t>The packet is forwarded out all interfaces associated with
the relay set selection</t>
</list></t>
</list></t>
<t>As previously mentioned, even packets sourced (or relayed) by
routers not participating in NHDP and/or the MPR-CDS relay set
selection may be forwarded by MPR-CDS 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.</t>
</section>
<section title="MPR-CDS Neighborhood Discovery Requirements">
<t>The neighborhood discovery requirements for MPR-CDS have
commonality with both the S-MPR and E-CDS algorithms. MPR-CDS
selection operation requires 2-hop neighbor knowledge as provided by
NHDP <xref target="RFC6130"></xref> or from external sources. Unlike
S-MPR operation, there is no need for associating link-layer address
information with 1-hop neighbors since MPR-CDS forwarding is
independent of the previous hop similar to E-CDS forwarding.</t>
<t>To advertise an optional "Router Priority" value or "WILLINGNESS"
an originating router may use the Message TLV of type SMF_TYPE:MPR-CDS
which shares a common <value> format with both SMF_TYPE:E-CDS
<xref target="ecdsMsgTLVValueDef"></xref> and SMF_TYPE:S-MPR <xref
target="smprMsgTLVValueDef"></xref>.</t>
<t>MPR-CDS only requires 1-hop knowledge of "Router Priority" for
correct operation. In the S-MPR phase of MPR-CDS selection, MPRs are
dynamically determined by each router and selections MUST be
advertised and dynamically updated using NHDP or an equivalent
protocol or mechanism. The <value> field of the
SMF_NBR_TYPE:MPR-CDS type TLV shares a common format with
SMF_NBR_TYPE:S-MPR <xref target="smprAddrTLVValueDef"></xref> to
convey MPR selection.</t>
</section>
<section title="MPR-CDS Selection Algorithm">
<t>This section describes an algorithm for the MPR-CDS selection
process. Note that the selection described is with respect to a
specific interface of the router performing selection and other router
interfaces referenced are reachable from this reference router
interface. An ordered tuple of "Router Priority" and "Router ID" is
used in MPR-CDS relay set selection. The "Router ID" value should be
set to the largest advertised address of a given router, this
information is provided to one hop neighbors via NHDP by default.
Precedence is given to the "Router Priority" portion and the "Router
ID" value is used as a tie-breaker. The evaluation of this tuple is
referred to as "RtrPri(n)" in the description below where "n"
references a specific router. 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 address values among SMF routers, a comparison of RtrPri(n)
between any two routers will always be an inequality. The following
steps, repeated upon any changes detected within the 1-hop and 2-hop
neighborhood, describe a basic algorithm for conducting MPR-CDS
selection for a router interface "n0":</t>
<t><list style="numbers">
<t>Perform steps 1-8 of <xref target="smprAlgorithm"></xref> to
select MPRs from the set of 1-hop neighbors of "n0" and
notify/update neighbors of selections.</t>
<t>Upon being selected as an MPR (or any change in the set of
routers selecting "n0" as an MPR):<list style="letters">
<t>If no neighbors have selected "n0" as an MPR, "n0" does not
act as a relay and no further steps are taken until a change
in neighborhood topology or selection status occurs.</t>
<t>Determine the router "n1_max" that has the maximum
"RtrPri()" of all 1-hop neighbors.</t>
<t>If "RtrPri(n0)" is greater than "RtrPri(n1_max)", then "n0"
selects itself as a relay for all multicast packets,</t>
<t>Else, if "n1_max" has selected "n0" as an MPR, then "0"
selects itself as a relay for all multicast packets.</t>
<t>Otherwise, "n0" does not act as a relay.</t>
</list></t>
</list></t>
<t>It is possible to extend this algorithm to consider neighboring SMF
routers that are known to be statically configured for CF (always
relaying). The modification to the above algorithm is to process such
routers as having a maximum possible "Router Priority" value. This is
the same as the case for participating routers that have been
configured with a S-MPR "WILLINGNESS" value of "WILL_ALWAYS". It is
expected that routers configured for CF and participating in NHDP
would indicate their status with use of the SMF_TYPE TLV type in their
NHDP_HELLO message TLV block. It is important to note however that CF
routers will not select MPR routers and therefore cannot guarantee
connectedness.</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:57:57 |