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

Abstract

This document describes a Simplified Multicast Forwarding (SMF) mechanism that provides basic IP multicast forwarding suitable for wireless mesh and mobile ad hoc network (MANET) use. SMF defines techniques for multicast duplicate packet detection (DPD) to be applied in the forwarding process and includes maintenance and checking operations for both IPv4 and IPv6 protocol use. SMF also specifies mechanisms for applying reduced relay sets to achieve more efficient multicast data distribution within a mesh topology versus simple flooding. The document describes interactions with other protocols and multiple deployment approaches. Distributed algorithms for selecting reduced relay sets and related discussion are provided in the Appendices. Basic issues relating to the operation of multicast MANET border routers are discussed but ongoing work remains in this area beyond the scope of this document.

Status of this Memo

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

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

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

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

Copyright Notice

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

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

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

Table of Contents

• 1. Requirements Notation
• 2. Introduction and Scope
• 2.1. Terminology
• 3. Design Overview
• 4. SMF Applicability
• 5. SMF Packet Processing and Forwarding
• 6. SMF Duplicate Packet Detection
• 6.1. IPv6 Duplicate Packet Detection
• 6.1.1. IPv6 SMF-DPD Header Option
• 6.1.2. IPv6 Identification-based DPD
• 6.1.3. IPv6 Hash-based DPD
• 6.2. IPv4 Duplicate Packet Detection
• 6.2.1. IPv4 Identification-based DPD
• 6.2.2. IPv4 Hash-based DPD
• 7. Relay Set Selection
• 7.1. Non-Reduced Relay Set Forwarding
• 7.2. Reduced Relay Set Forwarding
• 8. SMF Neighborhood Discovery Requirements
• 8.1. SMF Relay Algorithm TLV Types
• 8.1.1. SMF Message TLV Type
• 8.1.2. SMF Address Block TLV Type
• 9. SMF Border Gateway Considerations
• 9.1. Forwarded Multicast Groups
• 9.2. Multicast Group Scoping
• 9.3. Interface with Exterior Multicast Routing Protocols
• 9.4. Multiple Border Routers
• 10. Security Considerations
• 11. IANA Considerations
• 11.1. IPv6 SMF-DPD Header Extension
• 11.2. SMF Type-Length-Value
• 12. Acknowledgments
• 13. References
• 13.1. Normative References
• 13.2. Informative References
• Appendix A. Essential Connecting Dominating Set (E-CDS) Algorithm
• Appendix A.1. E-CDS Relay Set Selection Overview
• Appendix A.2. E-CDS Forwarding Rules
• Appendix A.3. E-CDS Neighborhood Discovery Requirements
• Appendix A.4. E-CDS Selection Algorithm
• Appendix B. Source-based Multipoint Relay (S-MPR)
• Appendix B.1. S-MPR Relay Set Selection Overview
• Appendix B.2. S-MPR Forwarding Rules
• Appendix B.3. S-MPR Neighborhood Discovery Requirements
• Appendix B.4. S-MPR Selection Algorithm
• Appendix C. Multipoint Relay Connected Dominating Set (MPR-CDS) Algorithm
• Appendix C.1. MPR-CDS Relay Set Selection Overview
• Appendix C.2. MPR-CDS Forwarding Rules
• Appendix C.3. MPR-CDS Neighborhood Discovery Requirements
• Appendix C.4. MPR-CDS Selection Algorithm
• Authors' Addresses

1. Requirements Notation

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

2. Introduction and Scope

Unicast routing protocol designs for MANET and wireless mesh use often apply distributed algorithms to flood routing control plane messages within an interior wireless routing domain. For example, algorithms specified within [RFC3626] and [RFC3684] provide distributed methods of dynamically electing reduced relay sets that attempt to efficiently flood routing control messages while maintaining a connected set under dynamic topological conditions.

In one sense, Simplified Multicast Forwarding (SMF) extends the efficient flooding concept to the data forwarding plane. Therefore, SMF provides an appropriate multicast forwarding capability for use cases where localized, efficient flooding is considered an effective design approach. The baseline design is intended to provide a basic, best effort multicast forwarding capability that is constrained to operate within an interior MANET or wireless mesh routing domain. An SMF routing domain is an instance of a SMF routing protocol with common policies that is under a single network administration authority. The main design goals of this SMF specification are to adapt efficient relay sets in MANET type environments [RFC2501] and to define the needed IPv4 and IPv6 multicast duplicate packet detection (DPD) mechanisms to support multi-hop, packet forwarding.

2.1. Terminology

The following abbreviations are used throughout this document:

3. Design Overview

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) occurs based on dynamic input from a neighborhood discovery process. SMF supports the case where neighborhood discovery and/or relay set selection information is obtained from a coexistent process (e.g., a lower layer mechanism or a unicast routing protocol using relay sets). In some algorithm designs, the forwarding decision for a packet can also depend on previous hop or incoming interface information. The asterisks (*) in Figure 1 mark the primitives and relationships needed by relay set algorithms requiring previous-hop packet forwarding knowledge.

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

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

Interoperable SMF implementations MUST use a common DPD approach and be able to process the header options defined in this document for IPv6 operation. We define Classical Flooding (CF), as the simplest case of SMF multicast forwarding. With CF, each SMF router forwards each received multicast packet exactly once. In this case, the need for any relay set selection or neighborhood topology information is eliminated at the expense of additional network overhead. In CF mode, the SMF-DPD functionality is still required. While SMF supports a CF mode of operation the use of more efficient relay set modes is RECOMMENDED to reduce contention and congestion caused by unnecessary packet retransmissions [NTSC99].

An efficient, reduced relay set is realized by selecting and maintaining a subset of all possible routers in a MANET routing domain. Known distributed relay set selection algorithms have demonstrated the ability to provide and maintain a dynamic connected set for forwarding multicast IP packets [MDC04]. A few such relay set selection algorithms are described in the Appendices of this document and the basic designs borrow directly from previously documented IETF work. SMF relay set configuration is extensible and additional relay set algorithms beyond those specified here can be accommodated in future work.

Determining and maintaining an optimized set of forwarding nodes generally requires dynamic neighborhood topology information. Neighborhood topology discovery functions MAY be externally provided by a MANET unicast routing protocol or by using the MANET NeighborHood Discovery Protocol (NHDP) [RFC6130] running in concurrence with SMF. Additionally, this specification allows alternative lower layer interfaces (radio router interface) to provide the necessary neighborhood information to aid in supporting more effective relay set election. Fundamentally, an SMF implementation SHOULD provide the ability for multicast forwarding state to be dynamically managed per operating network interface. Some of the relay state maintenance options and interactions are outlined later in Section 7. This document states specific requirements for neighborhood discovery with respect to the forwarding process and the relay set selection algorithms described herein. For determining dynamic relay sets in the absence of other control interfaces, SMF relies on the MANET NHDP specification to assist in IP layer 2-hop neighborhood state discovery and maintenance for relay set election. "SMF_TYPE" and "SMF_NBR_TYPE" Message and Address Block, respectfully, TLV structures (per [RFC5444]) are defined for use with the NHDP protocol. It is RECOMMENDED that all nodes performing SMF operation in conjunction with NHDP, include these TLV types in any NHDP HELLO messages generated. This capability allows for nodes participating in SMF to be explicitly identified along with their respective dynamic relay set algorithm.

4. SMF Applicability

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

Note again that Figure 1 provides a notional architecture for typical SMF-capable nodes. A goal is that simple leaf nodes may also participate in multicast traffic transmission and reception with standard IP network layer semantics (e.g., special or unnecessary encapsulation of IP packets should be avoided in this case). It is important that SMF deployments in localized edge network settings are able to connect and interoperate with existing standard multicast protocols operating within more conventional Internet infrastructures. A multicast border router or proxy mechanism MUST be used when deployed alongside more fixed-infrastructure IP multicast routing such Protocol Independent Multicast (PIM) variants [RFC3973] and [RFC4601]. Present experimental SMF implementations have demonstrated gateway functionality at MANET border routers operating with existing external IP multicast routing protocols [CDHM07],[DHS08],and [DHG09]. SMF may be extended or combined with other mechanisms to provide increased reliability and group specific filtering, but the details for this are not discussed here.

5. SMF Packet Processing and Forwarding

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

1. Processing of outbound, locally-generated multicast packets.
2. Reception and processing of inbound packets on specific network interfaces.

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

Inbound multicast packets are received by the SMF implementation and processed for possible forwarding. This document does not presently support forwarding of directed broadcast addresses [RFC2644]. SMF implementations MUST be capable of forwarding IP multicast packets with destination addresses that are not node-local and link-local for IPv6 as defined in [RFC4291] and that are not within the local network control block as defined by [RFC5771]

This will help support generic multi-hop multicast application needs or to distribute designated multicast traffic ingressing the SMF routing domain via border routers. The multicast addresses to be forwarded should be maintained by an a priori list or a dynamic forwarding information base (FIB) that MAY interact with future MANET dynamic group membership extensions or management functions. There will also be a well-known multicast group for SMF. This multicast group is specified to contain all routers within an SMF routing domain, so that packets transmitted to the multicast address associated with the group will be delivered to all connected routers running SMF. Due the mobile nature of a MANET, routers running SMF may not be topologically connected at particular times. For IPv6, the multicast address is specified to be "site-local". The name of the multicast group is "SL-MANET-ROUTERS". Minimally SMF MUST forward, as instructed by the relay set selection algorithm, unique (non-duplicate) packets received for this well-known group address when the TTL or hop limit value in the IP header is greater than 1. SMF MUST forward all additional global scope addresses specified within the dynamic FIB or configured list as well. In all cases, the following rules MUST be observed for SMF multicast forwarding:

1. IP multicast packets with TTL <= 1 MUST NOT be forwarded.
2. Link local IP multicast packets MUST NOT be forwarded.
3. Incoming IP multicast packets with an IP source address matching one of those of the local SMF router interface(s) MUST NOT be forwarded.
4. Received frames with the MAC source address matching any MAC address of the routers interfaces MUST NOT be forwarded.
5. Received packets for which SMF cannot reasonably ensure temporal DPD uniqueness MUST NOT be forwarded.
6. When packets are forwarded, TTL or hop limit MUST be decremented by one.

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

An additional processing rule also needs to be considered based upon a potential security threat. As discussed further in Section 10, there may be concern in some SMF deployments that malicious nodes may conduct a denial-of-service attack by remotely "previewing" (e.g., via a directional receive antenna) packets that an SMF node would be forwarding and conduct a "pre-play" attack by transmitting the packet before the SMF node would otherwise receive it but with a reduced TTL (or Hop Limit) 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 per-packet DPD state (hash value(s) and/or identifier as described in Section 6). Then, if a subsequent matching (with respect to DPD) packet arrives with a larger TTL value than the packet that was previously forwarded, SMF should forward the new packet and update the TTL value cached with corresponding DPD state to the new, larger TTL value. There may be temporal cases where SMF would unnecessarily forward some duplicate packets using this approach, but those cases are expected to be minimal and acceptable when compared with the potential threat of denied service.

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

6. SMF Duplicate Packet Detection

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

Trade-offs of the two approaches to DPD merit different consideration dependent upon the specific SMF deployment scenario. Because of the potential addition of a hop-by-hop option header with IPv6, SMF deployments MUST be configured to use a common mechanism and DPD algorithm. The main difference between IPv4 and IPv6 SMF-DPD specification is the avoidance of any additional header options in the IPv4 case.

For each network interface, SMF implementations MUST maintain DPD packet state as needed to support the forwarding heuristics of the relay set algorithm used. In general this involves keeping track of previously forwarded packets so that duplicates are not forwarded, but some relay techniques have additional considerations, such as discussed in Appendix Appendix B.2.

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

6.1. IPv6 Duplicate Packet Detection

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

1. the hop-by-hop SMF-DPD option header,
2. the use of IPv6 fragment header fields for I-DPD when they exist,
3. the use of IPsec sequencing for I-DPD when a non-fragmented, IPsec header is detected, and
4. an H-DPD approach assisted, as needed, by the SMF-DPD option header.

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

6.1.1. IPv6 SMF-DPD Header Option

The base IPv6 packet header does not contain a unique identifier suitable for DPD. This section defines an IPv6 Hop-by-Hop Option [RFC2460] to serve this purpose for IPv6 I-DPD. Additionally, the header option provides a mechanism to guarantee non-collision of hash values for different packets when H-DPD is used.

If this is the only hop-by-hop option present, the optional "TaggerId" field (see below) is not included, and the size of the DPD packet identifier (sequence number) or hash token is 24 bits or less, this will result in the addition of 8 bytes to the IPv6 packet header including the "Next Header", "Header Extension Length", SMF-DPD option fields, and padding.

    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 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |H|  DPD Identifier Option Fields or Hash Assist Value  ...      
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

"Opt. Data Len" = Length of option content (I.e., 1 + (<IdType> ? (<IdLen> + 1): 0) + Length(DPD ID)).

"H-bit" = a hash indicator bit value identifying DPD marking type. 0 == sequence-based approach w/ optional taggerId and a tuple-based sequence number. 1 == indicates a hash assist value (HAV) field follows to aid in avoiding hash-based DPD collisions.

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

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

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:

This format allows a quick check of the "TidType" field to determine if a "TaggerId" field is present. If the <TidType> is NULL, then the length of the DPD packet <Identifier> field corresponds to the (<Opt. Data Len> - 1). If the <TidType> is non-NULL, then the length of the "TaggerId" field is equal to (<TidLen> - 1) and the remainder of the option data comprises the DPD packet <Identifier> field. When the "TaggerId" field is present, the <Identifier> field can be considered a unique packet identifier in the context of the <taggerId:srcAddr:dstAddr> tuple. When the "TaggerId" field is not present, then it is assumed the source host applied the SMF-DPD option and the <Identifier> can be considered unique in the context of the IPv6 packet header <srcAddr:dstAddr> tuple. IPv6 I-DPD operation details are described in Section 6.1.2.

When the "H-bit" in the SMF-DPD option data is set, the data content value is interpreted as a Hash-Assist Value (HAV) used to facilitate H-DPD operation. In this case, source hosts or ingressing gateways apply the SMF-DPD with a HAV only when required to differentiate the hash value of a new packet with respect to hash values in the DPD cache. This situation can be detected locally on the node by running the hash algorithm and checking the DPD cache. prior ingressing a previously unmarked packet or a locally sourced packet. This helps to guarantee the uniqueness of generated hash values when H-DPD is used. Additionally, this also avoids the added overhead of applying the SMF-DPD option header to every packet. For many hash algorithms, it is expected that only sparse use of the SMF-DPD option may be required. The format of the SMF-DPD header option for H-DPD operation is given in Figure 4.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  ...              |0|0|0| OptType | Opt. Data Len |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|    Hash Assist Value (HAV) ... 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

6.1.2. IPv6 Identification-based DPD

The following table summarizes the IPv6 I-DPD processing and forwarding decision approach. Within the table '*' indicates an ignore field condition.

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 [RFC4302]. For unfragmented, non-IPsec, IPv6 packets, the use of the SMF-DPD header option is necessary to support I-DPD operation. The SMF-DPD header option is applied in the context of the <srcAddr> of the IP packet. End systems or ingressing SMF gateways are responsible for applying this option to support DPD. The following table summarizes these packet identification types:

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

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

6.1.3. IPv6 Hash-based DPD

A default hash-based DPD approach (H-DPD) for use by SMF is specified as follows. An MD5 [RFC1321] hash of the non-mutable header fields, options fields, and data content of the IPv6 multicast packet is used to produce a 128-bit digest. The least significant 64 bits of this digest is used for SMF packet identification. The approach for calculating this hash value SHOULD follow the same guidelines described for calculating the Integrity Check Value (ICV) described in [RFC4302] with respect to non-mutable fields. This approach should have a reasonably low probability of digest collision when packet headers and content are varying. MD5 is being applied in SMF only to provide a low probability of collision and is not being used for cryptographic or authentication purposes. A history of the packet hash values SHOULD be maintained within the context of the IPv6 packet header <srcAddr>. SMF ingress points (i.e., source hosts or gateways) use this history to confirm that new packets are unique with respect to their hash value. The Hash-assist Value (HAV) field described in Section 6.1.1 is provided as a differentiating field when a digest collision would otherwise occur. Note that the HAV is an immutable option field and SMF MUST process any included HAV values (see Section 6.1.1) in its hash calculation.

If a packet results in a digest collision (i.e., by checking the H-DPD digest history) within the DPD cache kept by SMF forwarders, the packet should be silently dropped. If a digest collision is detected at an SMF ingress point the H-DPD option header is constructed with a randomly generated HAV. A HAV is recalculated as needed to produce a non-colliding hash value prior to forwarding. The multicast packet is then forwarded with the added IPv6 SMF-DPD header option.

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

6.2. IPv4 Duplicate Packet Detection

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

1. the use of IPv4 fragment header fields for I-DPD when they exist,
2. the use of IPsec sequencing for I-DPD when a non-fragmented IPv4 IPsec packet is detected, and
3. a H-DPD approach.

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 [RFC0791] 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 forwarders may be operate with mixed H-DPD and I-DPD modes as long as they consistently perform the appropriate DPD routines outlined in the following sections. However, it is RECOMMENDED that a deployment be configured with a common mode for operational consistency.

6.2.1. IPv4 Identification-based DPD

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

For performance reasons, IPv4 network fragmentation and reassembly of multicast packets within wireless MANET networks should be minimized, yet SMF provides the forwarding of fragments when they occur. If the IPv4 multicast packet is a fragment, SMF MUST use the fragmentation header fields for packet identification. This identification can be considered temporally unique in the context of the <protocol:srcAddr:dstAddr> of the IPv4 packet. If the packet is an unfragmented IPv4 IPsec packet, SMF MUST use IPsec fields for packet identification. The IPsec header <sequence> field can be considered a unique identifier in the context of the <IPsecType:srcAddr:dstAddr:SPI> where the "IPsecType" is either AH or ESP [RFC4302]. Finally, for unfragmented, non-IPsec, IPv4 packets, the "Identification" field can be used for I-DPD purposes. The "Identification" field can be considered unique in the context of the IPv4 <protocol:scrAddr:dstAddr> tuple. The following table summarizes these packet identification types:

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

The limited size (16 bits) of the IPv4 header "Identification" field [RFC0791] may result in more frequent value field wrapping, particularly if a common sequence space is used by a source for multiple destinations. If I-DPD operation is required, the use of the "internal hashing" technique described in Section 10 may mitigate this limitation of the IPv4 "Identification" field for SMF-DPD. In this case the "internal hash" value would be concatenated with the "Identification" value for I-DPD operation.

6.2.2. IPv4 Hash-based DPD

To ensure consistent IPv4 H-DPD operation among SMF nodes, a default hashing approach is specified. This is similar to that specified 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 least significant 64 bits of this digest 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.

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

7. Relay Set Selection

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 node transmits a locally generated or newly received forwardable packet exactly once. The DPD techniques described in Section 6 are critical to proper operation and prevent duplicate packet retransmissions by the same forwarding node.

7.2. Reduced Relay Set Forwarding

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

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

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

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

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

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

Figure 5 depicts a information flow diagram of possible relay set control options. The SMF Relay Set State represents the information base that is used by SMF in the forwarding decision process. The relay set control option diagram demonstrates that the SMF relay set state may be determined by fundamentally three different methods: independent operation with NHDP [RFC5444] input providing dynamic network neighborhood adjacency information that is then used by a particular relay set selection, slave operation with an existing unicast MANET routing protocol that is capable of providing CDS election information that can be used by SMF, and cross layer operation that may involve lower layer neighbor or link information. Other heuristics to influence and control election can come from network management or other interfaces as shown on the right. Of course 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    |     
|______________|

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

8. SMF Neighborhood Discovery Requirements

This section defines the requirements for use of the MANET Neighborhood Discovery Protocol (NHDP) [RFC6130] to support SMF operation. Note that basic CF forwarding requires no neighborhood topology knowledge since in this configured mode every SMF node relays all traffic. Supporting more reduced SMF relay set operation requires the discovery and maintenance of dynamic neighborhood topology information. The MANET NHDP protocol can be leveraged provide this necessary information, however there are SMF-specific requirements for related NHDP use. This is the case for both "independent" SMF operation where NHDP is being used specifically to support SMF or when one NHDP instance is used for both for SMF and a coexistent MANET unicast routing protocol.

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

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

Appendices (A-C) of this document describe CDS-based relay set selection algorithms that can achieve efficient SMF operation, even in dynamic, mobile networks and each of the algorithms has been initially experimented within a working SMF prototype [MDDA07]. When using these algorithms in conjunction with NHDP, a method verifying neighbor SMF operation is required in order to insure correct relay set selection. NHDP along with SMF operation verification provides the necessary information required by these algorithms to conduct relay set selection. Verification of SMF operation may be done administratively or through the use of the SMF relay algorithms TLVs defined in the following subsections. Use of the SMF relay algorithm TLVs is RECOMMENDED when using NHDP for SMF neighborhood discovery.

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

8.1. SMF Relay Algorithm TLV Types

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

8.1.1. SMF Message TLV Type

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

This document defines the following Message TLV type as specified in Table 7 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.

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

Possible values for the <relayAlgorithmId> are defined in Table 8. The table provides value assignments, future IANA assignment spaces, and an experimental space. The experimental space use MUST NOT assume uniqueness and thus should not be used for general interoperable deployment prior to official IANA assignment.

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 9. This TLV enables CDS relay algorithm operation and configuration to be shared among 2-hop neighborhoods. Some relay algorithms require two hop neighbor configuration in order to correctly select relay sets. It is also useful when mixed relay algorithm operation is possible, some examples of mixed use is outlined in the appendices.

The message SMF_TYPE TLV and address block SMF_NBR_TYPE TLV types share a common format.

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

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

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

9. SMF Border Gateway Considerations

It is expected that SMF will be used to provide simple forwarding of multicast traffic within a MANET or mesh routing topology. A border router gateway approach should be used to allow interconnection of SMF areas 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. Determining which multicast group traffic transits the border router whether entering or exiting the attached SMF routing domain.
2. Enforcement of TTL threshold or other scoping policies.
3. Any marking or labeling to enable DPD on ingressing packets.
4. Interface with exterior multicast routing protocols.
5. Possible operation with multiple border routers (presently beyond scope of this document).
6. Provisions for participating non-SMF nodes.

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

9.1. Forwarded Multicast Groups

Mechanisms for dynamically determining groups for forwarding into a MANET SMF routing domain is an evolving technology area. Ideally, only groups for which there is active group membership should be injected into the SMF domain. This can be accomplished by providing an IPv4 Internet Group Membership Protocol (IGMP) or IPv6 Multicast Listener Discovery (MLD) proxy protocol so that MANET SMF nodes can inform attached border routers (and hence multicast networks) of their current group membership status. For specific systems and services it may be possible to statically configure group membership joins in border routers, but it is RECOMMENDED that some form of IGMP/MLD proxy or other explicit, dynamic control of membership be provided. Specification of such an IGMP/MLD proxy protocol is beyond the scope of this document.

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

9.2. Multicast Group Scoping

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

1. TTL scoping.
2. Administrative scoping.

For IPv4, network administrators can configure border routers with the appropriate TTL thresholds or administratively scoped multicast groups for the router interfaces as with any traditional multicast router. However, for the case of TTL scoping it SHOULD be taken into account that the packet could traverse multiple hops within the MANET SMF routing domain before reaching the border router. Thus, TTL thresholds SHOULD be selected carefully.

For IPv6, multicast address spaces include information about the scope of the group. Thus, border routers of an SMF routing domain know if they must forward a packet based on the IPv6 multicast group address. For the case of IPv6, it is RECOMMENDED that a MANET SMF routing domain be designated a site-scoped multicast domain. Thus, all IPv6 site-scoped multicast packets in the range FF05::/16 SHOULD be kept within the MANET SMF routing domain by border routers. IPv6 packets in any other wider range scopes (i.e. FF08::/16, FF0B::/16 and FF0E::16) MAY traverse border routers unless other restrictions different from the scope applies.

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

9.3. Interface with Exterior Multicast Routing Protocols

The traditional operation of multicast routing protocols is tightly integrated with the group membership function. Leaf routers are configured to periodically gather group membership information, while intermediate routers conspire to create multicast trees connecting routers with directly-connected multicast sources and routers with active multicast receivers. In the concrete case of SMF, border routers can be considered leaf routers. Mechanisms for multicast sources and receivers to interoperate with border routers over the multihop MANET SMF routing domain as if they were directly connected to the router need to be defined. The following issues need to be addressed:

1. A mechanism by which border routers gather membership information
2. A mechanism by which multicast sources are known by the border router
3. A mechanism for exchange of exterior routing protocol messages across the SMF routing domain if the SMF routing domain is to provide transit connectivity for multicast traffic.

It is beyond the scope of this document to address implementation solutions to these issues. As described in Section 9.1, IGMP/MLD proxy mechanisms can be deployed to address some of these issues. Similarly, exterior routing protocol messages could be tunneled or conveyed across an SMF routing domain but doing this robustly in a distributed wireless environment likely requires additional considerations outside the scope of this document.

The need for the border router to receive traffic from recognized multicast sources within the SMF routing domain is important to potentially achieve interoperability with existing routing protocols. For instance, PIM-S requires routers with locally attached multicast sources to register them to the Rendezvous Point (RP) so that nodes can join the multicast tree. In addition, if those sources are not advertised to other autonomous systems (AS) using Multicast Source Discovery Protocol (MSDP), receivers in those external networks are not able to join the multicast tree for that source.

9.4. Multiple Border Routers

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

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

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

1. Redundantly forward the multicast flows (identified by <srcAddr:dstAddr>) from each border router, performing DPD processing on a <taggerID:dstAddr> or <taggerID:srcAddr:dstAddr> basis, or
2. Use some basis to select the flow of one tagger (border router) over the others and forward packets for applicable flows (identified by <sourceAddress:dstAddr>) only for the selected "Tagger ID" until timeout or some other criteria to favor another tagger occurs.

It is RECOMMENDED that the first approach be used in the case of I-DPD operation. Additional specification may be required to describe an interoperable forwarding policy based on this second option. Note that the implementation of the second option requires that per-flow (i.e., <srcAddr::dstAddr>) state be maintained for the selected "Tagger ID".

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

10. Security Considerations

Gratuitous use of option headers can cause problems in routers. Other IP routers external to an SMF routing domains that might receive forwarded multicast should ignore SMF-specific header options when encountered. The header options types are encoded appropriately to allow for this behavior.

Here we briefly discuss several SMF denial-of-service (DoS) attack scenarios and we provide some initial recommended mitigation strategies.

A potential denial-of-service attack against SMF forwarding is possible when a malicious node has a form of wormhole access to multiple part of a network topology. In the wireless ad hoc case, a directional antenna is one way to provide such a wormhole physically. If such a node can preview forwarded packets in one part of the network and forward modified versions to another part of the network it can perform the following attack. The malicious node could reduce the TTL or Hop Limit of the packet and transmit it to the SMF node causing it to forward the packet with a limited TTL (or even drop it) and make a DPD entry that could block or limit the subsequent forwarding of later-arriving valid packets with correct TTL values. This would be a relatively low-cost, high-payoff attack that would be hard to detect and thus attractive to potential attackers. An approach of caching TTL information with DPD state and taking appropriate forwarding actions is identified in Section 5 to mitigate this form of attack.

Sequence-based packet identifiers are predictable and thus provide an opportunity for a DoS attack against forwarding. Forwarding protocols that use DPD techniques, such as SMF, may be vulnerable to DoS attacks based on spoofing packets with apparently valid packet identifier fields. In wireless environments, where SMF will most likely be used, the opportunity for such attacks may be more prevalent than in wired networks. In the case of IPv4 packets, fragmented IP packets or packets with IPsec headers applied, the DPD "identifier portions" of potential future packets that might be forwarded is highly predictable and easily subject to denial-of-service attacks against forwarding. A RECOMMENDED technique to counter this concern is for SMF implementations to generate an "internal" hash value that is concatenated with the explicit I-DPD packet identifier to form a unique identifier that is a function of the packet content as well as the visible identifier. SMF implementations could seed their hash generation with a random value to make it unlikely that an external observer could guess how to spoof packets used in a denial-of-service attack against forwarding. Since the hash computation and state is kept completely internal to SMF nodes, the cryptographic properties of this hashing would not need to be extensive and thus possibly of low complexity. Experimental implementations may determine that a lightweight hash of even only portions of packets may suffice to serve this purpose.

While H-DPD is not as readily susceptible to this form of DoS attack, it is possible that a sophisticated adversary could use side information to construct spoofing packets to mislead forwarders using 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.

11. IANA Considerations

This document raises multiple IANA Considerations. These include the IPv6 SMF_DPD hop-by-hop Header Extension defined and multiple Type-Length-Value (TLV) constructs [RFC5444]) to be used with NHDP [RFC6130]operation as needed to support different forms of SMF operation. There is one message TLV type and one address TLV type needed to be assigned for SMF purposes as discussed in Section 8.1.

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

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

11.1. IPv6 SMF-DPD Header Extension

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

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

ietf:manet:smf:taggerIdTypes

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

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

11.2. SMF Type-Length-Value

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

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

ietf:manet:packetbb:nhdp:smf:relayAlgorithmID

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

This specification registers the following Relay Algorithm ID Type values shown in Table 11 in the registry "ietf:manet:packetbb:nhdp:smf:relayAlgorithmID

12. Acknowledgments

Many of the concepts and mechanisms used and adopted by SMF resulted from many years of discussion and related work within the MANET working group since the late 1990s. There are obviously many contributors to past discussions and related draft documents within the working group that have influenced the development of SMF concepts that deserve acknowledgment. In particular, the document is largely a direct product of the earlier SMF design team within the IETF MANET working group and borrows text and implementation ideas from the related individuals and activities. Some of the direct contributors who have been involved in design, content editing, prototype implementation, major commenting, and core discussions are listed below in alphabetical order. We appreciate all the input and feedback from the many community members and early implementation users we have heard from that are not on this list as well.

• Key contributors/authors in alphabetical order:
• Brian Adamson
• Teco Boot
• Ian Chakeres
• Thomas Clausen
• Justin Dean
• Brian Haberman
• Ulrich Herberg
• Charles Perkins
• Pedro Ruiz
• Fred Templin
• Maoyu Wang

The RFC text was produced using Marshall Rose's xml2rfc tool and Bill Fenner's XMLmind add-ons.

13. References

13.1. Normative References

13.2. Informative References

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

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

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

Appendix A.1. E-CDS Relay Set Selection Overview

The E-CDS relay set selection requires 2-hop neighborhood information collected through NHDP or another process. Relay nodes, in E-CDS SMF selection, are "self-elected" using a router identifier (Router ID) and an optional nodal metric, referred to here as "Router Priority" for all 1-hop and 2-hop neighbors. To ensure proper relay set self-election, the Router ID and Router Priority MUST be consistent among participating nodes. It is RECOMMENDED that NHDP be used to share Router ID and Router Priority through the use of SMF_TYPE:E-CDS TLVs as described in this appendix.. The Router ID is a logical identification that MUST be consistent across interoperating SMF neighborhoods and it is RECOMMENDED to be chosen as the numerically largest address contained in a nodes "Neighbor Address List" as defined in NHDP. The E-CDS self-election process can be summarized as follows:

1. If an SMF node has a higher ordinal (Router Priority, Router ID) than all of its symmetric neighbors, it elects itself to act as a forwarder for all received multicast packets,
2. Else, if there does not exist a path from the neighbor with largest (Router Priority, Router ID) to any other neighbor, via neighbors with larger values of (Router Priority, Router ID), then it elects itself to the relay set.

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

Appendix A.2. E-CDS Forwarding Rules

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

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

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

Appendix A.3. E-CDS Neighborhood Discovery Requirements

It is possible to perform E-CDS relay set selection without modification of NHDP, basing the self-election process exclusively on the "Neighbor Address List" of participating SMF nodes. For example by setting the "Router Priority" to a default value and selecting the "Router ID" as the numerically largest address contained in the "Neighbor Address List". However steps MUST be taken to insure that all NHDP enabled nodes not using SMF_TYPE:E-CDS full type message TLVs are in fact running SMF E-CDS with the same methods for selecting "Router Priority" and "Router ID", otherwise incorrect forwarding may occur. Note that SMF nodes with higher "Router Priority" values will be favored as relays over nodes with lower "Router Priority". Thus, preferred relays MAY be administratively configured to be selected when possible. Additionally, other metrics (e.g. nodal degree, energy capacity, etc) may also be taken into account in constructing a "Router Priority" value. When using “Router Priority” with multiple interfaces all interfaces on a node MUST use and advertise a common "Router Priority" value. A nodes “Router Priority” value may be administratively or algorithmically selected. The method of selection does not need to be the same among different nodes.

E-CDS relay set selection may be configured to be influenced by statically configured CF relays that are identified via NHDP or other means. Nodes advertising CF through NHDP may be considered E-CDS SMF nodes with maximal "Router Priority".

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

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

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

bit 1-7: contain the unsigned "Router Priority" value, 0-127, which is associated with the "Neighbor Address List".

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

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  ...              |   SMF_TYPE    |1|0|0|1|0|0|   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     E-CDS     |0|0|0|0|0|0|0|1|R|  priority   |     ...       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

[RFC5444] are supported. SMF_NBR_TYPE:E-CDS value fields are defined thus:

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

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

bit 1-7: contain the unsigned "Router Priority" value, 0-127, which is associated with the appropriate address(es).

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

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  ...              | SMF_NBR_TYPE  |1|0|0|1|0|0|   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     E-CDS     |0|0|0|0|0|0|0|1|R|  priority   |     ...       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  ...              | SMF_NBR_TYPE  |1|0|1|1|0|1|   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     E-CDS     |  index-start  |   index-end   |    length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R|  priority0  |R|  priority1  |      ...      |R|  priorityN  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 9 , specifies that all address(es) contained in the address block are running SMF using the E-CDS algorithm and all address(es) share the value field and therefore the same "Router Priority".Figure 10, specifies that address(es) contained in the address block from index-start to index-end inclusive are running SMF using the E-CDS algorithm. Each address is associated with its own value byte and therefore its own "Router Priority".

Appendix A.4. E-CDS Selection Algorithm

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

The tuple of "Router Priority" and "Router ID" is used in E-CDS relay set selection. Precedence is given to the "Router Priority" portion and the "Router ID" value is used as a tie-breaker. The evaluation of this tuple is referred to as "RtrPri(n)" in the description below where "n" references a specific node. Note it is possible that the "Router Priority" portion may be optional and the evaluation of "RtrPri()" be solely based upon the unique "Router ID". Since there MUST NOT be any duplicate "Router ID" values among SMF nodes, a comparison of RtrPri(n) between any two nodes will always be an inequality. The use of nodal degree for calculating "Router Priority" is RECOMMENDED as default and the largest IP address in the "Neighbor Address List" as advertised by NHDP MUST be used as the "Router ID". NHDP provides all interface address throughout the 2-hop neighborhood through HELLO messages, so explicitly conveying a "Router ID" is not necessary. The following steps describe a basic algorithm for conducting E-CDS relay selection for a node "n0":

1. Initialize the set "N1" with tuples ("Router Priority", "Router ID", "Neighbor Address List" for each 1-hop neighbor of "n0".
2. If "N1" has less than 2 tuples, then "n0" does not elect itself as a relay and no further steps are taken.
3. Initialize the set "N2" with tuples ("Router Priority", "Router ID", "2-hop address") for each "2-hop address" of "n0", where "2-hop address" is defined in NHDP.
4. If "RtrPri(n0)" is greater than that of all tuples in the union of "N1" and "N2", then "n0" selects itself as a relay and no further steps are taken.
5. Initialize all tuples in the union of "N1" and "N2" as "unvisited".
6. Find the tuple "n1_Max" that has the largest "RtrPri()" of all tuples in "N1"
7. Initialize queue "Q" to contain "n1_Max", marking "n1_Max" as "visited"
8. While node queue "Q" is not empty, remove node "x" from the head of "Q", and for each 1-hop neighbor "n" of node "x" (excluding "n0") that is not marked "visited"
   1. Mark node "n" as "visited"
   2. If "RtrPri(n)" is greater than "RtrPri(n0), append "n" to "Q"
9. If any tuple in "N1" remains "unvisited", then "n0" selects itself as a relay. Otherwise "n0" does not act as a relay.

Note these steps are re-evaluated upon neighborhood status changes. Steps 5 through 8 of this procedure describe an approach to a path search. The purpose of this path search is to determine if paths exist from the 1-hop neighbor with maximum "RtrPri()" to all other 1-hop neighbors without traversing an intermediate node with a "RtrPri()" value less than "RtrPri(n0)". These steps comprise a breadth-first traversal that evaluates only paths that meet that criteria. If all 1-hop neighbors of "n0" are "visited" during this traversal, then the path search has succeeded and node "n0" does not need to provide relay. It can be assumed that other nodes will provide relay operation to ensure SMF connectivity.

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

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

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

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

Appendix B.1. S-MPR Relay Set Selection Overview

The S-MPR algorithm uses bi-directional 1-hop and 2-hop neighborhood information collected via NHDP to select, from a node's 1-hop neighbors, a set of relays that will cover the node's entire 2-hop neighbor set upon forwarding. The algorithm described uses a "greedy" heuristic of first picking the 1-hop neighbor who will cover the most 2-hop neighbors. Then, excluding those 2-hop neighbors that have been covered, additional relays from its 1-hop neighbor set are iteratively selected until the entire 2-hop neighborhood is covered. Note that 1-hop neighbors also identified as 2-hop neighbors are considered as 1-hop neighbors only.

NHDP HELLO messages supporting S-MPR forwarding operation SHOULD use the TLVs defined in Section 8.1 using the S-MPR extended type. The value field of an address block TLV which has a full type value of SMF_NBR_TYPE:S-MPR is defined in Table 15 such that signaling of MPR selections to 1-hop neighbors is possible. The value field of a message block TLV which has a full type value of SMF_TYPE:S-MPR is defined in Table 14 such that signaling of "Router Priority" (described as "WILLINGNESS" in [RFC3626]) to 1-hop neighbors is possible. It is important to note that S-MPR forwarding is dependent upon the previous hop of an incoming packet. An S-MPR node MUST forward packets only for neighbors which have explicitly selected it as a multi-point relay (i.e., its "selectors"). There are also some additional requirements for duplicate packet detection to support S-MPR SMF operation that are described below.

For multiple interface operation, MPR selection SHOULD be conducted on a per-interface basis. However, it is possible to economize MPR selection among multiple interfaces by selecting common MPRs to the extent possible.

Appendix B.2. S-MPR Forwarding Rules

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

1. If the previous-hop transmitter has selected the current node as an MPR,
   1. The packet identifier is checked against the DPD state for each possible outbound interface, including the <srcIface>.
   2. If the packet is not a duplicate for an outbound interface, the packet is forwarded on that interface and a DPD entry is made for the given packet identifier for the interface.
   3. If the packet is a duplicate, no action is taken for that interface.
2. Else, if the previous-hop transmitter is a 1-hop symmetric neighbor,
   1. A DPD entry is added for that packet for the <srcIface>, but the packet is not forwarded.
3. Otherwise, no action is taken.

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

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

Appendix B.3. S-MPR Neighborhood Discovery Requirements

Nodes may optionally signal a "Router Priority" value to their one hop neighbors by using the SMF_TYPE:S-MPR message block TLV value field. If the value field is omitted, a default "Router Priority" value of 64 is to be assumed. This is summarized here:

Where <value> is a one octet long bit field defined as:

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

bit 1-7: contain the "Router Priority" value, 0-127, which is associated with the "Neighbor Address List".

"Router Priority" values for S-MPR are interpreted in the same fashion as "WILLINGNESS" ([RFC3626])with value 0 indicating a node will NEVER forward and value 127 indicating a node will ALWAYS forward. Values 1-126 indicate how likely a S-MPR SMF router will be selected as an MPR by a neighboring SMF node, with higher values increasing the likelihood. Combinations of value field lengths and values other than specified here are NOT permitted and SHOULD be ignored. Below is an example SMF_TYPE:S-MPR message TLV.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  ...              |   SMF_TYPE    |1|0|0|1|0|0|   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     S-MPR     |0|0|0|0|0|0|0|1|R|  priority   |     ...       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

Where <value>, if present, is a one octet bit field defined as:

bit 0: The leftmost bit is the M bit. When set indicates MPR selection of the relevant interface, represented by the associated address(es), by the originator node of the NHDP HELLO message. When unset, indicates the originator node of the NHDP HELLO message has not selected the relevant interfaces, represented by the associated address(es), as its MPR.

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

Combinations of value field lengths and number of addresses other than specified here are NOT permitted and SHOULD be ignored. All bits, excepting the leftmost bit, are RESERVED and SHOULD be set to 0.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  ...              | SMF_NBR_TYPE  |1|1|0|1|0|0|   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     S-MPR     |  start-index  |0|0|0|0|0|0|0|1|M|  reserved   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

Appendix B.4. S-MPR Selection Algorithm

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

1. Initialize the set "MPR" to empty.
2. Initialize the set "N1" to include all 1-hop neighbors of "n0".
3. Initialize the set "N2" to include all 2-hop neighbors, excluding "n0" and any nodes in "N1". Nodes which are only reachable via "N1" nodes with router priority values of NEVER are also excluded.
4. For each interface "y" in "N1", initialize a set "N2(y)" to include any interfaces in "N2" that are 1-hop neighbors of "y".
5. For each interface "x" in "N1" with a router priority value of "ALWAYS" (or using CF relay algorithm), select "x" as a MPR:
   1. Add "x" to the set "MPR" and remove "x" from "N1".
   2. For each interface "z" in "N2(x)", remove "z" from "N2"
   3. For each interface "y" in "N1", remove any interfaces in "N2(x)" from "N2(y)"
6. For each interface "z" in "N2", initialize the set "N1(z)" to include any interfaces in "N1" that are 1-hop neighbors of "z".
7. For each interface "x" in "N2" where "N1(x)" has only one member, select "x" as a MPR:
   1. Add "x" to the set "MPR" and remove "x" from "N1".
   2. For each interface "z" in "N2(x)", remove "z" from "N2" and delete "N1(z)"
   3. For each interface "y" in "N1", remove any interfaces in "N2(x)" from "N2(y)"
8. While "N2" is not empty, select the interface "x" in "N1" with the largest router priority which has the number of members in "N_2(x)" as a MPR:
   1. Add "x" to the set "MPR" and remove "x" from "N1".
   2. For each interface "z" in "N2(x)", remove "z" from "N2"
   3. For each interface "y" in "N1", remove any interfaces in "N2(x)" from "N2(y)"

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

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

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

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

Appendix C.1. MPR-CDS Relay Set Selection Overview

The MPR-CDS relay set selection process is based upon the MPR selection process of the S-MPR algorithm with the added refinement of a distributed technique for subsequently down-selecting to a common reduced, shared relay set. A node ordering (or "prioritization") metric is used as part of this down-selection process like the E-CDS algorithm, this metric can be based upon node address(es) or some other unique router identifier (e.g. "Router ID" based on largest address contained within the "Neighbor Address List") as well as an additional "Router Priority" measure, if desired. The process for MPR-CDS relay selection is as follows:

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

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

Appendix C.2. MPR-CDS Forwarding Rules

The forwarding rules for MPR-CDS are common with those of E-CDS. Any SMF node that has selected itself as a relay performs DPD and forwards all non-duplicative multicast traffic allowed by the present forwarding policy. Packet previous hop knowledge is not needed for forwarding decisions when using MPR-CDS.

1. Upon packet reception, DPD is performed. Note MPR-CDS require one duplicate table for the set of interfaces associated with the relay set selection.
2. If the packet is a duplicate, no further action is taken.
3. If the packet is non-duplicative:
   1. A DPD entry is added for the packet identifier
   2. The packet is forwarded out all interfaces associated with the relay set selection

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

Appendix C.3. MPR-CDS Neighborhood Discovery Requirements

The neighborhood discovery requirements for MPR-CDS have commonality with both the S-MPR and E-CDS algorithms. MPR-CDS selection operation requires 2-hop neighbor knowledge as provided by the NHDP protocol [RFC6130] or from external sources. Unlike S-MPR operation, there is no need for associating link-layer address information with 1-hop neighbors since MPR-CDS forwarding is independent of the previous hop similar to E-CDS forwarding.

To advertise an optional "Router Priority" value or "WILLINGNESS" an originating node may use the message TLV of type SMF_TYPE:MPR-CDS which shares a common <value> format with both SMF_TYPE:E-CDS Table 12 and SMF_TYPE:S-MPR Table 14.

MPR-CDS only requires 1-hop knowledge of "Router Priority" for correct operation. In the S-MPR phase of MPR-CDS selection, MPRs are dynamically determined by each node and selections MUST be advertised and dynamically updated using NHDP or an equivalent protocol or mechanism. Therefore the <value> field of the SMF_NBR_TYPE:MPR-CDS type TLV shares a common format with SMF_NBR_TYPE:S-MPR Table 15 to convey MPR selection.

Appendix C.4. MPR-CDS Selection Algorithm

This section describes an algorithm for the MPR-CDS selection process. Note that the selection described is with respect to a specific interface of the node performing selection and other node interfaces referenced are reachable from this reference node interface. An ordered tuple of "Router Priority" and "Router ID" is used in MPR-CDS relay set selection. The "Router ID" value should be set to the largest advertised address of a given node, this information is provided to one hop neighbors via NHDP by default. Precedence is given to the "Router Priority" portion and the "Router ID" value is used as a tie-breaker. The evaluation of this tuple is referred to as "RtrPri(n)" in the description below where "n" references a specific node. Note it is possible that the "Router Priority" portion may be optional and the evaluation of "RtrPri()" be solely based upon the unique "Router ID". Since there MUST NOT be any duplicate address values among SMF nodes, a comparison of RtrPri(n) between any two nodes will always be an inequality. The following steps, repeated upon any changes detected within the 1-hop and 2-hop neighborhood, describe a basic algorithm for conducting MPR-CDS selection for a node interface "n0":

1. Perform steps 1-8 of Appendix Appendix B.4 to select MPRs from the set of 1-hop neighbors of "n0" and notify/update neighbors of selections.
2. Upon being selected as an MPR (or any change in the set of nodes selecting "n0" as an MPR):
   1. If no neighbors have selected "n0" as an MPR, "n0" does not act as a relay and no further steps are taken until a change in neighborhood topology or selection status occurs.
   2. Determine the node "n1_max" that has the maximum "RtrPri()" of all 1-hop neighbors.
   3. If "RtrPri(n0)" is greater than "RtrPri(n1_max)", then "n0" selects itself as a relay for all multicast packets,
   4. Else, if "n1_max" has selected "n0" as an MPR, then "0" selects itself as a relay for all multicast packets.
   5. Otherwise, "n0" does not act as a relay.

It is possible to extend this algorithm to consider neighboring SMF nodes that are known to be statically configured for CF (always relaying). The modification to the above algorithm is to process such nodes as having a maximum possible "Router Priority" value. This is the same as the case for participating nodes that have been configured with a S-MPR "WILLINGNESS" value of "WILL_ALWAYS". It is expected that nodes configured for CF and participating in NHDP would indicate their status with use of the SMF_TYPE TLV type in their NHDP_HELLO message TLV block. It is important to note however that CF nodes will not select MPR nodes and therefore cannot guarantee connectedness.

Authors' Addresses