Internet Engineering Task Force (IETF) IJ. Wijnands
Request for Comments: 8364 S. Venaas
Category: Experimental Cisco Systems, Inc.
ISSN: 2070-1721 M. Brig
Aegis BMD Program Office
A. Jonasson
FMV
March 2018
Internet Engineering Task Force (IETF) IJ. Wijnands
Request for Comments: 8364 S. Venaas
Category: Experimental Cisco Systems, Inc.
ISSN: 2070-1721 M. Brig
Aegis BMD Program Office
A. Jonasson
FMV
March 2018
PIM Flooding Mechanism (PFM) and Source Discovery (SD)
PIM泛洪机制（PFM）和震源发现（SD）
Abstract
摘要
Protocol Independent Multicast - Sparse Mode (PIM-SM) uses a Rendezvous Point (RP) and shared trees to forward multicast packets from new sources. Once Last-Hop Routers (LHRs) receive packets from a new source, they may join the Shortest Path Tree (SPT) for the source for optimal forwarding. This document defines a new mechanism that provides a way to support PIM-SM without the need for PIM registers, RPs, or shared trees. Multicast source information is flooded throughout the multicast domain using a new generic PIM Flooding Mechanism (PFM). This allows LHRs to learn about new sources without receiving initial data packets.
协议独立多播稀疏模式（PIM-SM）使用集合点（RP）和共享树转发来自新源的多播数据包。一旦最后一跳路由器（LHR）接收到来自新源的数据包，它们就可以加入源的最短路径树（SPT）以实现最佳转发。本文档定义了一种新机制，它提供了一种支持PIM-SM的方法，而不需要PIM寄存器、RPs或共享树。多播源信息使用一种新的通用PIM泛洪机制（PFM）在整个多播域中泛洪。这允许LHR在不接收初始数据包的情况下了解新的源。
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 candidates for any level of Internet Standard; see Section 2 of RFC 7841.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8364.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8364.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Testing and Deployment Experiences . . . . . . . . . . . . . 5
3. A Generic PIM Flooding Mechanism . . . . . . . . . . . . . . 5
3.1. PFM Message Format . . . . . . . . . . . . . . . . . . . 6
3.2. Administrative Boundaries . . . . . . . . . . . . . . . . 7
3.3. Originating PFM Messages . . . . . . . . . . . . . . . . 7
3.4. Processing PFM Messages . . . . . . . . . . . . . . . . . 9
3.4.1. Initial Checks . . . . . . . . . . . . . . . . . . . 9
3.4.2. Processing and Forwarding of PFM Messages . . . . . . 10
4. Distributing SG Mappings . . . . . . . . . . . . . . . . . . 11
4.1. Group Source Holdtime TLV . . . . . . . . . . . . . . . . 11
4.2. Originating Group Source Holdtime TLVs . . . . . . . . . 12
4.3. Processing GSH TLVs . . . . . . . . . . . . . . . . . . . 13
4.4. The First Packets and Bursty Sources . . . . . . . . . . 13
4.5. Resiliency to Network Partitioning . . . . . . . . . . . 14
5. Configurable Parameters . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Testing and Deployment Experiences . . . . . . . . . . . . . 5
3. A Generic PIM Flooding Mechanism . . . . . . . . . . . . . . 5
3.1. PFM Message Format . . . . . . . . . . . . . . . . . . . 6
3.2. Administrative Boundaries . . . . . . . . . . . . . . . . 7
3.3. Originating PFM Messages . . . . . . . . . . . . . . . . 7
3.4. Processing PFM Messages . . . . . . . . . . . . . . . . . 9
3.4.1. Initial Checks . . . . . . . . . . . . . . . . . . . 9
3.4.2. Processing and Forwarding of PFM Messages . . . . . . 10
4. Distributing SG Mappings . . . . . . . . . . . . . . . . . . 11
4.1. Group Source Holdtime TLV . . . . . . . . . . . . . . . . 11
4.2. Originating Group Source Holdtime TLVs . . . . . . . . . 12
4.3. Processing GSH TLVs . . . . . . . . . . . . . . . . . . . 13
4.4. The First Packets and Bursty Sources . . . . . . . . . . 13
4.5. Resiliency to Network Partitioning . . . . . . . . . . . 14
5. Configurable Parameters . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
Protocol Independent Multicast - Sparse Mode (PIM-SM) [RFC7761] uses a Rendezvous Point (RP) and shared trees to forward multicast packets to Last-Hop Routers (LHRs). After the first packet is received by an LHR, the source of the multicast stream is learned and the Shortest Path Tree (SPT) can be joined. This document defines a new mechanism that provides a way to support PIM-SM without the need for PIM registers, RPs, or shared trees. Multicast source information is flooded throughout the multicast domain using a new generic PIM flooding mechanism. By removing the need for RPs and shared trees, the PIM-SM procedures are simplified, thus improving router operations and management, and making the protocol more robust. Also, the data packets are only sent on the SPTs, providing optimal forwarding.
协议独立多播-稀疏模式（PIM-SM）[RFC7761]使用集合点（RP）和共享树将多播数据包转发给最后一跳路由器（LHR）。在LHR接收到第一个分组之后，多播流的源被学习，并且可以加入最短路径树（SPT）。本文档定义了一种新机制，它提供了一种支持PIM-SM的方法，而不需要PIM寄存器、RPs或共享树。使用一种新的通用PIM泛洪机制，在整个多播域中泛洪多播源信息。通过消除对RPs和共享树的需求，PIM-SM过程得到简化，从而改进路由器操作和管理，并使协议更加健壮。此外，数据包仅在SPT上发送，从而提供最佳转发。
This mechanism has some similarities to Protocol Independent Multicast - Dense Mode (PIM-DM) with its State-Refresh signaling [RFC3973], except that there is no initial flooding of data packets for new sources. It provides the traffic efficiency of PIM-SM, while being as easy to deploy as PIM-DM. The downside is that it cannot provide forwarding of initial packets from a new source, see Section 4.4. PIM-DM is very different from PIM-SM; it's not as mature, it is categorized as Experimental not an Internet Standard, and there are only a few implementations of it. The solution in this document consists of a lightweight source discovery mechanism on top of the Source-Specific Multicast (SSM) [RFC4607] parts of PIM-SM. It is feasible to implement only a subset of PIM-SM to provide SSM support and, in addition, implement the mechanism in this document to offer a source discovery mechanism for applications that do not provide their own source discovery.
该机制与具有状态刷新信令[RFC3973]的独立于协议的多播密集模式（PIM-DM）有一些相似之处，只是没有针对新源的初始数据包泛洪。它提供了PIM-SM的流量效率，同时与PIM-DM一样易于部署。缺点是它不能提供从新源转发初始数据包，请参见第4.4节。PIM-DM与PIM-SM非常不同；它还不成熟，它被归类为实验性的，而不是互联网标准，并且只有少数几个实现。本文中的解决方案包括PIM-SM中源特定多播（SSM）[RFC4607]部分之上的轻量级源发现机制。仅实现PIM-SM的一个子集以提供SSM支持是可行的，此外，还可以实现本文档中的机制，为不提供自己的源发现的应用程序提供源发现机制。
This document defines a generic flooding mechanism for distributing information throughout a PIM domain. While the forwarding rules are largely similar to the Bootstrap Router (BSR) mechanism [RFC5059], any router can originate information; this allows for flooding of any kind of information. Each message contains one or more pieces of information encoded as TLVs. This document defines one TLV used for distributing information about active multicast sources. Other documents may define additional TLVs.
本文档定义了一种通用的泛洪机制，用于在整个PIM域中分发信息。虽然转发规则在很大程度上类似于引导路由器（BSR）机制[RFC5059]，但任何路由器都可以发起信息；这允许任何类型的信息泛滥。每条消息包含一条或多条编码为TLV的信息。本文档定义了一个TLV，用于分发有关活动多播源的信息。其他文件可能会定义其他TLV。
Note that this document is an Experimental RFC. While the flooding mechanism is largely similar to BSR, there are some concerns about scale as there can be multiple routers distributing information, and potentially a larger amount of data that needs to be processed and stored. Distributing knowledge of active sources in this way is new; there are some concerns, mainly regarding potentially large amounts of source states that need to be distributed. While there has been
请注意，本文档是一个实验性RFC。虽然泛洪机制在很大程度上类似于BSR，但也存在一些规模问题，因为可能有多个路由器分发信息，并且可能需要处理和存储更多的数据。以这种方式分发活动资源的知识是新的；有一些担忧，主要是关于需要分发的潜在大量源状态。虽然有
some testing in the field, we need to learn more about the forwarding efficiency, both the amount of processing per router, propagation delay, and the amount of state that can be distributed. In particular, how many active sources one can support without consuming too many resources. There are also parameters, see Section 5, that can be tuned regarding how frequently information is distributed. It is not clear what parameters are useful for different types of networks.
在一些现场测试中，我们需要了解更多关于转发效率的信息，包括每个路由器的处理量、传播延迟以及可以分布的状态量。特别是，在不消耗太多资源的情况下，可以支持多少活动源。还有一些参数（见第5节）可以根据信息的分发频率进行调整。目前尚不清楚哪些参数对不同类型的网络有用。
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
RP: Rendezvous Point
交会点
BSR: Bootstrap Router
引导路由器
RPF: Reverse Path Forwarding
反向路径转发
SPT: Shortest Path Tree
最短路径树
FHR: First-Hop Router, directly connected to the source
FHR：第一跳路由器，直接连接到源
LHR: Last-Hop Router, directly connected to the receiver
LHR：最后一跳路由器，直接连接到接收器
PFM: PIM Flooding Mechanism
PFM:PIM泛洪机理
PFM-SD: PFM Source Discovery
PFM-SD:PFM源发现
SG Mapping: Multicast source group (SG) mapping
SG映射：多播源组（SG）映射
A prototype of this specification has been implemented, and there has been some limited testing in the field. The prototype was tested in a network with low-bandwidth radio links. The network has frequent topology changes, including frequent link or router failures. Previously existing mechanisms were tested (for example, PIM-SM and PIM-DM).
该规范的原型已经实现，并且在现场进行了一些有限的测试。原型在具有低带宽无线电链路的网络中进行了测试。网络具有频繁的拓扑变化，包括频繁的链路或路由器故障。对以前存在的机制进行了测试（例如，PIM-SM和PIM-DM）。
With PIM-SM, the existing RP election mechanisms were found to be too slow. With PIM-DM, issues were observed with new multicast sources starving low-bandwidth links even when there were no receivers; in some cases, so much so that there was no bandwidth left for prune messages.
对于PIM-SM，发现现有RP选举机制过于缓慢。在PIM-DM中，观察到新的多播源即使在没有接收器的情况下也缺乏低带宽链路的问题；在某些情况下，这会导致没有足够的带宽用于删除消息。
For the PFM-SD prototype tests, all routers were configured to send PFM-SD for the directly connected source and to cache received announcements. Applications such as SIP with multicast subscriber discovery, multicast voice conferencing, position tracking, and NTP were successfully tested. The tests went quite well. Packets were rerouted as needed; there was no unnecessary forwarding of packets. Ease of configuration was seen as a plus.
对于PFM-SD原型测试，所有路由器都配置为向直接连接的源发送PFM-SD，并缓存收到的通知。成功测试了具有多播订户发现的SIP、多播语音会议、位置跟踪和NTP等应用程序。测试进行得相当顺利。根据需要重新路由数据包；没有不必要的数据包转发。易于配置被视为一个优势。
The Bootstrap Router (BSR) mechanism [RFC5059] is a commonly used mechanism for distributing dynamic Group-to-RP mappings in PIM. It is responsible for flooding information about such mappings throughout a PIM domain so that all routers in the domain can have the same information. BSR, as defined, is only able to distribute Group-to-RP mappings. This document defines a more generic mechanism that can flood any kind of information. Administrative boundaries, see Section 3.2, may be configured to limit to which parts of a network the information is flooded.
引导路由器（BSR）机制[RFC5059]是PIM中分发动态组到RP映射的常用机制。它负责在整个PIM域中传播有关此类映射的信息，以便域中的所有路由器都可以拥有相同的信息。根据定义，BSR只能分发组到RP的映射。本文档定义了一种更通用的机制，它可以淹没任何类型的信息。管理边界（见第3.2节）可配置为限制信息被淹没到网络的哪个部分。
The forwarding rules are identical to BSR, except that one can control whether routers should forward unsupported data types. For some types of information, it is quite useful that it can be distributed without all routers having to support the particular type, while there may also be types where it is necessary for every single router to support it. The mechanism includes an originator address that is used for RPF checking to restrict the flooding and prevent loops, just like BSR. Like BSR, messages are forwarded hop-by-hop; the messages are link-local, and each router will process and resend the messages. Note that there is no equivalent to the BSR election mechanism; there can be multiple originators. This mechanism is named the PIM Flooding Mechanism (PFM).
转发规则与BSR相同，只是可以控制路由器是否转发不支持的数据类型。对于某些类型的信息，它可以在不需要所有路由器都支持特定类型的情况下分发，这是非常有用的，同时也可能存在需要每个路由器都支持的类型。该机制包括一个用于RPF检查的发起者地址，以限制泛洪并防止循环，就像BSR一样。与BSR一样，消息逐跳转发；消息是本地链路，每个路由器将处理并重新发送消息。请注意，没有与BSR选举机制等效的机制；可以有多个发起人。这种机制被称为PIM泛洪机制（PFM）。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type |N| Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| Type 1 | Length 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value 1 |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
|T| Type n | Length n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value n |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type |N| Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| Type 1 | Length 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value 1 |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
|T| Type n | Length n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value n |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Reserved, and Checksum: As specified in [RFC7761].
PIM版本、保留和校验和：如[RFC7761]所述。
Type: PIM Message Type. Value 12 for a PFM message.
类型：PIM消息类型。PFM消息的值为12。
[N]o-Forward bit: When set, this bit means that the PFM message is not to be forwarded. This bit is defined to prevent Bootstrap message forwarding in [RFC5059].
[N] o-转发位：设置时，该位表示不转发PFM消息。此位定义用于防止[RFC5059]中的引导消息转发。
Originator Address: The address of the router that originated the message. This can be any address assigned to the originating router, but it MUST be routable in the domain to allow successful forwarding. The format for this address is given in the Encoded-Unicast address in [RFC7761].
发起人地址：发起消息的路由器的地址。这可以是分配给发起路由器的任何地址，但它必须在域中可路由，以允许成功转发。[RFC7761]中的编码单播地址给出了该地址的格式。
[T]ransitive bit: Each TLV in the message includes a bit called the "Transitive" bit that controls whether the TLV is forwarded by routers that do not support the given type. See Section 3.4.2.
[T] Transitive位：消息中的每个TLV都包含一个称为“Transitive”位的位，该位控制TLV是否由不支持给定类型的路由器转发。见第3.4.2节。
Type 1..n: A message contains one or more TLVs, in this case n TLVs. The Type specifies what kind of information is in the Value. The Type range is from 0 to 32767 (15 bits).
类型1..n：消息包含一个或多个TLV，在本例中为n个TLV。类型指定值中的信息类型。类型范围从0到32767（15位）。
Length 1..n: The length of the Value field in octets.
长度1..n：值字段的长度（以八位字节为单位）。
Value 1..n: The value associated with the type and of the specified length.
值1..n：与指定长度的类型关联的值。
PFM messages are generally forwarded hop-by-hop to all PIM routers. However, similar to BSR, one may configure administrative boundaries to limit the information to certain domains or parts of the network. Implementations MUST have a way of defining a set of interfaces on a router as administrative boundaries for all PFM messages or, optionally, for certain TLVs, allowing for different boundaries for different TLVs. Usually, one wants boundaries to be bidirectional, but an implementation MAY also provide unidirectional boundaries. When forwarding a message, a router MUST NOT send it out on an interface that is an outgoing boundary, including a bidirectional boundary, for all PFM messages. If an interface is an outgoing boundary for certain TLVs, the message MUST NOT be sent out on the interface if it is a boundary for all the TLVs in the message. Otherwise, the router MUST remove all the boundary TLVs from the message and send the message with the remaining TLVs. Also, when receiving a PFM message on an interface, the message MUST be discarded if the interface is an incoming boundary, including a bidirectional boundary, for all PFM messages. If the interface is an incoming boundary for certain TLVs, the router MUST ignore all boundary TLVs. If all the TLVs in the message are boundary TLVs, then the message is effectively ignored. Note that when forwarding an incoming message, the boundary is applied before forwarding. If the message was discarded or all the TLVs were ignored, then no message is forwarded. When a message is forwarded, it MUST NOT contain any TLVs for which the incoming interface is an incoming or bidirectional boundary.
PFM消息通常逐跳转发到所有PIM路由器。然而，与BSR类似，可以配置管理边界以将信息限制到网络的某些域或部分。实现必须有一种方法，将路由器上的一组接口定义为所有PFM消息的管理边界，或者（可选）对于某些TLV，允许不同TLV的不同边界。通常，人们希望边界是双向的，但实现也可以提供单向边界。转发消息时，路由器不得在作为所有PFM消息的传出边界（包括双向边界）的接口上发送消息。如果某个接口是某些TLV的传出边界，则如果该接口是消息中所有TLV的边界，则不得在该接口上发送消息。否则，路由器必须从消息中删除所有边界TLV，并与其余TLV一起发送消息。此外，在接口上接收PFM消息时，如果接口是所有PFM消息的传入边界（包括双向边界），则必须丢弃该消息。如果接口是某些TLV的传入边界，则路由器必须忽略所有边界TLV。如果消息中的所有TLV都是边界TLV，则消息将被有效忽略。请注意，转发传入消息时，在转发之前应用边界。如果消息被丢弃或所有TLV被忽略，则不会转发任何消息。转发消息时，不得包含传入接口为传入或双向边界的任何TLV。
A router originates a PFM message when it needs to distribute information using a PFM message to other routers in the network. When a message is originated depends on what information is distributed. For instance, this document defines a TLV to distribute information about active sources. When a router has a new active source, a PFM message should be sent as soon as possible. Hence, a PFM message should be sent every time there is a new active source. However, the TLV also contains a holdtime and PFM messages need to be sent periodically. Generally speaking, a PFM message would typically be sent when there is a local state change, causing information to be distributed with the PFM to change. Also, some information may need to be sent periodically. These messages are called "triggered" and
当路由器需要使用PFM消息将信息分发给网络中的其他路由器时，它会发出PFM消息。消息何时发出取决于分发的信息。例如，本文档定义了一个TLV来分发有关活动源的信息。当路由器有新的活动源时，应尽快发送PFM消息。因此，每次有新的活动源时都应发送PFM消息。但是，TLV还包含保持时间，需要定期发送PFM消息。一般来说，当本地状态发生变化时，通常会发送PFM消息，从而导致随PFM一起分发的信息发生变化。此外，可能需要定期发送一些信息。这些消息称为“已触发”和
"periodic" messages, respectively. Each TLV definition will need to define when a triggered PFM message needs to be originated, whether or not to send periodic messages, and how frequently to send them.
分别为“定期”消息。每个TLV定义都需要定义触发的PFM消息何时需要发起、是否发送定期消息以及发送频率。
A router MUST NOT originate more than Max_PFM_Message_Rate messages per minute. This document does not mandate how this should be implemented; some possible ways could be having a minimal time between each message, counting the number of messages originated and resetting the count every minute, or using a leaky bucket algorithm. One benefit of using a leaky bucket algorithm is that it can handle bursts better. The default value of Max_PFM_Message_Rate is 6. The value MUST be configurable. Depending on the network, one may want to use a larger value of Max_PFM_Message_Rate to favor propagation of new information, but with a large number of routers and many updates, the total number of messages might become too large and require too much processing.
路由器每分钟发送的消息速率不得超过最大值。本文件并未规定应如何实施；一些可能的方法可以是在每条消息之间留出最短的时间，计算产生的消息数并每分钟重置一次计数，或者使用漏桶算法。使用漏桶算法的一个好处是它可以更好地处理突发事件。Max_PFM_Message_Rate的默认值为6。该值必须是可配置的。根据网络的不同，可能希望使用更大的Max_PFM_Message_Rate值来支持新信息的传播，但随着路由器数量和更新次数的增加，消息总数可能会变得太大，需要太多的处理。
There MUST be a minimum of Min_PFM_Message_Gap milliseconds between each originated message. The default value of Min_PFM_Message_Gap is 1000 (1 second). The value MUST be configurable.
每个原始消息之间必须至少有Min_PFM_Message_间隔毫秒。最小PFM消息间隔的默认值为1000（1秒）。该值必须是可配置的。
Unless otherwise specified by the TLV definitions, there is no relationship between different TLVs, and an implementation can choose whether to combine TLVs in one message or across separate messages. It is RECOMMENDED to combine multiple TLVs in one message to reduce the number of messages, but it is also RECOMMENDED that the message be small enough to avoid fragmentation at the IP layer. When a triggered PFM message needs to be sent due to a state change, a router MAY send a message containing only the information that changed. If there are many changes occurring at about the same time, it might be possible to combine multiple changes in one message. In the case where periodic messages are also needed, an implementation MAY include periodic PFM information in a triggered PFM. For example, if some information needs to be sent every 60 seconds and a triggered PFM message is about to be sent 20 seconds before the next periodic PFM message was scheduled, the triggered PFM message might include the periodic information and the next periodic PFM message can then be scheduled 60 seconds after that rather than 20 seconds later.
除非TLV定义另有规定，否则不同的TLV之间没有关系，实现可以选择是在一条消息中组合TLV，还是跨单独的消息组合TLV。建议在一条消息中组合多个TLV以减少消息数量，但也建议消息足够小，以避免在IP层出现碎片。当由于状态变化而需要发送触发的PFM消息时，路由器可以发送仅包含已更改信息的消息。如果在同一时间发生许多更改，则可以将多个更改合并到一条消息中。在还需要周期性消息的情况下，实现可以在触发的PFM中包括周期性PFM信息。例如，如果某些信息需要每60秒发送一次，并且触发的PFM消息将在计划下一个定期PFM消息之前20秒发送，触发的PFM消息可能包括周期性信息，然后可以在60秒之后而不是20秒之后调度下一个周期性PFM消息。
When a router originates a PFM message, it puts one of its own addresses in the originator field. An implementation MUST allow an administrator to configure which address is used. For a message to be received by all routers in a domain, all the routers need to have a route for this address due to the RPF-based forwarding. Hence, an administrator needs to be careful about which address to choose. When this is not configured, an implementation MUST NOT use a link-
当路由器发起PFM消息时，它会将自己的一个地址放在发起人字段中。实现必须允许管理员配置使用的地址。为了让域中的所有路由器都能接收到消息，由于基于RPF的转发，所有路由器都需要有一个该地址的路由。因此，管理员需要小心选择哪个地址。未配置时，实现不得使用链接-
local address. It is RECOMMENDED to use an address of a virtual interface such that the originator can remain unchanged and routable independent of which physical interfaces or links may go down.
本地地址。建议使用虚拟接口的地址，以便发起者可以保持不变并可路由，而不受物理接口或链路可能中断的影响。
The No-Forward bit MUST NOT be set, except for the case when a router receives a PIM Hello from a new neighbor or a PIM Hello with a new Generation Identifier (GenID), defined in [RFC7761], is received from an existing neighbor. In that case, an implementation MAY send PFM messages containing relevant information so that the neighbor can quickly get the correct state. The definition of the different PFM message TLVs needs to specify what, if anything, needs to be sent in this case. If such a PFM message is sent, the No-Forward bit MUST be set, and the message must be sent within 60 seconds after the neighbor state change. The processing rules for PFM messages will ensure that any other neighbors on the same link ignore the message. This behavior (and the choice of 60 seconds) is similar to what is defined for the No-Forward bit in [RFC5059].
不得设置无转发位，除非路由器从新邻居接收到PIM Hello，或从现有邻居接收到具有[RFC7761]中定义的新一代标识符（GenID）的PIM Hello。在这种情况下，实现可以发送包含相关信息的PFM消息，以便邻居可以快速获得正确的状态。不同PFM消息TLV的定义需要指定在这种情况下需要发送的内容（如果有）。如果发送这样的PFM消息，则必须设置No Forward（无转发）位，并且消息必须在邻居状态更改后60秒内发送。PFM消息的处理规则将确保同一链路上的任何其他邻居忽略该消息。此行为（以及60秒的选择）类似于[RFC5059]中为无前向位定义的行为。
A router that receives a PFM message MUST perform the initial checks specified here. If the checks fail, the message MUST be dropped. An error MAY be logged; otherwise, the message MUST be dropped silently. If the checks pass, the contents are processed according to the processing rules of the included TLVs.
接收PFM消息的路由器必须执行此处指定的初始检查。如果检查失败，则必须删除该消息。可能会记录错误；否则，必须以静默方式删除消息。如果检查通过，则根据包含的TLV的处理规则处理内容。
In order to do further processing, a message MUST meet the following requirements. The message MUST be from a directly connected PIM neighbor and the destination address MUST be ALL-PIM-ROUTERS. Also, the interface MUST NOT be an incoming, nor a bidirectional, administrative boundary for PFM messages, see Section 3.2. If the No-Forward bit is not set, the message MUST be from the RPF neighbor of the originator address. If the No-Forward bit is set, this system, the router doing these checks, MUST have enabled the PIM protocol within the last 60 seconds. See Section 3.3 for details. In pseudocode, the algorithm is as follows:
为了进行进一步处理，消息必须满足以下要求。消息必须来自直接连接的PIM邻居，并且目标地址必须是ALL-PIM-ROUTERS。此外，接口不得是PFM消息的传入或双向管理边界，见第3.2节。如果未设置“无转发”位，则消息必须来自发起方地址的RPF邻居。如果设置了No Forward（无转发）位，则执行这些检查的路由器必须在过去60秒内启用PIM协议。详见第3.3节。在伪码中，算法如下：
if ((DirectlyConnected(PFM.src_ip_address) == FALSE) OR
(PFM.src_ip_address is not a PIM neighbor) OR
(PFM.dst_ip_address != ALL-PIM-ROUTERS) OR
(Incoming interface is admin boundary for PFM)) {
drop the message silently, optionally log error.
}
if (PFM.no_forward_bit == 0) {
if (PFM.src_ip_address !=
RPF_neighbor(PFM.originator_ip_address)) {
drop the message silently, optionally log error.
}
} else if (more than 60 seconds elapsed since PIM enabled)) {
drop the message silently, optionally log error.
}
if ((DirectlyConnected(PFM.src_ip_address) == FALSE) OR
(PFM.src_ip_address is not a PIM neighbor) OR
(PFM.dst_ip_address != ALL-PIM-ROUTERS) OR
(Incoming interface is admin boundary for PFM)) {
drop the message silently, optionally log error.
}
if (PFM.no_forward_bit == 0) {
if (PFM.src_ip_address !=
RPF_neighbor(PFM.originator_ip_address)) {
drop the message silently, optionally log error.
}
} else if (more than 60 seconds elapsed since PIM enabled)) {
drop the message silently, optionally log error.
}
Note that "src_ip_address" is the source address in the IP header of the PFM message. "Originator" is the originator field inside the PFM message and is the router that originated the message. When the message is forwarded hop-by-hop, the originator address never changes, while the source address will be an address belonging to the router that last forwarded the message.
请注意，“src_ip_address”是PFM消息的ip头中的源地址。“发起人”是PFM消息内的发起人字段，是发起消息的路由器。当消息逐跳转发时，发起者地址永远不会更改，而源地址将是属于最后转发消息的路由器的地址。
When the message is received, the initial checks above must be performed. If it passes the checks, then for each included TLV, perform processing according to the specification for that TLV.
收到消息后，必须执行上述初始检查。如果通过检查，则针对每个包含的TLV，根据该TLV的规范执行处理。
After processing, the message is forwarded. Some TLVs may be omitted or modified in the forwarded message. This depends on administrative boundaries (see Section 3.2), the type specification, and the setting of the Transitive bit for the TLV. If a router supports the type, then the TLV is forwarded with no changes unless otherwise specified by the type specification. A router not supporting the given type MUST include the TLV in the forwarded message if and only if the Transitive bit is set. Whether or not a router supports the type, the value of the Transitive bit MUST be preserved if the TLV is included in the forwarded message. The message is forwarded out of all interfaces with PIM neighbors (including the interface it was received on). As specified in Section 3.2, if an interface is an outgoing boundary for any TLVs, the message MUST NOT be sent out on the interface if it is an outgoing boundary for all the TLVs in the message. Otherwise, the router MUST remove any outgoing boundary TLVs of the interface from the message and send the message out that interface with the remaining TLVs.
经过处理后，消息被转发。某些TLV可能在转发的消息中被省略或修改。这取决于管理边界（见第3.2节）、类型规范和TLV传递位的设置。如果路由器支持该类型，则除非类型规范另有规定，否则TLV在转发时不作任何更改。当且仅当设置了可传递位时，不支持给定类型的路由器必须在转发消息中包含TLV。无论路由器是否支持该类型，如果TLV包含在转发消息中，则必须保留可传递位的值。消息从与PIM邻居的所有接口（包括接收它的接口）转发出去。如第3.2节所述，如果接口是任何TLV的传出边界，则如果接口是消息中所有TLV的传出边界，则不得在接口上发送消息。否则，路由器必须从消息中删除接口的任何传出边界TLV，并将消息与其余TLV一起发送到该接口。
The generic PFM defined in the previous section can be used for distributing SG mappings about active multicast sources throughout a PIM domain. A Group Source Holdtime (GSH) TLV is defined for this purpose.
上一节中定义的通用PFM可用于在整个PIM域中分发有关活动多播源的SG映射。为此，定义了组源保持时间（GSH）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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Type = 1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Count | Src Holdtime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Address 1 (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Address 2 (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Address m (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Type = 1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Count | Src Holdtime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Address 1 (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Address 2 (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Address m (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1: The Transitive bit is set to 1. This means that this type will be forwarded even if a router does not support it. See Section 3.4.2.
1：可传递位设置为1。这意味着即使路由器不支持该类型，也会转发该类型。见第3.4.2节。
Type: This TLV has type 1.
类型：此TLV具有类型1。
Length: The length of the value in octets.
长度：值的长度（以八位字节为单位）。
Group Address: The group that sources are to be announced for. The format for this address is given in the Encoded-Group format in [RFC7761].
组地址：要为其宣布来源的组。该地址的格式以[RFC7761]中的编码组格式给出。
Src Count: The number of source addresses that are included.
Src Count：包含的源地址数。
Src Holdtime: The holdtime (in seconds) for the included source(s).
Src Holdtime：包含的源的保持时间（秒）。
Src Address: The source address for the corresponding group. The format for these addresses is given in the Encoded-Unicast address in [RFC7761].
Src地址：对应组的源地址。这些地址的格式在[RFC7761]中的编码单播地址中给出。
A PFM message MAY contain one or more Group Source Holdtime (GSH) TLVs. This is used to flood information about active multicast sources. Each FHR that is directly connected to an active multicast source originates PFM messages containing GSH TLVs. How a multicast router discovers the source of the multicast packet, and when it considers itself the FHR, follows the same procedures as the registering process described in [RFC7761]. When an FHR has decided that a register needs to be sent per [RFC7761], the SG is not registered via the PIM-SM register procedures, but the SG mapping is included in a GSH TLV in a PFM message. Note that only the SG mapping is distributed in the message: not the entire packet as would have been done with a PIM register.
PFM消息可能包含一个或多个组源保持时间（GSH）TLV。这用于大量提供有关活动多播源的信息。直接连接到活动多播源的每个FHR生成包含GSH TLV的PFM消息。多播路由器如何发现多播数据包的来源，以及当它认为自己是FHR时，遵循与[RFC7761]中描述的注册过程相同的过程。当FHR决定需要根据[RFC7761]发送寄存器时，SG不通过PIM-SM寄存器程序进行注册，但SG映射包含在PFM消息中的GSH TLV中。请注意，只有SG映射分布在消息中：而不是像PIM寄存器那样分布整个数据包。
The PFM messages containing the GSH TLV are sent periodically for as long as the multicast source is active, similar to how PIM registers are sent periodically. This means that as long as the source is active, it is included in a PFM message originated every Group_Source_Holdtime_Period seconds, within the general PFM timing requirements in Section 3.3. The default value of Group_Source_Holdtime_Period is 60. The value MUST be configurable. The holdtime for the source MUST be set to either zero or Group_Source_Holdtime_Holdtime. The value of the Group_Source_Holdtime_Holdtime parameter MUST be larger than Group_Source_Holdtime_Period. It is RECOMMENDED to be 3.5 times the Group_Source_Holdtime_Period. The default value is 210 (seconds). The value MUST be configurable. A source MAY be announced with a holdtime of zero to indicate that the source is no longer active.
只要多播源处于活动状态，包含GSH TLV的PFM消息就会定期发送，这与定期发送PIM寄存器的方式类似。这意味着，只要源处于活动状态，它就会包含在第3.3节中一般PFM定时要求范围内，在每个组\源\保持时间\周期秒发出的PFM消息中。组\源\保持时间\周期的默认值为60。该值必须是可配置的。源的保持时间必须设置为零或组\源\保持时间\保持时间。Group\u Source\u Holdtime\u Holdtime参数的值必须大于Group\u Source\u Holdtime\u Period。建议为组\u源\u保持时间\u周期的3.5倍。默认值为210（秒）。该值必须是可配置的。可以用保持时间为零来宣布源，以指示该源不再处于活动状态。
If an implementation supports originating GSH TLVs with different holdtimes for different sources, it can (if needed) send multiple TLVs with the same group address. Due to the format, all the sources in the same TLV have the same holdtime.
如果一个实现支持为不同的源使用不同的保持时间发起GSH TLV，那么它可以（如果需要）发送具有相同组地址的多个TLV。由于格式不同，同一TLV中的所有源具有相同的保持时间。
When a new source is detected, an implementation MAY send a PFM message containing just that particular source. However, it MAY also include information about other sources that were just detected, sources that are scheduled for periodic announcement later, or other types of information. See Section 3.3 for details. Note that when a new source is detected, one should trigger the sending of a PFM message as soon as possible; whereas if a source becomes inactive, there is no reason to trigger a message. There is no urgency in removing state for inactive sources. Note that the message timing requirements in Section 3.3 apply. This means that one cannot always send a triggered message immediately when a new source is detected. In order to meet the timing requirements, the sending of the message may have to be delayed for a small amount of time.
当检测到新的源时，实现可以发送仅包含该特定源的PFM消息。但是，它还可能包括有关刚刚检测到的其他源、计划稍后定期公布的源或其他类型的信息的信息。详见第3.3节。注意，当检测到新的源时，应尽快触发PFM消息的发送；然而，如果源变为非活动状态，则没有理由触发消息。删除非活动源的状态并不迫切。请注意，第3.3节中的消息定时要求适用。这意味着当检测到新的源时，不能总是立即发送触发的消息。为了满足定时要求，消息的发送可能必须延迟一小段时间。
When a new PIM neighbor is detected or an existing neighbor changes GenID, an implementation MAY send a triggered PFM message containing GSH TLVs for any SG mappings it has learned by receiving PFM GSH TLVs as well as any active directly connected sources. See Section 3.3 for further details.
当检测到新的PIM邻居或现有邻居更改GenID时，实现可发送包含GSH TLV的触发PFM消息，以用于其通过接收PFM GSH TLV以及任何活动的直接连接源而获知的任何SG映射。详见第3.3节。
A router that receives a PFM message containing GSH TLVs MUST parse the GSH TLVs and store each of them as SG mappings with an Expiry Timer started with the advertised holdtime, that is, unless the implementation specifically does not support GSH TLVs, the router is configured to ignore GSH TLVs in general, or it is configured to ignore GSH TLVs for certain sources or groups. In particular, an administrator might configure a router not to process GSH TLVs if the router is known never to have any directly connected receivers.
接收包含GSH TLV的PFM消息的路由器必须解析GSH TLV，并将每个GSH TLV存储为SG映射，其中过期计时器以播发的保持时间开始，也就是说，除非实现特别不支持GSH TLV，否则路由器通常配置为忽略GSH TLV，或者配置为忽略某些来源或组的GSH TLV。特别是，如果已知路由器从未有任何直接连接的接收器，管理员可能会将路由器配置为不处理GSH TLV。
For each group that has directly connected receivers, this router SHOULD send PIM (S,G) joins for all the SG mappings advertised in the message for the group. Generally, joins are sent, but there could be, for instance, an administrative policy limiting which sources and groups to join. The SG mappings are kept alive for as long as the Expiry Timer for the source is running. Once the Expiry Timer expires, a PIM router MAY send a PIM (S,G) prune to remove itself from the tree. However, when this happens, there should be no more packets sent by the source, so it may be desirable to allow the state to time out rather than sending a prune.
对于具有直接连接的接收器的每个组，此路由器应为该组的消息中公布的所有SG映射发送PIM（S，G）联接。通常，会发送连接，但例如，可能有一个管理策略限制要连接的源和组。只要源的到期计时器正在运行，SG映射就会保持活动状态。一旦到期计时器过期，PIM路由器可能会发送一个PIM（S，G）剪枝以从树中删除自身。但是，当发生这种情况时，源不应该再发送数据包，因此可能需要允许状态超时，而不是发送修剪。
Note that a holdtime of zero has a special meaning. It is to be treated as if the source just expired, and then the state should be removed. Source information MUST NOT be removed due to the source being omitted in a message. For instance, if there are a large number of sources for a group, there may be multiple PFM messages, each message containing a different list of sources for the group.
请注意，保持时间为零具有特殊含义。将其视为源刚刚过期，然后应删除该状态。由于消息中省略了源信息，因此不能删除源信息。例如，如果一个组有大量源，则可能有多条PFM消息，每条消息包含该组的不同源列表。
The PIM register procedure is designed to deliver multicast packets to the RP in the absence of an SPT from the RP to the source. The register packets received on the RP are decapsulated and forwarded down the shared tree to the LHRs. As soon as an SPT is built, multicast packets would flow natively over the SPT to the RP or LHR and the register process would stop. The PIM register process ensures packet delivery until an SPT is in place reaching the FHR. If the packets were not unicast encapsulated to the RP, they would be dropped by the FHR until the SPT is set up. This functionality is important for applications where the initial packet(s) must be received for the application to work correctly. Another reason would
PIM注册程序设计用于在没有从RP到源的SPT的情况下向RP发送多播数据包。RP上接收到的寄存器数据包被解封并沿着共享树转发到LHR。一旦建立了SPT，多播数据包就会在SPT上以本机方式流向RP或LHR，并且注册过程将停止。PIM注册过程确保数据包交付，直到SPT到位到达FHR。如果数据包不是单播封装到RP，FHR将丢弃它们，直到SPT设置完毕。对于必须接收初始数据包才能使应用程序正常工作的应用程序，此功能非常重要。另一个原因是
be for bursty sources. If the application sends out a multicast packet every 4 minutes (or longer), the SPT is torn down (typically after 3:30 minutes of inactivity) before the next packet is forwarded down the tree. This will prevent multicast packets from ever being forwarded. A well-behaved application should be able to deal with packet loss since IP is a best-effort-based packet delivery system. But in reality, this is not always the case.
对于突发性的消息源。如果应用程序每4分钟（或更长时间）发送一个多播数据包，则在下一个数据包沿树转发之前，SPT将被拆除（通常在3:30分钟不活动之后）。这将阻止多播数据包被转发。一个表现良好的应用程序应该能够处理数据包丢失，因为IP是一个基于尽力而为的数据包传递系统。但在现实中，情况并非总是如此。
With the procedures defined in this document, the packet(s) received by the FHR will be dropped until the LHR has learned about the source and the SPT is built. For bursty sources or applications sensitive for the delivery of the first packet, that means this solution would not be very applicable. This solution is mostly useful for applications that don't have a strong dependency on the initial packet(s) and have a fairly constant data rate, like video distribution, for example. For applications with strong dependency on the initial packet(s), using BIDIR-PIM [RFC5015] or SSM [RFC4607] is recommended. The protocol operations are much simpler compared to PIM-SM; they will cause less churn in the network. Both guarantee best-effort delivery for the initial packet(s).
根据本文件中规定的程序，FHR接收的数据包将被丢弃，直到LHR了解到数据源并建立SPT。对于对第一个数据包的交付敏感的突发源或应用程序，这意味着此解决方案不太适用。此解决方案主要适用于对初始数据包没有强依赖性且数据速率相当恒定的应用程序，例如视频分发。对于对初始数据包有强烈依赖性的应用程序，建议使用BIDIR-PIM[RFC5015]或SSM[RFC4607]。与PIM-SM相比，协议操作简单得多；它们将减少网络中的用户流失。两者都保证了初始数据包的最大努力交付。
In a PIM-SM deployment where the network becomes partitioned due to link or node failure, it is possible that the RP becomes unreachable to a certain part of the network. New sources that become active in that partition will not be able to register to the RP and receivers within that partition will not be able to receive the traffic. Ideally, having a candidate RP in each partition is desirable, but which routers will form a partitioned network is something unknown in advance. In order to be fully resilient, each router in the network may end up being a candidate RP. This would increase the operational complexity of the network.
在PIM-SM部署中，由于链路或节点故障，网络变得分区，RP可能无法到达网络的某个部分。在该分区中变为活动的新源将无法注册到RP，并且该分区内的接收器将无法接收流量。理想情况下，在每个分区中有一个候选RP是可取的，但哪些路由器将形成分区网络是事先未知的。为了具有完全的弹性，网络中的每个路由器可能最终成为候选RP。这将增加网络的操作复杂性。
The solution described in this document does not suffer from that problem. If a network becomes partitioned and new sources become active, the receivers in that partition will receive the SG mappings and join the source tree. Each partition works independently of the other partitions and will continue to have access to sources within that partition. Once the network has healed, the periodic flooding of SG mappings ensures that they are reflooded into the other partitions and then other receivers can join the newly learned sources.
本文档中描述的解决方案不存在该问题。如果网络被分区，并且新的源变为活动的，则该分区中的接收器将接收SG映射并加入源树。每个分区独立于其他分区工作，并将继续访问该分区内的源。一旦网络修复，SG映射的周期性泛洪将确保它们重新流入其他分区，然后其他接收器可以加入新学到的源。
This document contains a number of configurable parameters. These parameters are formally defined in Sections 3.3 and 4.2, but they are repeated here for ease of reference. These parameters all have default values as noted below.
本文档包含许多可配置参数。这些参数在第3.3节和第4.2节中有正式定义，但为了便于参考，此处重复这些参数。这些参数都具有如下所述的默认值。
Max_PFM_Message_Rate: The maximum number of PFM messages a router is allowed to originate per minute; see Section 3.3 for details. The default value is 6.
Max_PFM_Message_Rate：路由器每分钟允许发起的最大PFM消息数；详见第3.3节。默认值为6。
Min_PFM_Message_Gap: The minimum amount of time between each PFM message originated by a router in milliseconds; see Section 3.3 for details. The default is 1000.
Min_PFM_Message_Gap：路由器发出的每个PFM消息之间的最小时间量（毫秒）；详见第3.3节。默认值为1000。
Group_Source_Holdtime_Period: The announcement period for Group Source Holdtime TLVs in seconds; see Section 4.2 for details. The default value is 60.
Group_Source_Holdtime_Period：组源Holdtime TLV的公告期，以秒为单位；详见第4.2节。默认值为60。
Group_Source_Holdtime_Holdtime: The holdtime for Group Source Holdtime TLVs in seconds; see Section 4.2 for details. The default value is 210.
组\u源\u保持时间\u保持时间：组源保持时间TLV的保持时间，以秒为单位；详见第4.2节。默认值为210。
For general PIM message security, see [RFC7761]. PFM messages MUST only be accepted from a PIM neighbor, but as discussed in [RFC7761], any router can become a PIM neighbor by sending a Hello message. To control from where to accept PFM packets, one can limit on which interfaces PIM is enabled. Also, one can configure interfaces as administrative boundaries for PFM messages, see Section 3.2. The implications of forged PFM messages depend on which TLVs they contain. Documents defining new TLVs will need to discuss the security considerations for the specific TLVs. In general though, the PFM messages are flooded within the network; by forging a large number of PFM messages, one might stress all the routers in the network.
有关一般PIM消息安全性，请参阅[RFC7761]。PFM消息只能从PIM邻居处接受，但如[RFC7761]中所述，任何路由器都可以通过发送Hello消息成为PIM邻居。为了控制从何处接受PFM数据包，可以限制启用PIM的接口。此外，可以将接口配置为PFM消息的管理边界，请参见第3.2节。伪造PFM消息的含义取决于它们包含的TLV。定义新TLV的文件需要讨论特定TLV的安全注意事项。但是，一般来说，PFM消息在网络中被淹没；通过伪造大量PFM消息，可能会对网络中的所有路由器造成压力。
If an attacker can forge PFM messages, then such messages may contain arbitrary GSH TLVs. An issue here is that an attacker might send such TLVs for a huge amount of sources, potentially causing every router in the network to store huge amounts of source state. Also, if there is receiver interest for the groups specified in the GSH TLVs, routers with directly connected receivers will build SPTs for the announced sources, even if the sources are not actually active. Building such trees will consume additional resources on routers that the trees pass through.
如果攻击者可以伪造PFM消息，则此类消息可能包含任意GSH TLV。这里的一个问题是，攻击者可能发送此类TLV以获取大量源，这可能会导致网络中的每个路由器存储大量源状态。此外，如果GSH TLV中指定的组存在接收器利益，则具有直接连接接收器的路由器将为宣布的源建立SPT，即使源实际上不活动。构建这样的树将消耗树通过的路由器上的额外资源。
PIM-SM link-local messages can be authenticated using IPsec, see Section 6.3 of [RFC7761] and [RFC5796]. Since PFM messages are link-local messages sent hop-by-hop, a link-local PFM message can be authenticated using IPsec such that a router can verify that a message was sent by a trusted neighbor and has not been modified. However, to verify that a received message contains correct information announced by the originator specified in the message, one will have to trust every router on the path from the originator and that each router has authenticated the received message.
PIM-SM链路本地消息可以使用IPsec进行身份验证，请参见[RFC7761]和[RFC5796]的第6.3节。由于PFM消息是逐跳发送的链路本地消息，因此可以使用IPsec对链路本地PFM消息进行身份验证，以便路由器可以验证消息是否由受信任的邻居发送且未被修改。但是，要验证接收到的消息是否包含消息中指定的发起者所宣布的正确信息，必须信任发起者路径上的每个路由器，并且每个路由器都已对接收到的消息进行了身份验证。
This document registers a new PIM message type for the PIM Flooding Mechanism (PFM) with the name "PIM Flooding Mechanism" in the "PIM Message Types" registry with the value of 12.
本文档在“PIM消息类型”注册表中为PIM泛洪机制（PFM）注册了一个名为“PIM泛洪机制”的新PIM消息类型，其值为12。
IANA has also created a registry for PFM TLVs called "PIM Flooding Mechanism Message Types". Assignments for the registry are to be made according to the policy "IETF Review" as defined in [RFC8126]. The initial content of the registry is as follows:
IANA还为PFM TLV创建了一个名为“PIM洪泛机制消息类型”的注册表。根据[RFC8126]中定义的“IETF审查”政策进行注册分配。登记处的初步内容如下：
Type Name Reference
---------------------------------------------
0 Reserved [RFC8364]
1 Source Group Holdtime [RFC8364]
2-32767 Unassigned
Type Name Reference
---------------------------------------------
0 Reserved [RFC8364]
1 Source Group Holdtime [RFC8364]
2-32767 Unassigned
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)", RFC 5059, DOI 10.17487/RFC5059, January 2008, <https://www.rfc-editor.org/info/rfc5059>.
[RFC5059]Bhaskar，N.，Gall，A.，Lingard，J.，和S.Venaas，“用于协议独立多播（PIM）的引导路由器（BSR）机制”，RFC 5059，DOI 10.17487/RFC5059，2008年1月<https://www.rfc-editor.org/info/rfc5059>.
[RFC5796] Atwood, W., Islam, S., and M. Siami, "Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages", RFC 5796, DOI 10.17487/RFC5796, March 2010, <https://www.rfc-editor.org/info/rfc5796>.
[RFC5796]Atwood，W.，Islam，S.，和M.Siami，“协议独立多播稀疏模式（PIM-SM）链路本地消息中的身份验证和机密性”，RFC 5796，DOI 10.17487/RFC5796，2010年3月<https://www.rfc-editor.org/info/rfc5796>.
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 2016, <https://www.rfc-editor.org/info/rfc7761>.
[RFC7761]Fenner，B.，Handley，M.，Holbrook，H.，Kouvelas，I.，Parekh，R.，Zhang，Z.，和L.Zheng，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，STD 83，RFC 7761，DOI 10.17487/RFC7761，2016年3月<https://www.rfc-editor.org/info/rfc7761>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, DOI 10.17487/RFC3973, January 2005, <https://www.rfc-editor.org/info/rfc3973>.
[RFC3973]Adams，A.，Nicholas，J.，和W.Siadak，“协议独立多播-密集模式（PIM-DM）：协议规范（修订版）”，RFC 3973，DOI 10.17487/RFC3973，2005年1月<https://www.rfc-editor.org/info/rfc3973>.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, <https://www.rfc-editor.org/info/rfc4607>.
[RFC4607]Holbrook，H.和B.Cain，“IP的源特定多播”，RFC 4607，DOI 10.17487/RFC4607，2006年8月<https://www.rfc-editor.org/info/rfc4607>.
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, <https://www.rfc-editor.org/info/rfc5015>.
[RFC5015]Handley，M.，Kouvelas，I.，Speakman，T.，和L.Vicisano，“双向协议独立多播（BIDIR-PIM）”，RFC 5015，DOI 10.17487/RFC5015，2007年10月<https://www.rfc-editor.org/info/rfc5015>.
Acknowledgments
致谢
The authors would like to thank Arjen Boers for contributing to the initial idea, and David Black, Stewart Bryant, Yiqun Cai, Papadimitriou Dimitri, Toerless Eckert, Dino Farinacci, Alvaro Retana, and Liang Xia for their very helpful comments on the document.
作者要感谢Arjen Boers对最初想法的贡献，以及David Black、Stewart Bryant、蔡益群、Papadimitriou Dimitri、Toerless Eckert、Dino Farinaci、Alvaro Retana和梁霞对该文件的非常有益的评论。
Authors' Addresses
作者地址
IJsbrand Wijnands Cisco Systems, Inc. De kleetlaan 6a Diegem 1831 Belgium
IJsbrand Wijlands Cisco Systems，Inc.De kleetlaan 6a Diegem 1831比利时
Email: ice@cisco.com
Email: ice@cisco.com
Stig Venaas Cisco Systems, Inc. Tasman Drive San Jose CA 95134 United States of America
Stig Venaas Cisco Systems，Inc.美国加利福尼亚州圣何塞塔斯曼大道95134号
Email: stig@cisco.com
Email: stig@cisco.com
Michael Brig Aegis BMD Program Office 17211 Avenue D, Suite 160 Dahlgren VA 22448-5148 United States of America
Michael Brig Aegis BMD项目办公室美国弗吉尼亚州达尔格伦大道D 17211号160室22448-5148
Email: michael.brig@mda.mil
Email: michael.brig@mda.mil
Anders Jonasson Swedish Defence Material Administration (FMV) Loennvaegen 4 Vaexjoe 35243 Sweden
Anders Jonasson瑞典国防材料管理局（FMV）Loennvaegen 4 Vaexjoe 35243瑞典
Email: anders@jomac.se
Email: anders@jomac.se