Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 6621


Simplified Multicast Forwarding

Part 2 of 3, p. 20 to 39
Prev RFC Part       Next RFC Part


prevText      Top      Up      ToC       Page 20 
7.  Relay Set Selection

   SMF is flexible in its support of different reduced relay set
   mechanisms for efficient flooding, the constraints imposed herein
   being detailed in this section.

7.1.  Non-Reduced Relay Set Forwarding

   SMF implementations MUST support CF as a basic forwarding mechanism
   when reduced relay set information is not available or not selected
   for operation.  In CF mode, each router transmits a packet once that
   has passed the SMF forwarding rules.  The DPD techniques described in
   Section 6 are critical to proper operation and prevention of
   duplicate packet retransmissions by the same relays.

7.2.  Reduced Relay Set Forwarding

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

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

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

Top      Up      ToC       Page 21 
   Here is a recommended criteria list for SMF relay set selection
   algorithm candidates:

   1.  Robustness to topological dynamics and mobility

   2.  Localized election or coordination of any relay sets

   3.  Reasonable minimization of CDS relay set size given the above

   4.  Heuristic support for preference or election metrics

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

   Figure 5 depicts an information flow diagram of possible relay set
   control options.  The SMF Relay Set State represents the information
   base that is used by SMF in the forwarding decision process.  The
   diagram demonstrates that the SMF Relay Set State may be determined
   by three fundamentally different methods:

   o  Independent operation with NHDP [RFC6130] input providing dynamic
      network neighborhood adjacency information, used by a particular
      relay set selection algorithm.

   o  Slave operation with an existing unicast MANET routing protocol,
      capable of providing CDS election information for use by SMF.

   o  Cross-layer operation that may involve L2 triggers or information
      describing neighbors or links.

   Other heuristics to influence and control election can come from
   network management or other interfaces as shown on the right of
   Figure 5.  CF mode simplifies the control and does not require other
   input but relies solely on DPD.

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

             Figure 5: SMF Reduced Relay Set Information Flow

   Following is further discussion of the three styles of SMF operation
   with reduced relay sets as illustrated in Figure 5:

   1.  Independent operation: In this case, SMF operates independently
       from any unicast routing protocols.  To support reduced relay
       sets, SMF MUST perform its own relay set selection using
       information gathered from signaling.  It is RECOMMENDED that an
       associated NHDP process be used for this signaling.  NHDP
       messaging SHOULD be appended with additional [RFC5444] type-
       length-value (TLV) content as to support SMF-specific
       requirements as discussed in [RFC6130] and to support specific
       relay set operation as described in the appendices of this
       document or future specifications.  Unicast routing protocols may
       coexist, even using the same NHDP process, but signaling that
       supports reduced relay set selection for SMF is independent of
       these protocols.

Top      Up      ToC       Page 23 
   2.  Operation with CDS-aware unicast routing protocol: In this case,
       a coexistent unicast routing protocol provides dynamic relay set
       state based upon its own control plane CDS or neighborhood
       discovery information.

   3.  Cross-layer operation: In this case, SMF operates using
       neighborhood status and triggers from a cross-layer information
       base for dynamic relay set selection and maintenance (e.g.,
       lower-link layer).

8.  SMF Neighborhood Discovery Requirements

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

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

   1.  1-hop neighbor link sensing and bidirectionality checks of
       neighbor links,

   2.  2-hop neighborhood discovery including collection of 2-hop
       neighbors and connectivity information,

   3.  Collection and maintenance of the above information across
       multiple interfaces, and

   4.  A method for signaling SMF information throughout the 2-hop
       neighborhood through the use of TLV extensions.

   Appendices A-C of this document describe CDS-based relay set
   selection algorithms that can achieve efficient SMF operation, even
   in dynamic, mobile networks and each of the algorithms has been
   initially experimented with in a working SMF prototype [MDDA07].
   When using these algorithms in conjunction with NHDP, a method
   verifying neighbor SMF operation is required in order to ensure
   correct relay set selection.  NHDP, along with SMF operation

Top      Up      ToC       Page 24 
   verification, provides the necessary information required by these
   algorithms to conduct relay set selection.  Verification of SMF
   operation may be done administratively or through the use of the SMF
   relay algorithms TLVs defined in the following subsections.  Use of
   the SMF relay algorithm TLVs is RECOMMENDED when using NHDP for SMF
   neighborhood discovery.

   Section 8.1 specifies SMF-specific TLV types, supporting general SMF
   operation or supporting the algorithms described in the appendices.
   The appendices describing several relay set algorithms also specify
   any additional requirements for use with NHDP and reference the
   applicable TLV types as needed.

8.1.  SMF Relay Algorithm TLV Types

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

8.1.1.  SMF Message TLV Type

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

   This document defines a Message TLV type as specified in Table 6
   conforming to [RFC5444].  The TLV extended type field is used to
   contain the sender's "Relay Algorithm Type".  The interpretation of
   the "value" content of these TLVs is defined per "Relay Algorithm
   Type" and may contain algorithm-specific information.

Top      Up      ToC       Page 25 
          |               | TLV Syntax     | Field Values       |
          | type          | <tlv-type>     | SMF_TYPE           |
          | extended type | <tlv-type-ext> | <relayAlgorithmId> |
          | length        | <length>       | variable           |
          | value         | <value>        | variable           |

                       Table 6: SMF Type Message TLV

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

   Values for the <relayAlgorithmId> are defined in Table 7.  The table
   provides value assignments, future IANA assignment spaces, and an
   experimental space.  The experimental space use MUST NOT assume
   uniqueness; thus, it SHOULD NOT be used for general interoperable
   deployment prior to official IANA assignment.

   |  Type Value |    Extended Type   |            Algorithm           |
   |             |        Value       |                                |
   |   SMF_TYPE  |          0         |               CF               |
   |   SMF_TYPE  |          1         |              S-MPR             |
   |   SMF_TYPE  |          2         |              E-CDS             |
   |   SMF_TYPE  |          3         |             MPR-CDS            |
   |   SMF_TYPE  |        4-127       |  Future Assignment STD action  |
   |   SMF_TYPE  |       128-239      |     No STD action required     |
   |   SMF_TYPE  |       240-255      |       Experimental Space       |

                 Table 7: SMF Relay Algorithm Type Values

   Acceptable <length> and <value> fields of an SMF_TYPE TLV are
   dependent on the extended type value (i.e., relay algorithm type).
   The appropriate algorithm type, as conveyed in the <tlv-type-ext>
   field, defines the meaning and format of its TLV <value> field.  For
   the algorithms defined by this document, see the appropriate appendix
   for the <value> field format.

8.1.2.  SMF Address Block TLV Type

   An Address Block TLV type, denoted SMF_NBR_TYPE (i.e., SMF neighbor
   relay algorithm) is specified in Table 8.  This TLV enables CDS relay
   algorithm operation and configuration to be shared among 2-hop

Top      Up      ToC       Page 26 
   neighborhoods.  Some relay algorithms require 2-hop neighbor
   configuration in order to correctly select relay sets.  It is also
   useful when mixed relay algorithm operation is possible.  Some
   examples of mixed use are outlined in the appendices.

   The message SMF_TYPE TLV and Address Block SMF_NBR_TYPE TLV types
   share a common format.

          |               | TLV syntax     | Field Values       |
          | type          | <tlv-type>     | SMF_NBR_TYPE       |
          | extended type | <tlv-type-ext> | <relayAlgorithmId> |
          | length        | <length>       | variable           |
          | value         | <value>        | variable           |

                    Table 8: SMF Type Address Block TLV

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

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

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

9.  SMF Border Gateway Considerations

   It is expected that SMF will be used to provide simple forwarding of
   multicast traffic within a MANET or mesh routing topology.  A border
   router gateway approach should be used to allow interconnection of
   SMF routing domains with networks using other multicast routing
   protocols, such as PIM.  It is important to note that there are many
   scenario-specific issues that should be addressed when discussing
   border multicast routers.  At the present time, experimental
   deployments of SMF and PIM border router approaches have been
   demonstrated [DHS08].  Some of the functionality border routers may
   need to address includes the following:

Top      Up      ToC       Page 27 
   1.  Determination of which multicast group traffic transits the
       border router whether entering or exiting the attached SMF
       routing domain.

   2.  Enforcement of TTL/hop limit threshold or other scoping policies.

   3.  Any marking or labeling to enable DPD on ingressing packets.

   4.  Interface with exterior multicast routing protocols.

   5.  Possible operation with multiple border routers (presently beyond
       the scope of this document).

   6.  Provisions for participating non-SMF devices (routers or hosts).

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

9.1.  Forwarded Multicast Groups

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

   For outbound traffic, SMF border routers perform duplicate packet
   detection and forward non-duplicate traffic that meets TTL/hop limit
   and scoping criteria to interfaces external to the SMF routing
   domain.  Appropriate IP multicast routing (e.g., PIM-based solutions)
   on those interfaces can make further forwarding decisions with
   respect to the multicast packet.  Note that the presence of multiple

Top      Up      ToC       Page 28 
   border routers associated with a MANET routing domain raises
   additional issues.  This is further discussed in Section 9.4 but
   further work is expected to be needed here.

9.2.  Multicast Group Scoping

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

   1.  TTL scoping.

   2.  Administrative scoping.

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

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

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

Top      Up      ToC       Page 29 
9.3.  Interface with Exterior Multicast Routing Protocols

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

   1.  A mechanism by which border routers gather membership information

   2.  A mechanism by which multicast sources are known by the border

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

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

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

9.4.  Multiple Border Routers

   An SMF routing domain might be deployed with multiple participating
   routers having connectivity to external, fixed-infrastructure
   networks.  Allowing multiple routers to forward multicast traffic to/
   from the SMF routing domain can be beneficial since it can increase
   reliability and provide better service.  For example, if the SMF

Top      Up      ToC       Page 30 
   routing domain were to fragment with different SMF routers
   maintaining connectivity to different border routers, multicast
   service could still continue successfully.  But, the case of multiple
   border routers connecting an SMF routing domain to external networks
   presents several challenges for SMF:

   1.  Handling duplicate unmarked IPv4 or IPv6 (without IPsec
       encapsulation or DPD option) packets possibly injected by
       multiple border routers.

   2.  Handling of duplicate traffic injected by multiple border routers
       by source-based relay algorithms.

   3.  Determining which border router(s) will forward outbound
       multicast traffic.

   4.  Additional challenges with interfaces to exterior multicast
       routing protocols.

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

   1.  Redundantly forward the multicast flows (identified by <srcAddr:
       dstAddr>) from each border router, performing DPD processing on a
       <TaggerID:dstAddr> or <TaggerID:srcAddr:dstAddr> basis, or

   2.  Use some basis to select the flow of one tagger (border router)
       over the others and forward packets for applicable flows
       (identified by <sourceAddress:dstAddr>) only for the selected
       TaggerId until timeout or some other criteria to favor another
       tagger occurs.

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

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

10.  Security Considerations

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

   This section briefly discusses several SMF denial-of-service (DoS)
   attack scenarios and provides some initial recommended mitigation

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

   Sequence-based packet identifiers are predictable and thus provide an
   opportunity for a DoS attack against forwarding.  Forwarding
   protocols that use DPD techniques, such as SMF, may be vulnerable to
   DoS attacks based on spoofing packets with apparently valid packet
   identifier fields.  In wireless environments, where SMF will most
   likely be used, the opportunity for such attacks may be more
   prevalent than in wired networks.  In the case of IPv4 packets,
   fragmented IP packets, or packets with IPsec headers applied, the DPD
   "identifier portions" of potential future packets that might be
   forwarded is highly predictable and easily subject to DoS attacks
   against forwarding.  A RECOMMENDED technique to counter this concern
   is for SMF implementations to generate an "internal" hash value that
   is concatenated with the explicit I-DPD packet identifier to form a

Top      Up      ToC       Page 32 
   unique identifier that is a function of the packet content as well as
   the visible identifier.  SMF implementations could seed their hash
   generation with a random value to make it unlikely that an external
   observer could guess how to spoof packets used in a denial-of-service
   attack against forwarding.  Since the hash computation and state is
   kept completely internal to SMF routers, the cryptographic properties
   of this hashing would not need to be extensive and thus possibly of
   low complexity.  Experimental implementations may determine that even
   a lightweight hash of only portions of packets may suffice to serve
   this purpose.

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

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

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

   Furthermore, when the MANET Neighborhood Discovery Protocol [RFC6130]
   is used, the security considerations described in [RFC6130] also

11.  IANA Considerations

   This document defines one IPv6 Hop-by-Hop Option, a type for which
   has been allocated from the IPv6 "Destination Options and Hop-by-Hop
   Options" registry of [RFC2780].

   This document creates one registry called "TaggerId Types" for
   recording TaggerId types, (TidTy), as a sub-registry in the "IPv6
   Parameters" registry.

   This document registers one well-known multicast address from each of
   the IPv4 and IPv6 multicast address spaces.

   This document defines one Message TLV, a type for which has been
   allocated from the "Message TLV Types" registry of [RFC5444].

   Finally, this document defines one Address Block TLV, a type for
   which has been allocated from the "Address Block TLV Types" registry
   of [RFC5444].

Top      Up      ToC       Page 33 
11.1.  IPv6 SMF_DPD Header Extension Option Type

   IANA has allocated an IPv6 Option Type from the IPv6 "Destination
   Options and Hop-by-Hop Options" registry of [RFC2780], as specified
   in Table 9.

   | Hex Value |       Binary Value      | Description | Reference     |
   |           |    act | chg | rest     |             |               |
   |     8     |     00 |  0  | 01000    | SMF_DPD     | This Document |

                   Table 9: IPv6 Option Type Allocation

11.2.  TaggerId Types (TidTy)

   A portion of the option data content in the SMF_DPD is the Tagger
   Identifier Type (TidTy), which provides a context for the optionally
   included TaggerId.

   IANA has created a registry for recording TaggerId Types (TidTy),
   with initial assignments and allocation policies, as specified in
   Table 10.

   | Type | Mnemonic | Description                        | Reference  |
   |   0  |   NULL   | No TaggerId field is present       | This       |
   |      |          |                                    | document   |
   |   1  |  DEFAULT | A TaggerId of non-specific context | This       |
   |      |          | is present                         | document   |
   |   2  |   IPv4   | A TaggerId representing an IPv4    | This       |
   |      |          | address is present                 | document   |
   |   3  |   IPv6   | A TaggerId representing an IPv6    | This       |
   |      |          | address is present                 | document   |
   |  4-7 |          | Unassigned                         |            |

                         Table 10: TaggerId Types

   For allocation of unassigned values 4-7, IETF Review [RFC5226] is

Top      Up      ToC       Page 34 
11.3.  Well-Known Multicast Address

   IANA has allocated an IPv4 multicast address "SL-MANET-ROUTERS"
   ( from the "Internetwork Control Block ( (224.0.1/24))" sub-registry of the "IPv4 Multicast
   Address" registry.

   IANA has allocated an IPv6 multicast address "SL-MANET-ROUTERS" from
   the "Site-Local Scope Multicast Addresses" sub-sub-registry of the
   "Fixed Scope Multicast Addresses" sub-registry of the "INTERNET

11.4.  SMF TLVs

11.4.1.  Expert Review for Created Type Extension Registries

   Creation of Address Block TLV Types and Message TLV Types in
   registries of [RFC5444], and hence in the HELLO-message-specific
   registries of [RFC6130], entails creation of corresponding Type
   Extension registries for each such type.  For such Type Extension
   registries, where an Expert Review is required, the designated expert
   SHOULD take the same general recommendations into consideration as
   those specified by [RFC5444].

11.4.2.  SMF Message TLV Type (SMF_TYPE)

   This document defines one Message TLV Type, "SMF_TYPE", which has
   been allocated from the "HELLO Message-Type-specific Message TLV
   Types" registry, defined in [RFC6130].

   This created a new Type Extension registry, with initial assignments
   as specified in Table 11.

   |   Name   | Type |    Type   | Description        | Allocation     |
   |          |      | Extension |                    | Policy         |
   | SMF_TYPE |  128 |   0-255   | Specifies relay    | Section 11.4.4 |
   |          |      |           | algorithm          |                |
   |          |      |           | supported by the   |                |
   |          |      |           | SMF router,        |                |
   |          |      |           | originating the    |                |
   |          |      |           | HELLO message,     |                |
   |          |      |           | according to       |                |
   |          |      |           | Section 11.4.4.    |                |

          Table 11: SMF_TYPE Message TLV Type Extension Registry

Top      Up      ToC       Page 35 
11.4.3.  SMF Address Block TLV Type (SMF_NBR_TYPE)

   This document defines one Address Block TLV Type, "SMF_NBR_TYPE",
   which has been allocated from the "HELLO Message-Type-specific
   Address Block TLV Types" registry, defined in [RFC6130].

   This has created a new Type Extension registry, with initial
   assignments as specified in Table 12.

   |     Name     |  Type  |    Type   | Description     | Allocation  |
   |              |        | Extension |                 | Policy      |
   | SMF_NBR_TYPE |   128  |   0-255   | Specifies relay | Section     |
   |              |        |           | algorithm       | 11.4.4      |
   |              |        |           | supported by    |             |
   |              |        |           | the SMF router  |             |
   |              |        |           | corresponding   |             |
   |              |        |           | to the          |             |
   |              |        |           | advertised      |             |
   |              |        |           | address,        |             |
   |              |        |           | according to    |             |
   |              |        |           | Section 11.4.4. |             |

     Table 12: SMF_NBR_TYPE Address Block TLV Type Extension Registry

11.4.4.  SMF Relay Algorithm ID Registry

   Types for the Type Extension Registries for the SMF_TYPE Message TLV
   and the SMF_NBR_TYPE Address Block TLV are unified in this single SMF
   Relay Algorithm ID Registry, defined in this section.

   IANA has created a registry for recording Relay Algorithm
   Identifiers, with initial assignments and allocation policies as
   specified in Table 13.

Top      Up      ToC       Page 36 
          | Value   | Name    | Description | Allocation Policy |
          | 0       | CF      | Section 4   |                   |
          | 1       | S-MPR   | Appendix B  |                   |
          | 2       | E-CDS   | Appendix A  |                   |
          | 3       | MPR-CDS | Appendix C  |                   |
          | 4-127   |         | Unassigned  | Expert Review     |
          | 128-255 |         | Unassigned  | Experimental Use  |

                 Table 13: Relay Set Algorithm Type Values

   A specification requesting an allocation from the 4-127 range from
   the SMF Relay Algorithm ID Registry MUST specify the interpretation
   of the <value> field (if any).

12.  Acknowledgments

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

      Brian Adamson
      Teco Boot
      Ian Chakeres
      Thomas Clausen
      Justin Dean
      Brian Haberman
      Ulrich Herberg
      Charles Perkins
      Pedro Ruiz
      Fred Templin
      Maoyu Wang

Top      Up      ToC       Page 37 
13.  References

13.1.  Normative References

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

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

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

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC2644]  Senie, D., "Changing the Default for Directed Broadcasts
              in Routers", BCP 34, RFC 2644, August 1999.

   [RFC2780]  Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
              Values In the Internet Protocol and Related Headers",
              BCP 37, RFC 2780, March 2000.

   [RFC3174]  Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
              (SHA1)", RFC 3174, September 2001.

   [RFC3626]  Clausen, T. and P. Jacquet, "Optimized Link State Routing
              Protocol (OLSR)", RFC 3626, October 2003.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

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

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC5444]  Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
              "Generalized Mobile Ad Hoc Network (MANET) Packet/Message
              Format", RFC 5444, February 2009.

   [RFC5614]  Ogier, R. and P. Spagnolo, "Mobile Ad Hoc Network (MANET)
              Extension of OSPF Using Connected Dominating Set (CDS)
              Flooding", RFC 5614, August 2009.

Top      Up      ToC       Page 38 
   [RFC5771]  Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for
              IPv4 Multicast Address Assignments", BCP 51, RFC 5771,
              March 2010.

   [RFC6130]  Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
              Network (MANET) Neighborhood Discovery Protocol (NHDP)",
              RFC 6130, April 2011.

13.2.  Informative References

   [CDHM07]   Chakeres, I., Danilov, C., Henderson, T., and J. Macker,
              "Connecting MANET Multicast", IEEE MILCOM
              2007 Proceedings, 2007.

   [DHG09]    Danilov, C., Henderson, T., Goff, T., Kim, J., Macker, J.,
              Weston, J., Neogi, N., Ortiz, A., and D. Uhlig,
              "Experiment and field demonstration of a 802.11-based
              ground-UAV mobile ad-hoc network", Proceedings of the 28th
              IEEE conference on Military Communications, 2009.

   [DHS08]    Danilov, C., Henderson, T., Spagnolo, T., Goff, T., and J.
              Kim, "MANET Multicast with Multiple Gateways", IEEE MILCOM
              2008 Proceedings, 2008.

   [GM99]     Garcia-Luna-Aceves, JJ. and E. Madruga, "The Core-Assisted
              Mesh Protocol", Selected Areas in Communications, IEEE
              Journal,  Volume 17, Issue 8, August 1999.

              Touch, J., "Updated Specification of the IPv4 ID Field",
              Work in Progress, September 2011.

   [JLMV02]   Jacquet, P., Laouiti, V., Minet, P., and L. Viennot,
              "Performance of Multipoint Relaying in Ad Hoc Mobile
              Routing Protocols", Networking , 2002.

   [MDC04]    Macker, J., Dean, J., and W. Chao, "Simplified Multicast
              Forwarding in Mobile Ad hoc Networks", IEEE MILCOM 2004
              Proceedings, 2004.

   [MDDA07]   Macker, J., Downard, I., Dean, J., and R. Adamson,
              "Evaluation of Distributed Cover Set Algorithms in Mobile
              Ad hoc Network for Simplified Multicast Forwarding", ACM
              SIGMOBILE Mobile Computing and Communications
              Review, Volume 11, Issue 3, July 2007.

Top      Up      ToC       Page 39 
   [MGL04]    Mohapatra, P., Gui, C., and J. Li, "Group Communications
              in Mobile Ad hoc Networks", IEEE Computer, Vol. 37, No. 2,
              February 2004.

   [NTSC99]   Ni, S., Tseng, Y., Chen, Y., and J. Sheu, "The Broadcast
              Storm Problem in a Mobile Ad Hoc Network", Proceedings of
              ACM Mobicom 99, 1999.

   [RFC2501]  Corson, M. and J. Macker, "Mobile Ad hoc Networking
              (MANET): Routing Protocol Performance Issues and
              Evaluation Considerations", RFC 2501, January 1999.

   [RFC3684]  Ogier, R., Templin, F., and M. Lewis, "Topology
              Dissemination Based on Reverse-Path Forwarding (TBRPF)",
              RFC 3684, February 2004.

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

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

Next RFC Part