Internet Engineering Task Force (IETF) D. Farinacci
Request for Comments: 6807 G. Shepherd
Category: Experimental S. Venaas
ISSN: 2070-1721 Cisco Systems
Y. Cai
Microsoft
December 2012
Internet Engineering Task Force (IETF) D. Farinacci
Request for Comments: 6807 G. Shepherd
Category: Experimental S. Venaas
ISSN: 2070-1721 Cisco Systems
Y. Cai
Microsoft
December 2012
Population Count Extensions to Protocol Independent Multicast (PIM)
协议独立多播（PIM）的人口计数扩展
Abstract
摘要
This specification defines a method for providing multicast distribution-tree accounting data. Simple extensions to the Protocol Independent Multicast (PIM) protocol allow a rough approximation of tree-based data in a scalable fashion.
本规范定义了一种提供多播分发树记帐数据的方法。对协议独立多播（PIM）协议的简单扩展允许以可伸缩的方式粗略近似基于树的数据。
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/rfc6807.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6807.
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许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Pop-Count-Supported Hello Option . . . . . . . . . . . . . . . 4
3. New Pop-Count Join Attribute Format . . . . . . . . . . . . . 5
3.1. Options . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.1. Link Speed Encoding . . . . . . . . . . . . . . . . . 10
3.2. Example Message Layouts . . . . . . . . . . . . . . . . . 10
4. How to Use Pop-Count Encoding . . . . . . . . . . . . . . . . 11
5. Implementation Approaches . . . . . . . . . . . . . . . . . . 12
6. Caveats . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . . 14
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Pop-Count-Supported Hello Option . . . . . . . . . . . . . . . 4
3. New Pop-Count Join Attribute Format . . . . . . . . . . . . . 5
3.1. Options . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.1. Link Speed Encoding . . . . . . . . . . . . . . . . . 10
3.2. Example Message Layouts . . . . . . . . . . . . . . . . . 10
4. How to Use Pop-Count Encoding . . . . . . . . . . . . . . . . 11
5. Implementation Approaches . . . . . . . . . . . . . . . . . . 12
6. Caveats . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . . 14
This document specifies a mechanism to convey accounting information using the Protocol Independent Multicast (PIM) protocol [RFC4601] [RFC5015]. Putting the mechanism in PIM allows efficient distribution and maintenance of such accounting information. Previous mechanisms require data to be correlated from multiple router sources.
本文档指定了使用协议独立多播（PIM）协议[RFC4601][RFC5015]传输记帐信息的机制。将该机制纳入PIM可以有效地分发和维护此类会计信息。以前的机制要求从多个路由器源关联数据。
This mechanism allows a single router to be queried to obtain accounting and statistic information for a multicast distribution tree as a whole or any distribution sub-tree downstream from a queried router. The amount of information is fixed and does not increase as multicast membership, tree diameter, or branching increases.
该机制允许查询单个路由器，以获取多播分发树整体或查询路由器下游任何分发子树的记帐和统计信息。信息量是固定的，不会随着多播成员资格、树直径或分支的增加而增加。
The sort of accounting data this specification provides, on a per-multicast-route basis, are:
本规范在每个多播路由的基础上提供的记帐数据类型为：
1. The number of branches in a distribution tree.
1. 分布树中的分支数。
2. The membership type of the distribution tree, that is, Source-Specific Multicast (SSM) or Any-Source Multicast (ASM).
2. 分发树的成员类型，即源特定多播（SSM）或任何源多播（ASM）。
3. Routing domain and time zone boundary information.
3. 路由域和时区边界信息。
4. On-tree node and tree diameter counters.
4. 在树节点和树直径计数器上。
5. Effective MTU and bandwidth.
5. 有效MTU和带宽。
This document defines a new PIM Join Attribute type [RFC5384] for the Join/Prune message as well as a new Hello option. The mechanism is applicable to IPv4 and IPv6 multicast.
本文档为Join/Prune消息定义了一个新的PIM连接属性类型[RFC5384]，以及一个新的Hello选项。该机制适用于IPv4和IPv6组播。
This is a new extension to PIM, and it is not completely understood what impact collecting information using PIM would have on the operation of PIM. This is an entirely new concept. Many PIM features (including the core protocols) were first introduced in Experimental RFCs, and it seems appropriate to advance this work as Experimental. Reports of implementation and deployment across whole distribution trees or within sub-trees (see Section 6) will enable an assessment of the desirability and stability of this specification. The PIM Working Group will then consider whether to move this work to the Standards Track.
这是PIM的一个新扩展，目前还不完全了解使用PIM收集信息对PIM运行的影响。这是一个全新的概念。许多PIM特性（包括核心协议）最初是在实验性RFC中引入的，因此将这项工作作为实验性的推进似乎是合适的。整个分发树或子树（见第6节）内的实施和部署报告将有助于评估本规范的可取性和稳定性。PIM工作组将考虑是否将这项工作移到标准轨道上。
This document does not specify how an administrator or user can access this information. It is expected that an implementation may have a command-line interface or other ways of requesting and
本文档未指定管理员或用户如何访问此信息。预期实现可能具有命令行界面或其他请求和请求的方式
displaying this information. As this is currently an Experimental document, defining a MIB module has not been considered. If the PIM Working Group finds that this should move on to Standards Track, a MIB module should be considered.
显示此信息。由于这目前是一份实验性文档，因此尚未考虑定义MIB模块。如果PIM工作组认为这应该转到标准轨道，则应考虑使用MIB模块。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This section defines the terms used in this document.
本节定义了本文件中使用的术语。
Multicast Route: An (S,G) or (*,G) entry regardless of whether the route is in ASM, SSM, or BIDIR mode of operation.
多播路由：一个（S，G）或（*，G）条目，无论该路由是处于ASM、SSM还是BIDIR操作模式。
Stub Link: A link with members joined to the group via IGMP or Multicast Listener Discovery (MLD).
存根链接：成员通过IGMP或多播侦听器发现（MLD）加入组的链接。
Transit Link: A link put in the oif-list (outgoing interface list) for a multicast route because it was joined by PIM routers.
传输链路：为多播路由放入oif列表（传出接口列表）的链路，因为它由PIM路由器加入。
Note that a link can be both a Stub Link and a Transit Link at the same time.
请注意，链路可以同时是存根链路和传输链路。
A PIM router indicates that it supports the mechanism specified in this document by including the Pop-Count-Supported Hello option in its PIM Hello message. Note that it also needs to include the Join-Attribute Hello option as specified in [RFC5384]. The format of the Pop-Count-Supported Hello option is defined to be:
PIM路由器通过在其PIM Hello消息中包含Pop Count Supported Hello选项，表明其支持本文档中指定的机制。注意，它还需要包括[RFC5384]中指定的连接属性Hello选项。Pop Count Supported Hello选项的格式定义为：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OptionType | OptionLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OptionType | OptionLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OptionType = 29, OptionLength = 0. Note that there is no option value included. In order to allow future updates of this specification that may include an option value, implementations of this document MUST accept and process this option even if the length is non-zero. Implementations of this specification MUST accept and process the option ignoring any option value that may be included.
OptionType=29，OptionLength=0。请注意，没有包含任何选项值。为了允许将来更新可能包含选项值的本规范，本文档的实现必须接受并处理此选项，即使长度不为零。本规范的实现必须接受并处理该选项，忽略可能包含的任何选项值。
When a PIM router supports this mechanism and has determined from a received Hello that the neighbor supports this mechanism, and also that all the neighbors on the interface support the use of join attributes, it will send Join/Prune messages that MAY include a Pop-Count Join Attribute. The mechanism to process a PIM Join Attribute is described in [RFC5384]. The format of the new attribute is specified in the following.
当PIM路由器支持此机制，并从收到的Hello中确定邻居支持此机制，并且接口上的所有邻居都支持使用连接属性时，它将发送可能包含Pop计数连接属性的连接/删除消息。[RFC5384]中描述了处理PIM连接属性的机制。新属性的格式如下所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|E| Attr_Type | Length | Effective MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Options Bitmap |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options |
. . .
. . .
. . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|E| Attr_Type | Length | Effective MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Options Bitmap |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options |
. . .
. . .
. . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The above format is used only for entries in the join-list section of the Join/Prune message.
上述格式仅用于join/Prune消息的join list部分中的条目。
F bit: 0 (Non-Transitive Attribute).
F位：0（非传递属性）。
E bit: As specified by [RFC5384].
E位：按照[RFC5384]的规定。
Attr_Type: 3.
属性类型：3。
Length: The minimum length is 6.
长度：最小长度为6。
Effective MTU: This contains the minimum MTU for any link in the oif-list. The sender of a Join/Prune message takes the minimum value for the MTU (in bytes) from each link in the oif-list. If this value is less than the value stored for the multicast route (the one received from downstream joiners), then the value should be reset and sent in a Join/Prune message. Otherwise, the value should remain unchanged.
有效MTU：包含oif列表中任何链接的最小MTU。Join/Prune消息的发送方从oif列表中的每个链接获取MTU的最小值（以字节为单位）。如果该值小于为多播路由存储的值（从下游加入者接收的值），则应重置该值并在加入/删除消息中发送。否则，该值应保持不变。
This provides the MTU supported by multicast distribution tree when examined at the first-hop router(s) or for sub-tree for any router on the distribution tree.
当在第一跳路由器或分发树上的任何路由器的子树上检查时，这提供了多播分发树支持的MTU。
Flags: The flags field has the following format:
标志：标志字段的格式如下：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unalloc/Reserved |P|a|t|A|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unalloc/Reserved |P|a|t|A|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Unallocated/Reserved Flags: The flags that are currently not defined. If a new flag is defined and used by a new implementation, an old implementation should preserve the bit settings. This means that a router MUST preserve the settings of all Unallocated/Reserved Flags in PIM Join messages received from downstream routers in any PIM Join sent upstream.
未分配/保留标志：当前未定义的标志。如果新实现定义并使用了新标志，则旧实现应保留位设置。这意味着路由器必须保留从上游发送的任何PIM连接中的下游路由器接收的PIM连接消息中所有未分配/保留标志的设置。
S flag: This flag is set if an IGMPv3 or MLDv2 report with an INCLUDE mode group record was received on any oif-list entry or the bit was set from any PIM Join message. This bit should only be cleared when the above becomes untrue.
S标志：如果在任何oif列表条目上接收到包含模式组记录的IGMPv3或MLDv2报告，或者从任何PIM连接消息中设置了位，则设置此标志。只有当上述内容变得不真实时，才应清除该位。
A flag: This flag is set if an IGMPv3 or MLDv2 report with an EXCLUDE mode group record, or an IGMPv1, IGMPv2, or MLDv1 report, was received on any oif-list entry or the bit was set from any PIM Join message. This bit should only be cleared when the above becomes untrue.
标志：如果在任何oif列表条目上收到带有排除模式组记录的IGMPv3或MLDv2报告，或IGMPv1、IGMPv2或MLDv1报告，或从任何PIM连接消息中设置位，则设置此标志。只有当上述内容变得不真实时，才应清除该位。
A combination of settings for these bits indicate:
这些位的设置组合表示：
A flag S flag Description
------ ------ --------------------------------------
0 0 There are no members for the group.
('Stub Oif-List Count' is 0)
0 1 All group members are using SSM.
1 0 All group members are using ASM.
1 1 A mixture of SSM and ASM group members.
A flag S flag Description
------ ------ --------------------------------------
0 0 There are no members for the group.
('Stub Oif-List Count' is 0)
0 1 All group members are using SSM.
1 0 All group members are using ASM.
1 1 A mixture of SSM and ASM group members.
t flag: This flag is set if there are any manually configured tunnels on the distribution tree. This means any tunnel that is not an auto-tunnel. If a manually configured tunnel is in the oif-list, a router sets this bit in its Join/Prune messages. Otherwise, it propagates the bit setting from downstream joiners.
t标志：如果分发树上有任何手动配置的隧道，则设置此标志。这意味着任何不是自动隧道的隧道。如果人工配置的隧道在oif列表中，路由器将在其加入/删除消息中设置此位。否则，它将从下游连接器传播位设置。
a flag: This flag is set if there are any auto-tunnels on the distribution tree. If an auto-tunnel is in the oif-list, a router sets this bit in its Join/Prune messages. Otherwise, it propagates the bit setting from downstream joiners. An example of an auto-tunnel is a tunnel set up by the Automatic Multicast Tunneling [AMT] protocol.
标志：如果分发树上有任何自动隧道，则设置此标志。如果自动隧道在oif列表中，路由器将在其加入/删除消息中设置此位。否则，它将从下游连接器传播位设置。自动隧道的一个示例是由自动多播隧道[AMT]协议设置的隧道。
P flag: This flag is set by a router if all downstream routers support this specification. That is, they are all PIM Pop-Count capable. If a downstream router does not support this specification, it MUST be cleared. This allows one to tell if the entire sub-tree is completely accounting capable.
P标志：如果所有下游路由器都支持此规范，则该标志由路由器设置。也就是说，它们都具有PIM Pop Count功能。如果下游路由器不支持此规范，则必须将其清除。这使我们能够判断整个子树是否完全能够记帐。
Options Bitmap: This is a bitmap that shows which options are present. The format of the bitmap is as follows:
选项位图：这是一个显示存在哪些选项的位图。位图的格式如下所示：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|s|m|M|d|n|D|z| Unalloc/Rsrvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|s|m|M|d|n|D|z| Unalloc/Rsrvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Each one of the bits T, s, m, M, d, n, D and z is associated with one option, where the option is included if and only if the respective bit is set. Included options MUST be in the same order as these bits are listed. The bits denote the following options:
位T、s、m、m、d、n、d和z中的每一个与一个选项相关联，其中当且仅当设置了相应位时才包括该选项。包含的选项必须与列出的这些位的顺序相同。位表示以下选项：
bit Option
----- ------------------------
T Transit Oif-List Count
s Stub Oif-List Count
m Minimum Speed Link
M Maximum Speed Link
d Domain Count
n Node Count
D Diameter Count
z TZ Count
bit Option
----- ------------------------
T Transit Oif-List Count
s Stub Oif-List Count
m Minimum Speed Link
M Maximum Speed Link
d Domain Count
n Node Count
D Diameter Count
z TZ Count
See Section 3.1 for details on the different options. The unallocated bits are reserved. Any unknown bits MUST be set to 0 when a message is sent, and treated as 0 (ignored) when received. This means that unknown options that are denoted by unknown bits are ignored.
有关不同选项的详细信息，请参见第3.1节。未分配的位是保留的。发送消息时，任何未知位都必须设置为0，接收消息时，必须将其视为0（忽略）。这意味着忽略由未知位表示的未知选项。
By using this bitmap we can specify at most 16 options. If there becomes a need for more than 16 options, one can define a new option that contains a bitmap that can then be used to specify which further options are present. The last bit in the current bitmap could be used for that option. However, the exact definition of this is left for future documents.
通过使用此位图，我们最多可以指定16个选项。如果需要超过16个选项，可以定义一个包含位图的新选项，该位图可用于指定存在哪些其他选项。当前位图中的最后一位可用于该选项。但是，这一点的确切定义将留待将来的文档使用。
Options: This field contains options. Which options are present is determined by the flag bits. As new flags and options may be defined in the future, any unknown/reserved flags MUST be ignored, and any additional trailing options MUST be ignored. See Section 3.1 for details on the options defined in this document.
选项：此字段包含选项。存在哪些选项由标志位决定。由于将来可能会定义新的标志和选项，因此必须忽略任何未知/保留标志，并且必须忽略任何附加的后续选项。有关本文件中定义的选项的详细信息，请参见第3.1节。
There are several options defined in this document. For each option, there is also a related flag that shows whether the option is present. See the Options Bitmap above for a list of the options and their respective bits. Each option has a fixed size. Note that there are no alignment requirements for the options, so an implementation cannot assume they are aligned.
本文档中定义了几个选项。对于每个选项，还有一个相关标志，显示该选项是否存在。有关选项及其各自位的列表，请参见上面的选项位图。每个选项都有一个固定的大小。请注意，选项没有对齐要求，因此实现不能假定它们是对齐的。
Transit Oif-List Count: This is filled in by a router sending a Join/Prune message indicating the number of transit links on the multicast distribution tree. The value is the number of oifs (outgoing interfaces) for the multicast route that have been joined by PIM plus the sum of the values advertised by each of the downstream PIM routers that have joined on this oif. Length is 4 octets.
Transit Oif List Count（传输Oif列表计数）：由路由器发送一条连接/删除消息来填写，该消息指示多播分发树上传输链路的数量。该值是已由PIM加入的多播路由的oif（传出接口）数加上已加入该oif的每个下游PIM路由器公布的值之和。长度为4个八位字节。
Stub Oif-List Count: This is filled in by a router sending a Join/ Prune message indicating the number of stub links (links where there are host members) on the multicast distribution tree. The value is the number of oifs for the multicast route that have been joined by IGMP or MLD plus the sum of the values advertised by each of the downstream PIM routers that have joined on this oif. Length is 4 octets.
存根Oif列表计数：这是由路由器发送的加入/删减消息填写的，该消息指示多播分发树上存根链接（有主机成员的链接）的数量。该值是IGMP或MLD已加入的多播路由的oif数加上已加入该oif的每个下游PIM路由器公布的值之和。长度为4个八位字节。
Minimum Speed Link: This contains the minimum bandwidth rate for any link in the oif-list and is encoded as specified in Section 3.1.1. The sender of a Join/Prune message takes the minimum value for each link in the oif-list for the multicast route. If this value is less than the value stored for the multicast route (the smallest value received from downstream joiners), then the value should be reset and sent in a Join/Prune message. Otherwise, the value should remain unchanged. This, together with the Maximum
最小速度链路：包含oif列表中任何链路的最小带宽速率，并按照第3.1.1节的规定进行编码。Join/Prune消息的发送方为多播路由的oif列表中的每个链接获取最小值。如果该值小于为多播路由存储的值（从下游加入者接收的最小值），则应重置该值并在加入/删除消息中发送。否则，该值应保持不变。这个，加上最大
Speed Link option, provides a way to obtain the lowest- and highest-speed links for the multicast distribution tree. Length is 2 octets.
Speed Link（速度链接）选项提供了一种为多播分发树获取最低和最高速度链接的方法。长度为2个八位字节。
Maximum Speed Link: This contains the maximum bandwidth rate for any link in the oif-list and is encoded as specified in Section 3.1.1. The sender of a Join/Prune message takes the maximum value for each link in the oif-list for the multicast route. If this value is greater than the value stored for the multicast route (the largest value received from downstream joiners), then the value should be reset and sent in a Join/Prune message. Otherwise, the value should remain unchanged. This, together with the Minimum Speed Link option, provides a way to obtain the lowest- and highest-speed links for the multicast distribution tree. Length is 2 octets.
最大速度链路：包含oif列表中任何链路的最大带宽速率，并按照第3.1.1节的规定进行编码。Join/Prune消息的发送方为多播路由的oif列表中的每个链接获取最大值。如果该值大于为多播路由存储的值（从下游加入者接收到的最大值），则应重置该值并在加入/删除消息中发送。否则，该值应保持不变。这与最低速度链路选项一起，提供了一种为多播分发树获取最低和最高速度链路的方法。长度为2个八位字节。
Domain Count: This indicates the number of routing domains the distribution tree traverses. A router should increment this value if it is sending a Join/Prune message over a link that traverses a domain boundary. For this to work, an implementation needs a way of knowing that a neighbor or an interface is in a different domain. There is no standard way of doing this. Length is 1 octet.
域计数：这表示分发树遍历的路由域数。如果路由器通过穿越域边界的链路发送连接/删除消息，则应增加此值。要使其工作，实现需要知道邻居或接口位于不同的域中。没有标准的方法可以做到这一点。长度为1个八位组。
Node Count: This indicates the number of routers on the distribution tree. Each router will sum up all the Node Counts from all joiners on all oifs and increment by 1 before including this value in the Join/Prune message. Length is 1 octet.
节点计数：表示分发树上的路由器数量。每个路由器将汇总所有OIF上所有Joiner的所有节点计数，并在将该值包含在Join/Prune消息中之前递增1。长度为1个八位组。
Diameter Count: This indicates the longest length of any given branch of the tree in router hops. Each router that sends a Join increments the max value received by all downstream joiners by 1. Length is 1 octet.
直径计数：这表示路由器跳数中树的任何给定分支的最长长度。每个发送连接的路由器将所有下游连接收到的最大值增加1。长度为1个八位组。
TZ Count: This indicates the number of time zones the distribution tree traverses. A router should increment this value if it is sending a Join/Prune message over a link that traverses a time zone. This can be a configured link attribute, or using other means to determine the time zone is acceptable. Length is 1 octet.
TZ计数：这表示分发树所经过的时区数。如果路由器通过穿越时区的链路发送连接/删除消息，则应增加此值。这可以是已配置的链接属性，也可以使用其他方法来确定时区是否可接受。长度为1个八位组。
The speed is encoded using 2 octets as follows:
使用2个八位字节对速度进行编码，如下所示：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Exponent | Significand |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Exponent | Significand |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Using this format, the speed of the link is Significand * 10 ^ Exponent kbps. This allows specifying link speeds with up to 3 decimal digits precision and speeds from 1 kbps to 10 ^ 67 kbps. A computed speed of 0 kbps means the link speed is < 1 kbps.
使用此格式，链接速度为有效位*10^指数kbps。这允许指定高达3位小数精度的链路速度，以及从1 kbps到10^67 kbps的速度。计算速度为0 kbps意味着链路速度小于1 kbps。
Here are some examples of how this is used:
以下是一些如何使用的示例：
Link Speed Exponent Significand
------------ ---------- -------------
500 kbps 0 500
500 kbps 2 5
155 Mbps 3 155
40 Gpbs 6 40
100 Gpbs 6 100
100 Gpbs 8 1
Link Speed Exponent Significand
------------ ---------- -------------
500 kbps 0 500
500 kbps 2 5
155 Mbps 3 155
40 Gpbs 6 40
100 Gpbs 6 100
100 Gpbs 8 1
Here, we will give a few examples to illustrate the use of flags and options.
这里，我们将给出几个示例来说明标志和选项的使用。
A minimum-size message has no option flags set and looks like this:
最小大小消息未设置选项标志，如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|E| Attr_Type | Length = 6 | Effective MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unalloc/Reserved |P|a|t|A|S|0|0|0|0|0|0|0|0| Unalloc/Rsrvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|E| Attr_Type | Length = 6 | Effective MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unalloc/Reserved |P|a|t|A|S|0|0|0|0|0|0|0|0| Unalloc/Rsrvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A message containing all the options defined in this document would look like this:
包含此文档中定义的所有选项的消息如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|E| Attr_Type | Length = 18 | Effective MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unalloc/Reserved |P|a|t|A|S|1|1|1|1|1|1|1|1| Unalloc/Rsrvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transit Oif-List Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stub Oif-List Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Speed Link | Maximum Speed Link |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain Count | Node Count | Diameter Count| TZ Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|E| Attr_Type | Length = 18 | Effective MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unalloc/Reserved |P|a|t|A|S|1|1|1|1|1|1|1|1| Unalloc/Rsrvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transit Oif-List Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stub Oif-List Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Speed Link | Maximum Speed Link |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain Count | Node Count | Diameter Count| TZ Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A message containing only Stub Oif-List Count and Node Count would look like this:
仅包含存根Oif列表计数和节点计数的消息如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|E| Attr_Type | Length = 9 | Effective MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unalloc/Reserved |P|a|t|A|S|0|1|0|0|0|1|0|0| Unalloc/Rsrvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stub Oif-List Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node count |
+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|E| Attr_Type | Length = 9 | Effective MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unalloc/Reserved |P|a|t|A|S|0|1|0|0|0|1|0|0| Unalloc/Rsrvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stub Oif-List Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node count |
+-+-+-+-+-+-+-+-+
A router supporting this mechanism MUST, unless administratively disabled, include the PIM Join Attribute option in its PIM Hellos. See [RFC5384] and "PIM-Hello Options" on [PIM-REG] for details.
支持此机制的路由器必须在其PIM hello中包含PIM Join属性选项，除非被管理禁用。有关详细信息，请参阅[PIM-REG]上的[RFC5384]和“PIM Hello Options”。
It is RECOMMENDED that implementations allow for administrative control of whether to make use of this mechanism. Implementations MAY also allow further control of what information to store and send upstream.
建议实现允许对是否使用此机制进行管理控制。实现还允许进一步控制向上游存储和发送哪些信息。
It is very important to note that any changes to the values maintained by this mechanism MUST NOT trigger a new Join/Prune message. Due to the periodic nature of PIM, the values can be accurately obtained at 1-minute intervals (or whatever Join/Prune interval used).
请务必注意，对该机制维护的值所做的任何更改都不得触发新的加入/删除消息。由于PIM的周期性，可以以1分钟的间隔（或使用的任何连接/删除间隔）准确获取值。
When a router removes a link from an oif-list, it needs to be able to reevaluate the values that it will advertise upstream. This happens when an oif-list entry is timed out or a Prune is received.
当路由器从oif列表中删除链接时，它需要能够重新评估它将在上游公布的值。当oif列表条目超时或收到修剪时，会发生这种情况。
It is RECOMMENDED that the Join Attribute defined in this document be used only for entries in the join-list part of the Join/Prune message. If the attribute is used in the prune-list, an implementation MUST ignore it and process the Prune as if the attribute were not present.
建议仅将本文档中定义的联接属性用于联接/修剪消息的联接列表部分中的条目。如果在修剪列表中使用了该属性，则实现必须忽略该属性，并像不存在该属性一样处理修剪。
It is also RECOMMENDED that join suppression be disabled on a LAN when Pop-Count is used.
当使用Pop计数时，还建议在LAN上禁用连接抑制。
It is RECOMMENDED that, when triggered Join/Prune messages are sent by a downstream router, the accounting information not be included in the message. This way, when convergence is important, avoiding the processing time to build an accounting record in a downstream router and processing time to parse the message in the upstream router will help reduce convergence time. If an upstream router receives a Join/ Prune message with no accounting data, it SHOULD NOT interpret the message as a trigger to clear or reset the accounting data it has cached.
建议在下游路由器发送触发的加入/删除消息时，不要在消息中包含记帐信息。这样，当收敛非常重要时，避免在下游路由器中建立记帐记录的处理时间和在上游路由器中解析消息的处理时间将有助于减少收敛时间。如果上游路由器接收到没有记帐数据的加入/删减消息，则不应将该消息解释为清除或重置其缓存的记帐数据的触发器。
This section offers some non-normative suggestions for how Pop-Count may be implemented.
本节提供了一些关于如何实施流行音乐计数的非规范性建议。
An implementation can decide how the accounting attributes are maintained. The values can be stored as part of the multicast route data structure by combining the local information it has with the joined information on a per-oif basis. So, when it is time to send a Join/Prune message, the values stored in the multicast route can be copied to the message.
实现可以决定如何维护记帐属性。这些值可以作为多播路由数据结构的一部分存储，方法是在每个oif的基础上将其拥有的本地信息与加入的信息相结合。因此，当发送加入/删除消息时，可以将存储在多播路由中的值复制到消息中。
Or, an implementation could store the accounting values per oif and, when a Join/Prune message is sent, it can combine the oifs with its local information. Then, the combined information can be copied to the message.
或者，实现可以存储每个oif的记帐值，并且在发送连接/删除消息时，可以将oif与其本地信息结合起来。然后，可以将组合信息复制到消息中。
When a downstream joiner stops joining, accounting values cached must be evaluated. There are two approaches that can be taken. One is to keep values learned from each joiner, so when the joiner goes away, the count/max/min values are known and the combined value can be adjusted. The other approach is to set the value to 0 for the oif, and then start accumulating new values as subsequent Joins are received.
当下游joiner停止连接时，必须计算缓存的记帐值。可以采取两种方法。一种是保持从每个joiner学习到的值，这样当joiner离开时，count/max/min值是已知的，并且可以调整组合值。另一种方法是将oif的值设置为0，然后在接收后续联接时开始累积新值。
The same issue arises when an oif is removed from the oif-list. Keeping per-oif values allows you to adjust the per-route values when an oif goes away. Or, alternatively, a delay for reporting the new set a values from the route can occur while all oif values are zeroed (where accumulation of new values from subsequent Joins cause repopulation of values and a new max/min/count can be reevaluated for the route).
当oif从oif列表中删除时，也会出现同样的问题。保留每oif值允许您在oif消失时调整每路线值。或者，当所有oif值归零时，可能会发生从路由报告新集合a值的延迟（其中，来自后续连接的新值的累积会导致重新填充值，并且可以重新评估路由的新最大/最小/计数）。
This specification requires each router on a multicast distribution tree to support this specification or else the accounting attributes for the tree will not be known.
此规范要求多播分发树上的每个路由器都支持此规范，否则树的记帐属性将未知。
However, if there is a contiguous set of routers downstream in the distribution tree, they can maintain accounting information for the sub-tree.
但是，如果分发树下游有一组连续的路由器，它们可以维护子树的记帐信息。
If there is a set of contiguous routers supporting this specification upstream on the multicast distribution tree, accounting information will be available, but it will not represent an accurate assessment of the entire tree. Also, it will not be clear how much of the distribution tree the accounting information covers.
如果在多播分发树的上游有一组支持此规范的连续路由器，则会计信息将可用，但它不能代表对整个树的准确评估。此外，还不清楚会计信息覆盖了多少分布树。
A new PIM-Hello Option type, 29, has been assigned by IANA. Although the length is specified as 0 in this specification, non-zero length is allowed, so IANA has listed the length as being variable.
IANA分配了一个新的PIM Hello选项类型29。尽管在本规范中长度指定为0，但允许非零长度，因此IANA将长度列为变量。
A new PIM Join Attribute type, 3, has been assigned by IANA.
IANA分配了一个新的PIM连接属性类型3。
The use of this specification requires some additional processing of PIM Join/Prune messages. However, the additional amount of processing is fairly limited, so this is not believed to be a significant concern.
使用此规范需要对PIM加入/删除消息进行一些额外的处理。然而，额外的处理量是相当有限的，因此不认为这是一个重大问题。
The use of this mechanism includes information like the number of receivers. This information is assumed to not be of a sensitive nature. If an operator has concerns about revealing this information to upstream routers or other routers/hosts that may potentially inspect this information, there should be a way to disable the mechanism or, alternatively, more detailed control of what information to include.
该机制的使用包括接收器数量等信息。假定该信息不具有敏感性质。如果运营商担心向可能检查此信息的上游路由器或其他路由器/主机透露此信息，则应该有一种方法来禁用该机制，或者更详细地控制要包含的信息。
The authors would like to thank John Zwiebel, Amit Jain, and Clayton Wagar for their review comments on the initial versions of this document. Adrian Farrel did a detailed review of the document and proposed textual changes that have been incorporated. Further review and comments were provided by Thomas Morin and Zhaohui (Jeffrey) Zhang.
作者感谢John Zwiebel、Amit Jain和Clayton Wagar对本文件初始版本的评论。阿德里安·法雷尔（Adrian Farrel）对该文件进行了详细审查，并提出了已纳入的文本修改建议。Thomas Morin和赵辉（Jeffrey）Zhang提供了进一步的审查和评论。
[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月。
[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月。
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007.
[RFC5015]Handley，M.，Kouvelas，I.，Speakman，T.，和L.Vicisano，“双向协议独立多播（BIDIR-PIM）”，RFC 50152007年10月。
[RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol Independent Multicast (PIM) Join Attribute Format", RFC 5384, November 2008.
[RFC5384]Boers，A.，Wijnands，I.，和E.Rosen，“协议独立多播（PIM）连接属性格式”，RFC 5384，2008年11月。
[AMT] Bumgardner, G., "Automatic Multicast Tunneling", Work in Progress, June 2012.
[AMT]Bumgardner，G.，“自动多播隧道”，正在进行的工作，2012年6月。
[PIM-REG] IANA, "Protocol Independent Multicast (PIM) Parameters", <http://www.iana.org/assignments/pim-parameters>.
[PIM-REG]IANA，“协议独立多播（PIM）参数”<http://www.iana.org/assignments/pim-parameters>.
Authors' Addresses
作者地址
Dino Farinacci Cisco Systems Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞市塔斯曼大道迪诺·法里纳奇思科系统公司，邮编95134
EMail: dino@cisco.com
EMail: dino@cisco.com
Greg Shepherd Cisco Systems Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞市塔斯曼大道格雷格·谢泼德思科系统公司，邮编95134
EMail: gjshep@gmail.com
EMail: gjshep@gmail.com
Stig Venaas Cisco Systems Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞市塔斯曼大道Stig Venaas思科系统公司，邮编95134
EMail: stig@cisco.com
EMail: stig@cisco.com
Yiqun Cai Microsoft 1065 La Avenida Mountain View, CA 94043 USA
美国加利福尼亚州拉阿维尼达山景大道1065号益群蔡微软公司，邮编94043
EMail: yiqunc@microsoft.com
EMail: yiqunc@microsoft.com