One document matched: draft-ietf-manet-smf-06.txt
Differences from draft-ietf-manet-smf-05.txt
Network Working Group J. Macker, editor
Internet-Draft NRL
Intended status: Experimental SMF Design Team
Expires: May 20, 2008 IETF MANET WG
November 17, 2007
Simplified Multicast Forwarding for MANET
draft-ietf-manet-smf-06
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 20, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 1]
Internet-Draft SMF for MANET November 2007
Abstract
This document describes a Simplified Multicast Forwarding (SMF)
mechanism that provides basic IP multicast forwarding suitable for
wireless mesh and mobile ad hoc network (MANET) use. SMF specifies
techniques for multicast duplicate packet detection (DPD) to assist
the forwarding process. SMF also specifies DPD maintenance and
checking operations consistent with both IPv4 and IPv6. SMF takes
advantage of reduced relay sets for efficient MANET multicast
forwarding within a mesh topology and the document describes protocol
interaction with a number of approaches. Candidate algorithms for
selecting reduced relay sets and related discussion is provided in
the Appendices. Basic issues relating to the operation of multicast
MANET border routers are discussed but ongoing work remains in this
area beyond the scope of this document.
Table of Contents
1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
2. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 5
2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 7
3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 8
4. SMF Packet Processing and Forwarding . . . . . . . . . . . . . 9
5. SMF Duplicate Packet Detection . . . . . . . . . . . . . . . . 11
5.1. IPv6 Duplicate Packet Detection . . . . . . . . . . . . . 12
5.1.1. IPv6 SMF-DPD Header Option . . . . . . . . . . . . . . 12
5.1.2. IPv6 Identification-based DPD Operation . . . . . . . 14
5.1.3. IPv6 Hash-based DPD Operation . . . . . . . . . . . . 16
5.2. IPv4 Duplicate Packet Detection . . . . . . . . . . . . . 17
5.2.1. IPv4 Identification-based DPD Operation . . . . . . . 18
5.2.2. IPv4 Hash-based DPD Operation . . . . . . . . . . . . 19
5.3. Internal Hash Computation . . . . . . . . . . . . . . . . 20
6. Reduced Relay Set Forwarding and Relay Selection Capability . 21
7. SMF Neighborhood Discovery Requirements . . . . . . . . . . . 23
7.1. SMF Relay Set Algorithm ID Message TLV . . . . . . . . . . 24
7.2. Router Priority Message TLV . . . . . . . . . . . . . . . 24
7.3. Router Priority Address Block TLV . . . . . . . . . . . . 25
8. SMF Border Gateway Considerations . . . . . . . . . . . . . . 26
8.1. Forwarded Multicast Groups . . . . . . . . . . . . . . . . 26
8.2. Multicast Group Scoping . . . . . . . . . . . . . . . . . 27
8.3. Interface with Exterior Multicast Routing Protocols . . . 28
8.4. Multiple Border Routers . . . . . . . . . . . . . . . . . 29
9. Non-SMF MANET Node Interaction . . . . . . . . . . . . . . . . 31
10. Security Considerations . . . . . . . . . . . . . . . . . . . 32
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 2]
Internet-Draft SMF for MANET November 2007
13.1. Normative References . . . . . . . . . . . . . . . . . . . 35
13.2. Informative References . . . . . . . . . . . . . . . . . . 35
Appendix A. Reduced Relay Set Forwarding Algorithms and
Considerations . . . . . . . . . . . . . . . . . . . 37
Appendix B. Source-based Multipoint Relay (S-MPR) . . . . . . . . 38
B.1. S-MPR Relay Set Selection . . . . . . . . . . . . . . . . 38
B.2. S-MPR Forwarding Rules . . . . . . . . . . . . . . . . . . 38
B.3. S-MPR Neighborhood Discovery Requirements . . . . . . . . 39
B.4. S-MPR Selection Algorithm . . . . . . . . . . . . . . . . 39
B.4.1. MPR Node Selection Procedure . . . . . . . . . . . . . 40
Appendix C. Essential Connecting Dominating Set (E-CDS)
Algorithm . . . . . . . . . . . . . . . . . . . . . . 41
C.1. E-CDS Relay Set Selection . . . . . . . . . . . . . . . . 41
C.2. E-CDS Forwarding Rules . . . . . . . . . . . . . . . . . . 41
C.3. E-CDS Neighborhood Discovery Requirements . . . . . . . . 42
C.4. E-CDS Selection Algorithm (2-Hop) . . . . . . . . . . . . 43
Appendix D. Multipoint Relay Connected Dominating Set
(MPR-CDS) Algorithm . . . . . . . . . . . . . . . . . 44
D.1. MPR-CDS Relay Set Selection . . . . . . . . . . . . . . . 44
D.2. MPR-CDS Forwarding Rules . . . . . . . . . . . . . . . . . 44
D.3. MPR-CDS Neighborhood Discovery Requirements . . . . . . . 45
D.4. MPR-CDS Selection Algorithm . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46
Intellectual Property and Copyright Statements . . . . . . . . . . 47
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 3]
Internet-Draft SMF for MANET November 2007
1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 4]
Internet-Draft SMF for MANET November 2007
2. Introduction and Scope
MANET unicast routing protocol designs have demonstrated effective
and efficient mechanisms to flood routing control plane packets
throughout a wireless routing region. For example, algorithms
specified within [RFC3626]and [RFC3684] provide distributed methods
of dynamically electing reduced relay sets that attempt to optimize
control packet flooding of routing control packets amongst MANET
routing peers. Simplified Multicast Forwarding (SMF) extends the
efficient flooding concept to the forwarding plane for IP multicast
packets. When localized, efficient flooding is deemed an effective
technique, SMF provides an appropriate multicast forwarding
capability. The SMF baseline design limits the scope to basic, best
effort multicast forwarding intended to be constrained within a MANET
or wireless mesh routing region. The main design goals of this SMF
specification are to adapt efficient relay sets in MANET environments
[RFC2901] and define the needed IPv4 and IPv6 multicast duplicate
packet detection (DPD) mechanisms to support multi-hop, packet
forwarding. Figure 1 provides an overview of the logical SMF node
architecture, consisting of "Neighborhood Discovery", "Relay Set
Selection" and "Forwarding Process" components. Typically, relay set
selection (or self-election) will occur based on input from a
neighborhood discovery process, and the forwarding process will be
controlled by status based upon relay set selection. Note the
neighborhood discovery and/or relay set selection information MAY be
obtained from a coexistent process (e.g., MANET unicast routing
protocol using relay sets). In some cases, the forwarding decision
for a packet can also depend on previous hop or incoming interface
information. The asterisks (*) in Figure 1 mark the primitives and
relationships needed by relay set algorithms requiring previous-hop
packet forwarding knowledge.
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 5]
Internet-Draft SMF for MANET November 2007
______________ _____________
| | | |
| Neighborhood | | Relay Set |
| Discovery |------------->| Selection |
| Protocol | neighbor | Algorithm |
|______________| info |_____________|
\ /
\ /
neighbor\ /forwarding
info* \ ____________ / status
\ | | /
`-->| Forwarding |<--'
| Process |
~~~~~~~~~~~~~~~~~>|____________|~~~~~~~~~~~~~~~~~>
incoming packet, forwarded packets
interface id, and
previous hop*
Fig. 1 - SMF Node Architecture
Interoperable SMF implementations MUST use a common DPD approach and
be able to process the header options defined in this document for
IPv6 operation. We define Classical Flooding (CF), as the simplest
case of SMF multicast forwarding. With CF, each SMF router forwards
each received packet once. In this case, the need for any relay set
selection or neighborhood topology information is eliminated but DPD
is still required. While CF may be used, in general practice, a form
of efficient relay set selection is RECOMMENDED. An efficient,
reduced relay set is realized by selecting a _subset_ of all possible
SMF routers in a MANET routing region as the forwarding relay set.
Known relay set selection algorithms have demonstrated the ability to
provide and maintain a dynamic distribution mesh for forwarding user
multicast data [MDC04]. A few such relay set selection algorithms
are described in the Appendices of this document and the basic
designs borrow directly from previous work. Additional relay set
algorithms or extensions may be specified in the future for use with
SMF.
Dynamic neighborhood topology information is needed to determine and
maintain an optimized set of relay (forwarding) nodes. Neighborhood
topology discovery functions MAY be externally provided by a MANET
unicast routing protocol or by using the MANET NeighborHood Discovery
Protocol (NHDP) [NHDP] running in concurrence with SMF.
Additionally, this specification does not preclude a lower protocol
layer from providing necessary neighborhood information.
Fundamentally, an SMF implementation SHOULD provide the ability for
multicast forwarding state to be dynamically managed per operating
network interface. Some of the relay state maintenance options and
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 6]
Internet-Draft SMF for MANET November 2007
interactions are outlined later in Section 6. This document states
specific requirements for neighborhood discovery with respect to the
forwarding process and relay set selection algorithms described
herein. In the absence of a MANET unicast protocol or lower layer
information interface, SMF relies on the MANET NHDP specification to
assist in 2-hop neighborhood state discovery and maintenance for
relay set election when not operating in a CF mode.
2.1. Abbreviations
MANET : Mobile Ad hoc Network
SMF : Simplified Multicast Forwarding
CF : Classical Flooding
CDS : Connected Dominating Set
MCDS : Minimum Connected Domination Set
MPR : Multi-point Relay
S-MPR: Source-based MPR
CDS-MPR: CDS-based MPR
E-CDS: Essential Connected Dominating Set
DPD: Duplicate Packet Detection
NHDP: Neighborhood Discovery Protocol
I-DPD: Identification-based Duplicate Packet Detection
H-DPD: Hash-based Duplicate Packet Detection
HAV: Hash Assist Value
FIB: Forwarding Information Base
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 7]
Internet-Draft SMF for MANET November 2007
3. Applicability
Within dynamic, mobile routing topologies, maintaining traditional
forwarding trees to support a multicast routing protocol MAY not be
sensible or needed. A basic packet forwarding service that reaches
all MANET SMF routers participating within a localized MANET routing
region MAY provide a useful group communication mechanism for various
classes of applications. Applications that could take advantage of a
simple multicast forwarding service within a MANET routing region
include multimedia streaming, interactive group-based messaging and
applications, peer-to-peer middleware multicasting, and multi-hop
mobile discovery or registration services.
Note again that Figure 1 provides a notional architecture for
_typical_ MANET SMF-capable nodes. However, a goal is that simple
end-system (non-forwarding) wireless nodes may also participate in
multicast traffic transmission and reception with standard IP network
layer semantics (e.g., special or unnecessary encapsulation of IP
packets should be avoided in this case). A multicast border router
or proxy mechanism MUST be used when deployed alongside more fixed-
infrastructure IP multicast routing such Protocol Independent
Multicast (PIM) variants [RFC3973] and [RFC4601]. With present
experimental implementations, proxy methods have demonstrated gateway
functionality at MANET border routers operating with external IP
multicast routing protocols. SMF may be extended or combined with
other mechanisms to provide increased reliability and group specific
filtering, but the details for this are not discussed here.
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 8]
Internet-Draft SMF for MANET November 2007
4. SMF Packet Processing and Forwarding
The SMF Packet Processing and Forwarding actions are conducted with
the following packet handling activities:
1. Processing of outbound, locally-generated multicast packets.
2. Reception and processing of inbound packets on a specific network
interface(s).
The purpose of intercepting outbound, locally-generated multicast
packets is to enforce any of the DPD requirements described later so
that proper forwarding may be conducted.
Inbound multicast packets will be received by the SMF implementation
and processed for possible forwarding. This document does not
presently support forwarding of directed broadcast addresses
[RFC2644]. SMF implementations MUST be capable of forwarding packets
for "global scope" multicast groups to support generic multicast
application needs or to distribute designated multicast traffic that
ingresses the MANET routing region via border routers. The set of
destination addresses to be forwarded will be maintained by an _a
priori_ list or a dynamic forwarding information base (FIB) that may
interact with future MANET dynamic group membership extensions.
There will be a well-known multicast group for flooding to all SMF
forwarders. This multicast group is specified to contain all MANET
SMF routers of a connected MANET routing region, so that packets
transmitted to the multicast address associated with the group will
be delivered to all connected SMF routers. For IPv6, the multicast
address is specified to be "site-local". The name of the multicast
group is "SL-MANET-ROUTERS". Minimally SMF SHALL forward, as
instructed by the relay set selection algorithm, unique (non-
duplicate) packets received for this well-known group address when
the TTL or hop count value in the IP header is greater than 1. SMF
SHALL forward all additional global scope addresses specified within
the FIB as well. In all cases, the following rules SHALL be observed
for SMF multicast forwarding:
1. Multicast packets with TTL <= 1 MUST NOT be forwarded*.
2. Link local multicast packets MUST NOT be forwarded.
3. Incoming multicast packets with an IP source address matching one
of those of the local SMF router interface(s) MUST NOT be
forwarded.
4. Received packet frames with the MAC source address matching the
local SMF router interface(s) MUST NOT be forwarded.
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 9]
Internet-Draft SMF for MANET November 2007
5. Received packets for which SMF cannot reasonably ensure temporal
DPD uniqueness MUST NOT be forwarded.
6. When packets are forwarded, TTL or hop limit SHALL be decremented
by one.
Note that rule #3 is important because in wireless networks, the
local SMF router may receive re-transmissions of its own packets when
they are forwarded by neighboring nodes. This rule avoids
unnecessary retransmission of locally-generated packets even when
other forwarding decision rules would apply.
As mentioned in Section 10, there may be concern in some SMF
deployments that bad-behaving nodes could conduct a denial-of-service
attack by remotely "previewing" (e.g., via a directional receive
antenna) packets that an SMF node would be forwarding and conduct a
"pre-play" attack by transmitting the packet before the SMF node
would otherwise receive it but with a reduced TTL (or Hop Limit)
field value. This form of attack could cause an SMF node to create a
DPD entry that would block the proper forwarding of the valid packet
(with correct TTL) through the SMF area. A RECOMMENDED approach to
prevent this attack, when it is a concern, would be to cache temporal
packet TTL values along with the DPD state (hash value(s) and/or
identifier). Then, if a subsequent matching (with respect to DPD)
packet arrives with a _larger_ TTL value than the packet that was
previously forwarded, then SMF should forward the new packet _and_
update the TTL cached with corresponding DPD state to the new, larger
TTL value. There may be some isolated, temporary cases where SMF may
unnecessarily forward some duplicate packets using this approach, but
those case are expected to be exceptional.
Once these criteria have been met, an SMF implementation MUST examine
a forwarding decision algorithm to determine the next steps in packet
processing. If the SMF implementation is operating in a classical
flooding (CF) mode the forwarding decision is implicit after DPD
uniqueness is determined. Otherwise, a forwarding decision requires
additional information, including interface specific relay set state.
Relay set selection algorithms described later MAY be used to
determine the local SMF router's status with respect to forwarding.
Some algorithms control forwarding based on a relay set election and
previous hop identifier (e.g. S-MPR forwarding), while others
designate the local SMF router as a forwarder of all neighbor packets
based on the neighborhood topology (e.g. Essential CDS (E-CDS) and
MPR-CDS). A specific SMF node within a deployment may perform
redundant forwarding, but each forwarder MUST at a minimum support a
distributed election process that ensures a consistent dynamic CDS.
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 10]
Internet-Draft SMF for MANET November 2007
5. SMF Duplicate Packet Detection
Duplicate packet detection (DPD) is a common requirement in MANET
packet flooding because packets may be forwarded out the same
physical interface upon which they arrived and nodes may also receive
copies of previously-transmitted packets from other forwarding
neighbors. SMF implementations MUST detect and avoid forwarding
duplicate multicast packets using a temporal packet identification
scheme. It is RECOMMENDED this be implemented by keeping a history
of recently-processed multicast packets for comparison to incoming
packets. For both IPv4 and IPv6, this document describes two basic
approaches to multicast duplicate packet detection: header content
identification-based (I-DPD) and hash-based (H-DPD) duplicate
detection. The two approaches are described for experimental
purposes. Trade-offs of the two approaches to DPD may merit
different consideration depending upon specific SMF deployment
scenarios. Because of the potential addition of a hop-by-hop option
header with IPv6, SMF deployments MUST be configured to use a common
mechanism and DPD algorithm. The main difference between IPv4 and
IPv6 SMF DPD specification is the avoidance of any additional header
options or encapsulation in the IPv4 case.
For each network interface, SMF implementations MUST maintain DPD
packet state as needed to support the forwarding heuristics of the
relay set algorithm used. The specific requirements of several relay
set selection algorithms and their forwarding rules are described in
the Appendices of this document. In general this involves keeping
track of previously forwarded packets so that duplicates are not
forwarded, but some relay techniques (e.g., S-MPR) may have
additional considerations.
For I-DPD, packets are identified using explicit identifiers from the
IP header. The specific identifier to use depends upon the IP
protocol version and the type of packet. For example, IPv4 provides
an "Identification" field that may be used for DPD purposes, and
packets that contain IPSec protocol headers also provide a suitable
packet identifier. These identifier fields are unique within the
context of source address, destination address, protocol type, and/or
other header fields depending upon the type of identifier used for
DPD. Similarly, for H-DPD, it is expected that packet hash values
will be kept with respect to at least the source address to help
ensure hash collision avoidance. SMF implementations MUST maintain
DPD history per the applicable packet flow context (e.g., <protocol:
srcAddr:dstAddr> for DPD based upon IPv4 ID). The details for I-DPD
and H-DPD for different types of packets are described in the
sections below. In either case, this history SHOULD be kept long
enough to span the maximum network traversal lifetime,
MAX_PACKET_LIFETIME, of multicast packets being forwarded within an
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 11]
Internet-Draft SMF for MANET November 2007
SMF operating area. The required size of the DPD cache is governed
by this timeout value and is also a function of the packet forwarding
rates. The DPD mechanism SHOULD avoid keeping unnecessary state for
packet flows such as those that are locally-generated or link local
destinations that would not be considered for forwarding.
5.1. IPv6 Duplicate Packet Detection
This section describes the mechanisms and options for SMF IPv6 DPD.
The core IPv6 packet header does not provide any explicit
identification header field that can be exploited for I-DPD. The
following areas are described to support IPv6 DPD:
1. a hop-by-hop SMF-DPD option header (with supporting identifier or
hash assistance value),
2. the use of IPv6 fragment header fields for I-DPD when they exist,
3. the use of IPSec sequencing for I-DPD when a non-fragmented,
IPSec header is detected, and
4. an H-DPD approach assisted, as needed, by the SMF-DPD option
header.
SMF MUST provide a DPD marking module that can insert the hop-by-hop
IPv6 header option defined in this section. This process MUST come
after any source-based fragmentation that may occur with IPv6. As
with IPv4, SMF IPv6 DPD is presently specified to allow either a
packet hash or header identification method for DPD. An SMF
implementation MUST be configured to operate either in H-DPD or I-DPD
mode and perform the appropriate routines outlined in the following
sections.
5.1.1. IPv6 SMF-DPD Header Option
As previously mentioned, the base IPv6 packet header does not contain
a unique identifier suitable for DPD. This section defines an IPv6
hop-by-hop header option to serve this purpose for IPv6 I-DPD.
Additionally, the header option provides an opportunity to help
guarantee non-collision of hash values for different packets when
H-DPD is used. This header option format supports both of these
purposes.
The first bit of the data field of the SMF-DPD option is the "H-bit"
that determines the format of the data field. Two different formats
are supported. When the "H-bit" is cleared (zero value), the SMF-DPD
format to support I-DPD operation is specified as shown in Figure 5
and defines the extension header in accordance with [RFC2460].
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 12]
Internet-Draft SMF for MANET November 2007
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... |0|0|0| OptType | Opt. Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|TidTyp|TidLen| TaggerId (optional) ... |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig. 5 - IPv6 SMF-DPD Header Option in I-DPD mode
The "TidType" is a 3-bit field indicating the presence and type of
the optional "TaggerId" field. The optional "TaggerId" is used to
differentiate multiple ingressing border gateways that may commonly
apply the SMF-DPD option header to packets from a particular source.
This is provided for experimental purposes. The following table
lists the valid TaggerId types:
+---------+-------+-------------------------------------------------+
| Name | Value | Purpose |
+---------+-------+-------------------------------------------------+
| NULL | 0 | Indicates no "taggerId" field is present. |
| | | "TidLen" MUST also be set to ZERO. |
| | | |
| DEFAULT | 1 | A "TaggerId" of non-specific context is |
| | | present. "TidLen + 1" defines the length of |
| | | the TaggerId field in bytes. |
| | | |
| IPv4 | 2 | A "TaggerId" representing an IPv4 address is |
| | | present. The "TidLen" MUST be set to 3. |
| | | |
| IPv6 | 3 | A "TaggerId" representing an IPv6 address is |
| | | present. The "TidLen" MUST be set to 15. |
| | | |
| ExtId | 7 | RESERVED FOR FUTURE USE (possible extended ID) |
+---------+-------+-------------------------------------------------+
This format allows a quick check of the "TidType" field to determine
if a "TaggerId" field is present. If the <TidType> is NULL, then the
length of the DPD packet <Identifier> field corresponds to the (<Opt.
Data Len> - 1). If the <TidType> is non-NULL, then the length of the
"TaggerId" field is equal to (<TidLen> - 1) and the remainder of the
option data comprises the DPD packet <Identifier> field. When the
"TaggerId" field is present, the <Identifier> field can be considered
a unique packet identifier in the context of the <taggerId:srcAddr:
dstAddr> tuple. When the "TaggerId" field is not present, then it is
assumed the source host applied the SMF-DPD option and the
<Identifier> can be considered unique in the context of the IPv6
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 13]
Internet-Draft SMF for MANET November 2007
packet header <srcAddr:dstAddr> tuple. Details on IPV6 I-DPD
operation are described in Section 5.1.2.
When the "H-bit" in the SMF-DPD option data is set, the data content
value is interpreted as a Hash-Assist Value (HAV) used to facilitate
H-DPD operation. In this case, source hosts or ingressing gateways
apply the SMF-DPD with a HAV only when required to differentiate the
hash value of a new packet with respect to older packets in the
current DPD history cache. This helps to guarantee the uniqueness of
generated hash values when H-DPD is used. Additionally, this also
avoids the added overhead of applying the SMF-DPD option header to
every packet. For many hash algorithms, it is expected that only
sparse use of the SMF-DPD option may be required. The following
table illustrates the format of the SMF-DPD header option for H-DPD
operation:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... |0|0|0| OptType | Opt. Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Hash Assist Value (HAV) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig. 6 - IPv6 SMF-DPD Header Option in H-DPD mode
The SMF-DPD option should be applied with a HAV to produce a unique
hash digest for packets within the context of the IPv6 packet header
<srcAddr>. The size of the HAV field is implied by the "Opt. Data
Len". The appropriate size of the field depends upon the collision
properties of the specific hash algorithm used. More details on IPv6
H-DPD operation are provided in Section 5.1.3.
5.1.2. IPv6 Identification-based DPD Operation
The following table summarizes the IPv6 I-DPD processing approach.
Within the table '*' indicates a don't care condition.
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 14]
Internet-Draft SMF for MANET November 2007
IPv6 I-DPD Processing Rules
+-------------+-----------+-----------+-----------------------------+
| IPv6 | IPv6 | IPv6 | SMF IPv6 I-DPD Mode Action |
| Fragment | IPSEC | I-DPD | |
| Header | Header | Header | |
+-------------+-----------+-----------+-----------------------------+
| Present | * | * | Use Fragment Header I-DPD |
| | | | Check and Process for |
| | | | Forwarding |
| | | | |
| Not Present | Present | * | Use IPSEC Header I-DPD |
| | | | Check and Process for |
| | | | Forwarding |
| | | | |
| Present | * | Present | Invalid, do not Forward |
| | | | |
| Not Present | Present | Present | Invalid, do not Forward |
| | | | |
| Not Present | Not | Not | Add I-DPD Header,and |
| | Present | Present | Process for Forwarding |
| | | | |
| Not Present | Not | Present | Use I-DPD Header Check and |
| | Present | | Process for Forwarding |
+-------------+-----------+-----------+-----------------------------+
If the IPv6 multicast packet is an IPv6 fragment, SMF MUST use the
fragment extension header fields for packet identification. This
identifier can be considered unique in the context of the <srcAddr:
dstAddr> of the IP packet. If the packet is an unfragmented IPv6
IPSEC packet, SMF MUST use IPSec fields for packet identification.
The IPSec header <sequence> field can be considered a unique
identifier in the context of the <IPSecType:srcAddr:dstAddr:SPI>
where the "IPSecType" is either AH or ESP. For unfragmented, non-
IPSec, IPv6 packets, the use of the SMF DPD header option is
necessary to support I-DPD operation. The SMF DPD header option is
applied in the context of the <srcAddr> of the IP packet. End
systems or ingressing SMF gateways are responsible for applying this
option to support DPD. The following table summarizes these packet
identification types:
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 15]
Internet-Draft SMF for MANET November 2007
*IPv6 I-DPD Packet Identification Types*
+-----------+---------------------------------+---------------------+
| IPv6 | Packet DPD ID Context | Packet DPD ID |
| Packet | | |
| Type | | |
+-----------+---------------------------------+---------------------+
| Fragment | <srcAddr:dstAddr> | <fragmentOffset:id> |
| | | |
| IPSec | <IPSecType:srcAddr:dstAddr:SPI> | <sequence> |
| Packet | | |
| | | |
| Regular | <[taggerId:]srcAddr:dstAddr> | <SMF-DPD option |
| Packet | | header id> |
+-----------+---------------------------------+---------------------+
"IPSecType" is either Authentication Header (AH) or Encapsulating
Security Payload (ESP).
The "taggerId" is an optional feature of the IPv6 SMF-DPD header
option.
5.1.3. IPv6 Hash-based DPD Operation
A default hash-based DPD approach (H-DPD) for use by SMF is specified
as follows. An MD5 [RFC1321] hash of the non-mutable header fields,
options fields, and data content of the IPv6 multicast packet is used
to produce a 128-bit digest. The lower 64 bits of this digest
(MD5_64) is used for SMF packet identification. The approach for
calculating this hash value SHOULD follow the same guidelines
described for calculating the Integrity Check Value (ICV) described
in [RFC4302] with respect to non-mutable fields. This approach
should have a reasonably low probability of digest collision when
packet headers and content are varying. MD5 is being applied in SMF
only to provide a low probability of collision and is not being used
for cryptographic or authentication purposes. A history of the
packet hash values SHOULD be maintained within the context of the
IPv6 packet header <srcAddr>. This history is used by forwarding SMF
nodes (non-ingress points) to avoid forwarding duplicates. SMF
ingress points (i.e., source hosts or gateways) use this history to
confirm that new packets are unique with respect to their hash value.
The Hash-assist Value (HAV) field described in Section 5.1.1 is
provided as a differentiating field when a digest collision would
otherwise occur. Note that the HAV is an immutable option field and
SMF MUST use any included H-DPD hash assist value (HAV) option header
(see Section 5.1.1) in its hash calculation.
If a packet results in a digest collision (i.e., by checking the
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 16]
Internet-Draft SMF for MANET November 2007
H-DPD digest history) within the limited history kept by SMF
forwarders, the packet should be silently dropped. If a digest
collision is detected at an SMF ingress point (i.e., including SMF-
aware sources), the H-DPD option header is applied with a HAV. The
packet is retested for collision and the HAV is re-applied as needed
to produce a non-colliding hash value. The multicast packet is then
forwarded with the added IPv6 SMF-DPD header option.
The MD5 indexing and IPv6 HAV approaches are specified at present for
consistency and robustness to suit experimental application. Future
approaches and experimentation may discover designs tradeoffs in hash
robustness and efficiency worth considering. This MAY include
reducing the maximum payload length that is processed, determining
shorter indexes, or applying more efficient hashing algorithms. Use
of the HAV may allow for application of "lighter-weight" hashing
techniques that might have been not considered due to poor collision
properties otherwise.
5.2. IPv4 Duplicate Packet Detection
This section describes the mechanisms and options for IPv4 DPD. The
IPv4 packet header 16-bit "Identification" field MAY be used for DPD,
but its limitations may require alternative approaches in some
situations. The following areas are described to support IPv4 DPD::
1. the use of IPv4 fragment header fields for I-DPD when they exist,
2. the use of IPSec sequencing for I-DPD when a non-fragmented IPv4
IPSec packet is detected, and
3. a H-DPD approach.
A specific SMF-DPD marking option is not specified for IPv4 since
header options are not as tractable for end systems as for IPv6.
IPv4 packets from a particular source are assumed to be marked with a
temporally unique value in the "Identification" field of the packet
header that can serve for SMF DPD purposes. However, in present
operating system networking kernels, the IPv4 header "Identification"
value is not always generated properly, especially when the "don't
fragment" (DF) bit is set. The IPv4 I-DPD mode of this specification
requires that IPv4 "Identification" fields are managed reasonably by
source hosts and that temporally unique values are set within the
context of the packet header <protocol:srcAddr:dstAddr> tuple. If
this is not expected during an SMF deployment, then it is RECOMMENDED
that the H-DPD method be used as a more reliable approach.
Since IPv4 SMF does not specify an options header, the
interoperability constraints are looser than the IPv6 version and
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 17]
Internet-Draft SMF for MANET November 2007
forwarders may be operate with mixed H-DPD and I-DPD modes as long as
they consistently perform the appropriate DPD routines outlined in
the following sections. However, it is RECOMMENDED that a deployment
be configured with a common mode for operational consistency.
5.2.1. IPv4 Identification-based DPD Operation
The following table summarizes the IPv4 I-DPD processing approach
once a packet has passed the basic forwardable criteria described in
earlier SMF sections. Within the table '*' indicates a don't care
condition.
+----+----+----------+---------+------------------------------------+
| df | mf | fragment | IPSEC | IPv4 I-DPD Action |
| | | offset | | |
+----+----+----------+---------+------------------------------------+
| 1 | 1 | * | * | Invalid, Do Not Forward |
| | | | | |
| 1 | 0 | nonzero | * | Invalid, Do Not Forward |
| | | | | |
| * | 0 | zero | not | Tuple I-DPD Check and Process for |
| | | | Present | Forwarding |
| | | | | |
| * | 0 | zero | Present | IPSEC enhanced Tuple I-DPD Check |
| | | | | and Process for Forwarding |
| | | | | |
| 0 | 0 | nonzero | * | Extended Fragment Offset Tuple |
| | | | | I-DPD Check and Process for |
| | | | | Forwarding |
| | | | | |
| 0 | 1 | zero or | * | Extended Fragment Offset Tuple |
| | | nonzero | | I-DPD Check and Process for |
| | | | | Forwarding |
+----+----+----------+---------+------------------------------------+
For performance reasons, IPv4 network fragmentation and reassembly of
multicast packets within wireless MANET networks should be minimized,
yet SMF provides the forwarding of fragments when they occur. If the
IPv4 multicast packet is a fragment, SMF MUST use the fragmentation
header fields for packet identification. This identification can be
considered temporally unique in the context of the <protocol:srcAddr:
dstAddr> of the IPv4 packet. If the packet is an unfragmented IPv4
IPSEC packet, SMF MUST use IPSec fields for packet identification.
The IPSec header <sequence> field can be considered a unique
identifier in the context of the <IPSecType:srcAddr:dstAddr:SPI>
where the "IPSecType" is either AH or ESP. Finally, for
unfragmented, non-IPSec, IPv4 packets, the "Identification" field can
be used for I-DPD purposes. The "Identification" field can be
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 18]
Internet-Draft SMF for MANET November 2007
considered unique in the context of the IPv4 <protocol:scrAddr:
dstAddr> tuple. The following table summarizes these packet
identification types:
*IPv4 I-DPD Packet Identification Types*
+-----------+---------------------------------+---------------------+
| IPv4 | Packet Identification Context | Packet Identifier |
| Packet | | |
| Type | | |
+-----------+---------------------------------+---------------------+
| Fragment | <protocol:srcAddr:dstAddr> | <fragmentOffset:id> |
| | | |
| IPSec | <IPSecType:srcAddr:dstAddr:SPI> | <sequence> |
| Packet | | |
| | | |
| Regular | <protocol:srcAddr:dstAddr> | <id> |
| Packet | | |
+-----------+---------------------------------+---------------------+
"IPSecType" is either Authentication Header (AH) or Encapsulating
Security Payload (ESP).
The limited size (16 bits) of the IPv4 header "Identification" field
may result in the value rapidly wrapping, particularly if a common
sequence space is used by a source for multiple destinations. If
I-DPD operation is required, the use of the "internal hashing"
technique described in Section 5.3 may mitigate this limitation of
the IPv4 "Identification" field for SMF DPD. In this case the
"internal hash" value would be concatenated with the "Identification"
value for I-DPD operation.
5.2.2. IPv4 Hash-based DPD Operation
To ensure consistent IPv4 H-DPD operation among SMF nodes, a default
hashing approach is specified. This is similar to that specified for
IPv6, but the H-DPD header option with HAV is not considered. SMF
MUST perform an MD5 [RFC1321] hash of the immutable header fields,
option fields and data content of the IPv4 multicast packet resulting
in a 128-bit digest. The lower 64 bits of this digest (MD5_64) is
used for SMF packet identification. The approach for calculating the
hash value SHOULD follow the same guidelines described for
calculating the Integrity Check Value (ICV) described in [RFC4302]
with respect to non-mutable fields. A history of the packet hash
values SHOULD be maintained in the context of <protocol:srcAddr:
dstAddr>. The context for IPv4 is more specific than that of IPv6
since the SMF-DPD HAV cannot be employed to mitigate hash collisions.
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 19]
Internet-Draft SMF for MANET November 2007
The MD5 hash is specified at present for consistency and robustness.
Future approaches and experimentation may discover designs tradeoffs
in hash robustness and efficiency worth considering for future
versions of SMF. This MAY include reducing the packet payload length
that is processed, determining shorter indexes, or applying a more
efficient hashing algorithm.
5.3. Internal Hash Computation
Forwarding protocols that use DPD techniques, such as SMF, may be
vulnerable to denial-of-service (DoS) attacks based on spoofing
packets with apparently valid packet identifier fields. Such a
consideration is pointed out in Section 10. In wireless environments
where SMF will most likely be used, the opportunity for badly-
behaving nodes to conduct such attacks is more prevalent than in
wired networks. In the case of IPv4 packets, fragmented IP packets
or packets with IPSec headers applied, the DPD "identifier" of
potential future packets that might be forwarded is very predictable
and easily subject to denial-of-service attacks against forwarding.
A RECOMMENDED technique to counter this concern is for SMF
implementations to generate an "internal" hash value that is
concatenated with the explicit I-DPD packet identifier to form a
unique identifier that is a function of the packet content as well as
the visible identifier. SMF implementations could seed their hash
generation with a random value to make it unlikely that an external
observer could guess how to spoof packets used in a denial-of-service
attack against forwarding. Since the hash computation and state is
kept completely internal to SMF nodes, the cryptographic properties
of this hashing would not need to be extensive and thus possibly of
low complexity. Experimental implementations may determine that a
lightweight hash of even only portions of packets may suffice to
serve this purpose.
For IPv4 I-DPD based on the limited 16-bit "Identification" field, it
is possible that use of this "internal hash" technique may also
enhance I-DPD performance in cases where the IPv4 "Identification"
field may wrap quickly due to the source supporting high data rate
flows.
While H-DPD is not as readily susceptible to this form of DoS attack,
it is possible that a sophisticated adversary could use side
information to construct spoofing packets to mislead forwarders using
a well-known hash algorithm. Thus, similarly, a separate "internal"
hash value could be concatenated with the well-known hash value to
alleviate this security concern.
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 20]
Internet-Draft SMF for MANET November 2007
6. Reduced Relay Set Forwarding and Relay Selection Capability
SMF MUST support CF-based forwarding as a basic forwarding mechanism
when reduced relay set information is not available or not selected
for operation. In CF mode, each node transmits a locally generated
or newly received packet exactly once. The DPD techniques described
in Section 5 are critical to proper operation and prevent duplicate
packet retransmissions by the same forwarding node.
A goal of SMF is to apply reduced relay sets for more efficient
multicast dissemination within dynamic topologies. To accomplish
this SMF MUST support the ability to modify its multicast packet
forwarding rules based upon relay set state received dynamically
during operation. In this way, SMF forwarding can continue to
operate effectively as neighbor adjacencies or multicast forwarding
policies within the topology change.
In early SMF experimental deployments, the relay set information has
been derived from a coexistent unicast MANET protocol calculation of
a reduced relay set for control plane traffic. From this experience,
extra pruning considerations are sometimes required when utilizing a
relay set from a independent routing protocol process, since a relay
set formed for the unicast control plane flooding MAY include a more
redundant set of nodes than desired for multicast forwarding use
(e.g., biconnected control plane CDS meshes).
Here is a recommended criteria list for relay set selection algorithm
candidates:
1. Robustness to topological dynamics and mobility
2. Localized election or coordination of any relay sets
3. Heuristic support for preference or election metrics (Better
enables scenario-specific management of relay set)
Some relay set algorithms meeting these criteria are described in the
Appendices of this document. Different algorithms may be more
suitable for different MANET routing types or deployments.
Additional relay set selection algorithms may be specified in
separate specifications in the future. The Appendices in this
document can serve as a template for the content of such potential
future specifications.
Figure 7 depicts a state information diagram of possible relay set
control options. There are basically three style of SMF operation
with reduced relay sets as follows.
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 21]
Internet-Draft SMF for MANET November 2007
1. Unicast dependent operation with a coexisting MANET unicast
routing protocol in which the relay set state is derived from the
unicast control plane CDS information.
2. Unicast independent operation in which SMF performs its own Relay
Set Selection and derives dynamic neighborhood information from a
MANET NHDP process. In this case, additional TLV definitions for
related CDS collection SHOULD be used as discussed in Section 7.
3. Possible crosslayer implementation that uses L2 neighborhood
information and possible triggers to assist the dynamic relay set
selection and maintenance process.
Possible L2 Trigger/Information
|
|
______________ _______v_____ __________________
| MANET | | | | |
| Neighborhood | | Relay Set | | Other Heuristics |
| Discovery |------------->| Selection |<------| (Preference,etc) |
| Protocol | neighbor | Algorithm | | |
|______________| info |_____________| |__________________|
\ /
\ /
neighbor\ / Dynamic Relay
info* \ ____________ / Set Status
\ | SMF | / (State, {neighbor info})
`-->| Relay Set |<--'
| State |
-->|____________|
/
/
______________
| Coexistent |
| MANET |
| Unicast |
| Process |
|______________|
Fig. 7 - SMF Relay Set Control Options
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 22]
Internet-Draft SMF for MANET November 2007
7. SMF Neighborhood Discovery Requirements
In absence of a compatible, coexisting unicast routing protocol or
lower layer protocol providing neighborhood topology information
sufficient for relay set selection, this section defines the issues
and additional requirements for a MANET Neighborhood Discovery
Protocol (NHDP) that MAY be used by SMF nodes.
With respect to neighborhood topology knowledge and/or discovery,
there are three basic modes of SMF operation:
1. Classical Flooding (CF) mode: with no requirements for discovery
or knowledge of neighborhood topology,
2. External CDS control mode: an external process dynamically
determines the local SMF relay status (e.g., SMF prototypes have
leveraged neighborhood topology information collected by MANET
unicast routing protocol instantiations), and
3. Independent CDS control mode: SMF uses the MANET Neighborhood
Discovery Protocol (NHDP) [NHDP] to collect localized link
information required for the various CDS algorithm modes
discussed in the Appendices.
Core NHDP messages and the neighborhood information base are
described separately within the NHDP specification (IETF work in
progress). In this mode, SMF uses and relies upon an implementation
of NHDP. The NHDP protocol provides the following basic functions:
1. 1-hop Neighbor link sensing: maintaining neighbor lists and
performing bidirectionality checks of neighbor links
2. 2-hop Neighborhood Discovery: collecting 2-hop bidirectional
neighborhood information and any information relevant to relay
set election
3. The collection and maintenance of the above information across
multiple interfaces.
4. Relay Set Signaling: signal relay set selection to neighbor nodes
if the relay set algorithm requires such information
The Appendices discuss a set of implemented SMF CDS approaches that
may be needed by an NHDP implementation to support each approach.
The following subsections define TLVs consistent with [PacketBB]that
SHOULD be used when deploying SMF in Independent CDS control mode.
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 23]
Internet-Draft SMF for MANET November 2007
7.1. SMF Relay Set Algorithm ID Message TLV
The following TLV, SMF_RELAYALG_ID, is used within NHDP messages to
provide an indicator of the operating relay set selection algorithm.
When NHDP messages are used by SMF for independent CDS control mode a
SMF_RELAYALG_ID TLV SHOULD be included. Nodes receiving a NHDP
message with a SMF_RELAYALG_ID value differing from its own type the
entire message SHOULD NOT be used for relay set processing.
type=SMF_RELAYALG_ID, length=1 byte, value = <id>
<id> is an 8 bit value identifying the present relay algorithm of the
SMF node represented by the originator address of the NHDP message.
Values are defined in Table 6. The table provides present value
assignments, future IANA reserved space, and an experimental space.
Experimental space use MUST not assume uniqueness properties and
should be used only for experimentation prior to any IANA
assignment..
+---------------------+----------------------------------------+
| Value | Algorithm |
+---------------------+----------------------------------------+
| 0 | S-MPR |
| | |
| 1 | E-CDS |
| | |
| 2 | MPR-CDS |
| | |
| 3-127 | Reserved for Future Assignment |
| | |
| 128-255 | Experimental Space |
+---------------------+----------------------------------------+
Table 6
7.2. Router Priority Message TLV
For some relay set election operations, a value of Router Priority
(RtrPri) must be given or assumed for each address with the two-hop
neighborhood which is consistent for all nodes. More specific
discussions are provided in the Appendices.
The following TLV communicates router priority values among 1-hop
router neighbors.
type=SMF_RTR_PRI, length=1 byte, value = <priority>
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 24]
Internet-Draft SMF for MANET November 2007
<priority> is an 8 bit field which contains a number 0-255 which
represents RtrPri value of the node represented by the originator
address of the NHDP message.
Message TLVs of type SMF_RTR_PRI SHOULD only be used within NHDP
messages.
7.3. Router Priority Address Block TLV
For some relay set election operations, a value of Router Priority
(RtrPri) must be given or assumed for each address with the two-hop
neighborhood that is consistent for all nodes. More specific
discussions are provided in the Appendices.
The following TLV is defined to support the communication of router
priority values between 2-hop router neighbors. When generating
address block TLV router priority messages the RtrPri values included
MUST be consistent with advertised values contained within previously
received router priority message TLVs.
type=SMF_RTR_PRI, length=<num_addresses> bytes, value = <priorities>
<num_addresses> is the number of addresses which the TLV applies to.
This value MUST be consistent with the TLV semantics, length, and
index fields.
<priorities> is a single or multivalue field containing a <priority>
value field for each node represented by the address(es) the TLV
applies to.
+---------------------+-------+-------------------------------------+
| Mnemonic | Value | Description |
+---------------------+-------+-------------------------------------+
| SMF_ALGORITHM_ID | TBD | A message TLV which contains the an |
| | | id value representing the algorithm |
| | | being used by the originator |
| | | address in the NHDP message |
| | | |
| SMF_ROUTER_PRIORITY | TBD | A message TLV or address block TLV |
| | | which contains a router priority |
| | | value for each node represented by |
| | | the associated address(es). |
+---------------------+-------+-------------------------------------+
Table 7
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 25]
Internet-Draft SMF for MANET November 2007
8. SMF Border Gateway Considerations
It is expected that SMF will be used to provide simple forwarding of
multicast traffic _within_ a MANET mesh routing topology. A border
router approach should be used to allow interconnection of SMF areas
with networks using other multicast routing protocols (e.g., PIM).
It is important to note that there are many scenario-specific issues
that should be addressed when discussing border routers. At the
present time, experimental deployments of SMF and PIM border router
approaches are being used.
Some of the functionality border routers may need to address include
the following:
1. Determining which multicast groups should transit the border
router whether entering or exiting the attached MANET routing
region(s).
2. Enforcement of TTL threshold or other scoping policies.
3. Any marking or labeling to enable DPD on ingressing packets.
4. Interface with exterior multicast routing protocols.
5. Possible operation with multiple border routers (presently beyond
scope of this document).
6. Provisions for participating non-SMF nodes.
Note the behavior of border router SMF nodes is the same as that of
non-border SMF nodes when forwarding packets on interfaces within the
MANET routing region. Packets that are passed outbound to interfaces
operating fixed-infrastructure multicast routing protocols SHOULD be
evaluated for duplicate packet status since present standard
multicast forwarding mechanisms do not usually perform this function.
8.1. Forwarded Multicast Groups
Determining which groups should be forwarded into a MANET SMF routing
region is an evolving technology area. Ideally, only groups for
which there is active group membership should be injected into the
SMF domain. This might be accomplished by providing an IPv4 Internet
Group Membership Protocol (IGMP) or IPV6 Multicast Listener Discovery
(MLD) proxy protocol so that MANET SMF nodes can inform attached
border routers (and hence multicast networks) of their current group
membership status. For specific systems and services it may be
possible to statically configure group membership joins in border
routers, but it is RECOMMENDED that some form of IGMP/MLD proxy or
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 26]
Internet-Draft SMF for MANET November 2007
other explicit, dynamic control of membership be provided.
Specification of such an IGMP/MLD proxy protocol is beyond the scope
of this document.
Outbound traffic is less problematic. SMF border routers can perform
duplicate packet detection and forward non-duplicate traffic that
meets TTL/hop limit and scoping criteria to other interfaces.
Appropriate IP multicast routing (PIM, etc) on those interfaces can
then make further forwarding decisions with respect to the given
traffic and its MANET source address. Note that the presence of
multiple border routers associated with a MANET routing region may
create some additional issues. This is further discussed in
Section 8.4.
8.2. Multicast Group Scoping
Multicast scoping is used by network administrators to control the
network routing regions which are reached by multicast packets. This
is usually done by configuring external interfaces of border routers
in the border of an routing region to not forward multicast packets
which must be kept within the routing region. This is commonly done
based on TTL of messages or the basis of group addresses. These
schemes are known respectively as:
1. TTL scoping.
2. Administrative scoping.
For IPv4, network administrators can configure border routers with
the appropriate TTL thresholds or administratively scoped multicast
groups in the router's interfaces as with any traditional multicast
router. However, for the case of TTL scoping it must be taken into
account that the packet could traverse multiple hops within the MANET
SMF routing region before reaching the border router. Thus, TTL
thresholds must be selected carefully.
For IPv6, multicast address spaces include information about the
scope of the group. Thus, border routers of an SMF routing region
know if they must forward a packet based on the IPv6 multicast group
address. For the case of IPv6, it is RECOMMENDED that a MANET SMF
routing region be designated a site. Thus, all IPv6 multicast
packets in the range FF05::/16 SHOULD be kept within the MANET SMF
routing region by border routers. IPv6 packets in any other wider
range scopes (i.e. FF08::/16, FF0B::/16 and FF0E::16) MAY traverse
border routers unless other restrictions different from the scope
applies.
Given that scoping of multicast packets is performed at the border
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 27]
Internet-Draft SMF for MANET November 2007
routers, and given that existing scoping mechanisms are not designed
to work with mobile routers, it is assumed that non-border SMF
routers will not stop forwarding multicast data packets because of
their scope. That is, it is assumed that the entire MANET SMF
routing region is a non-divisible scoping area except in the case of
link-local addresses that are not forwarded by SMF.
8.3. Interface with Exterior Multicast Routing Protocols
The traditional operation of multicast routing protocols is tightly
integrated with the group membership function. Leaf routers are
configured to periodically gather group membership information, while
intermediate routers conspire to create multicast trees connecting
routers with directly-connected multicast sources and routers with
active multicast receivers. In the concrete case of SMF, border
routers can be considered leaf routers. Mechanisms for multicast
sources and receivers to interoperate with border routers over the
multihop MANET SMF routing region as if they were directly connected
to the router need to be defined. The following issues need to be
addressed:
1. Mechanism by which border routers gather membership information.
2. Mechanism by which multicast sources are known by the border
router.
3. Exchange of exterior routing protocol messages across the MANET
routing region if the MANET routing region is to provide transit
connectivity for multicast traffic.
It is beyond the scope of this document to address implementation
solutions to these issues. As described in Section 8.1, IGMP/MLD
proxy mechanisms can be deployed to address some of these issues.
Similarly, exterior routing protocol messages could be tunneled or
conveyed across the MANET routing region. But, because MANET routing
regions are multi-hop and potentially unreliable, as opposed to the
single-hop LAN interconnection that neighboring IP Multicast routers
might typically enjoy, additional provisions may be required to
achieve successful operation.
The need for the border router to receive traffic from recognized
multicast sources within the MANET SMF routing region is important to
achieve a smooth interworking with existing routing protocols. For
instance, PIM-S requires routers with locally attached multicast
sources to register them to the Rendezvous Point (RP) so that other
people can join the multicast tree. In addition, if those sources
are not advertised to other autonomous systems (AS) using MSDP,
receivers in those external networks are not able to join the
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 28]
Internet-Draft SMF for MANET November 2007
multicast tree for that source.
8.4. Multiple Border Routers
A MANET might be deployed with multiple participating nodes having
connectivity to external (to the MANET), fixed-infrastructure
networks. Allowing multiple nodes to forward multicast traffic to/
from the MANET routing region can be beneficial since it can increase
reliability, and provide better service. For example, if the MANET
routing region were to fragment with different MANET nodes
maintaining connectivity to different border routers, multicast
service could still continue successfully. But, the case of multiple
border routers connecting a MANET routing region to external networks
presents several challenges for SMF:
1. Detection/hash collision/sequencing of duplicate unmarked IPv4 or
IPv6 (without IPSec encapsulation or DPD option) packets possibly
injected by multiple border routers.
2. Source-based relay algorithms handling of duplicate traffic
injected by multiple border routers.
3. Determination of which border router(s) will forward outbound
multicast traffic.
4. Additional challenges with interfaces to exterior multicast
routing protocols.
One of the most obvious issues is when multiple border routers are
present and may be alternatively (due to route changes) or
simultaneously injecting common traffic into the MANET routing region
that has not been previously marked for SMF DPD. Different border
routers would not be able to implicitly synchronize sequencing of
injected traffic since they may not receive exactly the same messages
due to packet losses. For IPv6 I-DPD operation, the optional
"TaggerId" field described for the SMF-DPD header option can be used
to mitigate this issue. When multiple border routers are injecting a
flow into a MANET routing region, there are two forwarding policies
that SMF DPD-S nodes may implement:
1. Redundantly forward the multicast flows (identified by
<sourceAddress:destinationAddress>) from each border router,
performing DPD processing on a <taggerID:destinationAddress> or
<taggerID:sourceAddress:destinationAddress> basis, or
2. Use some basis to select the flow of one tagger (border router)
over the others and forward packets for applicable flows
(identified by <sourceAddress:destinationAddress>) only for that
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 29]
Internet-Draft SMF for MANET November 2007
"Tagger ID" until timeout or some other criteria to favor another
tagger occurs.
It is RECOMMENDED that the first approach be used in the case of
I-DPD operation unless the SMF system is specifically designed to
implement the second option. Additional specification may be
required to describe an interoperable forwarding policy based on this
second option. Note that the implementation of the second option
requires that per-flow (i.e., <sourceAddress::destinationAddress>)
state be maintained for the selected "Tagger ID".
The deployment of a H-DPD operational mode may alleviate DPD
resolution when ingressing traffic comes from multiple border
routers. Non-colliding hash indexes (those not requiring the H-DPD
options header in IPv6) should be resolved effectively.
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 30]
Internet-Draft SMF for MANET November 2007
9. Non-SMF MANET Node Interaction
There may be scenarios in which some neighboring wireless MANET node
is not running SMF and/or conduct forwarding, but is interested in
receiving multicast data. For example, a MANET service might be
deployed that is accessible to wireless edge devices that does not
participate in MANET routing and/or SMF forwarding operation. These
devices include:
1. Devices that opportunistically receive multicast traffic due to
proximity with SMF relays (possibly with asymmetric IP
connectivity e.g., sensor network device).
2. Devices that participate in NHDP (directly or via routing
protocol signaling) but do not forward traffic.
Note there is no guarantee of traffic delivery with category 1 above,
but the election heuristics shown in Figure 2 may be adjusted via
management to better support such devices. It is RECOMMENDED that
nodes participate in NHDP when possible. Such devices may also
transmit multicast traffic, but it is important to note that SMF
routing regions using source-specific relay set algorithms such as
(S-MPR) may not forward such traffic. These devices SHOULD also
listen for any IGMP/MLD Queries that are provided and transmit IGMP/
MLD Reports for groups they have joined per usual IP Multicast
operation. While it is not in the scope of this document, IGMP/MLD
proxy mechanisms may be in place to convey group membership
information to any border routers or intermediate systems providing
IP Multicast routing functions.
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 31]
Internet-Draft SMF for MANET November 2007
10. Security Considerations
Gratuitous use of option headers can cause problems in routers.
Routers outside of MANET routing regions should ignore SMF-specific
header options if encountered. The header options types are encoded
appropriately for this behavior.
Sequence-based packet identifiers are predictable and thus provide an
opportunity for a denial-of-service attack against forwarding. The
use of the "internal hashing" as described in Section 5.3 for the
I-DPD operation helps to mitigate denial-of-service attacks on
predictable packet identifiers. In this case, spoofed packets MAY be
forwarded but the additional internal history identifier will protect
against false collision events that may result from a predictive
denial-of-service attack.
Another potential denial-of-service attack against SMF forwarding is
possible when a bad-behaving node has a form of "wormhole" access
(via a directional antenna, etc) to preview packets before a
particular SMF node would receive them. The bad-behaving node could
reduce the TTL or Hop Limit of the packet and transmit it to the SMF
node causing it to forward the packet with a limited TTL (or even
drop it) and make a DPD entry that would block forwarding of the
subsequently-arriving valid packet with appropriate TTL value. This
would be a relatively low-cost, high-payoff attack that would be hard
to detect and thus attractive to potential attackers. An approach of
caching TTL information with DPD state and taking appropriate
forwarding actions is identified in Section 4 to mitigate this form
of attack.
The support of forwarding non-fragmented IPSEC datagrams without
further modification for both IPv4 and IPv6 is supported by this
specification.
Authentication mechanisms to identify the source of IPv6 option
headers should be considered to reduce vulnerability to a variety of
attacks.
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 32]
Internet-Draft SMF for MANET November 2007
11. IANA Considerations
There are number of discussions within this SMF specification that
will be subject to IANA registration and consideration. The IPv6
SMF-DPD hop-by-hop Header Extension being defined within this
document MUST have an IANA registry established upon publication of
the first RFC. Additionally, well-known site-scoped multicast
addresses intended as default forwardable addresses by the SMF
forwarding process for both IPv4 and IPv6 should be registered and
defined by the first RFC published. Also, SMF specific TLV types and
definitions MUST be registered in the context of packetbb and NHDP
use.
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 33]
Internet-Draft SMF for MANET November 2007
12. Acknowledgments
Many of the concepts and mechanisms used and adopted by SMF resulted
from many years of discussion and related work within the MANET WG
since the late 1990s. There are obviously many contributors to past
discussions and related draft documents within the WG that have
influenced the development of SMF concepts that deserve
acknowledgment. In particular, the document is largely a direct
product of the earlier SMF design team within the IETF MANET WG and
borrows text and implementation ideas from the related individuals.
Some of the contributors who have been involved in design, content
editing, prototype implementation, and core discussions are listed
below in alphabetical order. We appreciate input from many others we
may have missed in this list as well.
Design contributors in alphabetical order:
Brian Adamson
Teco Boot
Ian Chakeres
Thomas Clausen
Justin Dean
Brian Haberman
Charles Perkins
Pedro Ruiz
Fred Templin
Maoyu Wang
The RFC text was produced using Marshall Rose's xml2rfc tool and Bill
Fenner's XMLmind add-ons.
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 34]
Internet-Draft SMF for MANET November 2007
13. References
13.1. Normative References
[E-CDS] Ogier, R., "MANET Extension of OSPF Using CDS Flooding",
Proceedings of the 62nd IETF , March 2005.
[MPR-CDS] Adjih, C., Jacquet, P., and L. Viennot, "Computing
Connected Dominating Sets with Multipoint Relays", Ad Hoc
and Sensor Wireless Networks , January 2005.
[NHDP] Clausen, T. and et al, "Neighborhood Discovery Protocol",
draft-ietf-manet-ndp-00, Work in progress , July 2006.
[OLSRv2] Clausen, T. and et al, "Optimized Link State Routing
Protocol version 2", draft-ietf-manet-olsrv2-00, Work in
progress , March 2006.
[PacketBB]
Clausen, T. and et al, "Generalized MANET Packet/Message
Format", draft-ietf-manet-packetbb-00, Work in progress ,
March 2006.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2644] Senie, D., "Changing the Default for Directed Broadcasts
in Routers", BCP 34, RFC 2644, August 1999.
[RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing
Protocol", 2003.
[RFC4302] Kent, S., "IP Authentication Header", December 2005.
13.2. Informative References
[GJ79] Garey, M. and D. Johnson, "Computers and Intractability: A
Guide to the Theory of NP-Completeness.", Freeman and
Company , 1979.
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 35]
Internet-Draft SMF for MANET November 2007
[JLMV02] Jacquet, P., Laouiti, V., Minet, P., and L. Viennot,
"Performance of multipoint relaying in ad hoc mobile
routing protocols", Networking , 2002.
[MDC04] Macker, J., Dean, J., and W. Chao, "Simplified Multicast
Forwarding in Mobile Ad hoc Networks", IEEE MILCOM 2004
Proceedings , 2004.
[MDDA07] Macker, J., Downard, I., Dean, J., and R. Adamson,
"Evaluation of distributed cover set algorithms in mobile
ad hoc network for simplified multicast forwarding", ACM
SIGMOBILE Mobile Computing and Communications Review
Volume 11 , Issue 3 (July 2007), July 2007.
[NTSC99] Ni, S., Tseng, Y., Chen, Y., and J. Sheu, "The Broadcast
Storm Problem in Mobile Ad hoc Networks", Proceedings Of
ACM Mobicom 99 , 1999.
[RFC2901] Macker, JP. and MS. Corson, "Mobile Ad hoc Networking
(MANET): Routing Protocol Performance Issues and
Evaluation Considerations", 1999.
[RFC3684] Ogier, R., Templin, F., and M. Lewis, "Topology
Dissemination Based on Reverse-Path Forwarding", 2003.
[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol
Independent Multicast - Dense Mode (PIM-DM): Protocol
Specification (Revised)", RFC 3973, January 2005.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
[WC02] Williams, B. and T. Camp, "Comparison of Broadcasting
Techniques for Mobile Ad hoc Networks", Proceedings of ACM
Mobihoc 2002 , 2002.
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 36]
Internet-Draft SMF for MANET November 2007
Appendix A. Reduced Relay Set Forwarding Algorithms and Considerations
This Appendix discusses candidate SMF reduced relay set algorithms
that have been used in practice. Basic algorithm operation is
described along with related issues (e.g., TLV use).
The following definitions are used to describe algorithm operation
within sections to follow.
node : A MANET router operating SMF.
n_0 : The node performing the SMF algorithm computation.
N_1 : A set of 1-hop neighbors of n_0. Initially set to all 1-hop
neighbors.
N_2 : A set of 2-hop neighbors reachable by n_0, excluding n_0 and
all nodes in N_1. Initially set to all 2-hop neighbors excluding
n_0 and all nodes in N_1.
N_2(y) : The subset of N_2 nodes which are 1-hop neighbors of node
y, where node y is in N_1.
N_1(z) : The subset of N_1 nodes which are 1-hop neighbors of node
z, where z is in N_2.
RtrPri : an expression of router priority. In the case of a
RtrPri value tie, higher address values are equivalent to a higher
priority value result.
rp_max_1 : The node with the largest RtrPri of N_1.
MPRs : The subset of N_1 which have been selected by n_0 to
forward packets from n_0.
MPR-Selectors : The subset of N_1 for whom n_0 has been selected
to forward packets.
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 37]
Internet-Draft SMF for MANET November 2007
Appendix B. Source-based Multipoint Relay (S-MPR)
The source-based multipoint relay (S-MPR) set selection algorithm
enables individual nodes, using two-hop topology information, to
select relays from their set of neighboring nodes. Relays are
selected so that a nodes two-hop neighbor set is covered. This
distributed technique has been shown to approximate selection of a
minimal connected dominating set (MCDS) in [JLMV02]. Individual
nodes must collect two-hop neighborhood information from neighbors,
determine an appropriate current relay set, and inform selected
neighbors of their relay status. The Optimized Link State Routing
(OLSR) protocol has used this algorithm and protocol for relay of
link state updates and other control information [RFC3626] and it has
been demonstrated operationally in dynamic network environments.
B.1. S-MPR Relay Set Selection
If SMF is operating S-MPR relay set election is operating with
independent CDS control, the election algorithm and TLVs defined
within [OLSRv2] SHOULD be used. In this case, NHDP messages SHOULD
also include a message TLV of type SMF_RELAYALG_ID specifying S-MPR
relay election.
With S-MPR, a node's status as a relay is with respect to neighboring
nodes who have selected it (i.e., its "selectors".) This requires
nodes to inform neighbors of who they have selected as forwarders.
These relaying nodes must have previous-hop knowledge of packets
received to make forwarding decisions. Additionally, it is important
that relay nodes forward packets for only those nodes identified as
symmetric, one-hop neighbors to maintain correctness. The selection
of relays does not result in a common set among neighboring nodes, so
relays MUST mark in their duplicate table packets from non-selector,
symmetric, one-hop neighbors (for a given interface) and not forward
subsequent duplicates of that packet if received on that interface.
Deviation here can result in unnecessary, repeated packet forwarding
throughout the network, or incomplete flooding. When multiple
interfaces are present, the S-MPR SMF forwarder must keep independent
state for each interface with regards to duplicate packets. In these
respects, flooding for SMF based on the S-MPR algorithm is more
complex than previous hop independent relay set selection algorithms,
yet S-MPR is a known technique that has significant experimental and
operational experience and may have other performance advantages.
B.2. S-MPR Forwarding Rules
1. Upon reception of a packet, it is checked against the incoming
interfaces duplicate table. If a duplicate exists no further
action is taken.
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 38]
Internet-Draft SMF for MANET November 2007
2. Once uniqueness is verified and if the previous-hop transmitter
is a one-hop symmetric neighbor, the packet is added to the
duplicate table of the incoming interface. If the previous-hop
transmitter is not a one-hop symmetric neighbor the packet SHOULD
NOT be forwarded and SHOULD NOT be added to the duplicat table.
3. If the previous-hop transmitter has selected the current node, on
the incoming interface, as an MPR, the packet is forwarded out
all interfaces. If the node is not an MPR for the previous-hop,
on the incoming interface, no further action is taken.
4. Any packet sourced or forwarded through a node is added to the
duplicate tables of all of the nodes interfaces.
Basic S-MPR relay forwarding will not forward packets in which the
previous hop is not known through the neighbor discovery mechanism,
therefore nodes not participating in neighbor discovery and relay set
selection will not be able to source multicast packets into the MANET
and have SMF forward them. Correct S-MPR relay behavior will occur
with the introduction of repeaters (non SMF participant nodes that
relay multicast packets using duplicate detection and CF) but the
repeaters will be dead ends with regards to S-MPR SMF forwarding.
SMF participant nodes may not provide extra forwarding, forwarding
packets which are not selected by the algorithm, as this can break
network wide S-MPR flooding.
B.3. S-MPR Neighborhood Discovery Requirements
S-MPR election operation requires 2-hop neighbor knowledge as
provided by the NHDP protocol [NHDP] or as available from external
sources. MPRs are dynamically selected by each node and selections
MUST be advertised and dynamically updated within NHDP or equivalent
protocol. In this mode, the MPR specific TLVs defined in OLSRv2
[OLSRv2] are also required to be implemented by NHDP.
B.4. S-MPR Selection Algorithm
1. 1. Calculate N_1(z) for all nodes z in N_2.
2. 2. Calculate N_2(y) for all nodes y in N_1.
3. 3. For each z in N_2 where |N_1(z)| is equal to 1, select the
node in N_1(z) as an MPR by using Appendix B.4.1.
4. 4. While N_2 is not empty select the node y, with the largest
|N_2(y)|, as MPR by using Appendix B.4.1.
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 39]
Internet-Draft SMF for MANET November 2007
5. 5. Restore N_1 and N_2.
6. 6. Node n_0 shares its MPRs with N_1.
7. 7. Each node in n_0's MPRs set add n_0 to their MPR-Selectors
set.
8. 8. Nodes forward all unique multicast packets which are first
received from a node in their MPR-Selectors set.
B.4.1. MPR Node Selection Procedure
1. Add n to the MPRs set.
2. Remove node n from N_1.
3. For each y in N_2(n), remove y from N_2.
4. Calculate N_1(z) for all nodes z in N_2
5. Calculate N_2(y) for all nodes y in N_1.
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 40]
Internet-Draft SMF for MANET November 2007
Appendix C. Essential Connecting Dominating Set (E-CDS) Algorithm
The "Essential Connected Dominating Set" (E-CDS) algorithm [E-CDS]
allows nodes to use two-hop topology information to dynamically elect
_themselves_ as relay nodes to form an efficient (for flooding) CDS.
Its forwarding rules within SMF are non-dependent upon previous hop
information. Semantics for multiple interface support are simplified
as compared to S-MPR as only one duplicate table is required.
Packets which are received from non-symmetric neighbors may be
forwarded without compromising flooding efficiency or algorithm
correctness. The E-CDS based relay set selection algorithm is based
upon Richard Ogier's original summary within [E-CDS]. E-CDS was
originally discussed in the context of forming partial adjacencies
and efficient flooding for MANET OSPF extensions work but its core
algorithm is applied here.
If SMF is operating E-CDS relay set election with independent CDS
control, NHDP messages SHOULD also include a message TLV of type
SMF_RELAYALG_ID specifying E-CDS relay election.
C.1. E-CDS Relay Set Selection
E-CDS requires two-hop neighbor information collected through NHDP or
other process. Each router has a Router Identifier (that may be
represented by an interface address) and Router Priority
value(RtrPri). The Router Priority value may be dynamic and may
represent such metrics as node degree. The fundamental election
steps are as follows:
1. If an SMF node has a higher (Router Priority, Router ID) than all
of its symmetric neighbors, it elects itself to the relay set.
2. Else, if there does not exist a path from neighbor j with largest
(Router Priority, Router ID) to some other neighbor, via
neighbors with larger values of (Router Priority, Router ID),
then it elects itself to the relay set.
The basic form of E-CDS described and applied within this
specification does not at present define redundant relay set election
but such capability is supported by the basic E-CDS design.
C.2. E-CDS Forwarding Rules
Upon electing itself as an E-CDS relay set forwarder, SMF nodes
perform DPD functions and forward all ranges of non-duplicative
multicast traffic allowed by the present forwarding policy.
Knowledge of a packets previous hop is not needed for forwarding
decisions when using E-CDS.
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 41]
Internet-Draft SMF for MANET November 2007
1. Upon reception of a packet, it is checked against the duplicate
table. If a duplicate exists no further action is taken. E-CDS
and all other shared relay selection algorithms only require one
duplicate table for all interfaces of which the algorithm covers.
2. Once uniqueness is verified, the packet is added to the duplicate
table.
3. A unique packet is forwarded out all interfaces if the local node
has selected itself as a relay node according to the E-CDS
algorithm.
4. Any packet sourced or forwarded through a node is added to the
duplicate table.
Using E-CDS relay forwarding, nodes which are not participating in
neighbor discovery and relay set selection will have directly
injected multicast packets forwarded by SMF if they are received at a
relay node. Correct E-CDS relay behavior will occur with the
introduction of repeaters (non SMF participant nodes which relay
multicast packets using duplicate detection) and these repeaters can
be used to connect otherwise separate SMF relay sets. SMF
participant nodes may provide extra forwarding, becoming a relay node
when not selected by the E-CDS algorithm, without breaking correct
flooding throughout the network.
C.3. E-CDS Neighborhood Discovery Requirements
Two-hop knowledge is needed during the election process, but unlike
the MPR method, E-CDS is a self-electing algorithm. For E-CDS
operation, some value of RtrPri must be given or assumed for each
address with the two-hop neighborhood which is consistent for all
nodes. If RtrPri is a non-default value it MUST be shared with all
immediate neighbor and 2-hop neighbor nodes. To support this the
SMF_RTR_PRI TLVs MAY be used to transmit RtrPri for each address
within a NHDP message. If a NHDP message originator does not provide
a RtrPri value for given address(es) using the SMF_RTR_PRI TLVs, a
default value RTRPRI_DEFAULT = 128 should be assumed.
Local determination of a node RtrPri value can be done in multiple
ways as described in the [E-CDS]. An early experimental deployment
of an SMF prototype and E-CDS has used node degree as the default
priority value computed during neighbor discovery, yet it is still
unclear if this is the best method. Nonetheless, this is recommended
as the default mode on all SMF nodes to enable interoperability.
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 42]
Internet-Draft SMF for MANET November 2007
C.4. E-CDS Selection Algorithm (2-Hop)
1. If |N_1| < 2 than n_0 does not select itself as a forwarder and
no further steps need to be taken
2. If n_0 has a larger value of RtrPri than all nodes in N_1 and
N_2, then n_0 selects itself as a forwarder for all nodes.
Unless otherwise set, n_0 should assume a default RtrPri of 128.
RtrPri ties should be broken by comparing addresses.
3. If there does not exist a path from r_max_1 to every other node
in N_1 and N_2 using only N_1 and N_2 nodes that have RtrPri
larger than n_0's, then n_0 selects itself as a forwarder for all
nodes.
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 43]
Internet-Draft SMF for MANET November 2007
Appendix D. Multipoint Relay Connected Dominating Set (MPR-CDS)
Algorithm
The MPR-CDS algorithm is an extension to the basic MPR election
algorithm and results in a shared relay set that forms a CDS. Its
forwarding rules within SMF are non-dependent upon previous hop
information similar to E-CDS. An overview of the MPR-CDS selection
algorithm is provided in [MPR-CDS].
If SMF is operating MPR-CDS relay set election with independent CDS
control, NHDP messages SHOULD also include a message TLV of type
SMF_RELAYALG_ID specifying MPR-CDS relay election.
D.1. MPR-CDS Relay Set Selection
The basic requirements for election are similar to the basic MPR
algorithm with the addition that some node ordering knowledge is
required. This is similar to the E-CDS requirement and can be based
upon node IP address or some other unique router identifier. The
rules for election are as follows:
A node decides it is in the relay set if:
1. n_0 has a larger RtrPri than all of N_1 (Rule 1)
2. or n_0 is an MPR of rp_max_1 (Rule 2)
D.2. MPR-CDS Forwarding Rules
MPR-CDS forms a shared relay set so the forwarding rules do not
require previous previous hop information for making forwarding
decisions. Upon election as a MPR-CDS relay set forwarder, SMF nodes
perform DPD functions and forward all ranges of multicast traffic
allowed.
1. Upon reception of a packet, it is checked against the duplicate
table. If a duplicate exists no further action is taken. E-CDS
and all other shared relay selection algorithms only require one
duplicate table for all interfaces.
2. Once uniqueness is verified, the packet is added to the duplicate
table.
3. A unique packet is forwarded out all interfaces if the local node
has selected itself as a relay node according to the MPR-CDS
algorithm.
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 44]
Internet-Draft SMF for MANET November 2007
4. Any packet sourced or forwarded through a node is added to the
duplicate table.
Correct MPR-CDS relay behavior will occur with the introduction of
repeaters (non SMF participant nodes which relay multicast packets
using duplicate detection) and these repeaters can be used to connect
otherwise separate SMF relay sets. SMF participant nodes may provide
extra forwarding, becoming a relay node when not selected by the MPR-
CDS algorithm, without breaking correct flooding throughout the
network.
D.3. MPR-CDS Neighborhood Discovery Requirements
MPR-CDS election operation requires 2-hop neighbor knowledge as
provided by the NHDP protocol [NHDP] or as available from external
sources. MPR-CDS require the MPR specific TLVs defined in OLSRv2
[OLSRv2] and MAY use SMF_RTR_PRI message TLVs to convey router
priority values.
D.4. MPR-CDS Selection Algorithm
1. Perform steps 1-7 of Appendix B.4.
2. If n_0 RtrPri value is greater than rp_max_1's RtrPri value, and
|MPR-Selectors| > 0, then n_0 selects itself as a forwarder for
all nodes.
3. If rp_max_1 is in the MPR-Selectors set, then n_0 selects itself
as a forwarder for all nodes.
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 45]
Internet-Draft SMF for MANET November 2007
Authors' Addresses
Joseph Macker
NRL
Washington, DC 20375
USA
Email: macker@itd.nrl.navy.mil
SMF Design Team
IETF MANET WG
Email: manet@ietf.org
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 46]
Internet-Draft SMF for MANET November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Macker, editor & SMF Design Team Expires May 20, 2008 [Page 47]
| PAFTECH AB 2003-2026 | 2026-04-23 09:53:50 |