Internet Engineering Task Force (IETF) J. Macker, Ed.
Request for Comments: 6621 NRL
Category: Experimental May 2012
ISSN: 2070-1721
Internet Engineering Task Force (IETF) J. Macker, Ed.
Request for Comments: 6621 NRL
Category: Experimental May 2012
ISSN: 2070-1721
Simplified Multicast Forwarding
简化的多播转发
Abstract
摘要
This document describes a Simplified Multicast Forwarding (SMF) mechanism that provides basic Internet Protocol (IP) multicast forwarding suitable for limited wireless mesh and mobile ad hoc network (MANET) use. It is mainly applicable in situations where efficient flooding represents an acceptable engineering design trade-off. It defines techniques for multicast duplicate packet detection (DPD), to be applied in the forwarding process, for both IPv4 and IPv6 protocol use. This document also specifies optional mechanisms for using reduced relay sets to achieve more efficient multicast data distribution within a mesh topology as compared to Classic Flooding. Interactions with other protocols, such as use of information provided by concurrently running unicast routing protocols or interaction with other multicast protocols, as well as multiple deployment approaches are also described. Distributed algorithms for selecting reduced relay sets and related discussion are provided in the appendices. Basic issues relating to the operation of multicast MANET border routers are discussed, but ongoing work remains in this area and is beyond the scope of this document.
本文档描述了一种简化的多播转发（SMF）机制，该机制提供了适用于有限无线网状网和移动自组织网络（MANET）使用的基本Internet协议（IP）多播转发。它主要适用于高效注水代表可接受的工程设计权衡的情况。它定义了多播重复数据包检测（DPD）技术，将应用于IPv4和IPv6协议的转发过程。本文档还指定了使用精简中继集的可选机制，以便与传统泛洪相比，在网状拓扑中实现更高效的多播数据分发。还描述了与其他协议的交互，例如使用由并发运行单播路由协议提供的信息或与其他多播协议的交互，以及多种部署方法。附录中提供了选择简化继电器组的分布式算法和相关讨论。讨论了与多播MANET边界路由器的操作相关的基本问题，但仍在这一领域进行中的工作超出了本文档的范围。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6621.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6621.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction and Scope ..........................................4
2. Terminology .....................................................4
3. Applicability Statement .........................................5
4. Overview and Functioning ........................................6
5. SMF Packet Processing and Forwarding ............................8
6. SMF Duplicate Packet Detection .................................10
6.1. IPv6 Duplicate Packet Detection ...........................11
6.1.1. IPv6 SMF_DPD Option Header .........................12
6.1.2. IPv6 Identification-Based DPD ......................14
6.1.3. IPv6 Hash-Based DPD ................................16
6.2. IPv4 Duplicate Packet Detection ...........................17
6.2.1. IPv4 Identification-Based DPD ......................18
6.2.2. IPv4 Hash-Based DPD ................................19
7. Relay Set Selection ............................................20
7.1. Non-Reduced Relay Set Forwarding ..........................20
7.2. Reduced Relay Set Forwarding ..............................20
8. SMF Neighborhood Discovery Requirements ........................23
8.1. SMF Relay Algorithm TLV Types .............................24
8.1.1. SMF Message TLV Type ...............................24
1. Introduction and Scope ..........................................4
2. Terminology .....................................................4
3. Applicability Statement .........................................5
4. Overview and Functioning ........................................6
5. SMF Packet Processing and Forwarding ............................8
6. SMF Duplicate Packet Detection .................................10
6.1. IPv6 Duplicate Packet Detection ...........................11
6.1.1. IPv6 SMF_DPD Option Header .........................12
6.1.2. IPv6 Identification-Based DPD ......................14
6.1.3. IPv6 Hash-Based DPD ................................16
6.2. IPv4 Duplicate Packet Detection ...........................17
6.2.1. IPv4 Identification-Based DPD ......................18
6.2.2. IPv4 Hash-Based DPD ................................19
7. Relay Set Selection ............................................20
7.1. Non-Reduced Relay Set Forwarding ..........................20
7.2. Reduced Relay Set Forwarding ..............................20
8. SMF Neighborhood Discovery Requirements ........................23
8.1. SMF Relay Algorithm TLV Types .............................24
8.1.1. SMF Message TLV Type ...............................24
8.1.2. SMF Address Block TLV Type .........................25
9. SMF Border Gateway Considerations ..............................26
9.1. Forwarded Multicast Groups ................................27
9.2. Multicast Group Scoping ...................................28
9.3. Interface with Exterior Multicast Routing Protocols .......29
9.4. Multiple Border Routers ...................................29
10. Security Considerations .......................................31
11. IANA Considerations ...........................................32
11.1. IPv6 SMF_DPD Header Extension Option Type ................33
11.2. TaggerId Types (TidTy) ...................................33
11.3. Well-Known Multicast Address .............................34
11.4. SMF TLVs .................................................34
11.4.1. Expert Review for Created Type Extension
Registries ........................................34
11.4.2. SMF Message TLV Type (SMF_TYPE) ...................34
11.4.3. SMF Address Block TLV Type (SMF_NBR_TYPE) .........35
11.4.4. SMF Relay Algorithm ID Registry ...................35
12. Acknowledgments ...............................................36
13. References ....................................................37
13.1. Normative References .....................................37
13.2. Informative References ...................................38
Appendix A. Essential Connecting Dominating Set (E-CDS)
Algorithm ............................................40
A.1. E-CDS Relay Set Selection Overview ........................40
A.2. E-CDS Forwarding Rules ....................................41
A.3. E-CDS Neighborhood Discovery Requirements .................41
A.4. E-CDS Selection Algorithm .................................44
Appendix B. Source-Based Multipoint Relay (S-MPR) Algorithm ......46
B.1. S-MPR Relay Set Selection Overview ........................46
B.2. S-MPR Forwarding Rules ....................................47
B.3. S-MPR Neighborhood Discovery Requirements .................48
B.4. S-MPR Selection Algorithm .................................50
Appendix C. Multipoint Relay Connected Dominating Set
(MPR-CDS) Algorithm ..................................52
C.1. MPR-CDS Relay Set Selection Overview ......................52
C.2. MPR-CDS Forwarding Rules ..................................53
C.3. MPR-CDS Neighborhood Discovery Requirements ...............53
C.4. MPR-CDS Selection Algorithm ...............................54
8.1.2. SMF Address Block TLV Type .........................25
9. SMF Border Gateway Considerations ..............................26
9.1. Forwarded Multicast Groups ................................27
9.2. Multicast Group Scoping ...................................28
9.3. Interface with Exterior Multicast Routing Protocols .......29
9.4. Multiple Border Routers ...................................29
10. Security Considerations .......................................31
11. IANA Considerations ...........................................32
11.1. IPv6 SMF_DPD Header Extension Option Type ................33
11.2. TaggerId Types (TidTy) ...................................33
11.3. Well-Known Multicast Address .............................34
11.4. SMF TLVs .................................................34
11.4.1. Expert Review for Created Type Extension
Registries ........................................34
11.4.2. SMF Message TLV Type (SMF_TYPE) ...................34
11.4.3. SMF Address Block TLV Type (SMF_NBR_TYPE) .........35
11.4.4. SMF Relay Algorithm ID Registry ...................35
12. Acknowledgments ...............................................36
13. References ....................................................37
13.1. Normative References .....................................37
13.2. Informative References ...................................38
Appendix A. Essential Connecting Dominating Set (E-CDS)
Algorithm ............................................40
A.1. E-CDS Relay Set Selection Overview ........................40
A.2. E-CDS Forwarding Rules ....................................41
A.3. E-CDS Neighborhood Discovery Requirements .................41
A.4. E-CDS Selection Algorithm .................................44
Appendix B. Source-Based Multipoint Relay (S-MPR) Algorithm ......46
B.1. S-MPR Relay Set Selection Overview ........................46
B.2. S-MPR Forwarding Rules ....................................47
B.3. S-MPR Neighborhood Discovery Requirements .................48
B.4. S-MPR Selection Algorithm .................................50
Appendix C. Multipoint Relay Connected Dominating Set
(MPR-CDS) Algorithm ..................................52
C.1. MPR-CDS Relay Set Selection Overview ......................52
C.2. MPR-CDS Forwarding Rules ..................................53
C.3. MPR-CDS Neighborhood Discovery Requirements ...............53
C.4. MPR-CDS Selection Algorithm ...............................54
Unicast routing protocols, designed for MANET and wireless mesh use, often apply distributed algorithms to flood routing control plane messages within a MANET routing domain. For example, algorithms specified within [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.
单播路由协议设计用于MANET和无线网状网，通常将分布式算法应用于MANET路由域内的泛洪路由控制平面消息。例如，[RFC3626]和[RFC3684]中指定的算法提供了动态选择精简中继集的分布式方法，这些中继集试图在动态拓扑条件下维护连接集的同时有效地泛洪路由控制消息。
Simplified Multicast Forwarding (SMF) extends the efficient flooding concept to the data forwarding plane, providing an appropriate multicast forwarding capability for use cases where localized, efficient flooding is considered an effective design approach. The baseline design is intended to provide a basic, best-effort multicast forwarding capability that is constrained to operate within a single MANET routing domain.
简化多播转发（SMF）将高效泛洪的概念扩展到了数据转发平面，在局部高效泛洪被认为是有效设计方法的情况下，提供了适当的多播转发能力。基线设计旨在提供一种基本的、尽力而为的多播转发能力，该能力仅限于在单个MANET路由域内运行。
An SMF routing domain is an instance of an SMF routing protocol with common policies, under a single network administration authority. The main design goals of this document are to:
SMF路由域是具有公共策略的SMF路由协议的实例，位于单个网络管理机构下。本文件的主要设计目标是：
o adapt efficient relay sets in MANET environments [RFC2501], and
o 在MANET环境中适应高效的中继设备[RFC2501]，以及
o define the needed IPv4 and IPv6 multicast duplicate packet detection (DPD) mechanisms to support multi-hop packet forwarding.
o 定义所需的IPv4和IPv6多播重复数据包检测（DPD）机制以支持多跳数据包转发。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
The terms introduced in [RFC5444], including "packet", "message", "TLV Block", "TLV", and "address", are to be interpreted as described therein.
[RFC5444]中引入的术语，包括“分组”、“消息”、“TLV块”、“TLV”和“地址”，将按照其中所述进行解释。
The following abbreviations are used throughout this document:
本文件中使用了以下缩写：
+--------------+----------------------------------------------------+
| Abbreviation | Definition |
+--------------+----------------------------------------------------+
| MANET | Mobile Ad Hoc Network |
| SMF | Simplified Multicast Forwarding |
| CF | Classic Flooding |
| CDS | Connected Dominating Set |
| MPR | Multipoint Relay |
| S-MPR | Source-based MPR |
| MPR-CDS | MPR-based CDS |
| E-CDS | Essential CDS |
| NHDP | Neighborhood Discovery Protocol |
| DPD | Duplicate Packet Detection |
| I-DPD | Identification-based DPD |
| H-DPD | Hash-based DPD |
| HAV | Hash assist value |
| FIB | Forwarding Information Base |
| TLV | type-length-value encoding |
| DoS | Denial of Service |
| SMF Router | A MANET Router implementing the protocol specified |
| | in this document |
| SMF Routing | A MANET Routing Domain wherein the protocol |
| Domain | specified in this document is operating |
+--------------+----------------------------------------------------+
+--------------+----------------------------------------------------+
| Abbreviation | Definition |
+--------------+----------------------------------------------------+
| MANET | Mobile Ad Hoc Network |
| SMF | Simplified Multicast Forwarding |
| CF | Classic Flooding |
| CDS | Connected Dominating Set |
| MPR | Multipoint Relay |
| S-MPR | Source-based MPR |
| MPR-CDS | MPR-based CDS |
| E-CDS | Essential CDS |
| NHDP | Neighborhood Discovery Protocol |
| DPD | Duplicate Packet Detection |
| I-DPD | Identification-based DPD |
| H-DPD | Hash-based DPD |
| HAV | Hash assist value |
| FIB | Forwarding Information Base |
| TLV | type-length-value encoding |
| DoS | Denial of Service |
| SMF Router | A MANET Router implementing the protocol specified |
| | in this document |
| SMF Routing | A MANET Routing Domain wherein the protocol |
| Domain | specified in this document is operating |
+--------------+----------------------------------------------------+
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 MANET routing domain may provide a useful group communication paradigm for various classes of applications, for example, multimedia streaming, interactive group-based messaging and applications, peer-to-peer middleware multicasting, and multi-hop mobile discovery or registration services. SMF is likely only appropriate for deployment in limited dynamic MANET routing domains (further defined as administratively scoped multicast forwarding domains in Section 9.2) so that the flooding process can be contained.
在动态无线路由拓扑中，由于网状拓扑的可靠性降低和动态性增加，维护传统转发树以支持多播路由协议通常不如有线网络中的有效[MGL04][GM99]。到达MANET路由域内运行SMF协议的所有连接路由器的基本分组转发服务可以为各种类型的应用提供有用的组通信范例，例如，多媒体流、交互式基于组的消息传送和应用、对等中间件多播、，以及多跳移动发现或注册服务。SMF可能仅适用于在有限的动态MANET路由域（在第9.2节中进一步定义为管理范围的多播转发域）中部署，以便可以包含泛洪过程。
A design goal is that hosts may also participate in multicast traffic transmission and reception with standard IP network-layer semantics (e.g., special or unnecessary encapsulation of IP packets should be avoided in this case). SMF deployments are able to connect and
设计目标是，主机还可以使用标准IP网络层语义参与多播流量传输和接收（例如，在这种情况下，应避免对IP数据包进行特殊或不必要的封装）。SMF部署能够连接和
interoperate with existing standard multicast protocols operating within more conventional Internet infrastructures. To this end, a multicast border router or proxy mechanism MUST be used when deployed alongside more fixed-infrastructure IP multicast routing such Protocol Independent Multicast (PIM) variants [RFC3973][RFC4601]. Experimental SMF implementations and deployments have demonstrated gateway functionality at MANET border routers operating with existing external IP multicast routing protocols [CDHM07][DHS08][DHG09]. SMF may be extended or combined with other mechanisms to provide increased reliability and group-specific filtering; the details for this are out of the scope of this document.
与在更传统的互联网基础设施中运行的现有标准多播协议进行互操作。为此，当与更多固定基础设施IP多播路由（如协议独立多播（PIM）变体[RFC3973][RFC4601]一起部署时，必须使用多播边界路由器或代理机制。实验性SMF实现和部署已经在MANET边界路由器上演示了网关功能，这些路由器使用现有的外部IP多播路由协议[CDHM07][DHS08][DHG09]运行。SMF可以扩展或与其他机制结合，以提供更高的可靠性和特定于组的过滤；此操作的详细信息不在本文档的范围内。
This document does not presently support forwarding of packets with directed broadcast addresses as a destination [RFC2644].
本文档目前不支持将定向广播地址作为目的地的数据包转发[RFC2644]。
Figure 1 provides an overview of the logical SMF router architecture,
consisting of "Neighborhood Discovery", "Relay Set Selection", and
"Forwarding Process" components. Typically, relay set selection (or
self-election) occurs based on dynamic input from a neighborhood
discovery process. SMF supports the case where neighborhood
discovery and/or relay set selection information is obtained from a
coexistent process (e.g., a lower-layer mechanism or a unicast
routing protocol using relay sets). In some algorithm designs, the
forwarding decision for a packet can also depend on previous hop or
incoming interface information. The asterisks (*) in Figure 1 mark
the primitives and relationships needed by relay set algorithms
requiring previous-hop packet-forwarding knowledge.
______________ _____________
| | | |
| Neighborhood | | Relay Set |
| Discovery |------------->| Selection |
| | neighbor | |
|______________| info |_____________|
\ /
\ /
neighbor\ /forwarding
info* \ ____________ / status
\ | | /
`-->| Forwarding |<--'
| Process |
~~~~~~~~~~~~~~~~~>|____________|~~~~~~~~~~~~~~~~~>
incoming packet, forwarded packets
interface id*, and
previous hop*
Figure 1 provides an overview of the logical SMF router architecture,
consisting of "Neighborhood Discovery", "Relay Set Selection", and
"Forwarding Process" components. Typically, relay set selection (or
self-election) occurs based on dynamic input from a neighborhood
discovery process. SMF supports the case where neighborhood
discovery and/or relay set selection information is obtained from a
coexistent process (e.g., a lower-layer mechanism or a unicast
routing protocol using relay sets). In some algorithm designs, the
forwarding decision for a packet can also depend on previous hop or
incoming interface information. The asterisks (*) in Figure 1 mark
the primitives and relationships needed by relay set algorithms
requiring previous-hop packet-forwarding knowledge.
______________ _____________
| | | |
| Neighborhood | | Relay Set |
| Discovery |------------->| Selection |
| | neighbor | |
|______________| info |_____________|
\ /
\ /
neighbor\ /forwarding
info* \ ____________ / status
\ | | /
`-->| Forwarding |<--'
| Process |
~~~~~~~~~~~~~~~~~>|____________|~~~~~~~~~~~~~~~~~>
incoming packet, forwarded packets
interface id*, and
previous hop*
Figure 1: SMF Router Architecture
图1:SMF路由器架构
Certain IP multicast packets, defined in Sections 9.2 and 5, are "non-forwardable". These multicast packets MUST be ignored by the SMF forwarding engine. The SMF forwarding engine MAY also work with policies and management interfaces to allow additional filtering control over which multicast packets are considered for potential SMF forwarding. This interface would allow more refined dynamic forwarding control once such techniques are matured for MANET operation. At present, further discussion of dynamic control is left to future work.
第9.2节和第5节中定义的某些IP多播数据包是“不可转发的”。SMF转发引擎必须忽略这些多播数据包。SMF转发引擎还可以与策略和管理接口一起工作，以允许对考虑潜在SMF转发的多播分组进行额外的过滤控制。一旦这种技术成熟用于MANET操作，该接口将允许更精细的动态转发控制。目前，对动态控制的进一步讨论仍有待于今后的工作。
Interoperable SMF implementations MUST use compatible DPD approaches and be able to process the header options defined in this document for IPv6 operation.
可互操作的SMF实现必须使用兼容的DPD方法，并且能够处理本文档中定义的用于IPv6操作的头选项。
Classic Flooding (CF) is defined as the simplest case of SMF multicast forwarding. With CF, all SMF routers forward each received multicast packet exactly once. In this case, the need for any relay set selection or neighborhood topology information is eliminated, at the expense of additional network overhead incurred from unnecessary packet retransmissions. With CF, the SMF DPD functionality is still required. While SMF supports CF as a mode of operation, the use of more efficient relay set modes is RECOMMENDED in order to reduce contention and congestion caused by unnecessary packet retransmissions [NTSC99].
经典泛洪（CF）被定义为SMF多播转发的最简单情况。使用CF，所有SMF路由器将每个接收到的多播数据包转发一次。在这种情况下，消除了对任何中继集选择或邻域拓扑信息的需要，代价是由于不必要的分组重新传输而产生的额外网络开销。对于CF，仍然需要SMF DPD功能。虽然SMF支持CF作为一种操作模式，但建议使用更高效的中继集模式，以减少不必要的数据包重传引起的争用和拥塞[NTSC99]。
An efficient reduced relay set is constructed by selecting and updating, as needed, a subset of all possible routers in a MANET routing domain to act as SMF forwarders. Known distributed relay set selection algorithms have demonstrated the ability to provide and maintain a dynamic connected set for forwarding multicast IP packets [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.
通过根据需要选择和更新MANET路由域中所有可能路由器的子集以充当SMF转发器，构造了一个有效的简化中继集。已知的分布式中继集选择算法已证明能够为转发多播IP数据包提供和维护动态连接集[MDC04]。本文件附录中描述了一些这样的继电器组选择算法，基本设计直接借鉴了先前记录的IETF工作。SMF中继集配置是可扩展的，并且在将来的工作中可以容纳这里指定的中继集算法之外的其他中继集算法。
Determining and maintaining an optimized set of relays generally requires dynamic neighborhood topology information. Neighborhood topology discovery functions MAY be provided by a MANET unicast routing protocol or by using the MANET Neighborhood Discovery Protocol (NHDP) [RFC6130], operating concurrently with SMF. This specification also allows alternative lower-layer interfaces (e.g., radio router interfaces) to provide the necessary neighborhood information to aid in supporting more effective relay set selection. An SMF implementation SHOULD provide the ability for multicast forwarding state to be dynamically managed per operating network interface. The relay state maintenance options and interactions are outlined in Section 7. This document states specific requirements
确定和维护一组优化的继电器通常需要动态邻域拓扑信息。邻域拓扑发现功能可以由MANET单播路由协议提供，或者通过使用MANET邻域发现协议（NHDP）[RFC6130]，与SMF同时操作。本规范还允许替代低层接口（例如，无线电路由器接口）提供必要的邻域信息，以帮助支持更有效的中继集选择。SMF实现应该能够为每个操作网络接口动态管理多播转发状态。第7节概述了继电器状态维护选项和相互作用。本文件规定了具体要求
for neighborhood discovery with respect to the forwarding process and the relay set selection algorithms described herein. For determining dynamic relay sets in the absence of other control protocols, SMF relies on NHDP to assist in IP-layer 2-hop neighborhood discovery and maintenance for relay set selection. "SMF_TYPE" and "SMF_NBR_TYPE" Message and Address Block TLV structures (per [RFC5444]) are defined by this document for use with NHDP to carry SMF-specific information. It is RECOMMENDED that all routers performing SMF operation in conjunction with NHDP include these TLV types in any NHDP HELLO messages generated. This capability allows for routers participating in SMF to be explicitly identified along with their respective dynamic relay set algorithm configuration.
用于关于本文描述的转发过程和中继集选择算法的邻域发现。为了在没有其他控制协议的情况下确定动态中继集，SMF依赖NHDP来协助IP层2跳邻居发现和维护中继集选择。“SMF_类型”和“SMF_NBR_类型”消息和地址块TLV结构（根据[RFC5444]）由本文件定义，用于NHDP携带SMF特定信息。建议所有与NHDP一起执行SMF操作的路由器在生成的任何NHDP HELLO消息中包括这些TLV类型。此功能允许明确标识参与SMF的路由器及其各自的动态中继集算法配置。
The SMF packet processing and forwarding actions are conducted with the following packet handling activities:
SMF数据包处理和转发操作通过以下数据包处理活动进行：
1. Processing of outbound, locally generated multicast packets.
1. 处理出站本地生成的多播数据包。
2. Reception and processing of inbound packets on specific network interfaces.
2. 在特定网络接口上接收和处理入站数据包。
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.
拦截出站本地生成的多播数据包的目的是应用满足DPD要求所需的任何添加的数据包标记，以便进行适当的转发。请注意，对于某些系统配置，不需要为此目的拦截出站数据包。
Inbound multicast packets are received by the SMF implementation and processed for possible forwarding. SMF implementations MUST be capable of forwarding IP multicast packets with destination addresses that are not router-local and link-local for IPv6, as defined in [RFC4291], and that are not within the local network control block as defined by [RFC5771].
SMF实现接收入站多播数据包，并对其进行可能的转发处理。SMF实现必须能够转发IP多播数据包，其目标地址不是[RFC4291]中定义的IPv6路由器本地地址和链路本地地址，并且不在[RFC5771]中定义的本地网络控制块内。
This will support generic multi-hop multicast application needs or distribute designated multicast traffic ingressing the SMF routing domain via border routers. The multicast addresses to be forwarded should be maintained by an a priori list or a dynamic forwarding information base (FIB) that MAY interact with future MANET dynamic group membership extensions or management functions.
这将支持通用的多跳多播应用程序需求，或通过边界路由器将指定的多播流量分配到SMF路由域。要转发的多播地址应该由一个先验列表或一个动态转发信息库（FIB）来维护，该信息库可能与未来的MANET动态组成员扩展或管理功能交互。
The SL-MANET-ROUTERS multicast group is defined to contain all routers within an SMF routing domain, so that packets transmitted to the multicast address associated with the group will be attempted to be delivered to all connected routers running SMF. Due to the mobile nature of a MANET, routers running SMF may not be topologically
SL-MANET-ROUTES多播组被定义为包含SMF路由域内的所有路由器，因此传输到与该组相关联的多播地址的数据包将尝试传送到运行SMF的所有连接路由器。由于MANET的移动特性，运行SMF的路由器在拓扑上可能不稳定
connected at particular times. For IPv6, SL-MANET-ROUTERS is specified to be "site-local". Minimally, SMF MUST forward, as instructed by the relay set selection algorithm, unique (non-duplicate) packets received for SL-MANET-ROUTERS when the Time to Live (TTL) / hop limit or hop limit value in the IP header is greater than 1. SMF MUST forward all additional global-scope multicast addresses specified within the dynamic FIB or configured list as well. In all cases, the following rules MUST be observed for SMF multicast forwarding:
在特定时间连接。对于IPv6，SL-MANET-ROUTERS被指定为“站点本地”。当IP报头中的生存时间（TTL）/跃点限制或跃点限制值大于1时，SMF必须按照中继集选择算法的指示，转发为SL-MANET-Router接收的唯一（非重复）数据包。SMF还必须转发动态FIB或配置列表中指定的所有其他全局作用域多播地址。在所有情况下，SMF多播转发必须遵守以下规则：
1. Any IP packets not addressed to an IP multicast address MUST NOT be forwarded by the SMF forwarding engine.
1. SMF转发引擎不得转发任何未寻址到IP多播地址的IP数据包。
2. IP multicast packets with TTL/hop limit <= 1 MUST NOT be forwarded.
2. TTL/hop limit<=1的IP多播数据包不得转发。
3. Link local IP multicast packets MUST NOT be forwarded.
3. 链路本地IP多播数据包不得转发。
4. 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. IP源地址与本地SMF路由器接口之一匹配的传入IP多播数据包不得转发。
5. Received frames with the Media Access Control (MAC) source address matching any MAC address of the router's interfaces MUST NOT be forwarded.
5. 媒体访问控制（MAC）源地址和路由器接口的任何MAC地址匹配的接收帧不得转发。
6. Received packets for which SMF cannot reasonably ensure temporal DPD uniqueness MUST NOT be forwarded.
6. SMF无法合理确保时间DPD唯一性的接收数据包不得转发。
7. Prior to being forwarded, the TTL/hop limit of the forwarded packet MUST be decremented by one.
7. 在转发之前，转发数据包的TTL/hop限制必须减少1。
Note that rule #4 is important because over some types of wireless interfaces, the originating SMF router may receive retransmissions 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.
请注意，规则#4很重要，因为在某些类型的无线接口上，当相邻路由器转发自己的数据包时，原始SMF路由器可能会接收其自身数据包的重传。此规则避免了本地生成的数据包的不必要的重新传输，即使在应用其他转发决策规则时也是如此。
An additional processing rule also needs to be considered based upon a potential security threat. As discussed in Section 10, there is a potential DoS attack that can be conducted by remotely "previewing" (e.g., via a directional receive antenna) packets that an SMF router would be forwarding and conducting a "pre-play" attack by transmitting the packet before the SMF router would otherwise receive it, but with a reduced TTL/hop limit field value. This form of attack can cause an SMF router to create a DPD entry that would block the proper forwarding of the valid packet (with correct TTL/hop limit) through the SMF routing domain. A RECOMMENDED approach to
根据潜在的安全威胁，还需要考虑附加的处理规则。如第10节所述，存在潜在的DoS攻击，可通过远程“预览”（例如，通过定向接收天线）SMF路由器将转发的数据包，并通过在SMF路由器接收数据包之前发送数据包来进行“预播放”攻击，但具有减少的TTL/hop限制字段值。这种形式的攻击可导致SMF路由器创建DPD条目，从而阻止通过SMF路由域正确转发有效数据包（具有正确的TTL/跃点限制）。建议的解决方法
prevent this attack, when it is a concern, would be to cache temporal packet TTL/hop limit values along with the per-packet DPD state (hash value(s) and/or identifier as described in Section 6). Then, if a subsequent matching (with respect to DPD) packet arrives with a larger TTL/hop limit value than the packet that was previously forwarded, SMF should forward the new packet and update the TTL/hop limit value cached with corresponding DPD state to the new, larger TTL/hop limit value. There may be temporal cases where SMF would unnecessarily forward some duplicate packets using this approach, but those cases are expected to be minimal and acceptable when compared with the potential threat of denied service.
在需要考虑的情况下，防止此攻击将是缓存临时数据包TTL/hop限制值以及每个数据包DPD状态（散列值和/或标识符，如第6节所述）。然后，如果后续匹配（关于DPD）数据包到达时的TTL/hop限制值大于先前转发的数据包，则SMF应转发新数据包，并将使用相应DPD状态缓存的TTL/hop限制值更新为新的、更大的TTL/hop限制值。可能存在SMF使用此方法不必要地转发一些重复数据包的暂时情况，但与拒绝服务的潜在威胁相比，这些情况预计是最小的，并且是可以接受的。
Once the SMF multicast forwarding rules have been applied, an SMF implementation MUST make a forwarding decision dependent upon the relay set selection algorithm in use. If the SMF implementation is using Classic Flooding (CF), the forwarding decision is implicit once DPD uniqueness is determined. Otherwise, a forwarding decision depends upon the current interface-specific relay set state. The descriptions of the relay set selection algorithms in the appendices to this document specify the respective heuristics for multicast packet forwarding and specific DPD or other processing required to achieve correct SMF behavior in each case. For example, one class of forwarding is based upon relay set selection status and the packet's previous hop, while other classes designate the local SMF router as a forwarder for all neighboring routers.
应用SMF多播转发规则后，SMF实现必须根据使用的中继集选择算法做出转发决策。如果SMF实现使用经典泛洪（CF），则一旦确定DPD唯一性，则转发决策是隐式的。否则，转发决定取决于当前接口特定的中继设置状态。本文件附录中对中继集选择算法的描述规定了在每种情况下实现正确SMF行为所需的多播数据包转发和特定DPD或其他处理的相应试探法。例如，一类转发基于中继集选择状态和数据包的前一跳，而其他类将本地SMF路由器指定为所有相邻路由器的转发。
Duplicate packet detection (DPD) is often a requirement in MANET or wireless mesh packet forwarding mechanisms because packets may be transmitted out via the same physical interface as the one over which they were received. Routers may also receive multiple copies of the same packets from different neighbors or interfaces. SMF operation requires DPD, and implementations MUST provide mechanisms to detect and reduce the likelihood of forwarding duplicate multicast packets using temporal packet identification. It is RECOMMENDED this be implemented by keeping a history of recently processed multicast packets for comparison with incoming packets. A DPD packet cache history SHOULD be kept long enough so as to span the maximum network traversal lifetime, MAX_PACKET_LIFETIME, of multicast packets being forwarded within an SMF routing domain. The DPD mechanism SHOULD avoid keeping unnecessary state for packet flows such as those that are locally generated or link-local destinations that would not be considered for forwarding, as presented in Section 5.
重复数据包检测（DPD）通常是MANET或无线mesh数据包转发机制中的一项要求，因为数据包可以通过与接收它们的物理接口相同的物理接口发送出去。路由器还可以从不同的邻居或接口接收相同数据包的多个副本。SMF操作需要DPD，实现必须提供机制来检测和减少使用临时数据包标识转发重复多播数据包的可能性。建议通过保存最近处理的多播数据包的历史记录来实现这一点，以便与传入数据包进行比较。DPD数据包缓存历史应保持足够长的时间，以便跨越SMF路由域内转发的多播数据包的最大网络遍历生存期（MAX_packet_life）。如第5节所述，DPD机制应避免为分组流保留不必要的状态，例如本地生成的分组流或链接不考虑转发的本地目的地的分组流。
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 packet detection.
对于IPv4和IPv6，本文档描述了两种基本的多播重复数据包检测机制：基于报头内容标识（I-DPD）和基于哈希（H-DPD）的重复数据包检测。
I-DPD is a mechanism using specific packet headers, and option headers in the case of IPv6, in combination with flow state to estimate the temporal uniqueness of a packet. H-DPD uses hashing over header fields and payload of a multicast packet to provide an estimation of temporal uniqueness.
I-DPD是一种机制，它使用特定的数据包报头和IPv6情况下的选项报头，结合流状态来估计数据包的时间唯一性。H-DPD使用对多播数据包的报头字段和有效负载的哈希来提供时间唯一性的估计。
Trade-offs of the two approaches to DPD merit different considerations dependent upon the specific SMF deployment scenario.
DPD的两种方法的权衡值得根据具体的SMF部署场景进行不同的考虑。
Because of the potential addition of a hop-by-hop option header with IPv6, all SMF routers in the same SMF deployments MUST be configured so as to use a common mechanism and DPD algorithm. The main difference between IPv4 and IPv6 SMF DPD specifications is the avoidance of any additional header options for IPv4.
由于IPv6可能会添加逐跳选项标头，因此必须配置相同SMF部署中的所有SMF路由器，以便使用公共机制和DPD算法。IPv4和IPv6 SMF DPD规范之间的主要区别在于避免了IPv4的任何附加头选项。
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 those discussed in Appendix B.2.
对于每个网络接口，SMF实现必须根据需要维护DPD数据包状态，以支持所用中继集算法的转发试探。通常，这涉及跟踪先前转发的数据包，以便不转发重复数据包，但一些中继技术有额外的考虑，如附录B.2中讨论的那些。
Additional details of I-DPD and H-DPD processing and maintenance for different classes of packets are described in the following subsections.
以下小节描述了不同类别数据包的I-DPD和H-DPD处理和维护的其他细节。
This section describes the mechanisms and options for SMF IPv6 DPD. The base IPv6 packet header does not provide an explicit packet identification header field that can be exploited for I-DPD. The following options are therefore described to support IPv6 DPD:
本节介绍SMF IPv6 DPD的机制和选项。基本IPv6数据包标头不提供可用于I-DPD的显式数据包标识标头字段。因此，描述了以下选项以支持IPv6 DPD：
1. a hop-by-hop SMF_DPD option header, defined in this document (Section 6.1.1),
1. 本文件（第6.1.1节）中定义的逐跳SMF_DPD选项标题，
2. the use of IPv6 fragment header fields for I-DPD, if one is present (Section 6.1.2),
2. I-DPD使用IPv6片段头字段（如果存在）（第6.1.2节），
3. the use of IPsec sequencing for I-DPD when a non-fragmented, IPsec header is detected (Section 6.1.2), and
3. 当检测到未分段的IPsec报头时，对I-DPD使用IPsec排序（第6.1.2节），以及
4. an H-DPD approach assisted, as needed, by the SMF_DPD option header (Section 6.1.3).
4. 根据需要，由SMF_DPD选项标题（第6.1.3节）辅助的H-DPD方法。
SMF MUST provide a DPD marking module that can insert the hop-by-hop IPv6 header option, defined in Section 6.1.1. This module MUST be invoked after any source-based fragmentation that may occur with
SMF必须提供一个DPD标记模块，该模块可以插入第6.1.1节中定义的逐跳IPv6标头选项。此模块必须在任何基于源代码的碎片发生后调用
IPv6, so as to ensure that all fragments are suitably marked. SMF IPv6 DPD is presently specified to allow either a packet hash or header identification method for DPD. An SMF implementation MUST be configured to operate either in I-DPD or H-DPD mode and perform the corresponding tasks, outlined in Sections 6.1.2 and 6.1.3.
IPv6，以确保所有片段都进行了适当的标记。SMF IPv6 DPD目前被指定为允许DPD使用数据包哈希或报头标识方法。SMF实施必须配置为在I-DPD或H-DPD模式下运行，并执行第6.1.2节和第6.1.3节中概述的相应任务。
This section defines an IPv6 Hop-by-Hop Option [RFC2460], SMF_DPD, to serve the purpose of unique packet identification for IPv6 I-DPD. Additionally, the SMF_DPD option header provides a mechanism to guarantee non-collision of hash values for different packets when H-DPD is used.
本节定义了一个IPv6逐跳选项[RFC2460]，即SMF_DPD，用于为IPv6 I-DPD提供唯一的数据包标识。此外，SMF_DPD选项头提供了一种机制，以确保在使用H-DPD时，不同数据包的哈希值不会发生冲突。
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.
如果这是存在的唯一逐跳选项，则不包括可选标记ID字段（见下文），并且DPD数据包标识符（序列号）或哈希令牌的大小为24位或更小，这将导致向IPv6数据包报头添加8个字节，包括“下一个报头”、“报头扩展长度”、SMF_DPD选项字段，和填充物。
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| 01000 | Opt. Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|H| DPD Identifier Option Fields or Hash Assist Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 01000 | Opt. Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|H| DPD Identifier Option Fields or Hash Assist Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: IPv6 SMF_DPD Hop-by-Hop Option Header
图2:IPv6 SMF_DPD逐跳选项头
"Option Type" = 00001000. The highest order three bits are 000 because this specification requires that routers not recognizing this option type skip over this option and continue processing the header and that the option must not change en route [RFC2460].
“选项类型”=00001000。最高三位为000，因为本规范要求不识别此选项类型的路由器跳过此选项并继续处理报头，并且该选项不得在路由中更改[RFC2460]。
"Opt. Data Len" = Length of option content (i.e., 1 + (<IdType> ? (<IdLen> + 1): 0) + Length(DPD ID)).
“Opt.Data Len”=选项内容的长度（即1+（<IdType>？（<IdLen>+1）：0）+长度（DPD ID））。
"H-bit" = a hash indicator bit value identifying DPD marking type. 0 == sequence-based approach with optional TaggerId and a tuple-based sequence number. 1 == indicates a hash assist value (HAV) field follows to aid in avoiding hash-based DPD collisions.
“H位”=标识DPD标记类型的哈希指示符位值。0==具有可选标记ID和基于元组的序列号的基于序列的方法。1==指示后面的哈希辅助值（HAV）字段有助于避免基于哈希的DPD冲突。
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].
当清除“H位”（零值）时，如图3所示指定支持I-DPD操作的SMF_DPD格式，并根据[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| 01000 | Opt. Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|TidTy| TidLen| TaggerId (optional) ... |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 01000 | Opt. Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|TidTy| TidLen| TaggerId (optional) ... |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: IPv6 SMF_DPD Option Header in I-DPD mode
图3:I-DPD模式下的IPv6 SMF_DPD选项头
"TidTy" = a 3-bit field indicating the presence and type of the optional TaggerId field.
“TidTy”=一个3位字段，指示可选标记ID字段的存在和类型。
"TidLen" = a 4-bit field indicating the length (in octets) of the following TaggerId field.
“TidLen”=一个4位字段，表示以下TaggerId字段的长度（以八位字节为单位）。
"TaggerId" = a field, is used to differentiate multiple ingressing border gateways that may commonly apply the SMF_DPD option header to packets from a particular source. Table 1 lists the TaggerId types used in this document:
“TaggerId”=一个字段，用于区分多个入口边界网关，这些网关通常会将SMF_DPD选项头应用于来自特定源的数据包。表1列出了本文档中使用的标记ID类型：
+---------+---------------------------------------------------------+
| Name | Purpose |
+---------+---------------------------------------------------------+
| NULL | Indicates no TaggerId field is present. "TidLen" MUST |
| | also be set to ZERO. |
| DEFAULT | A TaggerId of non-specific context is present. "TidLen |
| | + 1" defines the length of the TaggerId field in bytes. |
| IPv4 | A TaggerId representing an IPv4 address is present. The |
| | "TidLen" MUST be set to 3. |
| IPv6 | A TaggerId representing an IPv6 address is present. The |
| | "TidLen" MUST be set to 15. |
+---------+---------------------------------------------------------+
+---------+---------------------------------------------------------+
| Name | Purpose |
+---------+---------------------------------------------------------+
| NULL | Indicates no TaggerId field is present. "TidLen" MUST |
| | also be set to ZERO. |
| DEFAULT | A TaggerId of non-specific context is present. "TidLen |
| | + 1" defines the length of the TaggerId field in bytes. |
| IPv4 | A TaggerId representing an IPv4 address is present. The |
| | "TidLen" MUST be set to 3. |
| IPv6 | A TaggerId representing an IPv6 address is present. The |
| | "TidLen" MUST be set to 15. |
+---------+---------------------------------------------------------+
Table 1: TaggerId Types
表1：标记ID类型
This format allows a quick check of the "TidTy" field to determine if
a TaggerId field is present. If "TidTy" is NULL, then the length of
the DPD packet <Identifier> field corresponds to (<Opt. Data Len> -
1). If the <TidTy> is non-NULL, then the length of the TaggerId
field is equal to (<TidLen> - 1), and the remainder of the option
data comprises the DPD packet <Identifier> field. When the TaggerId
field is present, the <Identifier> field can be considered a unique
packet identifier in the context of the <TaggerId:srcAddr:dstAddr>
tuple. When the TaggerId field is not present, then it is assumed
that the source applied the SMF_DPD option and the <Identifier> can
This format allows a quick check of the "TidTy" field to determine if
a TaggerId field is present. If "TidTy" is NULL, then the length of
the DPD packet <Identifier> field corresponds to (<Opt. Data Len> -
1). If the <TidTy> is non-NULL, then the length of the TaggerId
field is equal to (<TidLen> - 1), and the remainder of the option
data comprises the DPD packet <Identifier> field. When the TaggerId
field is present, the <Identifier> field can be considered a unique
packet identifier in the context of the <TaggerId:srcAddr:dstAddr>
tuple. When the TaggerId field is not present, then it is assumed
that the source applied the SMF_DPD option and the <Identifier> can
be considered unique in the context of the IPv6 packet header <srcAddr:dstAddr> tuple. IPv6 I-DPD operation details are in Section 6.1.2.
在IPv6数据包头的上下文中被认为是唯一的<srcadr:dstAddr>元组。IPv6 I-DPD操作详情见第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, the source or ingressing gateways apply the SMF_DPD with an HAV only when required to differentiate the hash value of a new packet with respect to hash values in the DPD cache. This situation can be detected locally on the router by running the hash algorithm and checking the DPD cache, prior to ingressing a previously unmarked packet or a locally sourced packet. This helps to guarantee the uniqueness of generated hash values when H-DPD is used. Additionally, this 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 option header for H-DPD operation is given in Figure 4.
当设置SMF_DPD选项数据中的“H位”时，数据内容值被解释为用于促进H-DPD操作的哈希辅助值（HAV）。在这种情况下，源或入口网关仅在需要区分新分组的散列值与DPD缓存中的散列值时，才使用HAV应用SMF_DPD。在进入以前未标记的数据包或本地来源的数据包之前，通过运行哈希算法并检查DPD缓存，可以在路由器上本地检测到这种情况。这有助于确保使用H-DPD时生成的哈希值的唯一性。此外，这避免了将SMF_DPD选项报头应用于每个数据包的额外开销。对于许多散列算法，预计可能只需要稀疏地使用SMF_DPD选项。图4给出了H-DPD操作的SMF_DPD选项头的格式。
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) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: IPv6 SMF_DPD Option Header in H-DPD Mode
图4:H-DPD模式下的IPv6 SMF_DPD选项头
The SMF_DPD option should be applied with an HAV to produce a unique hash digest for packets within the context of the IPv6 packet header <srcAddr>. The size of the HAV field is implied by "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.
SMF_DPD选项应与HAV一起应用，以在IPv6数据包头<srcadr>的上下文中为数据包生成唯一的哈希摘要。HAV字段的大小由“Opt.Data Len”表示。字段的适当大小取决于所使用的特定哈希算法的冲突属性。有关IPv6 H-DPD操作的更多详细信息，请参见第6.1.3节。
Table 2 summarizes the IPv6 I-DPD processing and forwarding decision approach. Within the table, '*' indicates an ignore field condition.
表2总结了IPv6 I-DPD处理和转发决策方法。在表中，“*”表示忽略字段条件。
+-------------+-----------+-----------+-----------------------------+
| IPv6 | IPv6 | IPv6 | SMF IPv6 I-DPD Mode Action |
| Fragment | IPsec | I-DPD | |
| Header | Header | Header | |
+-------------+-----------+-----------+-----------------------------+
| Present | * | Not | Use Fragment Header I-DPD |
| | | Present | Check and Process for |
| | | | Forwarding |
| Not Present | Present | Not | Use IPsec Header I-DPD |
| | | Present | Check and Process for |
| | | | Forwarding |
| Present | * | Present | Invalid; do not forward. |
| Not Present | Present | Present | Invalid; do not forward. |
| Not Present | Not | Not | Add I-DPD Header, and |
| | Present | Present | Process for Forwarding |
| Not Present | Not | Present | Use I-DPD Header Check and |
| | Present | | Process for Forwarding |
+-------------+-----------+-----------+-----------------------------+
+-------------+-----------+-----------+-----------------------------+
| IPv6 | IPv6 | IPv6 | SMF IPv6 I-DPD Mode Action |
| Fragment | IPsec | I-DPD | |
| Header | Header | Header | |
+-------------+-----------+-----------+-----------------------------+
| Present | * | Not | Use Fragment Header I-DPD |
| | | Present | Check and Process for |
| | | | Forwarding |
| Not Present | Present | Not | Use IPsec Header I-DPD |
| | | Present | Check and Process for |
| | | | Forwarding |
| Present | * | Present | Invalid; do not forward. |
| Not Present | Present | Present | Invalid; do not forward. |
| Not Present | Not | Not | Add I-DPD Header, and |
| | Present | Present | Process for Forwarding |
| Not Present | Not | Present | Use I-DPD Header Check and |
| | Present | | Process for Forwarding |
+-------------+-----------+-----------+-----------------------------+
Table 2: IPv6 I-DPD Processing Rules
表2:IPv6 I-DPD处理规则
1. If a received IPv6 multicast packet is an IPv6 fragment, SMF MUST use the fragment extension header fields for packet identification. This identifier can be considered unique in the context of the <srcAddr:dstAddr> of the IP packet.
1. 如果接收到的IPv6多播数据包是IPv6片段，SMF必须使用片段扩展头字段进行数据包标识。在IP数据包的<srcadr:dstAddr>上下文中，可以认为该标识符是唯一的。
2. 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 "IPsecType" is either Authentication Header (AH) or Encapsulating Security Payload (ESP) [RFC4302].
2. 如果数据包是未分段的IPv6 IPsec数据包，SMF必须使用IPsec字段进行数据包标识。IPsec头<sequence>字段可以被视为<IPsecType:srcAddr:dstAddr:SPI>上下文中的唯一标识符，其中“IPsecType”是身份验证头（AH）或封装安全负载（ESP）[RFC4302]。
3. For unfragmented, non-IPsec IPv6 packets, the use of the SMF_DPD option header is necessary to support I-DPD operation. The SMF_DPD option header is applied in the context of the <srcAddr> of the IP packet. Hosts or ingressing SMF gateways are responsible for applying this option to support DPD. Table 3 summarizes these packet identification types:
3. 对于未分段的非IPsec IPv6数据包，需要使用SMF_DPD选项头来支持I-DPD操作。SMF_DPD选项头应用于IP数据包的<srcadr>上下文中。主机或入口SMF网关负责应用此选项以支持DPD。表3总结了这些数据包标识类型：
+-----------+---------------------------------+---------------------+
| IPv6 | Packet DPD ID Context | Packet DPD ID |
| Packet | | |
| Type | | |
+-----------+---------------------------------+---------------------+
| Fragment | <srcAddr:dstAddr> | <fragmentOffset:id> |
| IPsec | <IPsecType:srcAddr:dstAddr:SPI> | <sequence> |
| Packet | | |
| Regular | <[TaggerId:]srcAddr:dstAddr> | <SMF_DPD option |
| Packet | | header id> |
+-----------+---------------------------------+---------------------+
+-----------+---------------------------------+---------------------+
| IPv6 | Packet DPD ID Context | Packet DPD ID |
| Packet | | |
| Type | | |
+-----------+---------------------------------+---------------------+
| Fragment | <srcAddr:dstAddr> | <fragmentOffset:id> |
| IPsec | <IPsecType:srcAddr:dstAddr:SPI> | <sequence> |
| Packet | | |
| Regular | <[TaggerId:]srcAddr:dstAddr> | <SMF_DPD option |
| Packet | | header id> |
+-----------+---------------------------------+---------------------+
Table 3: IPv6 I-DPD Packet Identification Types
表3:IPv6 I-DPD数据包标识类型
"IPsecType" is either Authentication Header (AH) or Encapsulating Security Payload (ESP).
“IPsecType”是身份验证头（AH）或封装安全负载（ESP）。
The "TaggerId" is an optional field of the IPv6 SMF_DPD option header.
“TaggerId”是IPv6 SMFU DPD选项标头的可选字段。
A default hash-based DPD approach (H-DPD) for use by SMF is specified as follows. An SHA-1 [RFC3174] hash of the non-mutable header fields, options fields, and data content of the IPv6 multicast packet is used to produce a 160-bit digest. The approach for calculating this hash value SHOULD follow the same guidelines described for calculating the Integrity Check Value (ICV) described in [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. SHA-1 is being applied in SMF only to provide a low probability of collision and is not being used for cryptographic or authentication purposes. A history of the packet hash values SHOULD be maintained within the context of the IPv6 packet header <srcAddr>. SMF ingress points (i.e., source hosts or gateways) use this history to confirm that new packets are unique with respect to their hash value. The hash assist value (HAV) field described in 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.
SMF使用的默认基于散列的DPD方法（H-DPD）指定如下。IPv6多播数据包的不可变头字段、选项字段和数据内容的SHA-1[RFC3174]散列用于生成160位摘要。计算该散列值的方法应遵循[RFC4302]中描述的关于不可变字段的完整性检查值（ICV）计算指南。当数据包头和内容发生变化时，这种方法应该具有相当低的摘要冲突概率。SHA-1在SMF中的应用只是为了提供较低的冲突概率，而不是用于加密或身份验证目的。应在IPv6数据包头的上下文中维护数据包哈希值的历史记录<srcadr>。SMF入口点（即，源主机或网关）使用此历史记录来确认新数据包的哈希值是唯一的。第6.1.1节中所述的哈希辅助值（HAV）字段是在可能发生摘要冲突时作为区分字段提供的。请注意，HAV是一个不可变的选项字段，SMF必须在其哈希计算中处理任何包含的HAV值（参见第6.1.1节）。
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. An HAV is recalculated as needed to produce a non-colliding hash value prior to forwarding.
如果数据包在SMF转发器保存的DPD缓存中导致摘要冲突（即，通过检查H-DPD摘要历史记录），则该数据包应被静默丢弃。如果在SMF入口点检测到摘要冲突，则用随机生成的HAV构造H-DPD选项报头。根据需要重新计算HAV，以在转发之前生成非冲突散列值。
The multicast packet is then forwarded with the added IPv6 SMF_DPD option header. A common hash approach MUST be used by SMF routers for the applied HAV to consistently avoid hash collision and thus inadvertent packet drops.
然后使用添加的IPv6 SMF_DPD选项报头转发多播数据包。SMF路由器必须为应用的HAV使用公共哈希方法，以一致地避免哈希冲突，从而避免意外的数据包丢失。
The SHA-1 indexing and IPv6 HAV approaches are specified at present for consistency and robustness to suit experimental uses. Future approaches and experimentation may discover design trade-offs 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 otherwise due to poor collision properties. Such techniques could reduce packet-processing overhead and memory requirements.
目前指定了SHA-1索引和IPv6 HAV方法，以确保一致性和健壮性，以适应实验用途。未来的方法和实验可能会发现哈希健壮性和效率方面的设计权衡值得考虑。增强功能可能包括减少处理的最大有效负载长度、确定更短的索引或应用更高效的哈希算法。HAV功能的使用可能允许应用“较轻重量”的散列技术，这些技术最初可能由于较差的冲突属性而未被考虑。这种技术可以减少数据包处理开销和内存需求。
This section describes the mechanisms and options for IPv4 DPD. The following areas are described to support IPv4 DPD:
本节介绍IPv4 DPD的机制和选项。描述了以下区域以支持IPv4 DPD：
1. the use of IPv4 fragment header fields for I-DPD when they exist (Section 6.2.1),
1. I-DPD的IPv4片段头字段的使用（第6.2.1节），
2. the use of IPsec sequencing for I-DPD when a non-fragmented IPv4 IPsec packet is detected (Section 6.2.1), and
2. 当检测到未分段的IPv4 IPsec数据包时，对I-DPD使用IPsec排序（第6.2.1节），以及
3. an H-DPD approach(Section 6.2.2) when neither of the above cases can be applied.
3. 当上述两种情况均不适用时，采用H-DPD方法（第6.2.2节）。
Although the IPv4 datagram has a 16-bit Identification (ID) field as specified in [RFC0791], it cannot be relied upon for DPD purposes due to common computer operating system implementation practices and the reasons described in the updated specification of the IPv4 ID Field [IPV4-ID-UPDATE]. An SMF IPv4 DPD marking option like the IPv6 SMF_DPD option header is not specified since IPv4 header options are not as tractable for hosts as they are for IPv6. However, when IPsec is applied or IPv4 packets have been fragmented, the I-DPD approach can be applied reliably using the corresponding packet identifier fields described in Section 6.2.1. For the general IPv4 case (non-IPsec and non-fragmented packets), the H-DPD approach of Section 6.2.2 is RECOMMENDED.
尽管IPv4数据报具有[RFC0791]中指定的16位标识（ID）字段，但由于常见的计算机操作系统实施实践以及IPv4 ID字段[IPv4-ID-UPDATE]更新规范中描述的原因，无法将其用于DPD目的。未指定SMF IPv4 DPD标记选项（如IPv6 SMF_DPD选项标头），因为IPv4标头选项对主机的可跟踪性不如对IPv6的可跟踪性。但是，当应用IPsec或IPv4数据包已分段时，可以使用第6.2.1节中描述的相应数据包标识符字段可靠地应用I-DPD方法。对于一般IPv4情况（非IPsec和非碎片数据包），建议使用第6.2.2节中的H-DPD方法。
Since IPv4 SMF does not specify an option header, the interoperability constraints are looser than in the IPv6 version, and forwarders may 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.
由于IPv4 SMF未指定选项标头，因此互操作性约束比IPv6版本更宽松，转发器可以使用混合的H-DPD和I-DPD模式运行，只要它们始终执行以下部分中概述的适当DPD例程。但是，建议使用通用模式配置部署，以实现操作一致性。
Table 4 summarizes the IPv4 I-DPD processing approach once a packet has passed the basic forwardable criteria described in Section 5. To summarize, for IPv4, I-DPD is applicable only for packets that have been fragmented or have IPsec applied. In Table 4, '*' indicates an ignore field condition. DF, MF, and Fragment offset correspond to related fields and flags defined in [RFC0791].
表4总结了当数据包通过第5节中描述的基本可转发标准时的IPv4 I-DPD处理方法。总之，对于IPv4，I-DPD仅适用于已分段或已应用IPsec的数据包。在表4中，“*”表示忽略字段条件。DF、MF和碎片偏移量对应于[RFC0791]中定义的相关字段和标志。
+------+------+----------+---------+--------------------------------+
| DF | MF | Fragment | IPsec | IPv4 I-DPD Action |
| flag | flag | offset | | |
+------+------+----------+---------+--------------------------------+
| 1 | 1 | * | * | Invalid; do not forward. |
| 1 | 0 | nonzero | * | Invalid; do not forward. |
| * | 0 | zero | not | Use H-DPD check instead |
| | | | Present | |
| * | 0 | zero | Present | IPsec enhanced Tuple I-DPD |
| | | | | Check and Process for |
| | | | | Forwarding |
| 0 | 0 | nonzero | * | Extended Fragment Offset Tuple |
| | | | | I-DPD Check and Process for |
| | | | | Forwarding |
| 0 | 1 | zero or | * | Extended Fragment Offset Tuple |
| | | nonzero | | I-DPD Check and Process for |
| | | | | Forwarding |
+------+------+----------+---------+--------------------------------+
+------+------+----------+---------+--------------------------------+
| DF | MF | Fragment | IPsec | IPv4 I-DPD Action |
| flag | flag | offset | | |
+------+------+----------+---------+--------------------------------+
| 1 | 1 | * | * | Invalid; do not forward. |
| 1 | 0 | nonzero | * | Invalid; do not forward. |
| * | 0 | zero | not | Use H-DPD check instead |
| | | | Present | |
| * | 0 | zero | Present | IPsec enhanced Tuple I-DPD |
| | | | | Check and Process for |
| | | | | Forwarding |
| 0 | 0 | nonzero | * | Extended Fragment Offset Tuple |
| | | | | I-DPD Check and Process for |
| | | | | Forwarding |
| 0 | 1 | zero or | * | Extended Fragment Offset Tuple |
| | | nonzero | | I-DPD Check and Process for |
| | | | | Forwarding |
+------+------+----------+---------+--------------------------------+
Table 4: IPv4 I-DPD Processing Rules
表4:IPv4 I-DPD处理规则
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
出于性能方面的考虑，IPv4网络碎片和无线MANET网络内多播数据包的重组应该最小化，但SMF在碎片出现时提供了碎片的转发。如果IPv4多播数据包是一个片段，SMF必须使用片段头字段进行数据包标识。在IPv4数据包的<protocol:srcadr:dstAddr>上下文中，可以认为该标识在时间上是唯一的。如果数据包是未分段的IPv4 IPsec数据包，SMF必须使用IPsec字段进行数据包标识。IPsec头<sequence>字段可以被视为唯一的
identifier in the context of the <IPsecType:srcAddr:dstAddr:SPI> where "IPsecType" is either AH or ESP [RFC4302]. Table 5 summarizes these packet identification types:
<ipspectype:srcadr:dstAddr:SPI>上下文中的标识符，其中“ipspectype”是AH或ESP[RFC4302]。表5总结了这些数据包标识类型：
+-----------+---------------------------------+---------------------+
| IPv4 | Packet Identification Context | Packet Identifier |
| Packet | | |
| Type | | |
+-----------+---------------------------------+---------------------+
| Fragment | <protocol:srcAddr:dstAddr> | <fragmentOffset:id> |
| IPsec | <IPsecType:srcAddr:dstAddr:SPI> | <sequence> |
| Packet | | |
+-----------+---------------------------------+---------------------+
+-----------+---------------------------------+---------------------+
| IPv4 | Packet Identification Context | Packet Identifier |
| Packet | | |
| Type | | |
+-----------+---------------------------------+---------------------+
| Fragment | <protocol:srcAddr:dstAddr> | <fragmentOffset:id> |
| IPsec | <IPsecType:srcAddr:dstAddr:SPI> | <sequence> |
| Packet | | |
+-----------+---------------------------------+---------------------+
Table 5: IPv4 I-DPD Packet Identification Types
表5:IPv4 I-DPD数据包标识类型
"IPsecType" is either Authentication Header (AH) or Encapsulating Security Payload (ESP).
“IPsecType”是身份验证头（AH）或封装安全负载（ESP）。
The hashing technique here is similar to that specified for IPv6 in Section 6.1.3, but the H-DPD header option with HAV is not considered. To ensure consistent IPv4 H-DPD operation among SMF routers, a default hashing approach is specified. A common DPD hashing algorithm for an SMF routing area is RECOMMENDED because colliding hash values for different packets result in "false positive" duplicate packet detection, and there is small probability that valid packets may be dropped based on the hashing technique used. Since the "hash assist value" approach is not available for IPv4, use of a common hashing approach minimizes the probability of hash collision packet drops over multiple hops of forwarding.
这里的散列技术类似于第6.1.3节中为IPv6指定的散列技术，但不考虑带有HAV的H-DPD头选项。为了确保SMF路由器之间的IPv4 H-DPD操作一致，指定了默认哈希方法。推荐用于SMF路由区域的通用DPD散列算法，因为不同分组的散列值冲突会导致“假阳性”重复分组检测，并且基于所使用的散列技术丢弃有效分组的概率很小。由于“哈希辅助值”方法不适用于IPv4，因此使用通用哈希方法可最大限度地降低哈希冲突数据包在多跳转发过程中丢失的概率。
SMF MUST perform a SHA-1 [RFC3174] hash of the immutable header fields, option fields, and data content of the IPv4 multicast packet resulting in a 160-bit digest. The approach for calculating the hash value SHOULD follow the same guidelines described for calculating the Integrity Check Value (ICV) described in [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. A RECOMMENDED implementation detail for IPv4 H-DPD is to concatenate the 16-bit IPv4 ID value with the computed hash value as an extended DPD hash value that may provide reduced hash collisions in the cases where the IPv4 ID field is being set by host operating systems or gateways.
SMF必须对IPv4多播数据包的不可变头字段、选项字段和数据内容执行SHA-1[RFC3174]哈希，从而生成160位摘要。计算散列值的方法应遵循[RFC4302]中描述的关于不可变字段的完整性检查值（ICV）计算指南。应在<protocol:srcadr:dstAddr>的上下文中维护数据包哈希值的历史记录。IPv4的上下文比IPv6的上下文更具体，因为SMF_DPD HAV不能用于缓解哈希冲突。IPv4 H-DPD的推荐实现细节是将16位IPv4 ID值与计算的哈希值连接起来，作为扩展DPD哈希值，在主机操作系统或网关设置IPv4 ID字段的情况下，可以减少哈希冲突。
When this approach is taken, the use of the supplemental "internal hash" technique as described in Section 10 is RECOMMENDED as a security measure.
采用这种方法时，建议使用第10节所述的补充“内部哈希”技术作为安全措施。
The SHA-1 hash is specified at present for consistency and robustness. Future approaches and experimentation may discover design trade-offs 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.
目前指定SHA-1哈希是为了一致性和健壮性。未来的方法和实验可能会发现散列健壮性和效率方面的设计权衡，值得在SMF的未来修订中考虑。这可能包括减少所处理的分组有效负载长度、确定更短的索引或应用更有效的散列算法。
SMF is flexible in its support of different reduced relay set mechanisms for efficient flooding, the constraints imposed herein being detailed in this section.
SMF灵活地支持不同的简化中继集机制以实现高效泛洪，本节将详细介绍本文施加的约束。
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.
SMF实现必须在减少的中继集信息不可用或未选择用于操作时支持CF作为基本转发机制。在CF模式下，每个路由器发送一次通过SMF转发规则的数据包。第6节中描述的DPD技术对于正确操作和防止相同中继器的重复数据包重传至关重要。
MANET reduced relay sets are often achieved by distributed algorithms that can dynamically calculate a topological connected dominating set (CDS).
MANET缩减中继集通常通过分布式算法实现，该算法可以动态计算拓扑连通支配集（CDS）。
A goal of SMF is to apply reduced relay sets for more efficient multicast dissemination within dynamic topologies. To accomplish this, an SMF implementation MUST support the ability to modify its multicast packet forwarding rules based upon relay set state received dynamically during operation. In this way, SMF operates effectively as neighbor adjacencies or multicast forwarding policies within the topology change.
SMF的一个目标是在动态拓扑中应用减少的中继集以实现更高效的多播传播。为了实现这一点，SMF实现必须支持基于在操作期间动态接收的中继集状态修改其多播分组转发规则的能力。通过这种方式，SMF可以有效地作为拓扑变化中的邻居邻接或多播转发策略进行操作。
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).
在早期的SMF实验原型中，中继集信息来自共存的单播路由控制平面流量泛洪过程[MDC04]。根据这一经验，当使用来自单独路由协议进程的中继集时，有时需要额外的修剪考虑。例如，为单播控制平面泛洪形成的中继集可以包括可能不希望用于多播转发的附加冗余（例如，双连接中继集）。
Here is a recommended criteria list for SMF relay set selection algorithm candidates:
以下是SMF中继集选择算法候选的推荐标准列表：
1. Robustness to topological dynamics and mobility
1. 对拓扑动力学和移动性的鲁棒性
2. Localized election or coordination of any relay sets
2. 任何继电器组的局部选择或协调
3. Reasonable minimization of CDS relay set size given the above constraints
3. 在上述约束条件下，CDS继电器组大小的合理最小化
4. Heuristic support for preference or election metrics
4. 对偏好或选举指标的启发式支持
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:
图5描述了可能的继电器组控制选项的信息流图。SMF中继集状态表示SMF在转发决策过程中使用的信息库。该图表明，SMF继电器设置状态可通过三种根本不同的方法确定：
o Independent operation with NHDP [RFC6130] input providing dynamic network neighborhood adjacency information, used by a particular relay set selection algorithm.
o NHDP[RFC6130]输入提供动态网络邻域邻接信息的独立操作，由特定的中继集选择算法使用。
o Slave operation with an existing unicast MANET routing protocol, capable of providing CDS election information for use by SMF.
o 使用现有单播MANET路由协议的从属操作，能够提供CDS选择信息供SMF使用。
o Cross-layer operation that may involve L2 triggers or information describing neighbors or links.
o 可能涉及L2触发器或描述邻居或链接的信息的跨层操作。
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.
影响和控制选举的其他启发式方法可以来自网络管理或其他界面，如图5右侧所示。CF模式简化了控制，不需要其他输入，但仅依赖于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 |
|______________|
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
图5:SMF简化继电器组信息流
Following is further discussion of the three styles of SMF operation with reduced relay sets as illustrated in Figure 5:
以下是对图5所示的三种SMF操作方式的进一步讨论，包括减少继电器组：
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.
1. 独立操作：在这种情况下，SMF独立于任何单播路由协议进行操作。为了支持减少的中继集，SMF必须使用从信令收集的信息执行自己的中继集选择。建议将相关的NHDP过程用于该信号。NHDP消息应附加额外的[RFC5444]类型长度值（TLV）内容，以支持[RFC6130]中讨论的SMF特定要求，并支持本文件附录或未来规范中描述的特定继电器组操作。单播路由协议可以共存，即使使用相同的NHDP过程，但支持SMF减少中继集选择的信令独立于这些协议。
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.
2. 使用支持CDS的单播路由协议进行操作：在这种情况下，共存单播路由协议根据其自身的控制平面CDS或邻域发现信息提供动态中继集状态。
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).
3. 跨层操作：在这种情况下，SMF使用邻域状态和来自跨层信息库的触发器进行操作，以进行动态中继集选择和维护（例如，较低链路层）。
This section defines the requirements for use of the MANET Neighborhood Discovery Protocol (NHDP) [RFC6130] to support SMF operation. Note that basic CF forwarding requires no neighborhood topology knowledge since in this configured mode, every SMF router relays all traffic. Supporting more reduced SMF relay set operation requires the discovery and maintenance of dynamic neighborhood topology information. NHDP can be used to provide this necessary information; however, there are SMF-specific requirements for NHDP use. This is the case for both "independent" SMF operation where NHDP is being used specifically to support SMF or when one NHDP instance is used for both SMF and a coexistent MANET unicast routing protocol.
本节定义了使用MANET邻居发现协议（NHDP）[RFC6130]支持SMF操作的要求。请注意，基本CF转发不需要邻域拓扑知识，因为在此配置模式下，每个SMF路由器都会中继所有流量。支持更精简的SMF中继集操作需要发现和维护动态邻域拓扑信息。NHDP可用于提供此必要信息；然而，NHDP的使用有SMF的具体要求。这是“独立”SMF操作的情况，其中NHDP专门用于支持SMF，或者一个NHDP实例用于SMF和共存的MANET单播路由协议。
NHDP HELLO messages and the resultant neighborhood information base are described separately within the NHDP specification. To summarize, NHDP provides the following basic functions:
NHDP HELLO消息和生成的邻居信息库在NHDP规范中分别描述。总而言之，NHDP提供以下基本功能：
1. 1-hop neighbor link sensing and bidirectionality checks of neighbor links,
1. 1跳邻居链路感测和邻居链路的双向性检查，
2. 2-hop neighborhood discovery including collection of 2-hop neighbors and connectivity information,
2. 2-hop邻居发现，包括收集2-hop邻居和连接信息，
3. Collection and maintenance of the above information across multiple interfaces, and
3. 跨多个接口收集和维护上述信息，以及
4. A method for signaling SMF information throughout the 2-hop neighborhood through the use of TLV extensions.
4. 一种通过使用TLV扩展在整个2跳邻居中发送SMF信息的方法。
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
本文档的附录A-C描述了基于CDS的中继集选择算法，该算法可以实现高效的SMF操作，即使在动态移动网络中也是如此，并且每个算法都已在一个工作的SMF原型中进行了初步试验[MDDA07]。当将这些算法与NHDP结合使用时，需要验证相邻SMF操作的方法，以确保正确选择继电器组。NHDP，以及SMF运行
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.
验证，提供这些算法所需的必要信息，以进行继电器组选择。SMF运行的验证可通过管理或使用以下小节中定义的SMF中继算法TLV来完成。当使用NHDP进行SMF邻域发现时，建议使用SMF中继算法TLVs。
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特定的TLV类型，支持一般SMF操作或支持附录中描述的算法。描述几种继电器组算法的附录还规定了NHDP使用的任何附加要求，并根据需要参考了适用的TLV类型。
This section specifies TLV types to be used within NHDP messages to identify the CDS relay set selection algorithm(s) in use. Two TLV types are defined: one Message TLV type and one Address Block TLV type.
本节规定了NHDP消息中使用的TLV类型，以识别正在使用的CDS中继集选择算法。定义了两种TLV类型：一种消息TLV类型和一种地址块TLV类型。
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.
表示为SMF_type的消息TLV type用于标识与NHDP一起运行的SMF实例的存在。此消息TLV类型利用[RFC5444]定义的扩展类型字段来传递SMF消息发起人当前使用的CDS中继集选择算法。当NHDP用于支持SMF操作时，包含具有适当值的扩展类型字段的SMF_类型TLV应包含在NHDP_HELLO消息（如[RFC6130]中定义的HELLO消息）中。这允许SMF路由器了解邻居何时配置为使用NHDP进行信息交换，包括算法类型和相关算法信息。这些信息可用于采取行动，例如使用不兼容的算法忽略邻居信息。SMF邻居可能会以不同的方式配置，并且仍然协同工作，但这些情况将根据指定的算法类型而有所不同。
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.
本文件定义了符合[RFC5444]的表6中规定的信息TLV类型。TLV扩展类型字段用于包含发送方的“中继算法类型”。这些TLV的“值”内容的解释是根据“中继算法类型”定义的，可能包含特定于算法的信息。
+---------------+----------------+--------------------+
| | TLV Syntax | Field Values |
+---------------+----------------+--------------------+
| type | <tlv-type> | SMF_TYPE |
| extended type | <tlv-type-ext> | <relayAlgorithmId> |
| length | <length> | variable |
| value | <value> | variable |
+---------------+----------------+--------------------+
+---------------+----------------+--------------------+
| | 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
表6:SMF类型消息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.
在表6中，<relayAlgorithmId>是一个8位字段，其中包含一个数字0-255，表示相应NHDP消息的发起者地址的“中继算法类型”。
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.
表7中定义了<relayAlgorithmId>的值。该表提供了值分配、未来IANA分配空间和实验空间。实验性空间使用不得假设唯一性；因此，在正式IANA分配之前，不应将其用于一般互操作部署。
+-------------+--------------------+--------------------------------+
| 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 |
+-------------+--------------------+--------------------------------+
+-------------+--------------------+--------------------------------+
| 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
表7:SMF继电器算法类型值
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.
SMF_类型TLV的可接受<length>和<value>字段取决于扩展类型值（即中继算法类型）。<tlv type ext>字段中传达的适当算法类型定义了其tlv<value>字段的含义和格式。关于本文件定义的算法，请参见<value>字段格式的相应附录。
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
表8规定了地址块TLV类型，表示为SMF_NBR_类型（即SMF邻居中继算法）。此TLV使CDS中继算法操作和配置能够在2-hop之间共享
neighborhoods. Some relay algorithms require 2-hop neighbor configuration in order to correctly select relay sets. It is also useful when mixed relay algorithm operation is possible. Some examples of mixed use are outlined in the appendices.
社区。某些中继算法需要2跳邻居配置，以便正确选择中继集。当混合中继算法操作可行时，它也很有用。附录中概述了混合使用的一些示例。
The message SMF_TYPE TLV and Address Block SMF_NBR_TYPE TLV types share a common format.
消息SMF_类型TLV和地址块SMF_NBR_类型TLV类型共享一种通用格式。
+---------------+----------------+--------------------+
| | TLV syntax | Field Values |
+---------------+----------------+--------------------+
| type | <tlv-type> | SMF_NBR_TYPE |
| extended type | <tlv-type-ext> | <relayAlgorithmId> |
| length | <length> | variable |
| value | <value> | variable |
+---------------+----------------+--------------------+
+---------------+----------------+--------------------+
| | 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
表8:SMF型地址块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.
表8中的<relayAlgorithmId>是一个8位无符号整数字段，其中包含一个数字0-255，表示与地址块中任何关联地址对应的“中继算法类型”值。注意，如[RFC5444]所述，2跳邻居的“中继算法类型”值可以在单个TLV或多值TLV中传输。预计使用NHDP的SMF路由器将构造具有SMF_NBR_类型TLV的地址块，以公布“中继算法类型”，并公布SMF_类型TLV中从这些邻居接收的邻居算法值。
Again, values for the <relayAlgorithmId> are defined in Table 7.
同样，表7中定义了<relayAlgorithmId>的值。
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.
SMF_NBR_型TLV“值”字段的解释根据“中继算法类型”定义，可能包含算法特定信息。有关本文档定义的算法的值字段定义，请参见相应的附录。
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:
预计SMF将用于在MANET或网状路由拓扑中提供简单的多播流量转发。边界路由器网关方法应用于允许SMF路由域与使用其他多播路由协议（如PIM）的网络互连。需要注意的是，在讨论边界多播路由器时，有许多特定于场景的问题需要解决。目前，已经演示了SMF和PIM边界路由器方法的实验部署[DHS08]。边界路由器可能需要解决的一些功能包括：
1. Determination of which multicast group traffic transits the border router whether entering or exiting the attached SMF routing domain.
1. 确定哪个多播组流量通过边界路由器进入或退出连接的SMF路由域。
2. Enforcement of TTL/hop limit threshold or other scoping policies.
2. 实施TTL/hop限制阈值或其他范围策略。
3. Any marking or labeling to enable DPD on ingressing packets.
3. 在进入数据包上启用DPD的任何标记或标签。
4. Interface with exterior multicast routing protocols.
4. 与外部多播路由协议的接口。
5. Possible operation with multiple border routers (presently beyond the scope of this document).
5. 可能使用多个边界路由器进行操作（目前超出本文档的范围）。
6. Provisions for participating non-SMF devices (routers or hosts).
6. 参与非SMF设备（路由器或主机）的规定。
Each of these areas is discussed in more detail in the following subsections. Note the behavior of SMF border routers is the same as that of non-border SMF routers when forwarding packets on interfaces within the SMF routing domain. Packets that are passed outbound to interfaces operating fixed-infrastructure multicast routing protocols SHOULD be evaluated for duplicate packet status since present standard multicast forwarding mechanisms do not usually perform this function.
以下各小节将对这些领域进行更详细的讨论。注意：SMF边界路由器在SMF路由域内的接口上转发数据包时的行为与非边界SMF路由器相同。由于目前的标准多播转发机制通常不执行此功能，因此应评估向外传递到操作固定基础结构多播路由协议的接口的数据包的重复数据包状态。
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.
用于动态确定转发到MANET SMF路由域的组的机制是一个不断发展的技术领域。理想情况下，只有具有活动组成员身份的流量才应注入SMF域。这可以通过提供IPv4 Internet组成员协议（IGMP）或IPv6多播侦听器发现（MLD）代理协议来实现，以便MANET SMF路由器可以将其当前组成员状态通知连接的边界路由器（从而通知多播网络）。对于特定的系统和服务，可以在边界路由器中静态配置组成员加入，但建议提供某种形式的IGMP/MLD代理或其他明确的、动态的成员控制。这种IGMP/MLD代理协议的规范超出了本文档的范围。
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
对于出站流量，SMF边界路由器执行重复数据包检测，并将满足TTL/hop限制和作用域标准的非重复流量转发到SMF路由域外部的接口。在这些接口上适当的IP多播路由（例如，基于PIM的解决方案）可以做出关于多播分组的进一步转发决策。请注意，存在多个
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.
与MANET路由域关联的边界路由器会引发其他问题。第9.4节对此进行了进一步讨论，但此处预计还需要进一步的工作。
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:
网络管理员使用多播作用域来控制多播数据包可访问的网络路由域。这通常通过在路由域的边界中配置边界路由器的外部接口来完成，以不转发必须保留在SMF路由域中的多播数据包。这通常是基于消息的TTL/hop限制或使用管理范围的组地址来完成的。这些方案分别称为：
1. TTL scoping.
1. TTL范围界定。
2. Administrative scoping.
2. 行政范围界定。
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.
对于IPv4，网络管理员可以像配置任何传统多播路由器一样，为路由器接口配置具有适当TTL/hop限制阈值的边界路由器或具有管理作用域的多播组。然而，对于TTL/hop限制范围的情况，应该考虑到在到达边界路由器之前，分组可以在MANET SMF路由域内穿越多个hop。因此，应仔细选择TTL阈值。
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.
对于IPv6，多播地址空间包含有关组范围的信息。因此，SMF路由域的边界路由器知道它们是否必须基于IPv6多播组地址转发数据包。对于IPv6，建议将MANET SMF路由域指定为站点范围的多播域。因此，FF05:：/16范围内的所有IPv6站点范围的多播数据包应由边界路由器保持在MANET SMF路由域内。任何其他范围更广的作用域（即FF08:：/16、FF0B:：/16和FF0E:：16）中的IPv6数据包可能会穿越边界路由器，除非适用与该作用域不同的其他限制。
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.
鉴于多播数据包的作用域是在边界路由器上执行的，并且鉴于现有的作用域机制不是设计用于移动路由器的，因此假设运行SMF的非边界路由器不会停止转发适当站点作用域的多播数据包。也就是说，假设SMF路由域是站点范围的多播区域。
The traditional operation of multicast routing protocols is tightly integrated with the group membership function. Leaf routers are configured to periodically gather group membership information, while intermediate routers conspire to create multicast trees connecting routers with directly connected multicast sources and routers with active multicast receivers. In the concrete case of SMF, border routers can be considered leaf routers. Mechanisms for multicast sources and receivers to interoperate with border routers over the multi-hop MANET SMF routing domain as if they were directly connected to the router need to be defined. The following issues need to be addressed:
组播路由协议的传统操作与组成员函数紧密结合。叶路由器被配置为周期性地收集组成员信息，而中间路由器合谋创建多播树，将具有直接连接的多播源的路由器和具有活动多播接收器的路由器连接起来。在SMF的具体情况下，边界路由器可以被视为叶路由器。需要定义多播源和接收器在多跳MANET SMF路由域上与边界路由器互操作的机制，就像它们直接连接到路由器一样。需要解决以下问题：
1. A mechanism by which border routers gather membership information
1. 边界路由器收集成员信息的机制
2. A mechanism by which multicast sources are known by the border router
2. 边界路由器知道多播源的一种机制
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.
3. 如果SMF路由域要为多播通信提供传输连接，则通过SMF路由域交换外部路由协议消息的机制。
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.
解决这些问题的实施解决方案超出了本文件的范围。如第9.1节所述，IGMP/MLD代理机制可以解决其中一些问题。类似地，外部路由协议消息可以通过SMF路由域进行隧道传输或传输，但在分布式无线环境中这样做可能需要本文档范围之外的其他考虑。
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.
边界路由器需要从SMF路由域内已识别的多播源接收流量，这对于实现与某些现有路由协议的互操作性非常重要。例如，PIM-S要求具有本地连接的多播源的路由器将其注册到集合点（RP），以便路由器可以加入多播树。此外，如果没有使用多播源发现协议（MSDP）将这些源通告给其他自治系统（ASE），则这些外部网络中的接收器将无法加入该源的多播树。
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
SMF路由域可以部署多个参与路由器，这些路由器可以连接到外部固定基础设施网络。允许多个路由器将多播通信转发到SMF路由域或从SMF路由域转发多播通信是有益的，因为它可以提高可靠性并提供更好的服务。例如，如果SMF
routing domain were to fragment with different SMF routers maintaining connectivity to different border routers, multicast service could still continue successfully. But, the case of multiple border routers connecting an SMF routing domain to external networks presents several challenges for SMF:
当路由域与不同的SMF路由器断开并保持与不同边界路由器的连接时，多播服务仍然可以成功继续。但是，多个边界路由器将SMF路由域连接到外部网络的情况给SMF带来了几个挑战：
1. Handling duplicate unmarked IPv4 or IPv6 (without IPsec encapsulation or DPD option) packets possibly injected by multiple border routers.
1. 处理可能由多个边界路由器注入的重复的未标记IPv4或IPv6（无IPsec封装或DPD选项）数据包。
2. Handling of duplicate traffic injected by multiple border routers by source-based relay algorithms.
2. 通过基于源的中继算法处理多个边界路由器注入的重复流量。
3. Determining which border router(s) will forward outbound multicast traffic.
3. 确定哪些边界路由器将转发出站多播流量。
4. Additional challenges with interfaces to exterior multicast routing protocols.
4. 外部多播路由协议接口的其他挑战。
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:
当存在多个边界路由器时，它们可能会交替地（由于路由更改）或同时向SMF路由域注入公共通信量，该SMF路由域以前未标记为IPv6 SMF_DPD。不同的边界路由器将无法隐式同步注入流量的排序，因为由于数据包丢失，它们可能无法接收完全相同的消息。对于IPv6 I-DPD操作，SMF_DPD选项标头中描述的可选标记ID字段可用于缓解此问题。当多个边界路由器向SMF路由域注入流时，运行I-DPD的SMF路由器可以实现两种转发策略：
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
1. 从每个边界路由器冗余转发多播流（由<srcadr:dstAddr>标识），在<TaggerID:dstAddr>或<TaggerID:srcadr:dstAddr>的基础上执行DPD处理，或
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.
2. 使用一些基础来选择一个标记器（边界路由器）的流而不是其他标记器的流，并仅为所选标记器ID转发适用流（由<sourceAddress:dstAddr>标识）的数据包，直到超时或其他有利于另一标记器的条件出现。
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.
建议在I-DPD操作的情况下使用第一种方法。可能需要附加规范来描述基于第二个选项的可互操作转发策略。注意，第二个选项的实现要求为所选标记ID维护每个流（即，<srcadr:：dstAddr>）状态。
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.
当入口流量来自多个边界路由器时，部署H-DPD操作可减轻DPD分辨率。应该有效地解决非冲突散列索引（IPv6中不需要H-DPD选项头的索引）。
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.
无偿使用选项头可能会导致路由器出现问题。SMF路由域外部可能接收转发多播的其他IP路由器在遇到SMF时应忽略特定于SMF的IPv6标头选项。标头选项类型经过适当编码以允许此行为。
This section briefly discusses several SMF denial-of-service (DoS) attack scenarios and provides some initial recommended mitigation strategies.
本节简要讨论几种SMF拒绝服务（DoS）攻击场景，并提供一些初步建议的缓解策略。
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.
当恶意路由器以虫洞形式访问网络拓扑的非相邻部分时，可能会对SMF转发发起潜在的拒绝服务攻击。在无线自组织的情况下，定向天线是物理上提供这种虫洞的一种方法。如果这样的路由器可以预览网络非相邻部分中转发的数据包，并将修改后的版本转发到网络的另一部分，那么它可以执行以下攻击。恶意路由器可降低数据包的TTL/hop限制或hop限制，并将其传输至SMF路由器，从而使其转发具有有限TTL/hop限制的数据包（甚至丢弃该数据包），并生成DPD条目，该条目可阻止或限制具有正确TTL/hop限制值的随后到达的有效数据包的转发。这将是一种相对低成本、高回报的攻击，很难检测到，因此对潜在攻击者具有吸引力。第5节确定了一种使用DPD状态缓存TTL/hop限制信息并采取适当转发操作的方法，以减轻这种形式的攻击。
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
基于序列的数据包标识符是可预测的，因此为针对转发的DoS攻击提供了机会。使用DPD技术（如SMF）的转发协议可能容易受到基于具有明显有效数据包标识符字段的欺骗数据包的DoS攻击。在最有可能使用SMF的无线环境中，此类攻击的机会可能比有线网络中更普遍。在IPv4数据包、分段IP数据包或应用IPsec报头的数据包的情况下，可能转发的潜在未来数据包的DPD“标识符部分”是高度可预测的，并且容易受到针对转发的DoS攻击。针对这一问题的推荐技术是SMF实现生成一个“内部”散列值，该散列值与显式I-DPD数据包标识符连接以形成一个
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.
唯一标识符，是数据包内容和可见标识符的函数。SMF实现可以使用一个随机值作为散列生成的种子，这样外部观察者就不太可能猜到如何欺骗拒绝服务攻击中使用的数据包。由于散列计算和状态完全保留在SMF路由器内部，因此该散列的密码特性不需要广泛，因此可能具有较低的复杂性。实验实现可以确定，即使只是数据包的一部分的轻量级散列也足以满足此目的。
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.
虽然H-DPD不太容易受到这种形式的DoS攻击，但一个老练的对手可能会利用旁侧信息来构造欺骗数据包，从而使用众所周知的哈希算法误导转发器。因此，类似地，可以将单独的“内部”散列值与众所周知的散列值连接起来，以减轻这种安全问题。
The support of forwarding IPsec packets without further modification for both IPv4 and IPv6 is supported by this specification.
本规范支持在不进一步修改IPv4和IPv6的情况下转发IPsec数据包。
Authentication mechanisms to identify the source of IPv6 option headers should be considered to reduce vulnerability to a variety of attacks.
应考虑使用身份验证机制来识别IPv6选项头的来源，以减少对各种攻击的脆弱性。
Furthermore, when the MANET Neighborhood Discovery Protocol [RFC6130] is used, the security considerations described in [RFC6130] also apply.
此外，当使用MANET邻居发现协议[RFC6130]时，[RFC6130]中描述的安全注意事项也适用。
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].
本文档定义了一个IPv6逐跳选项，其类型已从[RFC2780]的IPv6“目标选项和逐跳选项”注册表中分配。
This document creates one registry called "TaggerId Types" for recording TaggerId types, (TidTy), as a sub-registry in the "IPv6 Parameters" registry.
本文档创建了一个名为“TaggerId类型”的注册表，用于记录TaggerId类型（TidTy），作为“IPv6参数”注册表中的子注册表。
This document registers one well-known multicast address from each of the IPv4 and IPv6 multicast address spaces.
本文档从每个IPv4和IPv6多播地址空间注册一个众所周知的多播地址。
This document defines one Message TLV, a type for which has been allocated from the "Message TLV Types" registry of [RFC5444].
本文档定义了一个消息TLV，其类型已从[RFC5444]的“消息TLV类型”注册表中分配。
Finally, this document defines one Address Block TLV, a type for which has been allocated from the "Address Block TLV Types" registry of [RFC5444].
最后，本文档定义了一个地址块TLV，该类型已从[RFC5444]的“地址块TLV类型”注册表中分配。
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.
IANA已从[RFC2780]的IPv6“目标选项和逐跳选项”注册表中分配了IPv6选项类型，如表9所示。
+-----------+-------------------------+-------------+---------------+
| Hex Value | Binary Value | Description | Reference |
| | act | chg | rest | | |
+-----------+-------------------------+-------------+---------------+
| 8 | 00 | 0 | 01000 | SMF_DPD | This Document |
+-----------+-------------------------+-------------+---------------+
+-----------+-------------------------+-------------+---------------+
| Hex Value | Binary Value | Description | Reference |
| | act | chg | rest | | |
+-----------+-------------------------+-------------+---------------+
| 8 | 00 | 0 | 01000 | SMF_DPD | This Document |
+-----------+-------------------------+-------------+---------------+
Table 9: IPv6 Option Type Allocation
表9:IPv6选项类型分配
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.
SMF_DPD中选项数据内容的一部分是标记器标识符类型（TidTy），它为可选包含的标记器ID提供上下文。
IANA has created a registry for recording TaggerId Types (TidTy), with initial assignments and allocation policies, as specified in Table 10.
IANA已经创建了一个注册表，用于记录TaggerId类型（TITTY），以及初始分配和分配策略，如表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 | |
+------+----------+------------------------------------+------------+
+------+----------+------------------------------------+------------+
| 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
表10：标记符类型
For allocation of unassigned values 4-7, IETF Review [RFC5226] is required.
对于未分配值4-7的分配，需要IETF审查[RFC5226]。
IANA has allocated an IPv4 multicast address "SL-MANET-ROUTERS" (224.0.1.186) from the "Internetwork Control Block (224.0.1.0- 224.0.1.255 (224.0.1/24))" sub-registry of the "IPv4 Multicast Address" registry.
IANA已从“IPv4多播地址”注册表的“网络间控制块（224.0.1.0-224.0.1.255（224.0.1/24））”子注册表中分配了IPv4多播地址“SL-MANET-ROUTERS”（224.0.1.186）。
IANA has allocated an IPv6 multicast address "SL-MANET-ROUTERS" from the "Site-Local Scope Multicast Addresses" sub-sub-registry of the "Fixed Scope Multicast Addresses" sub-registry of the "INTERNET PROTOCOL VERSION 6 MULTICAST ADDRESSES" registry.
IANA已从“INTERNET协议版本6多播地址”注册表的“固定作用域多播地址”子注册表的“站点本地作用域多播地址”子注册表中分配了IPv6多播地址“SL-MANET-ROUTERS”。
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].
在[RFC5444]的注册表以及[RFC6130]的HELLO消息特定注册表中创建地址块TLV类型和消息TLV类型需要为每种此类类型创建相应的类型扩展注册表。对于此类类型扩展登记处，如果需要专家审查，指定专家应考虑[RFC5444]规定的一般建议。
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].
本文档定义了一种消息TLV类型“SMF_类型”，它是从[RFC6130]中定义的“HELLO消息类型特定消息TLV类型”注册表中分配的。
This created a new Type Extension registry, with initial assignments as specified in Table 11.
这创建了一个新的类型扩展注册表，初始分配如表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. | |
+----------+------+-----------+--------------------+----------------+
+----------+------+-----------+--------------------+----------------+
| Name | Type | Type | Description | Allocation |
| | | Extension | | Policy |
+----------+------+-----------+--------------------+----------------+
| SMF_TYPE | 128 | 0-255 | Specifies relay | Section 11.4.4 |
| | | | algorithm | |
| | | | supported by the | |
| | | | SMF router, | |
| | | | originating the | |
| | | | HELLO message, | |
| | | | according to | |
| | | | Section 11.4.4. | |
+----------+------+-----------+--------------------+----------------+
Table 11: SMF_TYPE Message TLV Type Extension Registry
表11:SMF_类型消息TLV类型扩展注册表
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].
本文档定义了一个地址块TLV类型“SMF_NBR_类型”，该类型已从[RFC6130]中定义的“HELLO消息类型特定地址块TLV类型”注册表中分配。
This has created a new Type Extension registry, with initial assignments as specified in Table 12.
这创建了一个新的类型扩展注册表，初始分配如表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. | |
+--------------+--------+-----------+-----------------+-------------+
+--------------+--------+-----------+-----------------+-------------+
| 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
表12:SMF_NBR_类型地址块TLV类型扩展注册表
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.
SMF_类型消息TLV和SMF_NBR_类型地址块TLV的类型扩展注册表的类型统一在本节中定义的单个SMF中继算法ID注册表中。
IANA has created a registry for recording Relay Algorithm Identifiers, with initial assignments and allocation policies as specified in Table 13.
IANA创建了一个用于记录中继算法标识符的注册表，初始分配和分配策略如表13所示。
+---------+---------+-------------+-------------------+
| Value | Name | Description | Allocation Policy |
+---------+---------+-------------+-------------------+
| 0 | CF | Section 4 | |
| 1 | S-MPR | Appendix B | |
| 2 | E-CDS | Appendix A | |
| 3 | MPR-CDS | Appendix C | |
| 4-127 | | Unassigned | Expert Review |
| 128-255 | | Unassigned | Experimental Use |
+---------+---------+-------------+-------------------+
+---------+---------+-------------+-------------------+
| 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
表13：继电器集算法类型值
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).
从SMF中继算法ID注册表请求4-127范围分配的规范必须指定<value>字段的解释（如果有）。
Many of the concepts and mechanisms used and adopted by SMF resulted over several years of discussion and related work within the MANET working group since the late 1990s. There are obviously many contributors to past discussions and related draft documents within the working group that have influenced the development of SMF concepts, and they deserve acknowledgment. In particular, this document is largely a direct product of the earlier SMF design team within the IETF MANET working group and borrows text and implementation ideas from the related individuals and activities. Some of the direct contributors who have been involved in design, content editing, prototype implementation, major commenting, and core discussions are listed below in alphabetical order. We appreciate all the input and feedback from the many community members and early implementation users we have heard from that are not on this list as well.
自20世纪90年代末以来，移动自组网工作组经过数年的讨论和相关工作，使用和采用了移动自组网的许多概念和机制。显然，工作组内过去的讨论和相关文件草案有许多贡献者，这些贡献者对SMF概念的发展产生了影响，值得肯定。特别是，本文件主要是IETF MANET工作组内早期SMF设计团队的直接成果，并借鉴了相关个人和活动的文本和实施理念。下面按字母顺序列出了一些参与设计、内容编辑、原型实现、主要评论和核心讨论的直接贡献者。我们感谢许多社区成员和早期实施用户的所有意见和反馈，他们也不在本列表中。
Brian Adamson Teco Boot Ian Chakeres Thomas Clausen Justin Dean Brian Haberman Ulrich Herberg Charles Perkins Pedro Ruiz Fred Templin Maoyu Wang
Brian Adamson Teco Boot Ian Chakeres Thomas Clausen Justin院长Brian Haberman Ulrich Herberg Charles Perkins Pedro Ruiz Fred Templin王茂宇
[MPR-CDS] Adjih, C., Jacquet, P., and L. Viennot, "Computing Connected Dominating Sets with Multipoint Relays", Ad Hoc and Sensor Wireless Networks, January 2005.
[MPR-CDS]Adjih，C.，Jacquet，P.，和L.Vienno，“使用多点中继计算连通支配集”，特设和传感器无线网络，2005年1月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC2644] Senie, D., "Changing the Default for Directed Broadcasts in Routers", BCP 34, RFC 2644, August 1999.
[RFC2644]Senie，D.，“更改路由器中定向广播的默认设置”，BCP 34，RFC 2644，1999年8月。
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000.
[RFC2780]Bradner，S.和V.Paxson，“互联网协议和相关报头中值的IANA分配指南”，BCP 37，RFC 2780，2000年3月。
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[RFC3174]Eastlake，D.和P.Jones，“美国安全哈希算法1（SHA1）”，RFC 3174，2001年9月。
[RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing Protocol (OLSR)", RFC 3626, October 2003.
[RFC3626]Clausen，T.和P.Jacquet，“优化链路状态路由协议（OLSR）”，RFC 3626，2003年10月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]Kent，S.，“IP认证头”，RFC43022005年12月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format", RFC 5444, February 2009.
[RFC5444]Clausen，T.，Dearlove，C.，Dean，J.，和C.Adjih，“通用移动自组网（MANET）数据包/消息格式”，RFC 54442009年2月。
[RFC5614] Ogier, R. and P. Spagnolo, "Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding", RFC 5614, August 2009.
[RFC5614]Ogier，R.和P.Spagnolo，“使用连接支配集（CDS）泛洪的OSPF移动自组织网络（MANET）扩展”，RFC 5614，2009年8月。
[RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51, RFC 5771, March 2010.
[RFC5771]Cotton，M.，Vegoda，L.，和D.Meyer，“IPv4多播地址分配的IANA指南”，BCP 51，RFC 57712010年3月。
[RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", RFC 6130, April 2011.
[RFC6130]Clausen，T.，Dearlove，C.，和J.Dean，“移动自组织网络（MANET）邻域发现协议（NHDP）”，RFC6130，2011年4月。
[CDHM07] Chakeres, I., Danilov, C., Henderson, T., and J. Macker, "Connecting MANET Multicast", IEEE MILCOM 2007 Proceedings, 2007.
[CDHM07]Chakeres，I.，Danilov，C.，Henderson，T.，和J.Macker，“连接MANET多播”，IEEE MILCOM 2007年会议记录，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.
[DHG09]Danilov，C.，Henderson，T.，Goff，T.，Kim，J.，Macker，J.，Weston，J.，Neogi，N.，Ortiz，A.，和D.Uhlig，“基于802.11的地面无人机移动自组网的实验和现场演示”，第28届IEEE军事通信会议记录，2009年。
[DHS08] Danilov, C., Henderson, T., Spagnolo, T., Goff, T., and J. Kim, "MANET Multicast with Multiple Gateways", IEEE MILCOM 2008 Proceedings, 2008.
[DHS08]Danilov，C.，Henderson，T.，Spagnolo，T.，Goff，T.，和J.Kim，“具有多个网关的MANET多播”，IEEE MILCOM 2008年会议记录，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.
[GM99]加西亚·卢娜·阿塞维斯，JJ。E.Madruga，“核心辅助Mesh协议”，通信选定领域，IEEE期刊，第17卷，第8期，1999年8月。
[IPV4-ID-UPDATE] Touch, J., "Updated Specification of the IPv4 ID Field", Work in Progress, September 2011.
[IPV4-ID-UPDATE]Touch，J.，“IPV4 ID字段的更新规范”，正在进行的工作，2011年9月。
[JLMV02] Jacquet, P., Laouiti, V., Minet, P., and L. Viennot, "Performance of Multipoint Relaying in Ad Hoc Mobile Routing Protocols", Networking , 2002.
[JLMV02]Jacquet，P.，Laouti，V.，Minet，P.，和L.Vienno，“adhoc移动路由协议中多点中继的性能”，网络，2002年。
[MDC04] Macker, J., Dean, J., and W. Chao, "Simplified Multicast Forwarding in Mobile Ad hoc Networks", IEEE MILCOM 2004 Proceedings, 2004.
[MDC04]Macker，J.，Dean，J.，和W.Chao，“移动自组织网络中的简化多播转发”，IEEE MILCOM 2004年论文集，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.
[MDDA07]Macker，J.，Downard，I.，Dean，J.，和R.Adamson，“移动自组织网络中用于简化多播转发的分布式覆盖集算法的评估”，ACM SIGMOBILE Mobile Computing and Communications Review，第11卷，第3期，2007年7月。
[MGL04] Mohapatra, P., Gui, C., and J. Li, "Group Communications in Mobile Ad hoc Networks", IEEE Computer, Vol. 37, No. 2, February 2004.
[MGL04]Mohapatra，P.，Gui，C.，和J.Li，“移动自组织网络中的组通信”，IEEE计算机，第37卷，第2期，2004年2月。
[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.
[NTSC99]倪，S.，曾，Y.，陈，Y.，和J.Sheu，“移动adhoc网络中的广播风暴问题”，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.
[RFC2501]Corson，M.和J.Macker，“移动自组网（MANET）：路由协议性能问题和评估考虑”，RFC 2501，1999年1月。
[RFC3684] Ogier, R., Templin, F., and M. Lewis, "Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)", RFC 3684, February 2004.
[RFC3684]Ogier，R.，Templin，F.，和M.Lewis，“基于反向路径转发（TBRPF）的拓扑传播”，RFC 3684，2004年2月。
[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005.
[RFC3973]Adams，A.，Nicholas，J.，和W.Siadak，“协议独立多播-密集模式（PIM-DM）：协议规范（修订版）”，RFC 3973，2005年1月。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4601]Fenner，B.，Handley，M.，Holbrook，H.，和I.Kouvelas，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，RFC 46012006年8月。
Appendix A. Essential Connecting Dominating Set (E-CDS) Algorithm
附录A.基本连接支配集（E-CDS）算法
The "Essential Connected Dominating Set" (E-CDS) algorithm [RFC5614] forms a single CDS mesh for the SMF operating region. It allows routers to use 2-hop neighborhood topology information to dynamically perform relay self-election to form a CDS. Its packet-forwarding rules are not dependent upon previous hop knowledge. Additionally, E-CDS SMF forwarders can be easily mixed without problems with CF SMF forwarders, even those not participating in NHDP. Another benefit is that packets opportunistically received from non-symmetric neighbors may be forwarded without compromising flooding efficiency or correctness. Furthermore, multicast sources not participating in NHDP may freely inject their traffic, and any neighboring E-CDS relays will properly forward the traffic. The E-CDS-based relay set selection algorithm is based upon [RFC5614]. 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.
“基本连通支配集”（E-CDS）算法[RFC5614]为SMF操作区域形成单个CDS网格。它允许路由器使用2跳邻域拓扑信息动态执行中继自选以形成CDS。它的包转发规则不依赖于前一跳的知识。此外，E-CDS SMF转发器可以很容易地与CF SMF转发器混合，即使不参与NHDP。另一个好处是，可以转发从非对称邻居机会主义地接收的分组，而不会影响泛洪效率或正确性。此外，不参与NHDP的多播源可以自由地注入其流量，并且任何相邻的E-CDS中继将正确地转发该流量。基于E-CDS的继电器集选择算法基于[RFC5614]。E-CDS最初是在MANET OSPF扩展工作中形成部分邻接和有效泛洪的背景下讨论的，核心算法在这里应用于SMF。
It is RECOMMENDED that the SMF_TYPE:E-CDS Message TLV be included in NHDP_HELLO messages that are generated by routers conducting E-CDS SMF operation. It is also RECOMMENDED that the SMF_NBR_TYPE:E-CDS Address Block TLV be used to advertise neighbor routers that are also conducting E-CDS SMF operation.
建议将SMF_类型：E-CDS消息TLV包含在由执行E-CDS SMF操作的路由器生成的NHDP_HELLO消息中。还建议使用SMF_NBR_TYPE:E-CDS地址块TLV来通告同样执行E-CDS SMF操作的邻居路由器。
The E-CDS relay set selection requires 2-hop neighborhood information collected through NHDP or another process. Relay routers, in E-CDS SMF selection, are "self-elected" using a Router Identifier (Router ID) and an optional nodal metric, referred to here as Router Priority for all 1-hop and 2-hop neighbors. To ensure proper relay set self-election, the Router ID and Router Priority MUST be consistent among participating routers. It is RECOMMENDED that NHDP be used to share Router ID and Router Priority through the use of SMF_TYPE:E-CDS TLVs as described in this appendix. The Router ID is a logical identification that MUST be consistent across interoperating SMF neighborhoods, and it is RECOMMENDED to be chosen as the numerically largest address contained in a router's "Neighbor Address List" as defined in NHDP. The E-CDS self-election process can be summarized as follows:
E-CDS中继集选择需要通过NHDP或其他过程收集2跳邻居信息。在E-CDS SMF选择中，中继路由器使用路由器标识符（路由器ID）和可选节点度量“自选”，这里称为所有1-hop和2-hop邻居的路由器优先级。为确保正确的中继集自选，参与路由器之间的路由器ID和路由器优先级必须一致。建议使用NHDP通过使用SMF_类型：E-CDS TLV共享路由器ID和路由器优先级，如本附录所述。路由器ID是一个逻辑标识，必须在互操作的SMF邻居之间保持一致，建议选择它作为NHDP中定义的路由器“邻居地址列表”中包含的数字最大的地址。E-CDS自选过程可总结如下：
1. If an SMF router has a higher ordinal (Router Priority, Router ID) than all of its symmetric neighbors, it elects itself to act as a forwarder for all received multicast packets.
1. 如果SMF路由器的序号（路由器优先级，路由器ID）高于其所有对称邻居，它会选择自己作为所有接收到的多播数据包的转发器。
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.
2. 否则，如果不存在从具有最大（路由器优先级，路由器ID）的邻居到任何其他邻居的路径，通过具有较大值（路由器优先级，路由器ID）的邻居，则它选择自己作为中继集。
The basic form of E-CDS described and applied within this specification does not provide for redundant relay set selection (e.g., bi-connected), but such capability is supported by the basic E-CDS design.
本规范中描述和应用的E-CD的基本形式不提供冗余继电器组选择（例如，双连接），但基本E-CD设计支持这种能力。
With E-CDS, any SMF router that has selected itself as a relay performs DPD and forwards all non-duplicative multicast traffic allowed by the present forwarding policy. Packet previous-hop knowledge is not needed for forwarding decisions when using E-CDS.
对于E-CDS，选择自身作为中继的任何SMF路由器执行DPD并转发当前转发策略允许的所有非重复多播流量。使用E-CD时，转发决策不需要数据包前一跳的知识。
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.
1. 在分组接收时，执行DPD。注：E-CDS需要一个与继电器组选择相关联的接口集的单一重复表。
2. If the packet is a duplicate, no further action is taken.
2. 如果数据包是重复的，则不采取进一步的操作。
3. If the packet is non-duplicative:
3. 如果数据包是非重复的：
A. A DPD entry is made for the packet identifier.
A.为数据包标识符创建DPD条目。
B. The packet is forwarded out to all interfaces associated with the relay set selection.
B.数据包被转发到与中继集选择相关的所有接口。
As previously mentioned, even packets sourced (or relayed) by routers not participating in NHDP and/or the E-CDS relay set selection may be forwarded by E-CDS forwarders without problem. A particular deployment MAY choose to not forward packets from previous hop routers that have been not explicitly identified via NHDP or other means as operating as part of a different relay set algorithm (e.g., S-MPR) to allow coexistent deployments to operate correctly. Also, E-CDS relay set selection may be configured to be influenced by statically configured CF relays that are identified via NHDP or other means.
如前所述，即使由不参与NHDP和/或E-CDS中继集选择的路由器来源（或中继）的分组也可以由E-CDS转发器毫无问题地转发。特定部署可选择不转发来自先前跳路由器的数据包，这些数据包未通过NHDP或其他方式明确标识为作为不同中继集算法（例如，S-MPR）的一部分运行，以允许共存部署正确运行。此外，E-CDS继电器组选择可配置为受通过NHDP或其他方式识别的静态配置CF继电器的影响。
It is possible to perform E-CDS relay set selection without modification of NHDP, basing the self-election process exclusively on the "Neighbor Address List" of participating SMF routers, for example, by setting the Router Priority to a default value and selecting the Router ID as the numerically largest address contained
可以在不修改NHDP的情况下执行E-CDS中继集选择，例如，通过将路由器优先级设置为默认值并选择路由器ID作为包含的数字最大的地址，将自选过程完全基于参与SMF路由器的“邻居地址列表”
in the "Neighbor Address List". However, steps MUST be taken to ensure that all NHDP-enabled routers not using SMF_TYPE:E-CDS full type Message TLVs are, in fact, running SMF E-CDS with the same methods for selecting Router Priority and Router ID; otherwise, incorrect forwarding may occur. Note that SMF routers with higher Router Priority values will be favored as relays over routers with lower Router Priority. Thus, preferred relays MAY be administratively configured to be selected when possible. Additionally, other metrics (e.g., nodal degree, energy capacity, etc.) may also be taken into account in constructing a Router Priority value. When using Router Priority with multiple interfaces, all interfaces on a router MUST use and advertise a common Router Priority value. A router's Router Priority value may be administratively or algorithmically selected. The method of selection does not need to be the same among different routers.
在“邻居地址列表”中。但是，必须采取措施确保所有未使用SMF_类型的NHDP启用路由器：E-CDS完整类型消息TLV实际上使用相同的方法运行SMF E-CDS，以选择路由器优先级和路由器ID；否则，可能会发生不正确的转发。请注意，具有较高路由器优先级值的SMF路由器将优先作为中继，而不是具有较低路由器优先级的路由器。因此，优选的继电器可以被管理地配置为在可能时被选择。此外，在构造路由器优先级值时还可以考虑其他度量（例如，节点度、能量容量等）。当对多个接口使用路由器优先级时，路由器上的所有接口都必须使用并公布一个公共路由器优先级值。路由器的路由器优先级值可以通过管理或算法选择。不同路由器之间的选择方法不需要相同。
E-CDS relay set selection may be configured to be influenced by statically configured CF relays that are identified via NHDP or other means. Nodes advertising CF through NHDP may be considered E-CDS SMF routers with maximal Router Priority.
E-CDS继电器组选择可配置为受通过NHDP或其他方式识别的静态配置CF继电器的影响。通过NHDP广告CF的节点可被视为具有最大路由器优先级的E-CDS SMF路由器。
To share a router's Router Priority with its 1-hop neighbors, the SMF_TYPE:E-CDS Message TLV's <value> field is defined as shown in Table 14.
为了与其1跳邻居共享路由器的路由器优先级，SMF_TYPE:E-CDS消息TLV的<value>字段定义如表14所示。
+----------------+---------+-----------------+
| Length (bytes) | Value | Router Priority |
+----------------+---------+-----------------+
| 0 | N/A | 64 |
| 1 | <value> | 0-127 |
+----------------+---------+-----------------+
+----------------+---------+-----------------+
| Length (bytes) | Value | Router Priority |
+----------------+---------+-----------------+
| 0 | N/A | 64 |
| 1 | <value> | 0-127 |
+----------------+---------+-----------------+
Table 14: E-CDS Message TLV Values
表14:E-CDS消息TLV值
Where <value> is a one-octet-long bit field that is defined as:
其中，<value>是一个八位字节长的位字段，定义为：
bit 0: the leftmost bit is reserved and SHOULD be set to 0.
位0：最左边的位是保留的，应设置为0。
bits 1-7: contain the unsigned Router Priority value, 0-127, which is associated with the "Neighbor Address List".
位1-7：包含与“邻居地址列表”关联的无符号路由器优先级值0-127。
Combinations of value field lengths and values other than specified here are NOT permitted and SHOULD be ignored. Figure 6 shows an example SMF_TYPE:E-CDS Message TLV.
不允许组合值字段长度和此处指定以外的值，应忽略。图6显示了一个示例SMF_类型：E-CDS消息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 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: E-CDS Message TLV Example
图6:E-CDS消息TLV示例
To convey Router Priority values among 2-hop neighborhoods, the SMF_NBR_TYPE:E-CDS Address Block TLV's <value> field is used. Multi-index and multivalue TLV layouts as defined in [RFC5444] are supported. SMF_NBR_TYPE:E-CDS value fields are defined thus:
为了在两跳邻居之间传递路由器优先级值，使用SMF_NBR_TYPE:E-CDS地址块TLV的<value>字段。支持[RFC5444]中定义的多索引和多值TLV布局。SMF_NBR_类型：E-CDS值字段定义如下：
+---------------+--------+----------+-------------------------------+
| Length(bytes) | # Addr | Value | Router Priority |
+---------------+--------+----------+-------------------------------+
| 0 | Any | N/A | 64 |
| 1 | Any | <value> | <value> is for all addresses |
| N | N | <value>* | Each address gets its own |
| | | | <value> |
+---------------+--------+----------+-------------------------------+
+---------------+--------+----------+-------------------------------+
| Length(bytes) | # Addr | Value | Router Priority |
+---------------+--------+----------+-------------------------------+
| 0 | Any | N/A | 64 |
| 1 | Any | <value> | <value> is for all addresses |
| N | N | <value>* | Each address gets its own |
| | | | <value> |
+---------------+--------+----------+-------------------------------+
Table 15: E-CDS Address Block TLV Values
表15:E-CDS地址块TLV值
Where <value> is a one-byte bit field that is defined as:
其中<value>是一个单字节位字段，定义为：
bit 0: the leftmost bit is reserved and SHOULD be set to 0.
位0：最左边的位是保留的，应设置为0。
bits 1-7: contain the unsigned Router Priority value, 0-127, which is associated with the appropriate address(es).
位1-7：包含无符号路由器优先级值0-127，该值与相应的地址相关联。
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.
不允许值字段长度和#地址的组合（此处未指定），应忽略。对于这些TLV类型的值字段，建议使用节点度（即，1跳邻居计数）的默认技术。下面是两个SMF_NBR_类型的示例：E-CDS地址块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_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|0|1|0|0| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| E-CDS |0|0|0|0|0|0|0|1|R| priority | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: E-CDS Address Block TLV Example 1
图7:E-CDS地址块TLV示例1
The single value example TLV, depicted in Figure 7, 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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The single value example TLV, depicted in Figure 7, 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.
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 8: E-CDS Address Block TLV Example 2
图8:E-CDS地址块TLV示例2
The example multivalued TLV, depicted in Figure 8, 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.
图8所示的示例多值TLV指定地址块中包含的从索引开始到索引结束（包括索引结束）的地址使用E-CDS算法运行SMF。每个地址都与自己的值字节相关联，因此也与自己的路由器优先级相关联。
This section describes an algorithm for E-CDS relay selection (self-election). The algorithm described uses 2-hop information. Note that 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 [RFC5614] 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.
本节介绍E-CDS继电器选择（自选）的算法。所描述的算法使用2跳信息。请注意，可以扩展该算法以使用具有额外计算复杂性的k-hop信息以及用于共享k-hop拓扑信息的机制，这些信息未在本文档或NHDP规范中描述。还应注意，当执行用于中继选择的路径搜索时，该算法不会施加[RFC5614]中所述的跃点限制界限。然而，下面的算法可以很容易地进行扩充，以适应这个额外的标准。预计跳数限制范围不会对本附录中定义的算法产生重大益处。
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 tiebreaker. The evaluation of this tuple is referred to as "RtrPri(n)" in the description below where "n" references a specific router. Note that it is possible that the Router Priority portion may be optional and the evaluation of "RtrPri()" be solely based upon the unique Router ID. Since there MUST NOT be any duplicate Router ID values among SMF routers, a comparison of "RtrPri(n)" between any two routers will always be an inequality. The use of nodal degree for calculating Router Priority is RECOMMENDED as default, and the largest IP address in the
路由器优先级和路由器ID的元组用于选择E-CDS中继集。优先权被赋予路由器优先级部分，并且路由器ID值被用作分接器。在下面的描述中，该元组的计算被称为“RtrPri（n）”，其中“n”引用特定路由器。请注意，路由器优先级部分可能是可选的，并且“RtrPri（）”的计算仅基于唯一的路由器ID。由于SMF路由器之间不得存在任何重复的路由器ID值，因此任何两个路由器之间的“RtrPri（n）”的比较将始终是一个不等式。默认情况下，建议使用节点度计算路由器优先级，并使用
"Neighbor Address List" as advertised by NHDP MUST be used as the Router ID. NHDP provides all interface addresses throughout the 2-hop neighborhood through HELLO messages, so explicitly conveying a Router ID is not necessary. The following steps describe a basic algorithm for conducting E-CDS relay selection for a router "n0":
NHDP公布的“邻居地址列表”必须用作路由器ID。NHDP通过HELLO消息提供整个2-hop邻居的所有接口地址，因此无需显式传递路由器ID。以下步骤描述了为路由器“n0”进行E-CDS中继选择的基本算法：
1. Initialize the set "N1" with tuples ("Router Priority", "Router ID", "Neighbor Address List") for each 1-hop neighbor of "n0".
1. 使用元组（“路由器优先级”、“路由器ID”、“邻居地址列表”）为“n0”的每个1跳邻居初始化集合“N1”。
2. If "N1" has less than 2 tuples, then "n0" does not elect itself as a relay, and no further steps are taken.
2. 如果“N1”的元组少于2个，则“n0”不会选择自己作为中继，并且不会采取进一步的步骤。
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.
3. 使用元组（“路由器优先级”、“路由器ID”、“2-hop地址”）为“n0”的每个“2-hop地址”初始化集合“N2”，其中“2-hop地址”在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.
4. 如果“RtrPri（n0）”大于“N1”和“N2”并集中所有元组的值，则“n0”选择自身作为中继，并且不采取进一步的步骤。
5. Initialize all tuples in the union of "N1" and "N2" as "unvisited".
5. 将“N1”和“N2”并集中的所有元组初始化为“未访问”。
6. Find the tuple "n1_Max" that has the largest "RtrPri()" of all tuples in "N1".
6. 查找“n1”中所有元组中具有最大“RtrPri（）”的元组“n1_Max”。
7. Initialize queue "Q" to contain "n1_Max", marking "n1_Max" as "visited".
7. 初始化队列“Q”以包含“n1_Max”，将“n1_Max”标记为“已访问”。
8. While router queue "Q" is not empty, remove router "x" from the head of "Q", and for each 1-hop neighbor "n" of router "x" (excluding "n0") that is not marked "visited".
8. 当路由器队列“Q”不为空时，将路由器“x”从“Q”的头部移除，并且对于未标记为“已访问”的路由器“x”（不包括“n0”）的每个1跳邻居“n”。
A. Mark router "n" as "visited".
A.将路由器“n”标记为“已访问”。
B. If "RtrPri(n)" is greater than "RtrPri(n0)", append "n" to "Q".
B.如果“RtrPri（n）”大于“RtrPri（n0）”，则在“Q”后面加上“n”。
9. If any tuple in "N1" remains "unvisited", then "n0" selects itself as a relay. Otherwise, "n0" does not act as a relay.
9. 如果“N1”中的任何元组保持“未访问”，则“n0”选择自身作为中继。否则，“n0”不起继电器的作用。
Note these steps are re-evaluated upon neighborhood status changes. Steps 5 through 8 of this procedure describe an approach to a path search. The purpose of this path search is to determine if paths exist from the 1-hop neighbor with maximum "RtrPri()" to all other 1-hop neighbors without traversing an intermediate router with a "RtrPri()" value less than "RtrPri(n0)". These steps comprise a breadth-first traversal that evaluates only paths that meet that
注：这些步骤将在邻居状态更改时重新评估。此过程的步骤5到8描述了路径搜索的方法。此路径搜索的目的是确定是否存在从最大“RtrPri（）”的1跳邻居到所有其他1跳邻居的路径，而无需遍历“RtrPri（）”值小于“RtrPri（n0）”的中间路由器。这些步骤包括一个广度优先遍历，该遍历只计算满足该条件的路径
criteria. If all 1-hop neighbors of "n0" are "visited" during this traversal, then the path search has succeeded, and router "n0" does not need to provide relay. It can be assumed that other routers will provide relay operation to ensure SMF connectivity.
标准如果在该遍历过程中“访问”了“n0”的所有1跳邻居，则路径搜索已成功，路由器“n0”不需要提供中继。可以假设其他路由器将提供中继操作以确保SMF连接。
It is possible to extend this algorithm to consider neighboring SMF routers that are known to be statically configured for CF (always relaying). The modification to the above algorithm is to process such routers as having a maximum possible Router Priority value. It is expected that routers configured for CF and participating in NHDP would indicate this with use of the SMF_TYPE:CF and SMF_NBR_TYPE:CF TLV types in their NHDP_HELLO message and address blocks, respectively.
可以扩展该算法来考虑已知为静态配置的CF（总是中继）的相邻SMF路由器。对上述算法的修改是将此类路由器处理为具有最大可能的路由器优先级值。预计为CF配置并参与NHDP的路由器将分别在其NHDP_HELLO消息和地址块中使用SMF_TYPE:CF和SMF_NBR_TYPE:CF TLV类型来表明这一点。
Appendix B. Source-Based Multipoint Relay (S-MPR) Algorithm
附录B.基于源的多点中继（S-MPR）算法
The source-based multipoint relay (S-MPR) set selection algorithm enables individual routers, using 2-hop topology information, to select relays from their set of neighboring routers. Relays are selected so that forwarding to the router's complete 2-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 routers must collect 2-hop neighborhood information from neighbors, determine an appropriate current relay set, and inform selected neighbors of their relay status. Note that since each router picks its neighboring relays independently, S-MPR forwarders depend upon previous hop information (e.g., source MAC address) to operate correctly. The Optimized Link State Routing (OLSR) protocol has used this algorithm and protocol for relay of link state updates and other control information [RFC3626], and it has been demonstrated operationally in dynamic network environments.
基于信源的多点中继（S-MPR）集合选择算法允许单个路由器使用2跳拓扑信息从其相邻路由器集合中选择中继。选择中继，以便覆盖转发到路由器的完整2跳邻居集。在[JLMV02]中，这种分布式中继集选择技术已被证明近似于最小连接支配集（MCDS）。单个路由器必须从邻居收集2跳邻居信息，确定适当的当前中继集，并将其中继状态通知选定的邻居。请注意，由于每个路由器独立选择其相邻的中继，因此S-MPR转发器依赖于先前的跃点信息（例如，源MAC地址）来正确操作。优化链路状态路由（OLSR）协议已将此算法和协议用于中继链路状态更新和其他控制信息[RFC3626]，并已在动态网络环境中进行了操作演示。
It is RECOMMENDED that the SMF_TYPE:S-MPR Message TLV be included in NHDP_HELLO messages that are generated by routers conducting S-MPR SMF operation. It is also RECOMMENDED that the SMF_NBR_TYPE:S-MPR Address Block TLV be used to specify which neighbor routers are conducting S-MPR SMF operation.
建议SMF_类型：S-MPR消息TLV包含在NHDP_HELLO消息中，该消息由执行S-MPR SMF操作的路由器生成。还建议使用SMF_NBR_TYPE:S-MPR地址块TLV指定哪些邻居路由器正在执行S-MPR SMF操作。
The S-MPR algorithm uses bi-directional 1-hop and 2-hop neighborhood information collected via NHDP to select, from a router's 1-hop neighbors, a set of relays that will cover the router's entire 2-hop neighbor set upon forwarding. The algorithm described uses a "greedy" heuristic of first picking the 1-hop neighbor who will cover the most 2-hop neighbors. Then, excluding those 2-hop neighbors that have been covered, additional relays from its 1-hop neighbor set are
S-MPR算法使用通过NHDP收集的双向1-hop和2-hop邻居信息，从路由器的1-hop邻居中选择一组中继，这些中继在转发时将覆盖路由器的整个2-hop邻居集。所描述的算法使用一种“贪婪”的启发式方法，首先选择覆盖最多2跳邻居的1跳邻居。然后，排除已覆盖的2跳邻居，从其1跳邻居集中添加额外的中继
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.
迭代选择，直到覆盖整个2跳邻居。请注意，也被标识为2-hop邻居的1-hop邻居仅被视为1-hop邻居。
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 that has a full type value of SMF_NBR_TYPE:S-MPR is defined in Table 17 such that signaling of MPR selections to 1-hop neighbors is possible. The value field of a message block TLV that has a full type value of SMF_TYPE:S-MPR is defined in Table 16 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 router MUST forward packets only for neighbors that have explicitly selected it as a multipoint 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.
支持S-MPR转发操作的NHDP HELLO消息应使用第8.1节中定义的TLV，使用S-MPR扩展类型。表17中定义了地址块TLV的值字段，该地址块TLV的完整类型值为SMF_NBR_type:S-MPR，因此可以向1跳邻居发送MPR选择信号。表16中定义了完整类型值为SMF_type:S-MPR的消息块TLV的值字段，以便可以向1跳邻居发送路由器优先级（在[RFC3626]中称为“意愿”）的信令。需要注意的是，S-MPR转发依赖于传入数据包的前一跳。S-MPR路由器必须仅为明确选择它作为多点中继的邻居转发数据包（即，它的“选择器”）。对于重复数据包检测也有一些额外的要求，以支持S-MPR SMF操作，如下所述。
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.
对于多接口操作，应根据每个接口进行MPR选择。然而，通过尽可能地选择公共MPR，可以节省多个接口之间的MPR选择。
An S-MPR SMF router MUST only forward packets for neighbors that have explicitly selected it as an MPR. The source-based forwarding technique also stipulates some additional duplicate packet detection operations. For multiple network interfaces, independent DPD state MUST be maintained for each separate interface. The following provides the procedure for S-MPR packet forwarding given the arrival of a packet on a given interface, denoted <srcIface>. There are three possible actions, depending upon the previous-hop transmitter:
S-MPR SMF路由器必须仅转发已明确选择它作为MPR的邻居的数据包。基于源的转发技术还规定了一些额外的重复数据包检测操作。对于多个网络接口，必须为每个单独的接口维护独立的DPD状态。以下提供了在给定接口（表示为<srcIface>）上的数据包到达时S-MPR数据包转发的过程。根据前一跳发射机的不同，有三种可能的操作：
1. If the previous-hop transmitter has selected the current router as an MPR,
1. 如果前一跳发射机已选择当前路由器作为MPR，
A. The packet identifier is checked against the DPD state for each possible outbound interface, including the <srcIface>.
A.针对每个可能的出站接口（包括<srcIface>）的DPD状态检查数据包标识符。
B. 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.
B.如果数据包不是出站接口的重复数据包，则数据包在该接口上转发，并为接口的给定数据包标识符创建DPD条目。
C. If the packet is a duplicate, no action is taken for that interface.
C.如果数据包是重复的，则不会对该接口采取任何操作。
2. Else, if the previous-hop transmitter is a 1-hop symmetric neighbor, a DPD entry is added for that packet for the <srcIface>, but the packet is not forwarded.
2. 否则，如果前一跳发射机是1跳对称邻居，则为<srcIface>的该分组添加DPD条目，但该分组不被转发。
3. Otherwise, no action is taken.
3. 否则，不采取任何行动。
Action number two in the list above is non-intuitive but important to ensure correctness of S-MPR SMF operation. The selection of source-based relays does not result in a common set among neighboring routers, so relays MUST mark, in their DPD state, packets received from non-selector, symmetric, 1-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.
上述列表中的第二项措施不直观，但对于确保S-MPR SMF操作的正确性非常重要。选择基于源的中继不会导致相邻路由器之间的公共集合，因此中继必须在其DPD状态下标记从非选择器、对称、1跳邻居（对于给定接口）接收的数据包，并且如果在该接口上接收到该数据包的后续副本，则不得转发该数据包。这里的偏差可能会导致不必要的、重复的数据包在整个网络中转发或不完全的泛洪。
Nodes not participating in neighborhood discovery and relay set selection will not be able to source multicast packets into the area and have SMF forward them, unlike E-CDS or MPR-CDS where forwarding may occur dependent on topology. Correct S-MPR relay behavior will occur with the introduction of repeaters (non-NHDP/SMF participants that relay multicast packets using duplicate detection and CF), but the repeaters will not efficiently contribute to S-MPR forwarding as these routers will not be identified as neighbors (symmetric or otherwise) in the S-MPR forwarding process. NHDP/SMF participants MUST NOT forward packets that are not selected by the algorithm, as this can disrupt network-wide S-MPR flooding, resulting in incomplete or inefficient flooding. The result is that non-S-MPR SMF routers will be unable to source multicast packets and have them forwarded by other S-MPR SMF routers.
不参与邻域发现和中继集选择的节点将无法将多播数据包发送到该区域并让SMF转发它们，这与E-CD或MPR-CD不同，E-CD或MPR-CD的转发可能根据拓扑发生。随着中继器（使用重复检测和CF中继多播数据包的非NHDP/SMF参与者）的引入，将出现正确的S-MPR中继行为，但中继器将不会有效地促进S-MPR转发，因为这些路由器在S-MPR转发过程中不会被识别为邻居（对称或其他）。NHDP/SMF参与者不得转发算法未选择的数据包，因为这可能会中断网络范围的S-MPR泛洪，导致不完整或低效的泛洪。其结果是，非S-MPR SMF路由器将无法源多播数据包，并由其他S-MPR SMF路由器转发这些数据包。
Nodes may optionally signal a Router Priority value to their 1-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:
节点可以通过使用SMF_TYPE:S-MPR消息块TLV值字段，选择性地向其1跳邻居发送路由器优先级值信号。如果省略值字段，则假定默认路由器优先级值为64。总结如下：
+---------------+---------+-----------------+
| Length(bytes) | Value | Router Priority |
+---------------+---------+-----------------+
| 0 | N/A | 64 |
| 1 | <value> | 0-127 |
+---------------+---------+-----------------+
+---------------+---------+-----------------+
| Length(bytes) | Value | Router Priority |
+---------------+---------+-----------------+
| 0 | N/A | 64 |
| 1 | <value> | 0-127 |
+---------------+---------+-----------------+
Table 16: S-MPR Message TLV Values
表16:S-MPR消息TLV值
Where <value> is a one-octet-long bit field defined as:
其中，<value>是一个八位字节长的位字段，定义为：
bit 0: the leftmost bit is reserved and SHOULD be set to 0.
位0：最左边的位是保留的，应设置为0。
bits 1-7: contain the Router Priority value, 0-127, which is associated with the "Neighbor Address List".
位1-7：包含路由器优先级值0-127，与“邻居地址列表”关联。
Router Priority values for S-MPR are interpreted in the same fashion as "WILLINGNESS" ([RFC3626]), with the value 0 indicating a router will NEVER forward and value 127 indicating a router will ALWAYS forward. Values 1-126 indicate how likely a S-MPR SMF router will be selected as an MPR by a neighboring SMF router, with higher values increasing the likelihood. Combinations of value field lengths and values other than those specified here are NOT permitted and SHOULD be ignored. Below is an example SMF_TYPE:S-MPR Message TLV.
S-MPR的路由器优先级值的解释方式与“意愿”（[RFC3626]）相同，值0表示路由器永远不会转发，值127表示路由器永远会转发。值1-126表示相邻SMF路由器选择S-MPR SMF路由器作为MPR的可能性，值越高，可能性越大。不允许组合值字段长度和此处指定以外的值，应忽略这些值。以下是SMF_类型示例：S-MPR消息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 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: S-MPR Message TLV Example
图9:S-MPR消息TLV示例
S-MPR election operation requires 2-hop neighbor knowledge as provided by NHDP [RFC6130] or from external sources. MPRs are dynamically selected by each router, and selections MUST be advertised and dynamically updated within NHDP or an equivalent protocol or mechanism. For NHDP use, the SMF_NBR_TYPE:S-MPR Address Block TLV value field is defined as such:
S-MPR选举操作需要NHDP[RFC6130]或外部来源提供的2跳邻居知识。MPR由每个路由器动态选择，选择必须在NHDP或等效协议或机制内公布和动态更新。对于NHDP使用，SMF_NBR_类型：S-MPR地址块TLV值字段定义如下：
+---------------+--------+----------+-------------------------------+
| Length(bytes) | # Addr | Value | Meaning |
+---------------+--------+----------+-------------------------------+
| 0 | Any | N/A | NOT MPRs |
| 1 | Any | <value> | <value> is for all addresses |
| N | N | <value>* | Each address gets its own |
| | | | <value> |
+---------------+--------+----------+-------------------------------+
+---------------+--------+----------+-------------------------------+
| Length(bytes) | # Addr | Value | Meaning |
+---------------+--------+----------+-------------------------------+
| 0 | Any | N/A | NOT MPRs |
| 1 | Any | <value> | <value> is for all addresses |
| N | N | <value>* | Each address gets its own |
| | | | <value> |
+---------------+--------+----------+-------------------------------+
Table 17: S-MPR Address Block TLV Values
表17:S-MPR地址块TLV值
Where <value>, if present, is a one-octet bit field defined as:
其中，<value>（如果存在）是一个八位字段，定义为：
bit 0: The leftmost bit is the M bit that, when set, indicates MPR selection of the relevant interface, represented by the associated address(es), by the originator router of the NHDP HELLO message. When unset, it indicates the originator router of the NHDP HELLO message has not selected the relevant interfaces, represented by the associated address(es), as its MPR.
位0：最左边的位是M位，当设置时，表示相关接口的MPR选择，由NHDP HELLO消息的发起者路由器的相关地址表示。未设置时，表示NHDP HELLO消息的发端路由器未选择相关接口（由关联地址表示）作为其MPR。
bits 1-7: These bits are reserved and SHOULD be set to 0.
位1-7：这些位是保留的，应设置为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。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: S-MPR Address Block TLV Example
图10:S-MPR地址块TLV示例
The single index TLV example, depicted in Figure 10, 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 8 for a similar example on how this may be done.
图10所示的单索引TLV示例表明，<start index>字段指定的地址正在使用S-MPR运行SMF，并且如果设置了M位，NHDP HELLO消息的发起者已选择该地址作为MPR转发器。多值TLV还可用于仅使用一个TLV指定多个地址的MPR选择状态。请参见图8，了解如何实现这一点的类似示例。
This section describes a basic algorithm for the S-MPR selection process. Note that the selection is with respect to a specific interface of the router performing selection, and other router interfaces referenced are reachable from this reference router interface. This is consistent with the S-MPR forwarding rules described above. When multiple interfaces per router are used, it is possible to enhance the overall selection process across multiple interfaces such that common routers are selected as MPRs for each interface to avoid unnecessary inefficiencies in flooding. The following steps describe a basic algorithm for conducting S-MPR selection for a router interface "n0":
本节介绍S-MPR选择过程的基本算法。注意，选择是关于执行选择的路由器的特定接口的，并且引用的其他路由器接口可以从该引用路由器接口访问。这与上述S-MPR转发规则一致。当每个路由器使用多个接口时，可以增强跨多个接口的总体选择过程，以便为每个接口选择公共路由器作为MPR，以避免泛洪中不必要的低效。以下步骤描述了为路由器接口“n0”进行S-MPR选择的基本算法：
1. Initialize the set "MPR" to empty.
1. 初始化设置“MPR”为空。
2. Initialize the set "N1" to include all 1-hop neighbors of "n0".
2. 初始化集合“N1”以包括“n0”的所有1跳邻居。
3. Initialize the set "N2" to include all 2-hop neighbors, excluding "n0" and any routers in "N1". Nodes that are only reachable via "N1" routers with router priority values of NEVER are also excluded.
3. 初始化集合“N2”以包括所有2跳邻居，不包括“n0”和“N1”中的任何路由器。仅可通过路由器优先级值为“从不”的“N1”路由器访问的节点也被排除在外。
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".
4. 对于“N1”中的每个接口“y”，初始化一组“N2（y）”，以包括“N2”中作为“y”的1跳邻居的任何接口。
5. For each interface "x" in "N1" with a router priority value of "ALWAYS" (or using the CF relay algorithm), select "x" as an MPR:
5. 对于路由器优先级值为“始终”（或使用CF中继算法）的“N1”中的每个接口“x”，选择“x”作为MPR：
A. Add "x" to the set "MPR" and remove "x" from "N1".
A.在集合“MPR”中添加“x”，并从“N1”中删除“x”。
B. For each interface "z" in "N2(x)", remove "z" from "N2".
B.对于“N2（x）”中的每个接口“z”，从“N2”中删除“z”。
C. For each interface "y" in "N1", remove any interfaces in "N2(x)" from "N2(y)".
C.对于“N1”中的每个接口“y”，从“N2（y）”中删除“N2（x）”中的任何接口。
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".
6. 对于“N2”中的每个接口“z”，初始化集合“N1（z）”以包括“N1”中作为“z”的1跳邻居的任何接口。
7. For each interface "x" in "N2" where "N1(x)" has only one member, select "x" as an MPR:
7. 对于“N2”中的每个接口“x”，其中“N1（x）”只有一个成员，选择“x”作为MPR：
A. Add "x" to the set "MPR" and remove "x" from "N1".
A.在集合“MPR”中添加“x”，并从“N1”中删除“x”。
B. For each interface "z" in "N2(x)", remove "z" from "N2" and delete "N1(z)".
B.对于“N2（x）”中的每个接口“z”，从“N2”中删除“z”，并删除“N1（z）”。
C. For each interface "y" in "N1", remove any interfaces in "N2(x)" from "N2(y)".
C.对于“N1”中的每个接口“y”，从“N2（y）”中删除“N2（x）”中的任何接口。
8. While "N2" is not empty, select the interface "x" in "N1" with the largest router priority that has the number of members in "N_2(x)" as an MPR:
8. 当“N2”不为空时，选择“N1”中具有最大路由器优先级且成员数在“N_2（x）”中的接口“x”作为MPR：
A. Add "x" to the set "MPR" and remove "x" from "N1".
A.在集合“MPR”中添加“x”，并从“N1”中删除“x”。
B. For each interface "z" in "N2(x)", remove "z" from "N2".
B.对于“N2（x）”中的每个接口“z”，从“N2”中删除“z”。
C. For each interface "y" in "N1", remove any interfaces in "N2(x)" from "N2(y)".
C.对于“N1”中的每个接口“y”，从“N2（y）”中删除“N2（x）”中的任何接口。
After the set of routers "MPR" is selected, router "n_0" must signal its selections to its neighbors. With NHDP, this is done by using the MPR Address Block TLV to mark selected neighbor addresses in NHDP_HELLO messages. Neighbors MUST record their MPR selection status and the previous hop address (e.g., link or MAC layer) of the selector. Note these steps are re-evaluated upon neighborhood status changes.
选择路由器集“MPR”后，路由器“n_0”必须向其邻居发送其选择的信号。对于NHDP，这是通过使用MPR地址块TLV在NHDP_HELLO消息中标记选定的邻居地址来完成的。邻居必须记录其MPR选择状态和选择器的上一跳地址（例如链路或MAC层）。注：这些步骤将在邻居状态更改时重新评估。
Appendix C. Multipoint Relay Connected Dominating Set (MPR-CDS) Algorithm
附录C.多点继电器连接支配集（MPR-CDS）算法
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].
MPR-CDS算法是基本S-MPR选举算法的扩展，该算法产生共享（非源特定）SMF CDS。因此，其转发规则不依赖于先前的跳信息，类似于E-cd。[MPR-CDS]中提供了MPR-CDS选择算法的概述。
It is RECOMMENDED that the SMF_TYPE Message TLV be included in NHDP_HELLO messages that are generated by routers conducting MPR-CDS SMF operation.
建议将SMF_类型的消息TLV包含在由执行MPR-CDS SMF操作的路由器生成的NHDP_HELLO消息中。
The MPR-CDS relay set selection process is based upon the MPR selection process of the S-MPR algorithm with the added refinement of a distributed technique for subsequently down-selecting to a common reduced, shared relay set. A router ordering (or "prioritization") metric is used as part of this down-selection process; like the E-CDS algorithm, this metric can be based upon router address(es) or some other unique router identifier (e.g., Router ID based on largest address contained within the "Neighbor Address List") as well as an additional Router Priority measure, if desired. The process for MPR-CDS relay selection is as follows:
MPR-CDS中继集选择过程以S-MPR算法的MPR选择过程为基础，并添加了分布式技术的改进，用于随后向下选择到一个通用的简化共享中继集。路由器排序（或“优先级排序”）指标用作向下选择过程的一部分；与E-CDS算法一样，该度量可以基于路由器地址或某些其他唯一路由器标识符（例如，基于“邻居地址列表”中包含的最大地址的路由器ID）以及额外的路由器优先级度量（如果需要）。MPR-CDS继电器选择过程如下：
1. First, MPR selection per the S-MPR algorithm is conducted, with selectors informing their MPRs (via NHDP) of their selection.
1. 首先，根据S-MPR算法进行MPR选择，选择器通知其MPR（通过NHDP）其选择。
2. Then, the following rules are used on a distributed basis by selected routers to possibly deselect themselves and thus jointly establish a common set of shared SMF relays:
2. 然后，所选路由器在分布式基础上使用以下规则，以可能取消选择自身，从而共同建立一组共享SMF中继：
A. If a selected router has a larger "RtrPri()" than all of its 1-hop symmetric neighbors, then it acts as a relay for all multicast traffic, regardless of the previous hop.
A.如果所选路由器的“RtrPri（）”大于其所有1跳对称邻居，则它将充当所有多播流量的中继，而不管前一跳是什么。
B. Else, if the 1-hop symmetric neighbor with the largest "RtrPri()" value has selected the router, then it also acts as a relay for all multicast traffic, regardless of the previous hop.
B.否则，如果具有最大“RtrPri（）”值的1跳对称邻居选择了路由器，那么它也将充当所有多播流量的中继，而不考虑前一跳。
C. Otherwise, it deselects itself as a relay and does not forward any traffic unless changes occur that require re-evaluation of the above steps.
C.否则，它会取消选择自身作为中继，并且不会转发任何流量，除非发生需要重新评估上述步骤的更改。
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 configured CF routers to be present, regardless of their participation in NHDP.
该技术与E-CDS技术在与不参与NHDP的多播源的兼容性以及静态配置的CF路由器存在的机会方面具有许多共同的期望特性，而不管它们是否参与NHDP。
The forwarding rules for MPR-CDS are similar to those for E-CDS. Any SMF router that has selected itself as a relay performs DPD and forwards all non-duplicative multicast traffic allowed by the present forwarding policy. Packet previous hop knowledge is not needed for forwarding decisions when using MPR-CDS.
MPR-CD的转发规则与E-CD的转发规则类似。选择自身作为中继的任何SMF路由器执行DPD并转发当前转发策略允许的所有非重复多播流量。使用MPR-CDS时，转发决策不需要数据包前一跳的知识。
1. Upon packet reception, DPD is performed. Note that MPR-CDS requires one duplicate table for the set of interfaces associated with the relay set selection.
1. 在分组接收时，执行DPD。注意，MPR-CDS需要一个与继电器组选择相关联的接口组的重复表。
2. If the packet is a duplicate, no further action is taken.
2. 如果数据包是重复的，则不采取进一步的操作。
3. If the packet is non-duplicative:
3. 如果数据包是非重复的：
A. A DPD entry is added for the packet identifier
A.为数据包标识符添加DPD条目
B. The packet is forwarded out to all interfaces associated with the relay set selection.
B.数据包被转发到与中继集选择相关的所有接口。
As previously mentioned, even packets sourced (or relayed) by routers not participating in NHDP and/or the MPR-CDS relay set selection may be forwarded by MPR-CDS forwarders without problem. A particular deployment MAY choose to not forward packets from sources or relays that have been explicitly identified via NHDP or other means as operating as part of a different relay set algorithm (e.g., S-MPR) to allow coexistent deployments to operate correctly.
如前所述，即使由不参与NHDP和/或MPR-CDS中继集选择的路由器来源（或中继）的分组也可以由MPR-CDS转发器毫无问题地转发。特定部署可以选择不转发来自已通过NHDP或其他方式明确标识为作为不同中继集算法（例如，S-MPR）的一部分运行的源或中继的数据包，以允许共存部署正确运行。
The neighborhood discovery requirements for MPR-CDS have commonality with both the S-MPR and E-CDS algorithms. MPR-CDS selection operation requires 2-hop neighbor knowledge as provided by NHDP
MPR-CDS的邻域发现要求与S-MPR和E-CDS算法具有共性。MPR-CDS选择操作需要NHDP提供的2跳邻居知识
[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.
[RFC6130]或来自外部来源。与S-MPR操作不同，不需要将链路层地址信息与1跳邻居关联，因为MPR-CDS转发独立于前一跳，类似于E-CDS转发。
To advertise an optional Router Priority value or "WILLINGNESS", an originating router may use the Message TLV of type SMF_TYPE:MPR-CDS, which shares a common <value> format with both SMF_TYPE:E-CDS (Table 14) and SMF_TYPE:S-MPR (Table 16).
为了公布可选的路由器优先级值或“意愿”，发起路由器可以使用SMF_类型：MPR-CDS的消息TLV，该消息TLV与SMF_类型：E-CDS（表14）和SMF_类型：S-MPR（表16）共享一种通用的<value>格式。
MPR-CDS only requires 1-hop knowledge of Router Priority for correct operation. In the S-MPR phase of MPR-CDS selection, MPRs are dynamically determined by each router, and selections MUST be advertised and dynamically updated using NHDP or an equivalent protocol or mechanism. The <value> field of the SMF_NBR_TYPE:MPR-CDS type TLV shares a common format with SMF_NBR_TYPE:S-MPR (Table 17) to convey MPR selection.
MPR-CDS只需要路由器优先级的1跳知识即可正确操作。在MPR-CDS选择的S-MPR阶段，MPR由每个路由器动态确定，必须使用NHDP或等效协议或机制公布和动态更新选择。SMF_NBR_类型：MPR-CDS类型TLV的<value>字段与SMF_NBR_类型：S-MPR（表17）共享一种通用格式，以传达MPR选择。
This section describes an algorithm for the MPR-CDS selection process. Note that the selection described is with respect to a specific interface of the router performing selection, and other router interfaces referenced are reachable from this reference router interface. An ordered tuple of Router Priority and Router ID is used in MPR-CDS relay set selection. The Router ID value should be set to the largest advertised address of a given router; this information is provided to one-hop neighbors via NHDP by default. Precedence is given to the Router Priority portion, and the Router ID value is used as a tiebreaker. The evaluation of this tuple is referred to as "RtrPri(n)" in the description below where "n" references a specific router. Note that it is possible that the Router Priority portion may be optional and the evaluation of "RtrPri()" be solely based upon the unique Router ID. Since there MUST NOT be any duplicate address values among SMF routers, a comparison of "RtrPri(n)" between any two routers will always be an inequality. The following steps, repeated upon any changes detected within the 1-hop and 2-hop neighborhood, describe a basic algorithm for conducting MPR-CDS selection for a router interface "n0":
本节介绍MPR-CDS选择过程的算法。注意，所描述的选择是关于执行选择的路由器的特定接口的，并且可以从该参考路由器接口访问所引用的其他路由器接口。MPR-CDS中继集选择使用路由器优先级和路由器ID的有序元组。路由器ID值应设置为给定路由器的最大播发地址；默认情况下，该信息通过NHDP提供给单跳邻居。优先权被赋予路由器优先级部分，并且路由器ID值被用作分接器。在下面的描述中，该元组的计算被称为“RtrPri（n）”，其中“n”引用特定路由器。请注意，路由器优先级部分可能是可选的，并且“RtrPri（）”的计算仅基于唯一的路由器ID。由于SMF路由器之间不得存在任何重复的地址值，因此任何两个路由器之间的“RtrPri（n）”比较将始终是一个不等式。在1-hop和2-hop邻域内检测到任何变化时，重复以下步骤，描述了为路由器接口“n0”进行MPR-CDS选择的基本算法：
1. Perform steps 1-8 of Appendix B.4 to select MPRs from the set of 1-hop neighbors of "n0" and notify/update neighbors of selections.
1. 执行附录B.4中的步骤1-8，从“n0”的一跳邻居集中选择MPR，并通知/更新选择的邻居。
2. Upon being selected as an MPR (or any change in the set of routers selecting "n0" as an MPR):
2. 被选为MPR后（或选择“n0”作为MPR的路由器组中的任何更改）：
A. 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.
A.如果没有邻居选择“n0”作为MPR，“n0”不作为中继，并且在邻居拓扑或选择状态发生变化之前，不会采取进一步的步骤。
B. Determine the router "n1_max" that has the maximum "RtrPri()" of all 1-hop neighbors.
B.确定在所有1跳邻居中具有最大“RtrPri（）”的路由器“n1_max”。
C. If "RtrPri(n0)" is greater than "RtrPri(n1_max)", then "n0" selects itself as a relay for all multicast packets.
C.如果“RtrPri（n0）”大于“RtrPri（n1_max）”，则“n0”选择自身作为所有多播数据包的中继。
D. Else, if "n1_max" has selected "n0" as an MPR, then "0" selects itself as a relay for all multicast packets.
D.否则，如果“n1_max”选择“n0”作为MPR，则“0”选择自身作为所有多播数据包的中继。
E. Otherwise, "n0" does not act as a relay.
E.否则，“n0”不作为继电器。
It is possible to extend this algorithm to consider neighboring SMF routers that are known to be statically configured for CF (always relaying). The modification to the above algorithm is to process such routers as having a maximum possible Router Priority value. This is the same as the case for participating routers that have been configured with a S-MPR "WILLINGNESS" value of "WILL_ALWAYS". It is expected that routers configured for CF and participating in NHDP would indicate their status with use of the SMF_TYPE TLV type in their NHDP_HELLO message TLV block. It is important to note, however, that CF routers will not select MPR routers and therefore cannot guarantee connectedness.
可以扩展该算法来考虑已知为静态配置的CF（总是中继）的相邻SMF路由器。对上述算法的修改是将此类路由器处理为具有最大可能的路由器优先级值。这与配置了S-MPR“意愿”值“WILL_ALWAYS”的参与路由器的情况相同。预计为CF配置并参与NHDP的路由器将在其NHDP_HELLO消息TLV块中使用SMF_类型TLV类型指示其状态。但需要注意的是，CF路由器不会选择MPR路由器，因此无法保证连接性。
Author's Address
作者地址
Joseph Macker (editor) NRL Washington, DC 20375 USA
Joseph Macker（编辑）美国华盛顿特区NRL 20375
EMail: macker@itd.nrl.navy.mil
EMail: macker@itd.nrl.navy.mil