RFC 6621
Simplified Multicast Forwarding
7. Relay Set Selection
SMF is flexible in its support of different reduced relay set mechanisms for efficient flooding, the constraints imposed herein being detailed in this section.7.1. Non-Reduced Relay Set Forwarding
SMF implementations MUST support CF as a basic forwarding mechanism when reduced relay set information is not available or not selected for operation. In CF mode, each router transmits a packet once that has passed the SMF forwarding rules. The DPD techniques described in Section 6 are critical to proper operation and prevention of duplicate packet retransmissions by the same relays.7.2. Reduced Relay Set Forwarding
MANET reduced relay sets are often achieved by distributed algorithms that can dynamically calculate a topological connected dominating set (CDS). A goal of SMF is to apply reduced relay sets for more efficient multicast dissemination within dynamic topologies. To accomplish this, 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. In early SMF experimental prototyping, the relay set information was derived from coexistent unicast routing control plane traffic flooding processes [MDC04]. From this experience, extra pruning considerations were sometimes required when utilizing a relay set from a separate routing protocol process. As an example, relay sets formed for the unicast control plane flooding MAY include additional redundancy that may not be desired for multicast forwarding use (e.g., biconnected relay set).
Here is a recommended criteria list for SMF relay set selection
algorithm candidates:
1. Robustness to topological dynamics and mobility
2. Localized election or coordination of any relay sets
3. Reasonable minimization of CDS relay set size given the above
constraints
4. Heuristic support for preference or election metrics
Some relay set algorithms meeting these criteria are described in the
appendices of this document. Additional relay set selection
algorithms may be specified in separate specifications in the future.
Each appendix subsection in this document can serve as a template for
specifying additional relay algorithms.
Figure 5 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
diagram demonstrates that the SMF Relay Set State may be determined
by three fundamentally different methods:
o Independent operation with NHDP [RFC6130] input providing dynamic
network neighborhood adjacency information, used by a particular
relay set selection algorithm.
o Slave operation with an existing unicast MANET routing protocol,
capable of providing CDS election information for use by SMF.
o Cross-layer operation that may involve L2 triggers or information
describing neighbors or links.
Other heuristics to influence and control election can come from
network management or other interfaces as shown on the right of
Figure 5. CF mode simplifies the control and does not require other
input but relies solely on DPD.
Possible L2 Trigger/Information | | ______________ ______v_____ __________________ | MANET | | | | | | Neighborhood | | Relay Set | | Other Heuristics | | Discovery |----------->| Selection |<------|(Preference, etc.)| | Protocol | neighbor | Algorithm | | Net Management | |______________| info |____________| |__________________| \ / \ / neighbor\ / Dynamic Relay info* \ ____________ / Set Status \ | SMF | / (State, {neighbor info}) `-->| Relay Set |<--' | State | -->|____________| / / ______________ | Coexistent | | MANET | | Unicast | | Process | |______________| Figure 5: SMF Reduced Relay Set Information Flow Following is further discussion of the three styles of SMF operation with reduced relay sets as illustrated in Figure 5: 1. Independent operation: In this case, SMF operates independently from any unicast routing protocols. To support reduced relay sets, SMF MUST perform its own relay set selection using information gathered from signaling. It is RECOMMENDED that an associated NHDP process be used for this signaling. NHDP messaging SHOULD be appended with additional [RFC5444] type- length-value (TLV) content as to support SMF-specific requirements as discussed in [RFC6130] and to support specific relay set operation as described in the appendices of this document or future specifications. Unicast routing protocols may coexist, even using the same NHDP process, but signaling that supports reduced relay set selection for SMF is independent of these protocols.
2. Operation with CDS-aware unicast routing protocol: In this case,
a coexistent unicast routing protocol provides dynamic relay set
state based upon its own control plane CDS or neighborhood
discovery information.
3. Cross-layer operation: In this case, SMF operates using
neighborhood status and triggers from a cross-layer information
base for dynamic relay set selection and maintenance (e.g.,
lower-link layer).
8. SMF Neighborhood Discovery Requirements
This section defines the requirements for use of the MANET
Neighborhood Discovery Protocol (NHDP) [RFC6130] to support SMF
operation. Note that basic CF forwarding requires no neighborhood
topology knowledge since in this configured mode, every SMF 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 for both SMF and a coexistent MANET unicast routing
protocol.
NHDP HELLO messages and the resultant neighborhood information base
are described separately within the NHDP specification. To
summarize, NHDP provides the following basic functions:
1. 1-hop neighbor link sensing and bidirectionality checks of
neighbor links,
2. 2-hop neighborhood discovery including collection of 2-hop
neighbors and connectivity information,
3. Collection and maintenance of the above information across
multiple interfaces, and
4. A method for signaling SMF information throughout the 2-hop
neighborhood through the use of TLV extensions.
Appendices A-C of this document describe CDS-based relay set
selection algorithms that can achieve efficient SMF operation, even
in dynamic, mobile networks and each of the algorithms has been
initially experimented with in a working SMF prototype [MDDA07].
When using these algorithms in conjunction with NHDP, a method
verifying neighbor SMF operation is required in order to ensure
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. Section 8.1 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.8.1. SMF Relay Algorithm TLV Types
This section specifies TLV types to be used within NHDP messages to identify the CDS relay set selection algorithm(s) in use. Two TLV types are defined: one Message TLV type and one Address Block TLV type.8.1.1. SMF Message TLV Type
The Message TLV type denoted SMF_TYPE is used to identify the existence of an SMF instance operating in conjunction with NHDP. This Message TLV type makes use of the extended type field as defined by [RFC5444] to convey the CDS relay set selection algorithm currently in use by the SMF message originator. When NHDP is used to support SMF operation, the SMF_TYPE TLV, containing the extended type field with the appropriate value, SHOULD be included in NHDP_HELLO messages (HELLO messages as defined in [RFC6130]). This allows SMF 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. This document defines a Message TLV type as specified in Table 6 conforming to [RFC5444]. The TLV extended type field is used to contain the sender's "Relay Algorithm Type". The interpretation of the "value" content of these TLVs is defined per "Relay Algorithm Type" and may contain algorithm-specific information.
+---------------+----------------+--------------------+ | | TLV Syntax | Field Values | +---------------+----------------+--------------------+ | type | <tlv-type> | SMF_TYPE | | extended type | <tlv-type-ext> | <relayAlgorithmId> | | length | <length> | variable | | value | <value> | variable | +---------------+----------------+--------------------+ Table 6: SMF Type Message TLV In Table 6, <relayAlgorithmId> is an 8-bit field containing a number 0-255 representing the "Relay Algorithm Type" of the originator address of the corresponding NHDP message. Values for the <relayAlgorithmId> are defined in Table 7. The table provides value assignments, future IANA assignment spaces, and an experimental space. The experimental space use MUST NOT assume uniqueness; thus, it SHOULD NOT be used for general interoperable deployment prior to official IANA assignment. +-------------+--------------------+--------------------------------+ | Type Value | Extended Type | Algorithm | | | Value | | +-------------+--------------------+--------------------------------+ | SMF_TYPE | 0 | CF | | SMF_TYPE | 1 | S-MPR | | SMF_TYPE | 2 | E-CDS | | SMF_TYPE | 3 | MPR-CDS | | SMF_TYPE | 4-127 | Future Assignment STD action | | SMF_TYPE | 128-239 | No STD action required | | SMF_TYPE | 240-255 | Experimental Space | +-------------+--------------------+--------------------------------+ Table 7: SMF Relay Algorithm Type Values Acceptable <length> and <value> fields of an SMF_TYPE TLV are dependent on the extended type value (i.e., relay algorithm type). The appropriate algorithm type, as conveyed in the <tlv-type-ext> field, defines the meaning and format of its TLV <value> field. For the algorithms defined by this document, see the appropriate appendix for the <value> field format.8.1.2. SMF Address Block TLV Type
An Address Block TLV type, denoted SMF_NBR_TYPE (i.e., SMF neighbor relay algorithm) is specified in Table 8. This TLV enables CDS relay algorithm operation and configuration to be shared among 2-hop
neighborhoods. Some relay algorithms require 2-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. The message SMF_TYPE TLV and Address Block SMF_NBR_TYPE TLV types share a common format. +---------------+----------------+--------------------+ | | TLV syntax | Field Values | +---------------+----------------+--------------------+ | type | <tlv-type> | SMF_NBR_TYPE | | extended type | <tlv-type-ext> | <relayAlgorithmId> | | length | <length> | variable | | value | <value> | variable | +---------------+----------------+--------------------+ Table 8: SMF Type Address Block TLV <relayAlgorithmId> in Table 8 is an 8-bit unsigned integer field containing a number 0-255 representing the "Relay Algorithm Type" value that corresponds to any associated address in the address block. Note that "Relay Algorithm Type" values for 2-hop neighbors can be conveyed in a single TLV or multiple value TLVs as described in [RFC5444]. It is expected that SMF 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. Again, values for the <relayAlgorithmId> are defined in Table 7. The interpretation of the "value" field of SMF_NBR_TYPE TLVs is defined per "Relay Algorithm Type" and may contain algorithm-specific information. See the appropriate appendix for definitions of value fields for the algorithms defined by this document.9. SMF Border Gateway Considerations
It is expected that SMF will be used to provide simple forwarding of multicast traffic within a MANET or mesh routing topology. A border router gateway approach should be used to allow interconnection of SMF 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 [DHS08]. Some of the functionality border routers may need to address includes the following:
1. Determination of which multicast group traffic transits the
border router whether entering or exiting the attached SMF
routing domain.
2. Enforcement of TTL/hop limit 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
the scope of this document).
6. Provisions for participating non-SMF devices (routers or hosts).
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.
9.1. Forwarded Multicast Groups
Mechanisms for dynamically determining groups for forwarding into a
MANET SMF routing domain is an evolving technology area. Ideally,
only 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.
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 Section 9.4 but further work is expected to be needed here.9.2. Multicast Group Scoping
Multicast scoping is used by network administrators to control the network routing domains reachable by multicast packets. This is usually done by configuring external interfaces of border routers in the border of a routing domain to not forward multicast packets that must be kept within the SMF routing domain. This is commonly done based on TTL/hop limit of messages or by using administratively scoped 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/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. For IPv6, multicast address spaces include information about the scope of the group. Thus, border routers of an SMF routing domain know if they must forward a packet based on the IPv6 multicast group address. For the case of IPv6, it is RECOMMENDED that a MANET SMF routing domain be designated a site-scoped multicast domain. Thus, all IPv6 site-scoped multicast packets in the range FF05::/16 SHOULD be kept within the MANET SMF routing domain by border routers. IPv6 packets in any other wider range scopes (i.e., FF08::/16, FF0B::/16, and FF0E::16) MAY traverse border routers unless other restrictions different from the scope applies. Given that scoping of multicast packets is performed at the border routers and given that existing scoping mechanisms are not designed to work with mobile routers, it is assumed that non-border routers running SMF will not stop forwarding multicast data packets of an appropriate site scoping. That is, it is assumed that an SMF routing domain is a site-scoped multicast area.
9.3. Interface with Exterior Multicast Routing Protocols
The traditional operation of multicast routing protocols is tightly integrated with the group membership function. Leaf routers are configured to periodically gather group membership information, while intermediate routers conspire to create multicast trees connecting routers with directly connected multicast sources and routers with active multicast receivers. In the concrete case of SMF, border routers can be considered leaf routers. Mechanisms for multicast sources and receivers to interoperate with border routers over the multi-hop MANET SMF routing domain as if they were directly connected to the router need to be defined. The following issues need to be addressed: 1. A mechanism by which border routers gather membership information 2. A mechanism by which multicast sources are known by the border router 3. A mechanism for exchange of exterior routing protocol messages across the SMF routing domain if the SMF routing domain is to provide transit connectivity for multicast traffic. It is beyond the scope of this document to address implementation solutions to these issues. As described in Section 9.1, IGMP/MLD proxy mechanisms can address some of these issues. Similarly, exterior routing protocol messages could be tunneled or conveyed across an SMF routing domain but doing this robustly in a distributed wireless environment likely requires additional considerations outside the scope of this document. The need for the border router to receive traffic from recognized multicast sources within the SMF routing domain is important to 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 (ASes) using Multicast Source Discovery Protocol (MSDP), receivers in those external networks are not able to join the multicast tree for that source.9.4. Multiple Border Routers
An SMF 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:
1. Handling duplicate unmarked IPv4 or IPv6 (without IPsec
encapsulation or DPD option) packets possibly injected by
multiple border routers.
2. Handling of duplicate traffic injected by multiple border routers
by source-based relay algorithms.
3. Determining which border router(s) will forward outbound
multicast traffic.
4. Additional challenges with interfaces to exterior multicast
routing protocols.
When multiple border routers are present, they may be alternatively
(due to route changes) or simultaneously injecting common traffic
into the 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 option header 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:
1. Redundantly forward the multicast flows (identified by <srcAddr:
dstAddr>) from each border router, performing DPD processing on a
<TaggerID:dstAddr> or <TaggerID:srcAddr:dstAddr> basis, or
2. Use some basis to select the flow of one tagger (border router)
over the others and forward packets for applicable flows
(identified by <sourceAddress:dstAddr>) only for the selected
TaggerId until timeout or some other criteria to favor another
tagger occurs.
It is RECOMMENDED that the first approach be used in the case of
I-DPD operation. Additional specification may be required to
describe an interoperable forwarding policy based on this second
option. Note that the implementation of the second option requires
that per-flow (i.e., <srcAddr::dstAddr>) state be maintained for the
selected TaggerId.
The deployment of H-DPD operation may alleviate DPD resolution when ingressing traffic comes from multiple border routers. Non-colliding hash indexes (those not requiring the H-DPD options header in IPv6) should be resolved effectively.10. Security Considerations
Gratuitous use of option headers can cause problems in routers. Other IP routers external to an SMF routing domain that might receive forwarded multicast SHOULD ignore SMF-specific IPv6 header options when encountered. The header option types are encoded appropriately to allow for this behavior. This section briefly discusses several SMF denial-of-service (DoS) attack scenarios and provides some initial recommended mitigation strategies. 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 Section 5 to mitigate this form of attack. Sequence-based packet identifiers are predictable and thus provide an opportunity for a DoS attack against forwarding. Forwarding protocols that use DPD techniques, such as SMF, may be vulnerable to DoS attacks based on spoofing packets with apparently valid packet identifier fields. In wireless environments, where SMF will most likely be used, the opportunity for such attacks may be more prevalent than in wired networks. In the case of IPv4 packets, fragmented IP packets, or packets with IPsec headers applied, the DPD "identifier portions" of potential future packets that might be forwarded is highly predictable and easily subject to 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 even a lightweight hash of only portions of packets may suffice to serve this purpose. While H-DPD is not as readily susceptible to this form of DoS attack, it is possible that a sophisticated adversary could use side information to construct spoofing packets to mislead forwarders using a well-known hash algorithm. Thus, similarly, a separate "internal" hash value could be concatenated with the well-known hash value to alleviate this security concern. The support of forwarding IPsec packets without further modification for both IPv4 and IPv6 is supported by this specification. Authentication mechanisms to identify the source of IPv6 option headers should be considered to reduce vulnerability to a variety of attacks. Furthermore, when the MANET Neighborhood Discovery Protocol [RFC6130] is used, the security considerations described in [RFC6130] also apply.11. IANA Considerations
This document defines one IPv6 Hop-by-Hop Option, a type for which has been allocated from the IPv6 "Destination Options and Hop-by-Hop Options" registry of [RFC2780]. This document creates one registry called "TaggerId Types" for recording TaggerId types, (TidTy), as a sub-registry in the "IPv6 Parameters" registry. This document registers one well-known multicast address from each of the IPv4 and IPv6 multicast address spaces. This document defines one Message TLV, a type for which has been allocated from the "Message TLV Types" registry of [RFC5444]. Finally, this document defines one Address Block TLV, a type for which has been allocated from the "Address Block TLV Types" registry of [RFC5444].
11.1. IPv6 SMF_DPD Header Extension Option Type
IANA has allocated an IPv6 Option Type from the IPv6 "Destination Options and Hop-by-Hop Options" registry of [RFC2780], as specified in Table 9. +-----------+-------------------------+-------------+---------------+ | Hex Value | Binary Value | Description | Reference | | | act | chg | rest | | | +-----------+-------------------------+-------------+---------------+ | 8 | 00 | 0 | 01000 | SMF_DPD | This Document | +-----------+-------------------------+-------------+---------------+ Table 9: IPv6 Option Type Allocation11.2. TaggerId Types (TidTy)
A portion of the option data content in the SMF_DPD is the Tagger Identifier Type (TidTy), which provides a context for the optionally included TaggerId. IANA has created a registry for recording TaggerId Types (TidTy), with initial assignments and allocation policies, as specified in Table 10. +------+----------+------------------------------------+------------+ | Type | Mnemonic | Description | Reference | +------+----------+------------------------------------+------------+ | 0 | NULL | No TaggerId field is present | This | | | | | document | | 1 | DEFAULT | A TaggerId of non-specific context | This | | | | is present | document | | 2 | IPv4 | A TaggerId representing an IPv4 | This | | | | address is present | document | | 3 | IPv6 | A TaggerId representing an IPv6 | This | | | | address is present | document | | 4-7 | | Unassigned | | +------+----------+------------------------------------+------------+ Table 10: TaggerId Types For allocation of unassigned values 4-7, IETF Review [RFC5226] is required.
11.3. Well-Known Multicast Address
IANA has allocated an IPv4 multicast address "SL-MANET-ROUTERS" (224.0.1.186) from the "Internetwork Control Block (224.0.1.0- 224.0.1.255 (224.0.1/24))" sub-registry of the "IPv4 Multicast Address" registry. IANA has allocated 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.11.4. SMF TLVs
11.4.1. Expert Review for Created Type Extension Registries
Creation of Address Block TLV Types and Message TLV Types in registries of [RFC5444], and hence in the HELLO-message-specific registries of [RFC6130], 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 those specified by [RFC5444].11.4.2. SMF Message TLV Type (SMF_TYPE)
This document defines one Message TLV Type, "SMF_TYPE", which has been allocated from the "HELLO Message-Type-specific Message TLV Types" registry, defined in [RFC6130]. This created a new Type Extension registry, with initial assignments as specified in Table 11. +----------+------+-----------+--------------------+----------------+ | Name | Type | Type | Description | Allocation | | | | Extension | | Policy | +----------+------+-----------+--------------------+----------------+ | SMF_TYPE | 128 | 0-255 | Specifies relay | Section 11.4.4 | | | | | algorithm | | | | | | supported by the | | | | | | SMF router, | | | | | | originating the | | | | | | HELLO message, | | | | | | according to | | | | | | Section 11.4.4. | | +----------+------+-----------+--------------------+----------------+ Table 11: SMF_TYPE Message TLV Type Extension Registry
11.4.3. SMF Address Block TLV Type (SMF_NBR_TYPE)
This document defines one Address Block TLV Type, "SMF_NBR_TYPE", which has been allocated from the "HELLO Message-Type-specific Address Block TLV Types" registry, defined in [RFC6130]. This has created a new Type Extension registry, with initial assignments as specified in Table 12. +--------------+--------+-----------+-----------------+-------------+ | Name | Type | Type | Description | Allocation | | | | Extension | | Policy | +--------------+--------+-----------+-----------------+-------------+ | SMF_NBR_TYPE | 128 | 0-255 | Specifies relay | Section | | | | | algorithm | 11.4.4 | | | | | supported by | | | | | | the SMF router | | | | | | corresponding | | | | | | to the | | | | | | advertised | | | | | | address, | | | | | | according to | | | | | | Section 11.4.4. | | +--------------+--------+-----------+-----------------+-------------+ Table 12: SMF_NBR_TYPE Address Block TLV Type Extension Registry11.4.4. SMF Relay Algorithm ID Registry
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. IANA has created a registry for recording Relay Algorithm Identifiers, with initial assignments and allocation policies as specified in Table 13.
+---------+---------+-------------+-------------------+ | Value | Name | Description | Allocation Policy | +---------+---------+-------------+-------------------+ | 0 | CF | Section 4 | | | 1 | S-MPR | Appendix B | | | 2 | E-CDS | Appendix A | | | 3 | MPR-CDS | Appendix C | | | 4-127 | | Unassigned | Expert Review | | 128-255 | | Unassigned | Experimental Use | +---------+---------+-------------+-------------------+ Table 13: Relay Set Algorithm Type Values 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).12. Acknowledgments
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, this 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. Brian Adamson Teco Boot Ian Chakeres Thomas Clausen Justin Dean Brian Haberman Ulrich Herberg Charles Perkins Pedro Ruiz Fred Templin Maoyu Wang
13. References
13.1. Normative References
[MPR-CDS] Adjih, C., Jacquet, P., and L. Viennot, "Computing Connected Dominating Sets with Multipoint Relays", Ad Hoc and Sensor Wireless Networks, January 2005. [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2644] Senie, D., "Changing the Default for Directed Broadcasts in Routers", BCP 34, RFC 2644, August 1999. [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000. [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001. [RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing Protocol (OLSR)", RFC 3626, October 2003. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format", RFC 5444, February 2009. [RFC5614] Ogier, R. and P. Spagnolo, "Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding", RFC 5614, August 2009.
[RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51, RFC 5771, March 2010. [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", RFC 6130, April 2011.13.2. Informative References
[CDHM07] Chakeres, I., Danilov, C., Henderson, T., and J. Macker, "Connecting MANET Multicast", IEEE MILCOM 2007 Proceedings, 2007. [DHG09] Danilov, C., Henderson, T., Goff, T., Kim, J., Macker, J., Weston, J., Neogi, N., Ortiz, A., and D. Uhlig, "Experiment and field demonstration of a 802.11-based ground-UAV mobile ad-hoc network", Proceedings of the 28th IEEE conference on Military Communications, 2009. [DHS08] Danilov, C., Henderson, T., Spagnolo, T., Goff, T., and J. Kim, "MANET Multicast with Multiple Gateways", IEEE MILCOM 2008 Proceedings, 2008. [GM99] Garcia-Luna-Aceves, JJ. and E. Madruga, "The Core-Assisted Mesh Protocol", Selected Areas in Communications, IEEE Journal, Volume 17, Issue 8, August 1999. [IPV4-ID-UPDATE] Touch, J., "Updated Specification of the IPv4 ID Field", Work in Progress, September 2011. [JLMV02] Jacquet, P., Laouiti, V., Minet, P., and L. Viennot, "Performance of Multipoint Relaying in Ad Hoc Mobile Routing Protocols", Networking , 2002. [MDC04] Macker, J., Dean, J., and W. Chao, "Simplified Multicast Forwarding in Mobile Ad hoc Networks", IEEE MILCOM 2004 Proceedings, 2004. [MDDA07] Macker, J., Downard, I., Dean, J., and R. Adamson, "Evaluation of Distributed Cover Set Algorithms in Mobile Ad hoc Network for Simplified Multicast Forwarding", ACM SIGMOBILE Mobile Computing and Communications Review, Volume 11, Issue 3, July 2007.
[MGL04] Mohapatra, P., Gui, C., and J. Li, "Group Communications in Mobile Ad hoc Networks", IEEE Computer, Vol. 37, No. 2, February 2004. [NTSC99] Ni, S., Tseng, Y., Chen, Y., and J. Sheu, "The Broadcast Storm Problem in a Mobile Ad Hoc Network", Proceedings of ACM Mobicom 99, 1999. [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations", RFC 2501, January 1999. [RFC3684] Ogier, R., Templin, F., and M. Lewis, "Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)", RFC 3684, February 2004. [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.
(next page on part 3)
