Internet Engineering Task Force (IETF) O. Dornon
Request for Comments: 8220 J. Kotalwar
Category: Informational V. Hemige
ISSN: 2070-1721 Nokia
R. Qiu
mistnet.io
Z. Zhang
Juniper Networks, Inc.
September 2017
Internet Engineering Task Force (IETF) O. Dornon
Request for Comments: 8220 J. Kotalwar
Category: Informational V. Hemige
ISSN: 2070-1721 Nokia
R. Qiu
mistnet.io
Z. Zhang
Juniper Networks, Inc.
September 2017
Protocol Independent Multicast (PIM) over Virtual Private LAN Service (VPLS)
虚拟专用LAN服务（VPLS）上的协议独立多播（PIM）
Abstract
摘要
This document describes the procedures and recommendations for Virtual Private LAN Service (VPLS) Provider Edges (PEs) to facilitate replication of multicast traffic to only certain ports (behind which there are interested Protocol Independent Multicast (PIM) routers and/or Internet Group Management Protocol (IGMP) hosts) via PIM snooping and proxying.
本文档描述了虚拟专用LAN服务（VPLS）提供商边缘（PEs）的程序和建议，以促进仅将多播通信量复制到某些端口（其后面有相关的协议独立多播（PIM）路由器和/或Internet组管理协议（IGMP）主机）通过PIM窥探和代理。
With PIM snooping, PEs passively listen to certain PIM control messages to build control and forwarding states while transparently flooding those messages. With PIM proxying, PEs do not flood PIM Join/Prune messages but only generate their own and send them out of certain ports, based on the control states built from downstream Join/Prune messages. PIM proxying is required when PIM Join suppression is enabled on the Customer Edge (CE) devices and is useful for reducing PIM control traffic in a VPLS domain.
通过PIM窥探，PEs被动地侦听某些PIM控制消息，以建立控制和转发状态，同时透明地淹没这些消息。通过PIM代理，PEs不会泛滥PIM加入/删减消息，而是根据从下游加入/删减消息生成的控制状态，生成自己的消息并从某些端口发送出去。当在客户边缘（CE）设备上启用PIM连接抑制时，需要PIM代理，这有助于减少VPLS域中的PIM控制流量。
This document also describes PIM relay, which can be viewed as lightweight proxying, where all downstream Join/Prune messages are simply forwarded out of certain ports and are not flooded, thereby avoiding the triggering of PIM Join suppression on CE devices.
本文档还描述了PIM中继，可将其视为轻量级代理，其中所有下游加入/删减消息仅从某些端口转发出去，不会被淹没，从而避免触发CE设备上的PIM加入抑制。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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 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/rfc8220.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8220.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 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 ....................................................4
1.1. Multicast Snooping in VPLS .................................5
1.2. Assumptions ................................................6
1.3. Definitions ................................................6
1.4. Requirements Language ......................................7
2. PIM Snooping for VPLS ...........................................7
2.1. PIM Protocol Background ....................................7
2.2. General Rules for PIM Snooping in VPLS .....................8
2.2.1. Preserving Assert Triggers ..........................8
2.3. Some Considerations for PIM Snooping .......................9
2.3.1. Scaling .............................................9
2.3.2. IPv4 and IPv6 ......................................10
2.3.3. PIM-SM (*,*,RP) ....................................10
1. Introduction ....................................................4
1.1. Multicast Snooping in VPLS .................................5
1.2. Assumptions ................................................6
1.3. Definitions ................................................6
1.4. Requirements Language ......................................7
2. PIM Snooping for VPLS ...........................................7
2.1. PIM Protocol Background ....................................7
2.2. General Rules for PIM Snooping in VPLS .....................8
2.2.1. Preserving Assert Triggers ..........................8
2.3. Some Considerations for PIM Snooping .......................9
2.3.1. Scaling .............................................9
2.3.2. IPv4 and IPv6 ......................................10
2.3.3. PIM-SM (*,*,RP) ....................................10
2.4. PIM Snooping vs. PIM Proxying .............................10
2.4.1. Differences between PIM Snooping, Relay,
and Proxying .......................................10
2.4.2. PIM Control Message Latency ........................11
2.4.3. When to Snoop and When to Proxy ....................12
2.5. Discovering PIM Routers ...................................13
2.6. PIM-SM and PIM-SSM ........................................14
2.6.1. Building PIM-SM States .............................15
2.6.2. Explanation for Per-(S,G,N) States .................17
2.6.3. Receiving (*,G) PIM-SM Join/Prune Messages .........18
2.6.4. Receiving (S,G) PIM-SM Join/Prune Messages .........20
2.6.5. Receiving (S,G,rpt) Join/Prune Messages ............22
2.6.6. Sending Join/Prune Messages Upstream ...............23
2.7. Bidirectional PIM (BIDIR-PIM) .............................24
2.8. Interaction with IGMP Snooping ............................24
2.9. PIM-DM ....................................................25
2.9.1. Building PIM-DM States .............................25
2.9.2. PIM-DM Downstream Per-Port PIM(S,G,N) State
Machine ............................................25
2.9.3. Triggering Assert Election in PIM-DM ...............26
2.10. PIM Proxy ................................................26
2.10.1. Upstream PIM Proxy Behavior .......................26
2.11. Directly Connected Multicast Source ......................26
2.12. Data-Forwarding Rules ....................................27
2.12.1. PIM-SM Data-Forwarding Rules ......................28
2.12.2. PIM-DM Data-Forwarding Rules ......................29
3. IANA Considerations ............................................29
4. Security Considerations ........................................30
5. References .....................................................30
5.1. Normative References ......................................30
5.2. Informative References ....................................31
Appendix A. BIDIR-PIM Considerations ..............................32
A.1. BIDIR-PIM Data-Forwarding Rules ............................32
Appendix B. Example Network Scenario ..............................33
B.1. PIM Snooping Example .......................................33
B.2. PIM Proxy Example with (S,G) / (*,G) Interaction ...........36
Acknowledgements ..................................................42
Contributors ......................................................42
Authors' Addresses ................................................43
2.4. PIM Snooping vs. PIM Proxying .............................10
2.4.1. Differences between PIM Snooping, Relay,
and Proxying .......................................10
2.4.2. PIM Control Message Latency ........................11
2.4.3. When to Snoop and When to Proxy ....................12
2.5. Discovering PIM Routers ...................................13
2.6. PIM-SM and PIM-SSM ........................................14
2.6.1. Building PIM-SM States .............................15
2.6.2. Explanation for Per-(S,G,N) States .................17
2.6.3. Receiving (*,G) PIM-SM Join/Prune Messages .........18
2.6.4. Receiving (S,G) PIM-SM Join/Prune Messages .........20
2.6.5. Receiving (S,G,rpt) Join/Prune Messages ............22
2.6.6. Sending Join/Prune Messages Upstream ...............23
2.7. Bidirectional PIM (BIDIR-PIM) .............................24
2.8. Interaction with IGMP Snooping ............................24
2.9. PIM-DM ....................................................25
2.9.1. Building PIM-DM States .............................25
2.9.2. PIM-DM Downstream Per-Port PIM(S,G,N) State
Machine ............................................25
2.9.3. Triggering Assert Election in PIM-DM ...............26
2.10. PIM Proxy ................................................26
2.10.1. Upstream PIM Proxy Behavior .......................26
2.11. Directly Connected Multicast Source ......................26
2.12. Data-Forwarding Rules ....................................27
2.12.1. PIM-SM Data-Forwarding Rules ......................28
2.12.2. PIM-DM Data-Forwarding Rules ......................29
3. IANA Considerations ............................................29
4. Security Considerations ........................................30
5. References .....................................................30
5.1. Normative References ......................................30
5.2. Informative References ....................................31
Appendix A. BIDIR-PIM Considerations ..............................32
A.1. BIDIR-PIM Data-Forwarding Rules ............................32
Appendix B. Example Network Scenario ..............................33
B.1. PIM Snooping Example .......................................33
B.2. PIM Proxy Example with (S,G) / (*,G) Interaction ...........36
Acknowledgements ..................................................42
Contributors ......................................................42
Authors' Addresses ................................................43
In the Virtual Private LAN Service (VPLS), the Provider Edge (PE) devices provide a logical interconnect such that Customer Edge (CE) devices belonging to a specific VPLS instance appear to be connected by a single LAN. The Forwarding Information Base (FIB) for a VPLS instance is populated dynamically by Media Access Control (MAC) address learning. Once a unicast MAC address is learned and associated with a particular Attachment Circuit (AC) or pseudowire (PW), a frame destined to that MAC address only needs to be sent on that AC or PW.
在虚拟专用LAN服务（VPLS）中，提供商边缘（PE）设备提供逻辑互连，使得属于特定VPLS实例的客户边缘（CE）设备似乎由单个LAN连接。VPLS实例的转发信息库（FIB）由媒体访问控制（MAC）地址学习动态填充。一旦单播MAC地址被读入并与特定连接电路（AC）或伪线（PW）相关联，就只需要在该AC或PW上发送目的地为该MAC地址的帧。
For a frame not addressed to a known unicast MAC address, flooding has to be used. This happens with the following so-called "BUM" (Broadcast, Unknown Unicast, and Multicast) traffic:
对于未寻址到已知单播MAC地址的帧，必须使用泛洪。这种情况发生在以下所谓的“BUM”（广播、未知单播和多播）流量中：
o B: The destination MAC address is a broadcast address.
o B:目标MAC地址是广播地址。
o U: The destination MAC address is unknown (has not been learned).
o U：目标MAC地址未知（尚未读入）。
o M: The destination MAC address is a multicast address.
o M：目标MAC地址是一个多播地址。
Multicast frames are flooded because a PE cannot know where corresponding multicast group members reside. VPLS solutions (RFC 4762 [VPLS-LDP] and RFC 4761 [VPLS-BGP]) perform replication for multicast traffic at the ingress PE devices. As stated in the VPLS Multicast Requirements document (RFC 5501 [VPLS-MCAST-REQ]), there are two issues with VPLS multicast today:
多播帧被淹没，因为PE无法知道相应的多播组成员所在的位置。VPLS解决方案（RFC 4762[VPLS-LDP]和RFC 4761[VPLS-BGP]）在入口PE设备上执行多播流量复制。正如VPLS多播要求文件（RFC 5501[VPLS-MCAST-REQ]）中所述，目前VPLS多播存在两个问题：
1. Multicast traffic is replicated to non-member sites.
1. 多播通信被复制到非成员站点。
2. Multicast traffic may be replicated when several PWs share a physical path.
2. 当多个PW共享一条物理路径时，可以复制多播流量。
Issue 1 can be solved by multicast snooping -- PEs learn sites with multicast group members by snooping multicast protocol control messages on ACs and forward IP multicast traffic only to member sites. This document describes the procedures to achieve this when CE devices are PIM adjacencies of each other. Issue 2 is outside the scope of this document and is discussed in RFC 7117 [VPLS-MCAST].
问题1可以通过多播嗅探解决——PEs通过嗅探ACs上的多播协议控制消息来学习具有多播组成员的站点，并仅将IP多播流量转发给成员站点。本文件描述了当CE设备彼此为PIM邻接时实现这一点的程序。问题2不在本文件范围内，RFC 7117[VPLS-MCAST]对此进行了讨论。
While descriptions in this document are in the context of the VPLS, the procedures also apply to regular Layer 2 switches interconnected by physical connections, except that the PW-related concepts and procedures do not apply in that case.
虽然本文档中的描述是在VPLS的上下文中进行的，但这些程序也适用于通过物理连接互连的常规第2层交换机，除非PW相关概念和程序不适用于这种情况。
IGMP snooping procedures described in RFC 4541 [IGMP-SNOOP] make sure that IP multicast traffic is only sent on the following:
RFC 4541[IGMP-SNOOP]中描述的IGMP侦听程序确保IP多播流量仅在以下情况下发送：
o ACs connecting to hosts that report related group membership
o 连接到报告相关组成员身份的主机的ACs
o ACs connecting to routers that join related multicast groups
o 连接到加入相关多播组的路由器的ACs
o PWs connecting to remote PEs that have the above-described ACs
o PWs连接到具有上述ACs的远程PEs
Note that traffic is always sent on ports that have point-to-point connections to routers that are attached to a LAN on which there is at least one other router. Because IGMP snooping alone cannot determine if there are interested receivers beyond those routers, we always need to send traffic to these ports, even if there are no snooped group memberships. To further restrict traffic sent to those routers, PIM snooping can be used. This document describes the procedures for PIM snooping, including rules for when both IGMP and PIM snooping are enabled in a VPLS instance; see Sections 2.8 and 2.11 for details.
请注意，流量始终在与连接到至少有一个其他路由器的LAN的路由器具有点对点连接的端口上发送。因为IGMP窥探无法单独确定这些路由器之外是否有感兴趣的接收器，所以我们始终需要向这些端口发送流量，即使没有窥探组成员身份。为了进一步限制发送到这些路由器的流量，可以使用PIM窥探。本文档描述了PIM窥探的过程，包括在VPLS实例中同时启用IGMP和PIM窥探的规则；详见第2.8节和第2.11节。
Note that for both IGMP and PIM, the term "snooping" is used loosely, referring to the fact that a Layer 2 device peeks into Layer 3 routing protocol messages to build relevant control and forwarding states. Depending on whether the control messages are transparently flooded, selectively forwarded, or aggregated, the processing may be called "snooping" or "proxying" in different contexts.
注意，对于IGMP和PIM，术语“窥探”使用得比较松散，指的是第2层设备窥视第3层路由协议消息以建立相关控制和转发状态的事实。取决于控制消息是透明地被淹没、选择性地转发还是聚合，处理在不同上下文中可以称为“窥探”或“代理”。
We will use the term "PIM snooping" in this document; however, unless explicitly noted otherwise, the procedures apply equally to PIM snooping and PIM proxying. The procedures specific to PIM proxying are described in Section 2.6.6. Differences that need to be observed while implementing one or the other and recommendations on which method to employ in different scenarios are noted in Section 2.4.
我们将在本文件中使用术语“PIM窥探”；但是，除非另有明确说明，否则这些程序同样适用于PIM窥探和PIM代理。第2.6.6节描述了PIM代理的具体程序。第2.4节指出了在实施一种或另一种方案时需要注意的差异以及在不同方案中采用哪种方法的建议。
This document also describes PIM relay, which can be viewed as lightweight PIM proxying. Unless explicitly noted otherwise, in the rest of this document proxying implicitly includes relay as well. Please refer to Section 2.4.1 for an overview of the differences between snooping, proxying, and relay.
本文档还介绍了PIM继电器，可将其视为轻量级PIM代理。除非另有明确说明，否则在本文档的其余部分中，代理也隐式包括中继。请参阅第2.4.1节，了解窥探、代理和中继之间的差异概述。
This document assumes that the reader has a good understanding of the PIM protocols. To help correlate the concepts and make the text easier to follow, this document is written in the same style as the following PIM RFCs:
本文档假设读者对PIM协议有很好的理解。为了帮助关联概念并使文本更易于理解，本文档采用与以下PIM RFC相同的样式编写：
o RFC 3973 [PIM-DM]
o RFC 3973[PIM-DM]
o RFC 4607 [PIM-SSM]
o RFC 4607[PIM-SSM]
o RFC 5015 [BIDIR-PIM]
o RFC 5015[BIDIR-PIM]
o RFC 5384 [JOIN-ATTR]
o RFC 5384[JOIN-ATTR]
o RFC 7761 [PIM-SM]
o RFC 7761[PIM-SM]
In order to avoid replicating text related to PIM protocol handling from the PIM RFCs, this document cross-references corresponding definitions and procedures in those RFCs. Deviations in protocol handling specific to PIM snooping are specified in this document.
为了避免从PIM RFC复制与PIM协议处理相关的文本，本文件交叉引用了这些RFC中的相应定义和程序。本文件规定了特定于PIM窥探的协议处理偏差。
There are several definitions referenced in this document that are well described in the following PIM RFCs: RFC 3973 [PIM-DM], RFC 5015 [BIDIR-PIM], and RFC 7761 [PIM-SM]. The following definitions and abbreviations are used throughout this document:
本文件中引用的几个定义在以下PIM RFC中有详细描述：RFC 3973[PIM-DM]、RFC 5015[BIDIR-PIM]和RFC 7761[PIM-SM]。本文件中使用了以下定义和缩写：
o A port is defined as either an AC or a PW.
o 端口定义为AC或PW。
o When we say that a PIM message is received on a PE port, it means that the PE is processing the message for snooping/proxying or relaying.
o 当我们说在PE端口上接收到PIM消息时，这意味着PE正在处理该消息以进行监听/代理或中继。
Abbreviations used in this document:
本文件中使用的缩写：
o S: IP address of the multicast source.
o S：多播源的IP地址。
o G: IP address of the multicast group.
o G：多播组的IP地址。
o N: Upstream Neighbor field in a Join/Prune/Graft message.
o N：加入/修剪/嫁接消息中的上游邻居字段。
o Port(N): Port on which neighbor N is learned, i.e., the port on which N's Hellos are received.
o 端口（N）：学习邻居N的端口，即接收N的Hello的端口。
o rpt: Rendezvous Point Tree.
o 会合点树。
o PIM-DM: Protocol Independent Multicast - Dense Mode.
o PIM-DM：协议独立多播-密集模式。
o PIM-SM: Protocol Independent Multicast - Sparse Mode.
o PIM-SM：协议独立多播-稀疏模式。
o PIM-SSM: Protocol Independent Multicast - Source-Specific Multicast.
o PIM-SSM：协议独立多播-源特定多播。
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]所述进行解释。
PIM is a multicast routing protocol running between routers, which are CE devices in a VPLS. It uses the unicast routing table to provide reverse-path information for building multicast trees. There are a few variants of PIM. As described in RFC 3973 [PIM-DM], multicast datagrams are pushed towards downstream neighbors, similar to a broadcast mechanism, but in areas of the network where there are no group members, routers prune back branches of the multicast tree towards the source. Unlike PIM-DM, other PIM flavors (RFC 7761 [PIM-SM], RFC 4607 [PIM-SSM], and RFC 5015 [BIDIR-PIM]) employ a pull methodology via explicit Joins instead of the push-and-prune technique.
PIM是在路由器（VPLS中的CE设备）之间运行的多播路由协议。它使用单播路由表为构建多播树提供反向路径信息。PIM有几种变体。如RFC 3973[PIM-DM]中所述，多播数据报被推送到下游邻居，类似于广播机制，但在网络中没有组成员的区域，路由器将多播树的分支向后修剪到源。与PIM-DM不同，其他PIM风格（RFC 7761[PIM-SM]、RFC 4607[PIM-SSM]和RFC 5015[BIDIR-PIM]）通过显式连接而不是推和修剪技术采用拉方法。
PIM routers periodically exchange Hello messages to discover and maintain stateful sessions with neighbors. After neighbors are discovered, PIM routers can signal their intentions to join or prune specific multicast groups. This is accomplished by having downstream routers send an explicit Join/Prune message (for the sake of generalization, consider Graft messages for PIM-DM as Join messages) to their corresponding upstream router. The Join/Prune message can be group specific (*,G) or group and source specific (S,G).
PIM路由器定期交换Hello消息，以发现和维护与邻居的有状态会话。发现邻居后，PIM路由器可以发出信号，表明其加入或删除特定多播组的意图。这是通过下游路由器发送显式连接/修剪消息（为了泛化，考虑将PIM-DM作为连接消息的移植消息）到它们对应的上游路由器。加入/删除消息可以是特定于组的（*，G），也可以是特定于组和源的（S，G）。
The following rules for the correct operation of PIM snooping MUST be followed.
必须遵循以下正确操作PIM窥探的规则。
o PIM snooping MUST NOT affect the operation of customer Layer 2 protocols or Layer 3 protocols.
o PIM窥探不得影响客户第2层协议或第3层协议的运行。
o PIM messages and multicast data traffic forwarded by PEs MUST follow the split-horizon rule for mesh PWs, as defined in RFC 4762 [VPLS-LDP].
o PEs转发的PIM消息和多播数据流量必须遵循RFC 4762[VPLS-LDP]中定义的网状PWs的分割地平线规则。
o PIM states in a PE MUST be per VPLS instance.
o PE中的PIM状态必须为每个VPLS实例。
o PIM Assert triggers MUST be preserved to the extent necessary to avoid sending duplicate traffic to the same PE (see Section 2.2.1).
o PIM断言触发器必须保留到必要的程度，以避免向同一PE发送重复流量（见第2.2.1节）。
In PIM-SM / PIM-DM, there are scenarios where multiple routers could be forwarding the same multicast traffic on a LAN. When this happens, these routers start the PIM Assert election process by sending PIM Assert messages, to ensure that only the Assert winner forwards multicast traffic on the LAN. The Assert election is a data-driven event and happens only if a router sees traffic on the interface to which it should be forwarding the traffic. In the case of a VPLS with PIM snooping, two routers may forward the same multicast datagrams at the same time, but each copy may reach a different set of PEs; this is acceptable from the point of view of avoiding duplicate traffic. If the two copies may reach the same PE, then the sending routers must be able to see each other's traffic, in order to trigger Assert election and stop duplicate traffic. To achieve that, PEs enabled with PIM-SSM / PIM-SM snooping MUST forward multicast traffic for an (S,G) / (*,G) not only on the ports on which they snooped Join(S,G) / Join(*,G) but also towards the upstream neighbor(s). In other words, the ports on which the upstream neighbors are learned must be added to the outgoing port list, along with the ports on which Joins are snooped. Please refer to Section 2.6.1 for the rules that determine the set of upstream neighbors for a particular (x,G).
在PIM-SM/PIM-DM中，存在多个路由器在LAN上转发相同多播流量的场景。发生这种情况时，这些路由器通过发送PIM Assert消息来启动PIM Assert选择过程，以确保只有Assert获胜者在LAN上转发多播流量。断言选择是一个数据驱动事件，仅当路由器在其应将流量转发到的接口上看到流量时才会发生。在具有PIM窥探的VPLS的情况下，两个路由器可同时转发相同的多播数据报，但每个副本可到达不同的PE集合；从避免重复通信的角度来看，这是可以接受的。如果两个副本可能到达相同的PE，那么发送路由器必须能够看到彼此的流量，以便触发断言选择并停止重复流量。为了实现这一点，启用PIM-SSM/PIM-SM窥探的PEs必须转发（S，G）/（*，G）的多播流量，不仅在其窥探连接（S，G）/Join（*，G）的端口上，而且还要转发到上游邻居。换句话说，必须将学习上游邻居的端口与监听联接的端口一起添加到传出端口列表中。请参考第2.6.1节，了解确定特定（x，G）上游邻居集的规则。
Similarly, PIM-DM snooping SHOULD make sure that Asserts can be triggered (Section 2.9.3).
同样，PIM-DM窥探应确保可以触发断言（第2.9.3节）。
The above logic needs to be facilitated without breaking VPLS split-horizon forwarding rules. That is, traffic should not be forwarded on the port on which it was received, and traffic arriving on a PW MUST NOT be forwarded onto other PW(s).
需要在不破坏VPLS分割地平线转发规则的情况下简化上述逻辑。也就是说，流量不应在其接收的端口上转发，并且到达PW的流量不得转发到其他PW。
The PIM snooping solution described here requires a PE to examine and operate on only PIM Hello and PIM Join/Prune packets. The PE does not need to examine any other PIM packets.
这里描述的PIM窥探解决方案要求PE只检查和操作PIM Hello和PIM Join/Prune数据包。PE不需要检查任何其他PIM数据包。
Most of the PIM snooping procedures for handling Hello/Join/Prune messages are very similar to those executed in a PIM router. However, the PE does not need to have any routing tables like those required in PIM routing. It knows how to forward Join/Prune messages only by looking at the Upstream Neighbor field in the Join/Prune packets, as described in Section 2.12.
处理Hello/Join/Prune消息的大多数PIM窥探过程与在PIM路由器中执行的过程非常相似。但是，PE不需要任何像PIM路由中所需的路由表。它知道如何仅通过查看加入/删减数据包中的上游邻居字段来转发加入/删减消息，如第2.12节所述。
The PE does not need to know about Rendezvous Points (RPs) and does not have to maintain any RP Set. All of that is transparent to a PIM snooping PE.
PE不需要知道集合点（RP），也不需要维护任何RP集。所有这些对于PIM窥探PE来说都是透明的。
In the following subsections, we list some considerations and observations for the implementation of PIM snooping in the VPLS.
在以下小节中，我们列出了在VPLS中实施PIM窥探的一些注意事项和观察结果。
PIM snooping needs to be employed on ACs at the downstream PEs (PEs receiving multicast traffic across the VPLS core) to prevent traffic from being sent out of ACs unnecessarily. PIM snooping techniques can also be employed on PWs at the upstream PEs (PEs receiving traffic from local ACs in a hierarchical VPLS) to prevent traffic from being sent to PEs unnecessarily. This may work well for small-scale or medium-scale deployments. However, if there are a large number of VPLS instances with a large number of PEs per instance, then the amount of snooping required at the upstream PEs can overwhelm the upstream PEs.
需要在下游PEs（通过VPLS核心接收多播流量的PEs）的ACs上使用PIM窥探，以防止不必要地将流量从ACs发送出去。PIM窥探技术也可用于上游PEs的PWs（PEs在分级VPLS中接收来自本地ACs的流量），以防止流量不必要地发送到PEs。这可能适用于小规模或中规模部署。但是，如果存在大量VPLS实例，且每个实例具有大量PE，则上游PE所需的窥探量可能会超过上游PE。
There are two methods to reduce the burden on the upstream PEs. One is to use PIM proxying, as described in Section 2.6.6, to reduce the control messages forwarded by a PE. The other is not to snoop on the PWs at all but to have PEs signal the snooped states to other PEs out of band via BGP, as described in RFC 7117 [VPLS-MCAST]. In this document, it is assumed that snooping is performed on PWs.
有两种方法可以减轻上游PEs的负担。一种是使用PIM代理，如第2.6.6节所述，以减少PE转发的控制消息。另一种方法是根本不窥探PWs，而是让PEs通过BGP向其他带外PEs发送窥探状态信号，如RFC 7117[VPLS-MCAST]所述。在本文件中，假设在PWs上执行窥探。
In the VPLS, PEs forward Ethernet frames received from CEs and as such are agnostic of the Layer 3 protocol used by the CEs. However, as a PIM snooping PE, the PE would have to look deeper into the IP and PIM packets and build snooping state based on that. The PIM protocol specifications handle both IPv4 and IPv6. The specification for PIM snooping in this document can be applied to both IPv4 and IPv6 payloads.
在VPLS中，PEs转发从CEs接收的以太网帧，因此与CEs使用的第3层协议无关。然而，作为PIM窥探PE，PE必须深入查看IP和PIM数据包，并在此基础上构建窥探状态。PIM协议规范处理IPv4和IPv6。本文档中的PIM窥探规范可应用于IPv4和IPv6有效负载。
This document does not address (*,*,RP) states in the VPLS network, as they have been removed from the PIM protocol as described in RFC 7761 [PIM-SM].
本文件不涉及VPLS网络中的（*、*、RP）状态，因为它们已按照RFC 7761[PIM-SM]中的说明从PIM协议中删除。
This document has previously alluded to PIM snooping/relay/proxying. Details on the PIM relay/proxying solution are discussed in Section 2.6.6. In this section, a brief description and comparison are given.
本文档之前曾提及PIM窥探/中继/代理。第2.6.6节讨论了PIM继电器/代理解决方案的详细信息。在这一部分中，将进行简要的描述和比较。
Differences between PIM snooping and relay/proxying can be summarized as follows:
PIM窥探和继电器/代理之间的差异可总结如下：
+--------------------+---------------------+-----------------------+
| PIM snooping | PIM relay | PIM proxying |
+====================|=====================|=======================+
| Join/Prune messages| Join/Prune messages | Join/Prune messages |
| snooped and flooded| snooped; forwarded | consumed. Regenerated|
| according to VPLS | as is out of certain| ones sent out of |
| flooding procedures| upstream ports | certain upstream ports|
+--------------------+---------------------+-----------------------+
| Hello messages | Hello messages | Hello messages |
| snooped and flooded| snooped and flooded | snooped and flooded |
| according to VPLS | according to VPLS | according to VPLS |
| flooding procedures| flooding procedures | flooding procedures |
+--------------------+---------------------+-----------------------+
| No PIM packets | No PIM packets | New Join/Prune |
| generated | generated | messages generated |
+--------------------+---------------------+-----------------------+
| CE Join suppression| CE Join suppression | CE Join suppression |
| not allowed | allowed | allowed |
+--------------------+---------------------+-----------------------+
+--------------------+---------------------+-----------------------+
| PIM snooping | PIM relay | PIM proxying |
+====================|=====================|=======================+
| Join/Prune messages| Join/Prune messages | Join/Prune messages |
| snooped and flooded| snooped; forwarded | consumed. Regenerated|
| according to VPLS | as is out of certain| ones sent out of |
| flooding procedures| upstream ports | certain upstream ports|
+--------------------+---------------------+-----------------------+
| Hello messages | Hello messages | Hello messages |
| snooped and flooded| snooped and flooded | snooped and flooded |
| according to VPLS | according to VPLS | according to VPLS |
| flooding procedures| flooding procedures | flooding procedures |
+--------------------+---------------------+-----------------------+
| No PIM packets | No PIM packets | New Join/Prune |
| generated | generated | messages generated |
+--------------------+---------------------+-----------------------+
| CE Join suppression| CE Join suppression | CE Join suppression |
| not allowed | allowed | allowed |
+--------------------+---------------------+-----------------------+
Other than the above differences, most of the procedures are common to PIM snooping and PIM relay/proxying, unless specifically stated otherwise.
除上述差异外，大多数程序对于PIM窥探和PIM中继/代理是通用的，除非另有特别说明。
Pure PIM snooping PEs simply snoop on PIM packets as they are being forwarded in the VPLS. As such, they truly provide transparent LAN services, since no customer packets are modified or consumed nor are new packets introduced in the VPLS. It is also simpler to implement than PIM proxying. However, for PIM snooping to work correctly, it is a requirement that CE routers MUST disable Join suppression in the VPLS. Otherwise, most of the CE routers with interest in a given multicast data stream will fail to send Join/Prune messages for that stream, and the PEs will not be able to tell which ACs and/or PWs have listeners for that stream.
纯PIM窥探PEs只是在PIM数据包在VPLS中转发时窥探它们。因此，它们真正提供了透明的LAN服务，因为没有修改或消费客户数据包，也没有在VPL中引入新数据包。它的实现也比PIM代理更简单。然而，为了使PIM窥探正常工作，CE路由器必须在VPLS中禁用加入抑制。否则，对给定多播数据流感兴趣的大多数CE路由器将无法为该流发送加入/删减消息，并且PEs将无法辨别哪些ACs和/或pw具有该流的侦听器。
Given that a large number of existing CE deployments do not support the disabling of Join suppression and given the operational complexity for a provider to manage the disabling of Join suppression in the VPLS, it becomes a difficult solution to deploy. Another disadvantage of PIM snooping is that it does not scale as well as PIM proxying. If there are a large number of CEs in a VPLS, then every CE will see every other CE's Join/Prune messages.
考虑到大量现有CE部署不支持禁用连接抑制，并且考虑到提供商管理VPLS中禁用连接抑制的操作复杂性，部署此解决方案变得非常困难。PIM窥探的另一个缺点是它的伸缩性不如PIM代理。如果VPLS中有大量CE，则每个CE将看到其他CE的加入/删除消息。
PIM relay/proxying has the advantage that it does not require Join suppression to be disabled in the VPLS. Multicast as part of a VPLS can be very easily provided without requiring any changes on the CE routers. PIM relay/proxying helps scale VPLS multicast, since Join/Prune messages are only sent to certain upstream ports instead of flooded, and in cases of full proxying (vs. relay), the PEs intelligently generate only one Join/Prune message for a given multicast stream.
PIM中继/代理的优点是不需要在VPLS中禁用连接抑制。多播作为VPLS的一部分可以非常容易地提供，而无需对CE路由器进行任何更改。PIM中继/代理有助于扩展VPLS多播，因为加入/删减消息只发送到某些上游端口，而不是被淹没，并且在完全代理（与中继相比）的情况下，PEs智能地为给定多播流只生成一条加入/删减消息。
PIM proxying, however, loses the transparency argument, since Join/Prune packets could get modified or even consumed at a PE. Also, new packets could get introduced in the VPLS. However, this loss of transparency is limited to PIM Join/Prune packets. It is in the interest of optimizing multicast in the VPLS and helping a VPLS network scale much better, for both the provider and the customer. Data traffic will still be completely transparent.
然而，PIM代理会丢失透明度参数，因为加入/删减数据包可能会在PE中被修改甚至消耗。此外，VPLS中可能会引入新的数据包。然而，这种透明度损失仅限于PIM加入/删减数据包。这有利于优化VPLS中的多播，并帮助VPLS网络更好地扩展，无论是对于提供商还是客户。数据通信仍然是完全透明的。
A PIM snooping/relay/proxying PE snoops on PIM Hello packets while transparently flooding them in the VPLS. As such, there is no latency introduced by the VPLS in the delivery of PIM Hello packets to remote CEs in the VPLS.
PIM嗅探/中继/代理PE嗅探PIM Hello数据包，同时在VPL中透明地将它们淹没。因此，在向VPLS中的远程CE发送PIM Hello数据包时，VPLS不会引入延迟。
A PIM snooping PE snoops on PIM Join/Prune packets while transparently flooding them in the VPLS. There is no latency introduced by the VPLS in the delivery of PIM Join/Prune packets when PIM snooping is employed.
PIM窥探PE窥探PIM加入/删减数据包，同时在VPL中透明地将其淹没。当采用PIM窥探时，VPLS在PIM加入/删减数据包的传递中不会引入延迟。
A PIM relay/proxying PE does not simply flood PIM Join/Prune packets. This can result in additional latency for a downstream CE to receive multicast traffic after it has sent a Join. When a downstream CE prunes a multicast stream, the traffic SHOULD stop flowing to the CE with no additional latency introduced by the VPLS.
PIM中继/代理PE不会简单地淹没PIM加入/删除数据包。这可能会导致下游CE在发送加入后接收多播流量的额外延迟。当下游CE删减多播流时，流量应停止流向CE，VPLS不会引入额外的延迟。
Performing only proxying of Join/Prune and not Hello messages keeps the PE's behavior very similar to that of a PIM router, without introducing too much additional complexity. It keeps the PIM proxying solution fairly simple. Since Join/Prune messages are forwarded by a PE along the slow path and all other PIM packet types are forwarded along the fast path, it is very likely that packets forwarded along the fast path will arrive "ahead" of Join/Prune packets at a CE router (note the stress on the fact that fast-path messages will never arrive after Join/Prune packets). Of particular importance are Hello packets sent along the fast path. We can construct a variety of scenarios resulting in out-of-order delivery of Hellos and Join/Prune messages. However, there should be no deviation from normal expected behavior observed at the CE router receiving these messages out of order.
只执行Join/Prune代理而不执行Hello消息，可以使PE的行为与PIM路由器的行为非常相似，而不会引入太多额外的复杂性。它使PIM代理解决方案相当简单。由于加入/删减消息由PE沿着慢路径转发，而所有其他PIM数据包类型沿着快速路径转发，因此沿着快速路径转发的数据包很可能会在CE路由器上“提前”到达加入/删减数据包（注意，快速路径消息决不会在加入/删减数据包之后到达）. 特别重要的是沿快速路径发送的Hello数据包。我们可以构建各种场景，导致Hello和Join/Prune消息的无序交付。但是，在CE路由器接收这些无序消息时，应不会偏离正常预期行为。
From the above descriptions, factors that affect the choice of snooping/relay/proxying include:
根据以上描述，影响窥探/中继/代理选择的因素包括：
o Whether CEs do Join suppression or not
o CEs是否加入抑制
o Whether Join/Prune latency is critical or not
o 加入/删除延迟是否至关重要
o Whether the scale of PIM protocol messages/states in a VPLS requires the scaling benefit of proxying
o VPLS中PIM协议消息/状态的规模是否需要代理的规模优势
Of the above factors, Join suppression is the hard one -- pure snooping can only be used when Join suppression is disabled on all CEs. The latency associated with relay/proxying is implementation dependent and may not be a concern at all with a particular implementation. The scaling benefit may not be important either, in that on a real LAN with Explicit Tracking (ET) a PIM router will need to receive and process all PIM Join/Prune messages as well.
在上述因素中，加入抑制是最困难的一个——只有在所有CE上禁用加入抑制时，才能使用纯窥探。与中继/代理相关联的延迟取决于实现，对于特定的实现可能根本不是问题。扩展的好处可能也不重要，因为在具有显式跟踪（ET）的真实LAN上，PIM路由器也需要接收和处理所有PIM加入/删减消息。
A PIM router indicates that Join suppression is disabled if the T-bit is set in the LAN Prune Delay option of its Hello message. If all PIM routers on a LAN set the T-bit, ET is possible, allowing an upstream router to track all the downstream neighbors that have Join states for any (S,G) or (*,G). This has two benefits:
PIM路由器表示，如果在其Hello消息的LAN Prune Delay选项中设置了T位，则连接抑制被禁用。如果LAN上的所有PIM路由器都设置了T位，则ET是可能的，从而允许上游路由器跟踪具有任何（S，G）或（*，G）连接状态的所有下游邻居。这有两个好处：
o No need for the Prune-Pending process -- the upstream router may immediately stop forwarding data when it receives a Prune from the last downstream neighbor and immediately prune to its upstream neighbor.
o 不需要修剪挂起过程——当上游路由器从最后一个下游邻居接收到修剪时，它可以立即停止转发数据，并立即修剪到其上游邻居。
o For management purposes, the upstream router knows exactly which downstream routers exist for a particular Join state.
o 出于管理目的，上游路由器确切地知道针对特定连接状态存在哪些下游路由器。
While full proxying can be used with or without Join suppression on CEs and does not interfere with an upstream CE's bypass of the Prune-Pending process, it does proxy all its downstream CEs as a single one to the upstream neighbors, removing the second benefit mentioned above.
虽然完全代理可以在CEs上使用或不使用连接抑制，并且不会干扰上游CE对修剪挂起过程的旁路，但它确实将其所有下游CE作为单个CE代理给上游邻居，从而消除了上述第二个好处。
Therefore, the general rule is that if Join suppression is enabled on one or more CEs, then proxying or relay MUST be used, but if Join suppression is known to be disabled on all CEs, then snooping, relay, or proxying MAY be used, while snooping or relay SHOULD be used.
因此，一般规则是，如果在一个或多个CE上启用了连接抑制，则必须使用代理或中继，但如果已知在所有CE上禁用了连接抑制，则可以使用窥探、中继或代理，而应使用窥探或中继。
An implementation MAY choose to dynamically determine which mode to use, through the tracking of the above-mentioned T-bit in all snooped PIM Hello messages, or MAY simply require static provisioning.
实现可以通过跟踪所有窥探的PIM Hello消息中的上述T比特来选择动态地确定使用哪种模式，或者可以仅仅需要静态设置。
A PIM snooping PE MUST snoop on PIM Hellos received on ACs and PWs. That is, the PE transparently floods the PIM Hello while snooping on it. PIM Hellos are used by the snooping PE to discover PIM routers and their characteristics.
PIM窥探PE必须窥探ACs和PWs上接收到的PIM HELOS。也就是说，PE在窥探PIM Hello时会透明地将其淹没。窥探PE使用PIM Hello来发现PIM路由器及其特性。
For each neighbor discovered by a PE, it includes an entry in the PIM Neighbor Database with the following fields:
对于PE发现的每个邻居，它在PIM邻居数据库中包含一个条目，其中包含以下字段：
o Layer 2 encapsulation for the router sending the PIM Hello.
o 发送PIM Hello的路由器的第2层封装。
o IP address and address family of the router sending the PIM Hello.
o 发送PIM Hello的路由器的IP地址和地址系列。
o Port (AC/PW) on which the PIM Hello was received.
o 接收PIM Hello的端口（AC/PW）。
o Hello Option fields.
o Hello选项字段。
The PE should be able to interpret and act on Hello Option fields as currently defined in RFC 7761 [PIM-SM]. The Option fields of particular interest in this document are:
PE应能够解释RFC 7761[PIM-SM]中当前定义的Hello选项字段并对其进行操作。本文件中特别关注的选项字段包括：
o Hello-Hold-Time
o 你好，等待时间
o Tracking Support
o 跟踪支持
o Designated Router (DR) Priority
o 指定路由器（DR）优先级
Please refer to RFC 7761 [PIM-SM] for a list of the Hello Option fields. When a PIM Hello is received, the PE MUST reset the neighbor-expiry-timer to Hello-Hold-Time. If a PE does not receive a Hello message from a router within Hello-Hold-Time, the PE MUST remove that neighbor from its PIM Neighbor Database. If a PE receives a Hello message from a router with the Hello-Hold-Time value set to zero, the PE MUST remove that router from the PIM snooping state immediately.
有关Hello选项字段的列表，请参阅RFC 7761[PIM-SM]。当收到PIM Hello时，PE必须将邻居到期计时器重置为Hello保持时间。如果PE在Hello保持时间内没有从路由器接收Hello消息，则PE必须从其PIM邻居数据库中删除该邻居。如果PE从路由器收到Hello保持时间值设置为零的Hello消息，则PE必须立即将该路由器从PIM窥探状态中移除。
From the PIM Neighbor Database, a PE MUST be able to use the procedures defined in RFC 7761 [PIM-SM] to identify the PIM DR in the VPLS instance. It should also be able to determine if tracking support is active in the VPLS instance.
从PIM邻居数据库中，PE必须能够使用RFC 7761[PIM-SM]中定义的过程来识别VPLS实例中的PIM DR。它还应该能够确定跟踪支持在VPLS实例中是否处于活动状态。
The key characteristic of PIM-SM and PIM-SSM is explicit Join behavior. In this model, multicast traffic is only forwarded to locations that specifically request it. All the procedures described in this section apply to both PIM-SM and PIM-SSM, except for the fact that there is no (*,G) state in PIM-SSM.
PIM-SM和PIM-SSM的关键特征是显式连接行为。在该模型中，多播流量仅转发到专门请求它的位置。本节所述的所有程序均适用于PIM-SM和PIM-SSM，但PIM-SSM中没有（*，G）状态的情况除外。
PIM-SM and PIM-SSM states are built by snooping on the PIM-SM Join/Prune messages received on ACs/PWs.
PIM-SM和PIM-SSM状态是通过窥探ACs/PWs上接收的PIM-SM加入/删减消息建立的。
The downstream state machine of a PIM-SM snooping PE very closely resembles the downstream state machine of PIM-SM routers. The downstream state consists of:
PIM-SM窥探PE的下游状态机与PIM-SM路由器的下游状态机非常相似。下游状态包括：
Per downstream (Port,*,G):
每个下游（港口，*，G）：
o DownstreamJPState: One of {"NoInfo" (NI), "Join" (J), "Prune-Pending" (PP)}
o 下游州：一个{“NoInfo”（NI），“Join”（J），“Prune Pending”（PP）}
Per downstream (Port,*,G,N):
每下游（港口，*，G，N）：
o Prune-Pending Timer (PPT(N))
o 删除挂起计时器（PPT（N））
o Join Expiry Timer (ET(N))
o 加入到期计时器（ET（N））
Per downstream (Port,S,G):
每下游（港口、S、G）：
o DownstreamJPState: One of {"NoInfo" (NI), "Join" (J), "Prune-Pending" (PP)}
o 下游州：一个{“NoInfo”（NI），“Join”（J），“Prune Pending”（PP）}
Per downstream (Port,S,G,N):
每下游（港口、S、G、N）：
o Prune-Pending Timer (PPT(N))
o 删除挂起计时器（PPT（N））
o Join Expiry Timer (ET(N))
o 加入到期计时器（ET（N））
Per downstream (Port,S,G,rpt):
每下游（港口、S、G、rpt）：
o DownstreamJPRptState: One of {"NoInfo" (NI), "Pruned" (P), "Prune-Pending" (PP)}
o 下游州：其中一个{“NoInfo”（NI），“Pruned”（P），“Prune Pending”（PP）}
Per downstream (Port,S,G,rpt,N):
每下游（港口、S、G、rpt、N）：
o Prune-Pending Timer (PPT(N))
o 删除挂起计时器（PPT（N））
o Join Expiry Timer (ET(N))
o 加入到期计时器（ET（N））
where S is the address of the multicast source, G is the group address, and N is the Upstream Neighbor field in the Join/Prune message.
其中S是多播源的地址，G是组地址，N是加入/删减消息中的上游邻居字段。
Note that unlike the case of PIM-SM routers, where the PPT and ET are per (Interface,S,G), PIM snooping PEs have to maintain the PPT and ET per (Port,S,G,N). The reasons for this are explained in Section 2.6.2.
请注意，与PIM-SM路由器不同，PIM-SM路由器的PPT和ET为per（接口，S，G），PIM窥探PE必须维护PPT和ET per（端口，S，G，N）。第2.6.2节解释了原因。
Apart from the above states, we define the following state summarization macros:
除上述状态外，我们还定义了以下状态摘要宏：
UpstreamNeighbors(*,G): If there are one or more Join(*,G)s received on any port with upstream neighbor N and ET(N) is active, then N is added to UpstreamNeighbors(*,G). This set is used to determine if a Join(*,G) or a Prune(*,G) with upstream neighbor N needs to be sent upstream.
上游IGHBORS（*，G）：如果在上游邻居N的任何端口上接收到一个或多个连接（*，G），且ET（N）处于活动状态，则N将添加到上游IGHBORS（*，G）。此集合用于确定是否需要向上游发送与上游邻居N的连接（*，G）或修剪（*，G）。
UpstreamNeighbors(S,G): If there are one or more Join(S,G)s received on any port with upstream neighbor N and ET(N) is active, then N is added to UpstreamNeighbors(S,G). This set is used to determine if a Join(S,G) or a Prune(S,G) with upstream neighbor N needs to be sent upstream.
上游IGHBORS（S，G）：如果在上游邻居N的任何端口上接收到一个或多个连接（S，G），且ET（N）处于活动状态，则N将添加到上游IGHBORS（S，G）。该集合用于确定是否需要向上游发送与上游邻居N的连接（S，G）或修剪（S，G）。
UpstreamPorts(*,G): This is the set of all Port(N) ports where N is in the set UpstreamNeighbors(*,G). Multicast streams forwarded using a (*,G) match MUST be forwarded to these ports. So, UpstreamPorts(*,G) MUST be added to OutgoingPortList(*,G).
UpstreamImports（*，G）：这是所有端口（N）的集合，其中N位于集合UpstreamNighbors（*，G）中。使用（*，G）匹配转发的多播流必须转发到这些端口。因此，必须将上游导入（*，G）添加到OutgoingPortList（*，G）。
UpstreamPorts(S,G): This is the set of all Port(N) ports where N is in the set UpstreamNeighbors(S,G). UpstreamPorts(S,G) MUST be added to OutgoingPortList(S,G).
上行端口（S，G）：这是所有端口（N）的集合，其中N位于集合的上行IGHBORS（S，G）中。上游入口（S，G）必须添加到OutgoingPortList（S，G）中。
InheritedUpstreamPorts(S,G): This is the union of UpstreamPorts(S,G) and UpstreamPorts(*,G).
继承的流端口（S，G）：这是上游端口（S，G）和上游端口（*，G）的并集。
UpstreamPorts(S,G,rpt): If PruneDesired(S,G,rpt) becomes TRUE, then this set is set to UpstreamPorts(*,G). Otherwise, this set is empty. UpstreamPorts(*,G) (-) UpstreamPorts(S,G,rpt) MUST be added to OutgoingPortList(S,G).
上流导入（S，G，rpt）：如果PruneDesired（S，G，rpt）变为TRUE，则此集合设置为上流导入（*，G）。否则，此集合为空。上行端口（*，G）（）必须将上行端口（S，G，rpt）添加到OutgoingPortList（S，G）。
UpstreamPorts(G): This set is the union of all the UpstreamPorts(S,G) and UpstreamPorts(*,G) for a given G. Proxy (S,G) Join/Prune and (*,G) Join/Prune messages MUST be sent to a subset of UpstreamPorts(G) as specified in Section 2.6.6.1.
UpstreamPorts（G）：该集合是给定G的所有UpstreamPorts（S，G）和UpstreamPorts（*，G）的并集。代理（S，G）连接/删除和（*，G）连接/删除消息必须发送到第2.6.6.1节中规定的UpstreamPorts（G）的子集。
PWPorts: This is the set of all PWs.
PWPorts：这是所有PW的集合。
OutgoingPortList(*,G): This is the set of all ports to which traffic needs to be forwarded on a (*,G) match.
OutgoingPortList（*，G）：这是在（*，G）匹配中需要将流量转发到的所有端口的集合。
OutgoingPortList(S,G): This is the set of all ports to which traffic needs to be forwarded on an (S,G) match.
OutgoingPortList（S，G）：这是在（S，G）匹配中需要将流量转发到的所有端口的集合。
See Section 2.12 ("Data-Forwarding Rules") for the specification on how OutgoingPortList is calculated.
有关如何计算OutgoingPortList的规范，请参见第2.12节（“数据转发规则”）。
NumETsActive(Port,*,G): This is the number of (Port,*,G,N) entries that have the Expiry Timer running. This macro keeps track of the number of Join(*,G)s that are received on this Port with different upstream neighbors.
NumETsActive（Port，*，G）：这是过期计时器正在运行的（Port，*，G，N）条目数。此宏跟踪此端口上接收到的具有不同上游邻居的连接（*，G）的数量。
NumETsActive(Port,S,G): This is the number of (Port,S,G,N) entries that have the Expiry Timer running. This macro keeps track of the number of Join(S,G)s that are received on this Port with different upstream neighbors.
NumETsActive（Port，S，G）：这是过期计时器正在运行的（Port，S，G，N）条目数。此宏跟踪此端口上接收到的具有不同上游邻居的连接数（S，G）。
JoinAttributeTlvs(*,G): Join Attributes (RFC 5384 [JOIN-ATTR]) are TLVs that may be present in received Join(*,G) messages. An example would be Reverse Path Forwarding (RPF) Vectors (RFC 5496 [RPF-VECTOR]). If present, they must be copied to JoinAttributeTlvs(*,G).
JoinAttributeTlvs（*，G）：连接属性（RFC 5384[Join-ATTR]）是可能出现在接收到的连接（*，G）消息中的TLV。例如，反向路径转发（RPF）向量（RFC 5496[RPF-VECTOR]）。如果存在，则必须将它们复制到JoinAttributeTlvs（*，G）。
JoinAttributeTlvs(S,G): Join Attributes (RFC 5384 [JOIN-ATTR]) are TLVs that may be present in received Join(S,G) messages. If present, they must be copied to JoinAttributeTlvs(S,G).
JoinAttributeTlvs（S，G）：连接属性（RFC 5384[Join-ATTR]）是可能存在于接收的连接（S，G）消息中的TLV。如果存在，则必须将它们复制到JoinAttributeTlvs（S，G）。
Since there are a few differences between the downstream state machines of PIM-SM routers and PIM-SM snooping PEs, we specify the details of the downstream state machine of PIM-SM snooping PEs, at the risk of repeating most of the text documented in RFC 7761 [PIM-SM].
由于PIM-SM路由器和PIM-SM窥探PEs的下游状态机之间存在一些差异，我们指定了PIM-SM窥探PEs的下游状态机的详细信息，但有可能重复RFC 7761[PIM-SM]中记录的大部分文本。
In PIM routing protocols, states are built per (S,G). On a router, an (S,G) has only one RPF-Neighbor. However, a PIM snooping PE does not have the Layer 3 routing information available to the routers in order to determine the RPF-Neighbor for a multicast flow. It merely discovers it by snooping the Join/Prune message. A PE could have snooped on two or more different Join/Prune messages for the same (S,G) that could have carried different Upstream Neighbor fields. This could happen during transient network conditions or due to dual-homed sources. A PE cannot make assumptions on which one to pick but instead must allow the CE routers to decide which upstream
在PIM路由协议中，状态是按照（S，G）构建的。在路由器上，（S，G）只有一个RPF邻居。然而，PIM窥探PE不具有路由器可用于确定多播流的RPF邻居的第3层路由信息。它只是通过窥探Join/Prune消息来发现它。PE可能窥探了两个或多个不同的加入/删减消息，这些消息可能包含不同的上游邻居字段。这可能发生在瞬态网络条件下，或由于双驻留源。PE不能对选择哪一个进行假设，但必须允许CE路由器决定选择哪个上游
neighbor gets elected as the RPF-Neighbor. And for this purpose, the PE will have to track downstream and upstream Joins and Prunes per (S,G,N).
邻居被选为RPF邻居。为此，PE必须根据（S，G，N）跟踪下游和上游连接和修剪。
A Join(*,G) or Prune(*,G) is considered "received" if one of the following conditions is met:
如果满足以下条件之一，则连接（*，G）或修剪（*，G）被视为“已接收”：
o The port on which it arrived is not Port(N) where N is the upstream neighbor N of the Join/Prune(*,G).
o 它到达的端口不是端口（N），其中N是连接/修剪（*，G）的上游邻居N。
o If both Port(N) and the arrival port are PWs, then there exists at least one other (*,G,Nx) or (Sx,G,Nx) state with an AC UpstreamPort.
o 如果端口（N）和到达端口都是PWs，则存在至少一个其他（*，G，Nx）或（Sx，G，Nx）状态与AC上游导入。
For simplicity, the case where both Port(N) and the arrival port are PWs is referred to as "PW-only Join/Prune" in this document. The PW-only Join/Prune handling is so that the Port(N) PW can be added to the related forwarding entries' OutgoingPortList to trigger an Assert, but that is only needed for those states with AC UpstreamPorts. Note that in the PW-only case, it is OK for the arrival port and Port(N) to be the same. See Appendix B for examples.
为简单起见，在本文档中，端口（N）和到达端口均为PWs的情况称为“仅PW加入/删减”。PW only Join/Prune处理用于将端口（N）PW添加到相关转发条目的OutgoingPortList以触发断言，但这仅适用于具有AC UpstreamPorts的状态。注意，在仅PW的情况下，到达端口和端口（N）相同是可以的。示例见附录B。
When a router receives a Join(*,G) or a Prune(*,G) with upstream neighbor N, it must process the message as defined in the state machine below. Note that the macro computations of the various macros resulting from this state machine transition are exactly as specified in RFC 7761 [PIM-SM].
当路由器接收到与上游邻居N的连接（*，G）或修剪（*，G）时，它必须按照下面的状态机中的定义处理消息。请注意，由该状态机转换产生的各种宏的宏计算完全符合RFC 7761[PIM-SM]中的规定。
We define the following per-port (*,G,N) macro to help with the state machine below.
我们定义以下每端口（*，G，N）宏来帮助下面的状态机。
+---------------++-------------------------------------------------+
| || Previous State |
| ++-------------+--------------+--------------------+
| Event || NoInfo (NI) | Join (J) | Prune-Pending (PP) |
+---------------++-------------+--------------+--------------------+
| Receive || -> J state | -> J state | -> J state |
| Join(*,G) || Action | Action | Action |
| || RxJoin(N) | RxJoin(N) | RxJoin(N) |
+---------------++-------------+--------------+--------------------+
|Receive || - | -> PP state | -> PP state |
|Prune(*,G) and || | Start PPT(N) | |
|NumETsActive<=1|| | | |
+---------------++-------------+--------------+--------------------+
|Receive || - | -> J state | - |
|Prune(*,G) and || | Start PPT(N) | |
|NumETsActive>1 || | | |
+---------------++-------------+--------------+--------------------+
|PPT(N) expires || - | -> J state | -> NI state |
| || | Action | Action |
| || | PPTExpiry(N) | PPTExpiry(N) |
+---------------++-------------+--------------+--------------------+
|ET(N) expires || - | -> NI state | -> NI state |
|and || | Action | Action |
|NumETsActive<=1|| | ETExpiry(N) | ETExpiry(N) |
+---------------++-------------+--------------+--------------------+
|ET(N) expires || - | -> J state | - |
|and || | Action | |
|NumETsActive>1 || | ETExpiry(N) | |
+---------------++-------------+--------------+--------------------+
+---------------++-------------------------------------------------+
| || Previous State |
| ++-------------+--------------+--------------------+
| Event || NoInfo (NI) | Join (J) | Prune-Pending (PP) |
+---------------++-------------+--------------+--------------------+
| Receive || -> J state | -> J state | -> J state |
| Join(*,G) || Action | Action | Action |
| || RxJoin(N) | RxJoin(N) | RxJoin(N) |
+---------------++-------------+--------------+--------------------+
|Receive || - | -> PP state | -> PP state |
|Prune(*,G) and || | Start PPT(N) | |
|NumETsActive<=1|| | | |
+---------------++-------------+--------------+--------------------+
|Receive || - | -> J state | - |
|Prune(*,G) and || | Start PPT(N) | |
|NumETsActive>1 || | | |
+---------------++-------------+--------------+--------------------+
|PPT(N) expires || - | -> J state | -> NI state |
| || | Action | Action |
| || | PPTExpiry(N) | PPTExpiry(N) |
+---------------++-------------+--------------+--------------------+
|ET(N) expires || - | -> NI state | -> NI state |
|and || | Action | Action |
|NumETsActive<=1|| | ETExpiry(N) | ETExpiry(N) |
+---------------++-------------+--------------+--------------------+
|ET(N) expires || - | -> J state | - |
|and || | Action | |
|NumETsActive>1 || | ETExpiry(N) | |
+---------------++-------------+--------------+--------------------+
Figure 1: Downstream Per-Port (*,G) State Machine in Tabular Form
图1：下游每个端口（*，G）状态机的表格形式
Action RxJoin(N):
行动RxJoin（N）：
If ET(N) is not already running, then start ET(N). Otherwise, restart ET(N). If N is not already in UpstreamNeighbors(*,G), then add N to UpstreamNeighbors(*,G) and trigger a Join(*,G) with upstream neighbor N to be forwarded upstream. If there are Join Attribute TLVs in the received (*,G) message and if they are different from the recorded JoinAttributeTlvs(*,G), then copy them into JoinAttributeTlvs(*,G). In the case of conflicting attributes, the PE will need to perform conflict resolution per (N) as described in RFC 5384 [JOIN-ATTR].
如果ET（N）尚未运行，则启动ET（N）。否则，重新启动ET（N）。如果N不在上游IGHBORS（*，G）中，则将N添加到上游IGHBORS（*，G），并触发与上游邻居N的连接（*，G）向上游转发。如果接收到的（*，G）消息中存在连接属性TLV，并且它们与记录的JoinAttributeTlvs（*，G）不同，则将它们复制到JoinAttributeTlvs（*，G）中。在属性冲突的情况下，PE需要按照RFC 5384[JOIN-ATTR]中所述的per（N）执行冲突解决。
Action PPTExpiry(N):
行动计划（N）：
Same as Action ETExpiry(N) below, plus send a Prune-Echo(*,G) with upstream neighbor N on the downstream port.
与下面的操作ETExpiry（N）相同，加上在下游端口上与上游邻居N发送一个修剪回显（*，G）。
Action ETExpiry(N):
行动E解释（N）：
Disable timers ET(N) and PPT(N). Delete Neighbor state (Port,*,G,N). If there are no other (Port,*,G) states with NumETsActive(Port,*,G) > 0, transition DownstreamJPState (RFC 7761 [PIM-SM]) to NoInfo. If there are no other (Port,*,G,N) states (different ports but for the same N), remove N from UpstreamPorts(*,G) -- this will also trigger the Upstream Finite State Machine (FSM) with "JoinDesired(*,G,N) to FALSE".
禁用定时器ET（N）和PPT（N）。删除邻居状态（端口，*，G，N）。如果没有NumETsActive（Port，*，G）>0的其他（Port，*，G）状态，则将下游Pstate（RFC 7761[PIM-SM]）转换为NoInfo。如果没有其他（端口，*，G，N）状态（不同的端口，但对于相同的N），则从上游端口（*，G）中删除N——这也将触发上游有限状态机（FSM），其中“JoinDesired（*，G，N）为FALSE”。
A Join(S,G) or Prune(S,G) is considered "received" if one of the following conditions is met:
如果满足以下条件之一，则连接（S，G）或修剪（S，G）被视为“已接收”：
o The port on which it arrived is not Port(N) where N is the upstream neighbor N of the Join/Prune(S,G).
o 它到达的端口不是端口（N），其中N是连接/修剪（S，G）的上游邻居N。
o If both Port(N) and the arrival port are PWs, then there exists at least one other (*,G,Nx) or (S,G,Nx) state with an AC UpstreamPort.
o 如果端口（N）和到达端口都是PWs，则存在至少一个其他（*，G，Nx）或（S，G，Nx）状态与AC上游导入。
For simplicity, the case where both Port(N) and the arrival port are PWs is referred to as "PW-only Join/Prune" in this document. The PW-only Join/Prune handling is so that the Port(N) PW can be added to the related forwarding entries' OutgoingPortList to trigger an Assert, but that is only needed for those states with AC UpstreamPorts. Note that in the PW-only case, it is OK for the arrival port and Port(N) to be the same. See Appendix B for examples.
为简单起见，在本文档中，端口（N）和到达端口均为PWs的情况称为“仅PW加入/删减”。PW only Join/Prune处理用于将端口（N）PW添加到相关转发条目的OutgoingPortList以触发断言，但这仅适用于具有AC UpstreamPorts的状态。注意，在仅PW的情况下，到达端口和端口（N）相同是可以的。示例见附录B。
When a router receives a Join(S,G) or a Prune(S,G) with upstream neighbor N, it must process the message as defined in the state machine below. Note that the macro computations of the various macros resulting from this state machine transition are exactly as specified in RFC 7761 [PIM-SM].
当路由器接收到与上游邻居N的连接（S，G）或修剪（S，G）时，它必须按照下面的状态机中的定义处理消息。请注意，由该状态机转换产生的各种宏的宏计算完全符合RFC 7761[PIM-SM]中的规定。
+---------------++-------------------------------------------------+
| || Previous State |
| ++-------------+--------------+--------------------+
| Event || NoInfo (NI) | Join (J) | Prune-Pending (PP) |
+---------------++-------------+--------------+--------------------+
| Receive || -> J state | -> J state | -> J state |
| Join(S,G) || Action | Action | Action |
| || RxJoin(N) | RxJoin(N) | RxJoin(N) |
+---------------++-------------+--------------+--------------------+
|Receive || - | -> PP state | - |
|Prune(S,G) and || | Start PPT(N) | |
|NumETsActive<=1|| | | |
+---------------++-------------+--------------+--------------------+
|Receive || - | -> J state | - |
|Prune(S,G) and || | Start PPT(N) | |
|NumETsActive>1 || | | |
+---------------++-------------+--------------+--------------------+
|PPT(N) expires || - | -> J state | -> NI state |
| || | Action | Action |
| || | PPTExpiry(N) |PPTExpiry(N) |
+---------------++-------------+--------------+--------------------+
|ET(N) expires || - | -> NI state | -> NI state |
|and || | Action | Action |
|NumETsActive<=1|| | ETExpiry(N) | ETExpiry(N) |
+---------------++-------------+--------------+--------------------+
|ET(N) expires || - | -> J state | - |
|and || | Action | |
|NumETsActive>1 || | ETExpiry(N) | |
+---------------++-------------+--------------+--------------------+
+---------------++-------------------------------------------------+
| || Previous State |
| ++-------------+--------------+--------------------+
| Event || NoInfo (NI) | Join (J) | Prune-Pending (PP) |
+---------------++-------------+--------------+--------------------+
| Receive || -> J state | -> J state | -> J state |
| Join(S,G) || Action | Action | Action |
| || RxJoin(N) | RxJoin(N) | RxJoin(N) |
+---------------++-------------+--------------+--------------------+
|Receive || - | -> PP state | - |
|Prune(S,G) and || | Start PPT(N) | |
|NumETsActive<=1|| | | |
+---------------++-------------+--------------+--------------------+
|Receive || - | -> J state | - |
|Prune(S,G) and || | Start PPT(N) | |
|NumETsActive>1 || | | |
+---------------++-------------+--------------+--------------------+
|PPT(N) expires || - | -> J state | -> NI state |
| || | Action | Action |
| || | PPTExpiry(N) |PPTExpiry(N) |
+---------------++-------------+--------------+--------------------+
|ET(N) expires || - | -> NI state | -> NI state |
|and || | Action | Action |
|NumETsActive<=1|| | ETExpiry(N) | ETExpiry(N) |
+---------------++-------------+--------------+--------------------+
|ET(N) expires || - | -> J state | - |
|and || | Action | |
|NumETsActive>1 || | ETExpiry(N) | |
+---------------++-------------+--------------+--------------------+
Figure 2: Downstream Per-Port (S,G) State Machine in Tabular Form
图2：表格形式的每个端口（S，G）下游状态机
Action RxJoin(N):
行动RxJoin（N）：
If ET(N) is not already running, then start ET(N). Otherwise, restart ET(N).
如果ET（N）尚未运行，则启动ET（N）。否则，重新启动ET（N）。
If N is not already in UpstreamNeighbors(S,G), then add N to UpstreamNeighbors(S,G) and trigger a Join(S,G) with upstream neighbor N to be forwarded upstream. If there are Join Attribute TLVs in the received (S,G) message and if they are different from the recorded JoinAttributeTlvs(S,G), then copy them into JoinAttributeTlvs(S,G). In cases of conflicting attributes, the PE will need to perform conflict resolution per (N) as described in RFC 5384 [JOIN-ATTR].
如果N不在上游IGHBORS（S，G）中，则将N添加到上游IGHBORS（S，G）中，并触发与上游邻居N的连接（S，G）向上游转发。如果接收到的（S，G）消息中存在连接属性TLV，并且它们与记录的JoinAttributeTlvs（S，G）不同，则将它们复制到JoinAttributeTlvs（S，G）中。在属性冲突的情况下，PE需要按照RFC 5384[JOIN-ATTR]中所述的per（N）执行冲突解决。
Action PPTExpiry(N):
行动计划（N）：
Same as Action ETExpiry(N) below, plus send a Prune-Echo(S,G) with upstream neighbor N on the downstream port.
与下面的操作ETExpiry（N）相同，加上在下游端口上与上游邻居N发送一个修剪回音（S，G）。
Action ETExpiry(N):
行动E解释（N）：
Disable timers ET(N) and PPT(N). Delete Neighbor state (Port,S,G,N). If there are no other (Port,S,G) states with NumETsActive(Port,S,G) > 0, transition DownstreamJPState to NoInfo. If there are no other (Port,S,G,N) states (different ports but for the same N), remove N from UpstreamPorts(S,G) -- this will also trigger the Upstream FSM with "JoinDesired(S,G,N) to FALSE".
禁用定时器ET（N）和PPT（N）。删除邻居状态（端口、S、G、N）。如果不存在NumETsActive（Port，S，G）>0的其他（Port，S，G）状态，则将下游Pstate转换为NoInfo。如果没有其他（端口，S，G，N）状态（不同的端口，但对于相同的N），则从上游端口（S，G）中删除N--这也将触发上游FSM，其中“JoinDesired（S，G，N）为FALSE”。
A Join(S,G,rpt) or Prune(S,G,rpt) is "received" when the port on which it was received is not also the port on which the upstream neighbor N of the Join/Prune(S,G,rpt) was learned.
当接收到连接（S，G，rpt）或修剪（S，G，rpt）的端口不是学习连接/修剪（S，G，rpt）的上游邻居N的端口时，连接（S，G，rpt）或修剪（S，G，rpt）被“接收”。
While it is important to ensure that the (S,G) and (*,G) state machines allow for handling per-(S,G,N) states, it is not as important for (S,G,rpt) states. It suffices to say that the downstream (S,G,rpt) state machine is the same as what is defined in Section 4.5.3 of RFC 7761 [PIM-SM].
虽然确保（S，G）和（*，G）状态机允许处理每-（S，G，N）个状态很重要，但对于（S，G，rpt）状态来说却不那么重要。只需说明下游（S、G、rpt）状态机与RFC 7761[PIM-SM]第4.5.3节中定义的状态机相同即可。
This section applies only to a PIM relay/proxying PE and not to a PIM snooping PE.
本节仅适用于PIM继电器/代理PE，不适用于PIM窥探PE。
A full PIM proxying (not relay) PE MUST implement the Upstream FSM along the lines of the procedure described in Section 4.5.4 of RFC 7761 [PIM-SM].
完整的PIM代理（非继电器）PE必须按照RFC 7761[PIM-SM]第4.5.4节所述程序执行上游FSM。
For the purposes of the Upstream FSM, a Join or Prune message with upstream neighbor N is "seen" on a PIM relay/proxying PE if the port on which the message was received is also Port(N) and the port is an AC. The AC requirement is needed because a Join received on the Port(N) PW must not suppress this PE's Join on that PW.
出于上游FSM的目的，如果接收消息的端口也是端口（N）且端口是AC，则在PIM中继/代理PE上“看到”具有上游邻居N的联接或删减消息。需要AC要求，因为在端口（N）PW上接收的联接不得抑制该PE在该PW上的联接。
A PIM relay PE does not implement the Upstream FSM. It simply forwards received Join/Prune messages out of the same set of upstream ports as in the PIM proxying case.
PIM继电器PE不执行上游FSM。它只是从与PIM代理情况相同的一组上游端口转发接收到的加入/删减消息。
In order to correctly facilitate Asserts among the CE routers, such Join/Prune messages need to send not only towards the upstream neighbor but also on certain PWs, as described below.
为了正确地促进CE路由器之间的断言，这样的加入/删减消息不仅需要向上游邻居发送，而且还需要在某些pw上发送，如下所述。
If JoinAttributeTlvs(*,G) is not empty, then it must be encoded in a Join(*,G) message sent upstream.
如果JoinAttributeTlvs（*，G）不为空，则必须在向上游发送的Join（*，G）消息中对其进行编码。
If JoinAttributeTlvs(S,G) is not empty, then it must be encoded in a Join(S,G) message sent upstream.
如果JoinAttributeTlvs（S，G）不是空的，则必须在向上游发送的Join（S，G）消息中对其进行编码。
The following rules apply to both (1) forwarded (in the case of PIM relay) and (2) refreshed and triggered (in the case of PIM proxying) (S,G) / (*,G) Join/Prune messages.
以下规则适用于（1）转发（对于PIM中继）和（2）刷新和触发（对于PIM代理）（S，G）/（*，G）加入/删除消息。
o The Upstream Neighbor field in the Join/Prune to be sent is set to the N in the corresponding Upstream FSM.
o 要发送的连接/修剪中的上游邻居字段在相应的上游FSM中设置为N。
o If Port(N) is an AC, send the message to Port(N).
o 如果端口（N）是AC，则将消息发送到端口（N）。
o Additionally, if OutgoingPortList(x,G,N) contains at least one AC, then the message MUST be sent to at least all the PWs in UpstreamPorts(G) (for (*,G)) or InheritedUpstreamPorts(S,G) (for (S,G)). Alternatively, the message MAY be sent to all PWs.
o 此外，如果OutgoingPortList（x，G，N）包含至少一个AC，则必须将消息发送到上游端口（G）（对于（*，G））或继承流端口（S，G）（对于（S，G））中的至少所有PW。或者，可以将消息发送到所有PW。
Sending to a subset of PWs as described above guarantees that if traffic (of the same flow) from two upstream routers were to reach this PE, then the two routers will receive from each other, triggering an Assert.
如上所述发送到PWs的子集可以保证，如果来自两个上游路由器的（相同流的）流量到达该PE，那么两个路由器将相互接收，从而触发断言。
Sending to all PWs guarantees that if two upstream routers both send traffic for the same flow (even if it is to different sets of downstream PEs), then the two routers will receive from each other, triggering an Assert.
发送到所有PWs保证，如果两个上游路由器都为相同的流发送流量（即使是发送到不同的下游PE集），那么两个路由器将相互接收，从而触发断言。
Bidirectional PIM (BIDIR-PIM) is a variation of PIM-SM. The main differences between PIM-SM and BIDIR-PIM are as follows:
双向PIM（BIDIR-PIM）是PIM-SM的一种变体。PIM-SM和BIDIR-PIM之间的主要区别如下：
o There are no source-based trees, and SSM is not supported (i.e., no (S,G) states) in BIDIR-PIM.
o 没有基于源的树，并且在BIDIR-PIM中不支持SSM（即没有（S，G）状态）。
o Multicast traffic can flow up the shared tree in BIDIR-PIM.
o 在BIDIR-PIM中，多播流量可以向上流动到共享树上。
o To avoid forwarding loops, one router on each link is elected as the Designated Forwarder (DF) for each RP in BIDIR-PIM.
o 为了避免转发循环，在BIDIR-PIM中，每个链路上的一个路由器被选为每个RP的指定转发器（DF）。
The main advantage of BIDIR-PIM is that it scales well for many-to-many applications. However, the lack of source-based trees means that multicast traffic is forced to remain on the shared tree.
BIDIR-PIM的主要优点是它可以很好地扩展多对多应用程序。然而，缺少基于源的树意味着多播流量必须保留在共享树上。
As described in RFC 5015 [BIDIR-PIM], parts of a BIDIR-PIM-enabled network may forward traffic without exchanging Join/Prune messages -- for instance, between DFs and the Rendezvous Point Link (RPL).
如RFC 5015[BIDIR-PIM]所述，启用BIDIR PIM的网络的一部分可以转发流量，而无需交换加入/删减消息——例如，在DFs和集合点链路（RPL）之间。
As the described procedures for PIM snooping rely on the presence of Join/Prune messages, enabling PIM snooping on BIDIR-PIM networks could break the BIDIR-PIM functionality. Deploying PIM snooping on BIDIR-PIM-enabled networks will require some further study. Some thoughts on this topic are discussed in Appendix A.
由于所述PIM窥探过程依赖于加入/删减消息的存在，因此在BIDIR-PIM网络上启用PIM窥探可能会破坏BIDIR-PIM功能。在支持BIDIR PIM的网络上部署PIM窥探需要进一步研究。关于这个主题的一些想法在附录A中讨论。
Whenever IGMP snooping is enabled in conjunction with PIM snooping in the same VPLS instance, the PE SHOULD follow these rules:
每当在同一VPLS实例中启用IGMP侦听和PIM侦听时，PE应遵循以下规则：
o To maintain the list of multicast routers and ports on which they are attached, the PE SHOULD NOT use the rules described in RFC 4541 [IGMP-SNOOP] but SHOULD rely on the neighbors discovered by PIM snooping. This list SHOULD then be used to apply the first forwarding rule (rule 1) listed in Section 2.1.1 of RFC 4541 [IGMP-SNOOP].
o 为了维护多播路由器及其连接端口的列表，PE不应使用RFC 4541[IGMP-SNOOP]中描述的规则，而应依赖PIM窥探发现的邻居。然后，应使用该列表应用RFC 4541[IGMP-SNOOP]第2.1.1节中列出的第一条转发规则（规则1）。
o If the PE supports proxy reporting, an IGMP membership learned only on a port to which a PIM neighbor is attached (i.e., not learned elsewhere) SHOULD NOT be included in the summarized upstream report sent to that port.
o 如果PE支持代理报告，则发送到该端口的汇总上游报告中不应包括仅在PIM邻居连接到的端口上学习的IGMP成员资格（即，未在别处学习）。
The key characteristic of PIM-DM is flood-and-prune behavior. Shortest-path trees are built as a multicast source starts transmitting.
PIM-DM的关键特征是泛洪和修剪行为。当多播源开始传输时，将建立最短路径树。
PIM-DM states are built by snooping on the PIM-DM Join, Prune, Graft, and State Refresh messages received on ACs/PWs and State Refresh messages sent on ACs/PWs. By snooping on these PIM-DM messages, a PE builds the following states per (S,G,N) where S is the address of the multicast source, G is the group address, and N is the upstream neighbor to which Prunes/Grafts are sent by downstream CEs:
PIM-DM状态是通过窥探ACs/PWs上接收的PIM-DM连接、修剪、嫁接和状态刷新消息以及ACs/PWs上发送的状态刷新消息来构建的。通过窥探这些PIM-DM消息，PE根据（S，G，N）建立以下状态，其中S是多播源的地址，G是组地址，N是下游CE向其发送剪枝/嫁接的上游邻居：
Per PIM(S,G,N):
根据PIM（S、G、N）：
Port PIM(S,G,N) Prune State:
端口PIM（S、G、N）修剪状态：
* DownstreamPState(S,G,N,Port): One of {"NoInfo" (NI), "Pruned" (P), "Prune-Pending" (PP)}
* 下游州（S、G、N、港口）：其中一个{“NoInfo”（NI），“Pruned”（P），“Prune Pending”（PP）}
* Prune-Pending Timer (PPT)
* 删除挂起计时器（PPT）
* Prune Timer (PT)
* 修剪计时器（PT）
* Upstream Port (valid if the PIM(S,G,N) Prune state is "Pruned")
* 上游端口（如果PIM（S、G、N）修剪状态为“修剪”，则有效）
The downstream per-port PIM(S,G,N) state machine is as defined in Section 4.4.2 of RFC 3973 [PIM-DM], with a few changes relevant to PIM snooping. When reading Section 4.4.2 of RFC 3973 [PIM-DM], please be aware that, for the purposes of PIM snooping, the downstream states are built per (S,G,N,Downstream-Port) in PIM snooping and not per (Downstream-Interface,S,G) as in a PIM-DM router. As noted in Section 2.9.1, the states (DownstreamPState) and timers (PPT and PT) are per (S,G,N,Port).
下游每端口PIM（S，G，N）状态机如RFC 3973[PIM-DM]第4.4.2节所定义，其中有一些与PIM窥探相关的更改。阅读RFC 3973[PIM-DM]第4.4.2节时，请注意，为了PIM窥探的目的，下游状态是按照PIM窥探中的（S，G，N，下游端口）构建的，而不是按照PIM-DM路由器中的（下游接口，S，G）构建的。如第2.9.1节所述，状态（下游状态）和计时器（PPT和PT）为per（S、G、N、端口）。
Since PIM-DM is a flood-and-prune protocol, traffic is flooded to all routers unless explicitly pruned. Since PIM-DM routers do not prune on non-RPF interfaces, PEs should typically not receive Prunes on Port(RPF-Neighbor). So, the asserting routers should typically be in pim_oiflist(S,G). In most cases, Assert election should occur naturally without any special handling, since data traffic will be forwarded to the asserting routers.
由于PIM-DM是一种泛洪和剪枝协议，除非明确剪枝，否则流量将被泛洪到所有路由器。由于PIM-DM路由器不会对非RPF接口进行修剪，因此PEs通常不应在端口（RPF邻居）上接收修剪。因此，断言路由器通常应该是pim_oiflist（S，G）。在大多数情况下，断言选择应该在没有任何特殊处理的情况下自然发生，因为数据流量将被转发到断言路由器。
However, there are some scenarios where a Prune might be received on a port that is also an upstream port. If we prune the port from pim_oiflist(S,G), then it would not be possible for the asserting routers to determine if traffic arrived on their downstream port. This can be fixed by adding pim_iifs(S,G) to pim_oiflist(S,G) so that data traffic flows to the upstream ports.
但是，在某些情况下，可能会在同时也是上游端口的端口上接收修剪。如果我们从pim_oiflist（S，G）中删除端口，那么断言路由器就不可能确定流量是否到达其下游端口。这可以通过将pim_iifs（S，G）添加到pim_oiflist（S，G）来解决，以便数据流量流向上游端口。
As noted earlier, PIM snooping will work correctly only if Join suppression is disabled in the VPLS. If Join suppression is enabled in the VPLS, then PEs MUST do PIM relay/proxying for VPLS multicast to work correctly. This section applies specifically to full proxying and not to relay.
如前所述，只有在VPLS中禁用连接抑制时，PIM侦听才能正常工作。如果VPLS中启用了加入抑制，则PEs必须执行PIM中继/代理，以便VPLS多播正常工作。本节特别适用于完全代理，而不适用于继电器。
A PIM proxying PE consumes Join/Prune messages and regenerates PIM Join/Prune messages to be sent upstream by implementing the Upstream FSM as specified in Section 4.5.4 of RFC 7761 [PIM-SM]. This is the only difference from PIM relay.
PIM代理PE根据RFC 7761[PIM-SM]第4.5.4节的规定，通过实施上游FSM，使用加入/删减消息并重新生成要向上游发送的PIM加入/删减消息。这是与动力传动系接口模块继电器的唯一区别。
The source IP address in PIM packets sent upstream SHOULD be the address of a PIM downstream neighbor in the corresponding Join/Prune state. The chosen address MUST NOT be the Upstream Neighbor field to be encoded in the packet. The Layer 2 encapsulation for the selected source IP address MUST be the encapsulation recorded in the PIM Neighbor Database for that IP address.
上游发送的PIM数据包中的源IP地址应为处于相应加入/删除状态的PIM下游邻居的地址。所选地址不能是要在数据包中编码的上游邻居字段。所选源IP地址的第2层封装必须是该IP地址的PIM邻居数据库中记录的封装。
PIM snooping/relay/proxying could be enabled on a LAN that connects a multicast source and a PIM First-Hop Router (FHR). As the FHR will not send any downstream Join/Prune messages, we will not be able to establish any forwarding states for that source. Therefore, if there is a source in the CE network that connects directly into the VPLS instance, then multicast traffic from that source MUST be sent to all PIM routers on the VPLS instance in addition to the IGMP
PIM窥探/中继/代理可以在连接多播源和PIM第一跳路由器（FHR）的LAN上启用。由于FHR不会发送任何下游加入/删减消息，因此我们将无法为该源建立任何转发状态。因此，如果CE网络中有一个源直接连接到VPLS实例，那么来自该源的多播流量必须发送到VPLS实例上除IGMP之外的所有PIM路由器
receivers in the VPLS. If there is already (S,G) or (*,G) snooping state that is formed on any PE, this will not happen per the current forwarding rules and guidelines. So, in order to determine if traffic needs to be flooded to all routers, a PE must be able to determine if the traffic came from a host on that LAN. There are three ways to address this problem:
VPLS中的接收器。如果已经在任何PE上形成（S，G）或（*，G）窥探状态，则根据当前的转发规则和指导原则，不会发生这种情况。因此，为了确定是否需要将流量淹没到所有路由器，PE必须能够确定流量是否来自该LAN上的主机。有三种方法可以解决此问题：
o The PE would have to do IPv4 ARP snooping and/or IPv6 Neighbor Discovery snooping to determine if a source is directly connected.
o PE必须进行IPv4 ARP侦听和/或IPv6邻居发现侦听，以确定源是否直接连接。
o Another option is to configure all PEs to indicate that there are CE sources that are directly connected to the VPLS instance and disallow snooping for the groups for which the source is going to send traffic. This way, traffic from that source to those groups will always be flooded within the provider network.
o 另一个选项是配置所有PE，以指示存在直接连接到VPLS实例的CE源，并且不允许对源将要为其发送流量的组进行窥探。这样，从该源到这些组的流量将始终淹没在提供商网络中。
o A third option is to require that sources of CE multicast traffic must be behind a router.
o 第三种选择是要求CE多播通信源必须位于路由器后面。
This document recommends the third option -- sources of traffic must be behind a router.
本文档推荐第三种选择——流量源必须位于路由器后面。
First, we define the rules that are common to PIM-SM and PIM-DM PEs. Forwarding rules for each protocol type are specified in the subsections below.
首先，我们定义PIM-SM和PIM-DM PEs通用的规则。每个协议类型的转发规则在下面的小节中指定。
If there is no matching forwarding state, then the PE SHOULD discard the packet, i.e., the UserDefinedPortList (Sections 2.12.1 and 2.12.2) SHOULD be empty.
如果没有匹配的转发状态，则PE应丢弃该数据包，即UserDefinedPortList（第2.12.1节和第2.12.2节）应为空。
The following general rules MUST be followed when forwarding multicast traffic in a VPLS:
在VPLS中转发多播流量时，必须遵循以下一般规则：
o Traffic arriving on a port MUST NOT be forwarded back onto the same port.
o 到达某个端口的流量不得转发回同一端口。
o Due to VPLS split-horizon rules, traffic ingressing on a PW MUST NOT be forwarded to any other PW.
o 根据VPLS分割地平线规则，PW上的流量进入不得转发给任何其他PW。
Per the rules in RFC 7761 [PIM-SM] and per the additional rules specified in this document,
根据RFC 7761[PIM-SM]中的规则和本文件中规定的附加规则，
OutgoingPortList(*,G) = immediate_olist(*,G) (+)
UpstreamPorts(*,G) (+)
Port(PimDR)
OutgoingPortList(*,G) = immediate_olist(*,G) (+)
UpstreamPorts(*,G) (+)
Port(PimDR)
OutgoingPortList(S,G) = inherited_olist(S,G) (+)
UpstreamPorts(S,G) (+)
(UpstreamPorts(*,G) (-)
UpstreamPorts(S,G,rpt)) (+)
Port(PimDR)
OutgoingPortList(S,G) = inherited_olist(S,G) (+)
UpstreamPorts(S,G) (+)
(UpstreamPorts(*,G) (-)
UpstreamPorts(S,G,rpt)) (+)
Port(PimDR)
RFC 7761 [PIM-SM] specifies how immediate_olist(*,G) and inherited_olist(S,G) are built. PimDR is the IP address of the PIM DR in the VPLS.
RFC 7761[PIM-SM]指定如何构建直接的集合（*，G）和继承的集合（S，G）。PimDR是VPLS中PIM DR的IP地址。
The PIM-SM snooping data-forwarding rules are defined below in pseudocode:
PIM-SM窥探数据转发规则在伪代码中定义如下：
BEGIN iif is the incoming port of the multicast packet. S is the source IP address of the multicast packet. G is the destination IP address of the multicast packet.
BEGIN iif是多播数据包的传入端口。S是多播数据包的源IP地址。G是多播数据包的目标IP地址。
If there is (S,G) state on the PE Then OutgoingPortList = OutgoingPortList(S,G) Else if there is (*,G) state on the PE Then OutgoingPortList = OutgoingPortList(*,G) Else OutgoingPortList = UserDefinedPortList Endif
如果PE上存在（S，G）状态，则OutgoingPortList=OutgoingPortList（S，G）否则如果PE上存在（*，G）状态，则OutgoingPortList=OutgoingPortList（*，G）否则OutgoingPortList=UserDefinedPortList Endif
If iif is an AC Then OutgoingPortList = OutgoingPortList (-) iif Else ## iif is a PW OutgoingPortList = OutgoingPortList (-) PWPorts Endif
如果iif是AC，则OutgoingPortList=OutgoingPortList（-）iif Else##iif是PW OutgoingPortList=OutgoingPortList（-）PWPorts Endif
Forward the packet to OutgoingPortList. END
将数据包转发到OutgoingPortList。终止
First, if there is (S,G) state on the PE, then the set of outgoing ports is OutgoingPortList(S,G).
首先，如果PE上存在（S，G）状态，则传出端口集是OutgoingPortList（S，G）。
Otherwise, if there is (*,G) state on the PE, then the set of outgoing ports is OutgoingPortList(*,G).
否则，如果PE上存在（*，G）状态，则传出端口集为OutgoingPortList（*，G）。
The packet is forwarded to the selected set of outgoing ports while observing the general rules above in Section 2.12.
在遵守上述第2.12节中的一般规则的同时，数据包被转发到选定的一组传出端口。
The PIM-DM snooping data-forwarding rules are defined below in pseudocode:
PIM-DM窥探数据转发规则在伪代码中定义如下：
BEGIN iif is the incoming port of the multicast packet. S is the source IP address of the multicast packet. G is the destination IP address of the multicast packet.
BEGIN iif是多播数据包的传入端口。S是多播数据包的源IP地址。G是多播数据包的目标IP地址。
If there is (S,G) state on the PE Then OutgoingPortList = olist(S,G) Else OutgoingPortList = UserDefinedPortList Endif
如果PE上存在（S，G）状态，则OutgoingPortList=olist（S，G）Else OutgoingPortList=UserDefinedPortList Endif
If iif is an AC Then OutgoingPortList = OutgoingPortList (-) iif Else ## iif is a PW OutgoingPortList = OutgoingPortList (-) PWPorts Endif
如果iif是AC，则OutgoingPortList=OutgoingPortList（-）iif Else##iif是PW OutgoingPortList=OutgoingPortList（-）PWPorts Endif
Forward the packet to OutgoingPortList. END
将数据包转发到OutgoingPortList。终止
If there is forwarding state for (S,G), then forward the packet to olist(S,G) while observing the general rules above in Section 2.12.
如果（S，G）存在转发状态，则在遵守上文第2.12节中的一般规则的同时，将数据包转发给olist（S，G）。
RFC 3973 [PIM-DM] specifies how olist(S,G) is constructed.
RFC 3973[PIM-DM]指定了olist（S，G）的构造方式。
This document does not require any IANA actions.
本文件不要求IANA采取任何行动。
Security considerations provided in the VPLS solution documents (i.e., RFC 4762 [VPLS-LDP] and RFC 4761 [VPLS-BGP]) apply to this document as well.
VPLS解决方案文件（即RFC 4762[VPLS-LDP]和RFC 4761[VPLS-BGP]）中提供的安全注意事项也适用于本文件。
[BIDIR-PIM] 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>.
[BIDIR-PIM]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>.
[JOIN-ATTR] Boers, A., Wijnands, I., and E. Rosen, "The Protocol Independent Multicast (PIM) Join Attribute Format", RFC 5384, DOI 10.17487/RFC5384, November 2008, <https://www.rfc-editor.org/info/rfc5384>.
[JOIN-ATTR]Boers，A.，Wijnands，I.，和E.Rosen，“协议独立多播（PIM）连接属性格式”，RFC 5384，DOI 10.17487/RFC5384，2008年11月<https://www.rfc-editor.org/info/rfc5384>.
[PIM-DM] 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>.
[PIM-DM]Adams，A.，Nicholas，J.，和W.Siadak，“协议独立多播-密集模式（PIM-DM）：协议规范（修订版）”，RFC 3973，DOI 10.17487/RFC3973，2005年1月<https://www.rfc-editor.org/info/rfc3973>.
[PIM-SM] 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>.
[PIM-SM]Fenner，B.，Handley，M.，Holbrook，H.，Kouvelas，I.，Parekh，R.，Zhang，Z.，和L.Zheng，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，STD 83，RFC 7761，DOI 10.17487/RFC77612016年3月<https://www.rfc-editor.org/info/rfc7761>.
[PIM-SSM] 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>.
[PIM-SSM]Holbrook，H.和B.Cain，“IP的源特定多播”，RFC 4607，DOI 10.17487/RFC4607，2006年8月<https://www.rfc-editor.org/info/rfc4607>.
[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>.
[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>.
[RPF-VECTOR] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path Forwarding (RPF) Vector TLV", RFC 5496, DOI 10.17487/RFC5496, March 2009, <https://www.rfc-editor.org/info/rfc5496>.
[RPF-VECTOR]Wijnands，IJ.，Boers，A.，和E.Rosen，“反向路径转发（RPF）向量TLV”，RFC 5496，DOI 10.17487/RFC5496，2009年3月<https://www.rfc-editor.org/info/rfc5496>.
[IGMP-SNOOP] Christensen, M., Kimball, K., and F. Solensky, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, <https://www.rfc-editor.org/info/rfc4541>.
[IGMP-SNOOP]Christensen，M.，Kimball，K.，和F.Solensky，“互联网组管理协议（IGMP）和多播侦听器发现（MLD）侦听交换机的注意事项”，RFC 4541，DOI 10.17487/RFC45412006年5月<https://www.rfc-editor.org/info/rfc4541>.
[VPLS-BGP] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, <https://www.rfc-editor.org/info/rfc4761>.
[VPLS-BGP]Kompella，K.，Ed.，和Y.Rekhter，Ed.，“使用BGP进行自动发现和信令的虚拟专用局域网服务（VPLS）”，RFC 4761，DOI 10.17487/RFC4761，2007年1月<https://www.rfc-editor.org/info/rfc4761>.
[VPLS-LDP] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, <https://www.rfc-editor.org/info/rfc4762>.
[VPLS-LDP]Lasserre，M.，Ed.，和V.Kompella，Ed.，“使用标签分发协议（LDP）信令的虚拟专用LAN服务（VPLS）”，RFC 4762，DOI 10.17487/RFC4762，2007年1月<https://www.rfc-editor.org/info/rfc4762>.
[VPLS-MCAST] Aggarwal, R., Ed., Kamite, Y., Fang, L., Rekhter, Y., and C. Kodeboniya, "Multicast in Virtual Private LAN Service (VPLS)", RFC 7117, DOI 10.17487/RFC7117, February 2014, <https://www.rfc-editor.org/info/rfc7117>.
[VPLS-MCAST]Aggarwal，R.，Ed.，Kamite，Y.，Fang，L.，Rekhter，Y.，和C.Kodeboniya，“虚拟专用局域网服务（VPLS）中的多播”，RFC 7117，DOI 10.17487/RFC71172014年2月<https://www.rfc-editor.org/info/rfc7117>.
[VPLS-MCAST-REQ] Kamite, Y., Ed., Wada, Y., Serbest, Y., Morin, T., and L. Fang, "Requirements for Multicast Support in Virtual Private LAN Services", RFC 5501, DOI 10.17487/RFC5501, March 2009, <https://www.rfc-editor.org/info/rfc5501>.
[VPLS-MCAST-REQ]Kamite，Y.，Ed.，Wada，Y.，Serbest，Y.，Morin，T.，和L.Fang，“虚拟专用LAN服务中多播支持的要求”，RFC 5501，DOI 10.17487/RFC5501，2009年3月<https://www.rfc-editor.org/info/rfc5501>.
This appendix describes some guidelines that may be used to preserve BIDIR-PIM functionality in combination with PIM snooping.
本附录描述了一些可用于结合PIM窥探来保留BIDIR-PIM功能的指南。
In order to preserve BIDIR-PIM snooping, routers need to set up forwarding states so that:
为了保护BIDIR-PIM窥探，路由器需要设置转发状态，以便：
o on the RPL, all traffic is forwarded to all Port(N) ports.
o 在RPL上，所有流量都转发到所有端口（N）端口。
o on any other interface, traffic is always forwarded to the DF.
o 在任何其他接口上，流量始终转发到DF。
The information needed to set up these states may be obtained by:
建立这些状态所需的信息可通过以下方式获得：
o determining the mapping between the group (range) and the RP.
o 确定组（范围）和RP之间的映射。
o snooping and storing DF election information.
o 窥探和存储DF选举信息。
o determining where the RPL is. This could be achieved by static configuration or by combining the information mentioned in the two bullet items above.
o 确定RPL的位置。这可以通过静态配置或结合上面两个项目符号中提到的信息来实现。
The BIDIR-PIM snooping data-forwarding rules are defined below in pseudocode:
BIDIR-PIM窥探数据转发规则在伪代码中定义如下：
BEGIN iif is the incoming port of the multicast packet. G is the destination IP address of the multicast packet.
BEGIN iif是多播数据包的传入端口。G是多播数据包的目标IP地址。
If there is forwarding state for G Then OutgoingPortList = olist(G) Else OutgoingPortList = UserDefinedPortList Endif
如果存在G的转发状态，则OutgoingPortList=olist（G）Else OutgoingPortList=UserDefinedPortList Endif
If iif is an AC Then OutgoingPortList = OutgoingPortList (-) iif Else ## iif is a PW OutgoingPortList = OutgoingPortList (-) PWPorts Endif
如果iif是AC，则OutgoingPortList=OutgoingPortList（-）iif Else##iif是PW OutgoingPortList=OutgoingPortList（-）PWPorts Endif
Forward the packet to OutgoingPortList. END
将数据包转发到OutgoingPortList。终止
If there is forwarding state for G, then forward the packet to olist(G) while observing the general rules above in Section 2.12.
如果存在G的转发状态，则在遵守上述第2.12节中的一般规则的同时，将数据包转发给olist（G）。
RFC 5015 [BIDIR-PIM] specifies how olist(G) is constructed.
RFC 5015[BIDIR-PIM]规定了如何构造olist（G）。
Let us consider the scenario in Figure 3.
让我们考虑图3中的场景。
+------+ AC3 +------+
| PE2 |-----| CE3 |
/| | +------+
/ +------+ |
/ | |
/ | |
/PW12 | |
/ | /---\
/ |PW23 | S |
/ | \---/
/ | |
/ | |
/ | |
+------+ / +------+ |
+------+ | PE1 |/ PW13 | PE3 | +------+
| CE1 |-----| |-------------| |-----| CE4 |
+------+ AC1 +------+ +------+ AC4 +------+
|
|AC2
+------+
| CE2 |
+------+
+------+ AC3 +------+
| PE2 |-----| CE3 |
/| | +------+
/ +------+ |
/ | |
/ | |
/PW12 | |
/ | /---\
/ |PW23 | S |
/ | \---/
/ | |
/ | |
/ | |
+------+ / +------+ |
+------+ | PE1 |/ PW13 | PE3 | +------+
| CE1 |-----| |-------------| |-----| CE4 |
+------+ AC1 +------+ +------+ AC4 +------+
|
|AC2
+------+
| CE2 |
+------+
Figure 3: An Example Network for Triggering an Assert
图3：触发断言的示例网络
In the examples below, JT(Port,S,G,N) is the downstream Join Expiry Timer on the specified Port for the (S,G) with upstream neighbor N.
在下面的示例中，JT（Port，S，G，N）是具有上游邻居N的（S，G）的指定端口上的下游加入到期计时器。
In the network depicted in Figure 3, S is the source of a multicast stream (S,G). CE1 and CE2 both have two ECMP routes to reach the source.
在图3所示的网络中，S是多播流（S，G）的源。CE1和CE2都有两条到达源头的ECMP路线。
1. CE1 sends a Join(S,G) with UpstreamNeighbors(S,G) = CE3.
1. CE1发送一个连接（S，G），其上游IGHBORS（S，G）=CE3。
2. PE1 snoops on the Join(S,G) and builds forwarding state, since it is received on an AC. It also floods the Join(S,G) in the VPLS. PE2 snoops on the Join(S,G) and builds forwarding state, since
2. PE1窥探连接（S，G）并建立转发状态，因为它是在AC上接收的。它还会在VPL中淹没连接（S，G）。PE2窥探连接（S、G）并建立转发状态，因为
the Join(S,G)is targeting a neighbor residing on an AC. PE3 does not create forwarding state for (S,G) because this is a PW-only Join and there is neither an existing (*,G) state with an AC in UpstreamPorts(*,G) nor an existing (S,G) state with an AC in UpstreamPorts(S,G). Both PE2 and PE3 will also flood the Join(S,G) in the VPLS.
连接（S，G）的目标是居住在AC上的邻居。PE3不会为（S，G）创建转发状态，因为这是一个仅限PW的连接，并且既没有上游入口（*，G）中存在AC的现有（*，G）状态，也没有上游入口（S，G）中存在AC的现有（S，G）状态。PE2和PE3也将淹没VPL中的连接（S，G）。
The resulting states at the PEs are as follows:
PEs的结果状态如下：
PE1 states:
JT(AC1,S,G,CE3) = JP_HoldTime
UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { PW12 }
OutgoingPortList(S,G) = { AC1, PW12 }
PE1 states:
JT(AC1,S,G,CE3) = JP_HoldTime
UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { PW12 }
OutgoingPortList(S,G) = { AC1, PW12 }
PE2 states:
JT(PW12,S,G,CE3) = JP_HoldTime
UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { AC3 }
OutgoingPortList(S,G) = { PW12, AC3 }
PE2 states:
JT(PW12,S,G,CE3) = JP_HoldTime
UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { AC3 }
OutgoingPortList(S,G) = { PW12, AC3 }
PE3 states: No (S,G) state
PE3状态：无（S，G）状态
3. The multicast stream (S,G) flows along CE3 -> PE2 -> PE1 -> CE1.
3. 多播流（S，G）沿着CE3->PE2->PE1->CE1流动。
4. Now CE2 sends a Join(S,G) with UpstreamNeighbors(S,G) = CE4.
4. 现在CE2发送一个连接（S，G），其上游IGHBORS（S，G）=CE4。
5. All PEs snoop on the Join(S,G), build forwarding state, and flood the Join(S,G) in the VPLS. Note that for PE2, even though this is a PW-only Join, forwarding state is built on this Join(S,G), since PE2 has an existing (S,G) state with an AC in UpstreamPorts(S,G).
5. 所有PEs在VPL中侦听连接（S，G）、生成转发状态和泛洪连接（S，G）。请注意，对于PE2，即使这是一个仅PW的连接，转发状态也建立在该连接（S，G）上，因为PE2在上游（S，G）中有一个AC的现有（S，G）状态。
The resulting states at the PEs are as follows:
PEs的结果状态如下：
PE1 states:
JT(AC1,S,G,CE3) = active
JT(AC2,S,G,CE4) = JP_HoldTime
UpstreamNeighbors(S,G) = { CE3, CE4 }
UpstreamPorts(S,G) = { PW12, PW13 }
OutgoingPortList(S,G) = { AC1, PW12, AC2, PW13 }
PE1 states:
JT(AC1,S,G,CE3) = active
JT(AC2,S,G,CE4) = JP_HoldTime
UpstreamNeighbors(S,G) = { CE3, CE4 }
UpstreamPorts(S,G) = { PW12, PW13 }
OutgoingPortList(S,G) = { AC1, PW12, AC2, PW13 }
PE2 states:
JT(PW12,S,G,CE4) = JP_HoldTime
JT(PW12,S,G,CE3) = active
UpstreamNeighbors(S,G) = { CE3, CE4 }
UpstreamPorts(S,G) = { AC3, PW23 }
OutgoingPortList(S,G) = { PW12, AC3, PW23 }
PE2 states:
JT(PW12,S,G,CE4) = JP_HoldTime
JT(PW12,S,G,CE3) = active
UpstreamNeighbors(S,G) = { CE3, CE4 }
UpstreamPorts(S,G) = { AC3, PW23 }
OutgoingPortList(S,G) = { PW12, AC3, PW23 }
PE3 states:
JT(PW13,S,G,CE4) = JP_HoldTime
UpstreamNeighbors(S,G) = { CE4 }
UpstreamPorts(S,G) = { AC4 }
OutgoingPortList(S,G) = { PW13, AC4 }
PE3 states:
JT(PW13,S,G,CE4) = JP_HoldTime
UpstreamNeighbors(S,G) = { CE4 }
UpstreamPorts(S,G) = { AC4 }
OutgoingPortList(S,G) = { PW13, AC4 }
6. The multicast stream (S,G) flows into the VPLS from two of the CEs -- CE3 and CE4. PE2 forwards the stream received from CE3 to PW23, and PE3 forwards the stream to AC4. This helps the CE routers to trigger Assert election. Let us say that CE3 becomes the Assert winner.
6. 多播流（S，G）从CE3和CE4这两个CE流入VPL。PE2将从CE3接收到的流转发给PW23，PE3将流转发给AC4。这有助于CE路由器触发断言选举。让我们说，CE3成为最终的赢家。
7. CE3 sends an Assert message to the VPLS. The PEs flood the Assert message without examining it.
7. CE3向VPLS发送断言消息。PEs在不检查Assert消息的情况下将其淹没。
8. CE4 stops sending the multicast stream to the VPLS.
8. CE4停止向VPLS发送多播流。
9. CE2 notices an RPF change due to the Assert and sends a Prune(S,G) with upstream neighbor = CE4. CE2 also sends a Join(S,G) with upstream neighbor = CE3.
9. CE2注意到由于断言而导致的RPF更改，并发送上游邻居=CE4的修剪（S，G）。CE2还发送上游邻居=CE3的连接（S，G）。
10. All the PEs start a Prune-Pending timer on the ports on which they received the Prune(S,G). When the Prune-Pending timer expires, all PEs will remove the downstream (S,G,CE4) states.
10. 所有PE在接收修剪的端口（S、G）上启动一个修剪挂起计时器。当修剪挂起计时器过期时，所有PEs将删除下游（S、G、CE4）状态。
The resulting states at the PEs are as follows:
PEs的结果状态如下：
PE1 states:
JT(AC1,S,G,CE3) = active
UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { PW12 }
OutgoingPortList(S,G) = { AC1, AC2, PW12 }
PE1 states:
JT(AC1,S,G,CE3) = active
UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { PW12 }
OutgoingPortList(S,G) = { AC1, AC2, PW12 }
PE2 states:
JT(PW12,S,G,CE3) = active
UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { AC3 }
OutgoingPortList(S,G) = { PW12, AC3 }
PE2 states:
JT(PW12,S,G,CE3) = active
UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { AC3 }
OutgoingPortList(S,G) = { PW12, AC3 }
PE3 states:
JT(PW13,S,G,CE3) = JP_HoldTime
UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { PW23 }
OutgoingPortList(S,G) = { PW13, PW23 }
PE3 states:
JT(PW13,S,G,CE3) = JP_HoldTime
UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { PW23 }
OutgoingPortList(S,G) = { PW13, PW23 }
Note that at this point at PE3, since there is no AC in OutgoingPortList(S,G) and no (*,G) or (S,G) state with an AC in UpstreamPorts(*,G) or UpstreamPorts(S,G), respectively, the existing (S,G) state at PE3 can also be removed. So, finally:
请注意，在PE3的这一点上，由于在OutgoingPortList（S，G）中没有AC，并且在上游入口（*，G）或上游入口（S，G）中分别没有AC（*，G）或（S，G）状态，因此也可以删除PE3处的现有（S，G）状态。因此，最后：
PE3 states: No (S,G) state
PE3状态：无（S，G）状态
Note that at the end of the Assert election, there should be no duplicate traffic forwarded downstream, and traffic should flow only on the desired path. Also note that there are no unnecessary (S,G) states on PE3 after the Assert election.
请注意，在断言选择结束时，不应存在向下游转发的重复流量，且流量应仅在所需路径上流动。还要注意的是，在Assert选举之后，PE3上没有不必要的（S，G）状态。
In the same network, let us assume that CE4 is the upstream neighbor towards the RP for G.
在同一网络中，假设CE4是G的RP的上游邻居。
JPST(S,G,N) is the JP sending timer for the (S,G) with upstream neighbor N.
JPST（S，G，N）是具有上游邻居N的（S，G）的JP发送计时器。
1. CE1 sends a Join(S,G) with UpstreamNeighbors(S,G) = CE3.
1. CE1发送一个连接（S，G），其上游IGHBORS（S，G）=CE3。
2. PE1 consumes the Join(S,G) and builds forwarding state, since the Join(S,G) is received on an AC.
2. PE1使用连接（S，G）并建立转发状态，因为连接（S，G）是在AC上接收的。
PE2 consumes the Join(S,G) and builds forwarding state, since the Join(S,G) is targeting a neighbor residing on an AC.
PE2使用连接（S，G）并建立转发状态，因为连接（S，G）的目标是居住在AC上的邻居。
PE3 consumes the Join(S,G) but does not create forwarding state for (S,G), since this is a PW-only Join and there is neither an existing (*,G) state with an AC in UpstreamPorts(*,G) nor an existing (S,G) state with an AC in UpstreamPorts(S,G).
PE3使用连接（S，G），但不为（S，G）创建转发状态，因为这是一个仅PW的连接，并且既没有上游入口（*，G）中存在AC的现有（*，G）状态，也没有上游入口（S，G）中存在AC的现有（S，G）状态。
The resulting states at the PEs are as follows:
PEs的结果状态如下：
PE1 states:
JT(AC1,S,G,CE3) = JP_HoldTime
JPST(S,G,CE3) = t_periodic
UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { PW12 }
OutgoingPortList(S,G) = { AC1, PW12 }
PE1 states:
JT(AC1,S,G,CE3) = JP_HoldTime
JPST(S,G,CE3) = t_periodic
UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { PW12 }
OutgoingPortList(S,G) = { AC1, PW12 }
PE2 states:
JT(PW12,S,G,CE3) = JP_HoldTime
JPST(S,G,CE3) = t_periodic
UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { AC3 }
OutgoingPortList(S,G) = { PW12, AC3 }
PE2 states:
JT(PW12,S,G,CE3) = JP_HoldTime
JPST(S,G,CE3) = t_periodic
UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { AC3 }
OutgoingPortList(S,G) = { PW12, AC3 }
PE3 states: No (S,G) state
PE3状态：无（S，G）状态
Joins are triggered as follows: PE1 triggers a Join(S,G) targeting CE3. Since the Join(S,G) was received on an AC and is targeting a neighbor that is residing across a PW, the triggered Join(S,G) is sent on all PWs.
联接的触发方式如下：PE1触发以CE3为目标的联接（S，G）。由于连接（S，G）是在AC上接收的，并且目标是驻留在PW上的邻居，因此触发的连接（S，G）将在所有PW上发送。
PE2 triggers a Join(S,G) targeting CE3. Since the Join(S,G) is targeting a neighbor residing on an AC, it only sends the Join on AC3.
PE2触发以CE3为目标的连接（S，G）。由于连接（S，G）的目标是位于AC上的邻居，因此它只在AC3上发送连接。
PE3 ignores the Join(S,G), since this is a PW-only Join and there is neither an existing (*,G) state with an AC in UpstreamPorts(*,G) nor an existing (S,G) state with an AC in UpstreamPorts(S,G).
PE3忽略连接（S，G），因为这是一个仅限PW的连接，并且既不存在上游端口（*，G）中存在AC的现有（*，G）状态，也不存在上游端口（S，G）中存在AC的现有（S，G）状态。
3. The multicast stream (S,G) flows along CE3 -> PE2 -> PE1 -> CE1.
3. 多播流（S，G）沿着CE3->PE2->PE1->CE1流动。
4. Now let us say that CE2 sends a Join(*,G) with UpstreamNeighbors(*,G) = CE4.
4. 现在让我们假设CE2发送一个连接（*，G）和上游IGHBORS（*，G）=CE4。
5. PE1 consumes the Join(*,G) and builds forwarding state, since the Join(*,G) is received on an AC.
5. PE1使用连接（*，G）并建立转发状态，因为连接（*，G）是在AC上接收的。
PE2 consumes the Join(*,G); although this is a PW-only Join, forwarding state is built on this Join(*,G), since PE2 has an existing (S,G) state with an AC in UpstreamPorts(S,G). However, since this is a PW-only Join, PE2 only adds the PW towards PE3 (PW23) into UpstreamPorts(*,G) and hence into OutgoingPortList(*,G). It does not add the PW towards PE1 (PW12) into OutgoingPortList(*,G).
PE2消耗连接（*，G）；尽管这是一个仅限PW的连接，但转发状态是建立在该连接（*，G）上的，因为PE2在上行端口（S，G）中有一个AC的现有（S，G）状态。然而，由于这是一个仅PW的连接，PE2只将PW向PE3（PW23）添加到上游入口（*，G）中，从而添加到OutgoingPortList（*，G）中。它不会将通向PE1（PW12）的PW添加到OutgoingPortList（*，G）中。
PE3 consumes the Join(*,G) and builds forwarding state, since the Join(*,G) is targeting a neighbor residing on an AC.
PE3使用连接（*，G）并建立转发状态，因为连接（*，G）的目标是居住在AC上的邻居。
The resulting states at the PEs are as follows:
PEs的结果状态如下：
PE1 states:
JT(AC1,*,G,CE4) = JP_HoldTime
JPST(*,G,CE4) = t_periodic
UpstreamNeighbors(*,G) = { CE4 }
UpstreamPorts(*,G) = { PW13 }
OutgoingPortList(*,G) = { AC2, PW13 }
PE1 states:
JT(AC1,*,G,CE4) = JP_HoldTime
JPST(*,G,CE4) = t_periodic
UpstreamNeighbors(*,G) = { CE4 }
UpstreamPorts(*,G) = { PW13 }
OutgoingPortList(*,G) = { AC2, PW13 }
JT(AC1,S,G,CE3) = active
JPST(S,G,CE3) = active
UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { PW12 }
OutgoingPortList(S,G) = { AC1, PW12, PW13 }
JT(AC1,S,G,CE3) = active
JPST(S,G,CE3) = active
UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { PW12 }
OutgoingPortList(S,G) = { AC1, PW12, PW13 }
PE2 states:
JT(PW12,*,G,CE4) = JP_HoldTime
UpstreamNeighbors(*,G) = { CE4 }
UpstreamPorts(G) = { PW23 }
OutgoingPortList(*,G) = { PW23 }
PE2 states:
JT(PW12,*,G,CE4) = JP_HoldTime
UpstreamNeighbors(*,G) = { CE4 }
UpstreamPorts(G) = { PW23 }
OutgoingPortList(*,G) = { PW23 }
JT(PW12,S,G,CE3) = active
JPST(S,G,CE3) = active
UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { AC3 }
OutgoingPortList(S,G) = { PW12, AC3, PW23 }
JT(PW12,S,G,CE3) = active
JPST(S,G,CE3) = active
UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { AC3 }
OutgoingPortList(S,G) = { PW12, AC3, PW23 }
PE3 states:
JT(PW13,*,G,CE4) = JP_HoldTime
JPST(*,G,CE4) = t_periodic
UpstreamNeighbors(*,G) = { CE4 }
UpstreamPorts(*,G) = { AC4 }
OutgoingPortList(*,G) = { PW13, AC4 }
PE3 states:
JT(PW13,*,G,CE4) = JP_HoldTime
JPST(*,G,CE4) = t_periodic
UpstreamNeighbors(*,G) = { CE4 }
UpstreamPorts(*,G) = { AC4 }
OutgoingPortList(*,G) = { PW13, AC4 }
Joins are triggered as follows: PE1 triggers a Join(*,G) targeting CE4. Since the Join(*,G) was received on an AC and is targeting a neighbor that is residing across a PW, the triggered Join(S,G) is sent on all PWs.
联接的触发方式如下：PE1触发以CE4为目标的联接（*，G）。由于连接（*，G）是在AC上接收的，并且目标是驻留在PW上的邻居，因此触发的连接（S，G）将在所有PW上发送。
PE2 does not trigger a Join(*,G) based on this Join, since this is a PW-only Join.
PE2不会基于此联接触发联接（*，G），因为这是仅限PW的联接。
PE3 triggers a Join(*,G) targeting CE4. Since the Join(*,G) is targeting a neighbor residing on an AC, it only sends the Join on AC4.
PE3触发以CE4为目标的连接（*，G）。由于联接（*，G）的目标是位于AC上的邻居，因此它只在AC4上发送联接。
6. If traffic is not flowing yet (i.e., step 3 is delayed so that it occurs after step 6) and in the interim JPST(S,G,CE3) on PE1 expires, causing it to send a refresh Join(S,G) targeting CE3, since the refresh Join(S,G) is targeting a neighbor that is residing across a PW, the refresh Join(S,G) is sent on all PWs.
6. 如果通信量尚未流动（即，步骤3被延迟，以致其发生在步骤6之后），并且在此期间PE1上的JPST（S，G，CE3）过期，导致其发送以CE3为目标的刷新连接（S，G），因为刷新连接（S，G）的目标是驻留在PW上的邻居，所以刷新连接（S，G）将在所有PW上发送。
7. Note that PE1 refreshes its JT based on reception of refresh Joins from CE1 and CE2.
7. 注意，PE1根据从CE1和CE2接收到的刷新连接刷新其JT。
PE2 consumes the Join(S,G) and refreshes the JT(PW12,S,G,CE3) timer.
PE2消耗联接（S，G）并刷新JT（PW12，S，G，CE3）计时器。
PE3 consumes the Join(S,G). It also builds forwarding state on this Join(S,G), even though this is a PW-only Join, since now PE2 has an existing (*,G) state with an AC in UpstreamPorts(*,G). However, since this is a PW-only Join, PE3 only adds the PW towards PE2 (PW23) into UpstreamPorts(S,G) and hence into OutgoingPortList(S,G). It does not add the PW towards PE1 (PW13) into OutgoingPortList(S,G).
PE3消耗联接（S，G）。它还在此连接（S，G）上构建转发状态，即使这是仅PW连接，因为现在PE2在上游（*，G）中有一个AC的现有（*，G）状态。然而，由于这是一个仅PW的连接，PE3只将PW向PE2（PW23）添加到上游入口（S，G）中，从而添加到OutgoingPortList（S，G）中。它不会将针对PE1（PW13）的PW添加到OutgoingPortList（S，G）中。
PE3 states:
JT(PW13,*,G,CE4) = active
JPST(S,G,CE4) = active
UpstreamNeighbors(*,G) = { CE4 }
UpstreamPorts(*,G) = { AC4 }
OutgoingPortList(*,G) = { PW13, AC4 }
PE3 states:
JT(PW13,*,G,CE4) = active
JPST(S,G,CE4) = active
UpstreamNeighbors(*,G) = { CE4 }
UpstreamPorts(*,G) = { AC4 }
OutgoingPortList(*,G) = { PW13, AC4 }
JT(PW13,S,G,CE3) = JP_HoldTime
UpstreamNeighbors(*,G) = { CE3 }
UpstreamPorts(*,G) = { PW23 }
OutgoingPortList(*,G) = { PW13, AC4, PW23 }
JT(PW13,S,G,CE3) = JP_HoldTime
UpstreamNeighbors(*,G) = { CE3 }
UpstreamPorts(*,G) = { PW23 }
OutgoingPortList(*,G) = { PW13, AC4, PW23 }
Joins are triggered as follows: PE2 already has (S,G) state, so it does not trigger a Join(S,G) based on reception of this refresh Join.
连接的触发方式如下：PE2已经具有（S，G）状态，因此它不会基于接收到此刷新连接而触发连接（S，G）。
PE3 does not trigger a Join(S,G) based on this Join, since this is a PW-only Join.
PE3不会基于此联接触发联接（S，G），因为这是仅限PW的联接。
8. The multicast stream (S,G) flows into the VPLS from two of the CEs -- CE3 and CE4. PE2 forwards the stream received from CE3 to PW12 and PW23. At the same time, PE3 forwards the stream received from CE4 to PW13 and PW23.
8. 多播流（S，G）从CE3和CE4这两个CE流入VPL。PE2将从CE3接收到的流转发到PW12和PW23。同时，PE3将从CE4接收到的流转发到PW13和PW23。
The stream received over PW12 and PW13 is forwarded by PE1 to AC1 and AC2.
通过PW12和PW13接收的流由PE1转发到AC1和AC2。
The stream received by PE3 over PW23 is forwarded to AC4. The stream received by PE2 over PW23 is forwarded to AC3. Either of these helps the CE routers to trigger Assert election.
PE3通过PW23接收的流被转发到AC4。PE2通过PW23接收的流被转发到AC3。其中任何一个都有助于CE路由器触发断言选举。
9. CE3 and/or CE4 send(s) Assert message(s) to the VPLS. The PEs flood the Assert message(s) without examining it.
9. CE3和/或CE4向VPLS发送断言消息。PEs在不检查断言消息的情况下将其淹没。
10. CE3 becomes the (S,G) Assert winner, and CE4 stops sending the multicast stream to the VPLS.
10. CE3成为（S，G）断言赢家，CE4停止向VPLS发送多播流。
11. CE2 notices an RPF change due to the Assert and sends a Prune(S,G,rpt) with upstream neighbor = CE4.
11. CE2注意到由于断言而导致的RPF更改，并发送上游邻居为CE4的修剪（S、G、rpt）。
12. PE1 consumes the Prune(S,G,rpt), and since PruneDesired(S,G,Rpt,CE4) is TRUE, it triggers a Prune(S,G,rpt) to CE4. Since the Prune is targeting a neighbor across a PW, it is sent on all PWs.
12. PE1消耗剪枝（S，G，rpt），并且由于PruneDesired（S，G，rpt，CE4）为TRUE，因此它会将剪枝（S，G，rpt）触发到CE4。由于剪枝的目标是PW中的一个邻居，因此会在所有PW上发送剪枝。
PE2 consumes the Prune(S,G,rpt) and does not trigger any Prune based on this Prune(S,G,rpt), since this was a PW-only Prune.
PE2消耗剪枝（S，G，rpt），并且不会基于该剪枝（S，G，rpt）触发任何剪枝，因为这是一个仅限PW的剪枝。
PE3 consumes the Prune(S,G,rpt), and since PruneDesired(S,G,rpt,CE4) is TRUE, it sends the Prune(S,G,rpt) on AC4.
PE3消耗剪枝（S，G，rpt），并且由于PruneDesired（S，G，rpt，CE4）为TRUE，它在AC4上发送剪枝（S，G，rpt）。
PE1 states:
JT(AC2,*,G,CE4) = active
JPST(*,G,CE4) = active
UpstreamNeighbors(*,G) = { CE4 }
UpstreamPorts(*,G) = { PW13 }
OutgoingPortList(*,G) = { AC2, PW13 }
PE1 states:
JT(AC2,*,G,CE4) = active
JPST(*,G,CE4) = active
UpstreamNeighbors(*,G) = { CE4 }
UpstreamPorts(*,G) = { PW13 }
OutgoingPortList(*,G) = { AC2, PW13 }
JT(AC2,S,G,CE4) = JP_HoldTime with S,G,rpt prune flag
JPST(S,G,CE4) = none, since this is sent along
with the Join(*,G) to CE4 based
on JPST(*,G,CE4) expiry
UpstreamPorts(S,G,rpt) = { PW13 }
UpstreamNeighbors(S,G,rpt) = { CE4 }
JT(AC2,S,G,CE4) = JP_HoldTime with S,G,rpt prune flag
JPST(S,G,CE4) = none, since this is sent along
with the Join(*,G) to CE4 based
on JPST(*,G,CE4) expiry
UpstreamPorts(S,G,rpt) = { PW13 }
UpstreamNeighbors(S,G,rpt) = { CE4 }
JT(AC1,S,G,CE3) = active
JPST(S,G,CE3) = active
UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { PW12 }
OutgoingPortList(S,G) = { AC1, PW12, AC2 }
JT(AC1,S,G,CE3) = active
JPST(S,G,CE3) = active
UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { PW12 }
OutgoingPortList(S,G) = { AC1, PW12, AC2 }
PE2 states:
JT(PW12,*,G,CE4) = active
UpstreamNeighbors(*,G) = { CE4 }
UpstreamPorts(*,G) = { PW23 }
OutgoingPortList(*,G) = { PW23 }
PE2 states:
JT(PW12,*,G,CE4) = active
UpstreamNeighbors(*,G) = { CE4 }
UpstreamPorts(*,G) = { PW23 }
OutgoingPortList(*,G) = { PW23 }
JT(PW12,S,G,CE4) = JP_HoldTime with S,G,rpt prune flag
JPST(S,G,CE4) = none, since this was created
off a PW-only Prune
UpstreamPorts(S,G,rpt) = { PW23 }
UpstreamNeighbors(S,G,rpt) = { CE4 }
JT(PW12,S,G,CE4) = JP_HoldTime with S,G,rpt prune flag
JPST(S,G,CE4) = none, since this was created
off a PW-only Prune
UpstreamPorts(S,G,rpt) = { PW23 }
UpstreamNeighbors(S,G,rpt) = { CE4 }
JT(PW12,S,G,CE3) = active
JPST(S,G,CE3) = active
UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { AC3 }
OutgoingPortList(*,G) = { PW12, AC3 }
JT(PW12,S,G,CE3) = active
JPST(S,G,CE3) = active
UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { AC3 }
OutgoingPortList(*,G) = { PW12, AC3 }
PE3 states:
JT(PW13,*,G,CE4) = active
JPST(*,G,CE4) = active
UpstreamNeighbors(*,G) = { CE4 }
UpstreamPorts(*,G) = { AC4 }
OutgoingPortList(*,G) = { PW13, AC4 }
PE3 states:
JT(PW13,*,G,CE4) = active
JPST(*,G,CE4) = active
UpstreamNeighbors(*,G) = { CE4 }
UpstreamPorts(*,G) = { AC4 }
OutgoingPortList(*,G) = { PW13, AC4 }
JT(PW13,S,G,CE4) = JP_HoldTime with S,G,rpt prune flag
JPST(S,G,CE4) = none, since this is sent along
with the Join(*,G) to CE4 based
on JPST(*,G,CE4) expiry
UpstreamNeighbors(S,G,rpt) = { CE4 }
UpstreamPorts(S,G,rpt) = { AC4 }
JT(PW13,S,G,CE4) = JP_HoldTime with S,G,rpt prune flag
JPST(S,G,CE4) = none, since this is sent along
with the Join(*,G) to CE4 based
on JPST(*,G,CE4) expiry
UpstreamNeighbors(S,G,rpt) = { CE4 }
UpstreamPorts(S,G,rpt) = { AC4 }
JT(PW13,S,G,CE3) = active
JPST(S,G,CE3) = none, since this state is
created by a PW-only Join
UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { PW23 }
OutgoingPortList(S,G) = { PW23 }
JT(PW13,S,G,CE3) = active
JPST(S,G,CE3) = none, since this state is
created by a PW-only Join
UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { PW23 }
OutgoingPortList(S,G) = { PW23 }
Even in this example, at the end of the (S,G) / (*,G) Assert election, there should be no duplicate traffic forwarded downstream, and traffic should flow only to the desired CEs.
即使在本例中，在（S，G）/（*，G）断言选择结束时，也不应存在向下游转发的重复流量，并且流量应仅流向所需的CE。
However, we don't have duplicate traffic because one of the CEs stops sending traffic due to the Assert, not because we don't have any forwarding state in the PEs to do this forwarding.
但是，我们没有重复流量，因为其中一个CEs由于断言而停止发送流量，而不是因为我们在PEs中没有任何转发状态来执行此转发。
Acknowledgements
致谢
Many members of the former L2VPN and PIM working groups have contributed to, and provided valuable comments and feedback on, this document, including Vach Kompella, Shane Amante, Sunil Khandekar, Rob Nath, Marc Lasserre, Yuji Kamite, Yiqun Cai, Ali Sajassi, Jozef Raets, Himanshu Shah (Ciena), and Himanshu Shah (Cisco).
前L2VPN和PIM工作组的许多成员对本文件做出了贡献，并提供了宝贵的意见和反馈，包括Vach Kompella、Shane Amante、Sunil Khandekar、Rob Nath、Marc Lasserre、Yuji Kamite、Yiqun Cai、Ali Sajassi、Jozef Raets、Himanshu Shah（CINA）和Himanshu Shah（Cisco）。
Contributors
贡献者
Yetik Serbest and Suresh Boddapati coauthored earlier draft versions of this document.
Yetik Serbest和Suresh Boddapati共同撰写了本文件的早期草案版本。
Karl (Xiangrong) Cai and Princy Elizabeth made significant contributions to bring the specification to its current state, especially in the area of Join forwarding rules.
Karl（Xianglong）Cai和Princy Elizabeth为规范的发展做出了重大贡献，尤其是在连接转发规则方面。
Authors' Addresses
作者地址
Olivier Dornon Nokia Copernicuslaan 50 B-2018 Antwerp Belgium
奥利维尔·多农诺基亚哥白尼50 B-2018比利时安特卫普
Email: olivier.dornon@nokia.com
Email: olivier.dornon@nokia.com
Jayant Kotalwar Nokia 701 East Middlefield Rd. Mountain View, CA 94043 United States of America
美国加利福尼亚州山景城东米德菲尔德路701号诺基亚公司，邮编94043
Email: jayant.kotalwar@nokia.com
Email: jayant.kotalwar@nokia.com
Venu Hemige Nokia
维努海米奇诺基亚
Email: vhemige@gmail.com
Email: vhemige@gmail.com
Ray Qiu mistnet.io
Ray.net.io
Email: ray@mistnet.io
Email: ray@mistnet.io
Jeffrey Zhang Juniper Networks, Inc. 10 Technology Park Drive Westford, MA 01886 United States of America
Jeffrey Zhang Juniper Networks，Inc.美国马萨诸塞州韦斯特福德科技园大道10号01886
Email: zzhang@juniper.net
Email: zzhang@juniper.net