Network Working Group D. Thaler
Request for Comments: 2715 Microsoft
Category: Informational October 1999
Network Working Group D. Thaler
Request for Comments: 2715 Microsoft
Category: Informational October 1999
Interoperability Rules for Multicast Routing Protocols
多播路由协议的互操作性规则
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
The rules described in this document will allow efficient interoperation among multiple independent multicast routing domains. Specific instantiations of these rules are given for the DVMRP, MOSPF, PIM-DM, PIM-SM, and CBT multicast routing protocols, as well as for IGMP-only links. Future versions of these protocols, and any other multicast routing protocols, may describe their interoperability procedure by stating how the rules described herein apply to them.
本文档中描述的规则将允许在多个独立的多播路由域之间进行有效的互操作。针对DVMRP、MOSPF、PIM-DM、PIM-SM和CBT多播路由协议以及仅IGMP链路，给出了这些规则的具体实例。这些协议和任何其他多播路由协议的未来版本可以通过说明本文所述规则如何应用于它们来描述它们的互操作性过程。
To allow sources and receivers inside multiple autonomous multicast routing domains (or "regions") to communicate, the domains must be connected by multicast border routers (MBRs). To prevent black holes or routing loops among domains, we assume that these domains are organized into one of the following topologies:
为了允许多个自治多播路由域（或“区域”）内的源和接收器通信，这些域必须通过多播边界路由器（MBR）连接。为了防止域之间出现黑洞或路由循环，我们假设这些域被组织为以下拓扑之一：
o A tree (or star) topology (figure 1) with a backbone domain at the root, stub domains at the leaves, and possibly "transit" domains as branches between the root and the leaves. Each pair of adjacent domains is connected by one or more MBRs. The root of each subtree of domains receives all globally-scoped traffic originated anywhere within the subtree, and forwards traffic to its parent and children where needed. Each parent domain's MBR injects a default route into its child domains, while child domains' MBRs inject actual (but potentially aggregated) routes into parent domains. Thus, the arrows in the figure indicate both the direction in which the default route points, as well as the direction in which all globally-scoped traffic is sent.
o 树形（或星形）拓扑（图1），根上有主干域，叶上有存根域，根和叶之间可能有“过渡”域作为分支。每对相邻域由一个或多个MBR连接。域的每个子树的根接收子树中任何位置产生的所有全局范围的流量，并在需要时将流量转发给其父级和子级。每个父域的MBR将默认路由注入其子域，而子域的MBR将实际（但可能聚合）路由注入父域。因此，图中的箭头既指示默认路由点的方向，也指示发送所有全局范围的流量的方向。
+--------+
+----| |----+
+---+ +---+ | ===> <=== |
| | | | +----| # |----+
| | | # | +-----#------+
| # | +---#-------| v |-----------+
+--#----| v | | |-----+
| v ===> ===> Backbone <=== <=== |
+-------| ^ | | ^ |-----+
+---#-------| ^ |-----#-----+
| # | +-----#------+ | # |-----+
| | | # | | <=== |
+---+ +---| | | |-----+
| ===> | +--------+
+---+--------+
+--------+
+----| |----+
+---+ +---+ | ===> <=== |
| | | | +----| # |----+
| | | # | +-----#------+
| # | +---#-------| v |-----------+
+--#----| v | | |-----+
| v ===> ===> Backbone <=== <=== |
+-------| ^ | | ^ |-----+
+---#-------| ^ |-----#-----+
| # | +-----#------+ | # |-----+
| | | # | | <=== |
+---+ +---| | | |-----+
| ===> | +--------+
+---+--------+
Figure 1: Tree Topology of Domains
图1：域的树拓扑
o An arbitrary topology, in which a higher level (inter-domain) routing protocol, such as HDVMRP [1] or BGMP [9], is used to calculate paths among domains. Each pair of adjacent domains is connected by one or more MBRs.
o 一种任意拓扑结构，其中使用更高级别（域间）路由协议（如HDVMRP[1]或BGMP[9]）来计算域之间的路径。每对相邻域由一个或多个MBR连接。
Section 2 describes rules allowing interoperability between existing multicast routing protocols [2,3,4,5,6], and reduces the interoperability problem from O(N^2) potential protocol interactions, to just N (1 per protocol) instantiations of the same set of invariant rules. This document specifically applies to Multicast Border Routers (MBRs) which meet the following assumptions:
第2节描述了允许现有多播路由协议之间互操作的规则[2,3,4,5,6]，并将互操作性问题从O（N^2）个潜在协议交互减少到相同不变规则集的N（每个协议1个）实例化。本文档特别适用于满足以下假设的多播边界路由器（MBR）：
o The MBR consists of two or more active multicast routing components, each running an instance of some multicast routing protocol. No assumption is made about the type of multicast routing protocol (e.g., broadcast-and-prune vs. explicit-join) any component runs, or the nature of a "component". Multiple components running the same protocol are allowed.
o MBR由两个或多个活动多播路由组件组成，每个组件运行某个多播路由协议的实例。没有对任何组件运行的多播路由协议类型（例如，广播和剪枝与显式连接）或“组件”的性质做出任何假设。允许运行相同协议的多个组件。
o The router is configured to forward packets between two or more independent domains. The router has one or more active interfaces in each domain, and one component per domain. The router also has an inter-component "alert dispatcher", which we cover in Section 3.
o 路由器配置为在两个或多个独立域之间转发数据包。路由器在每个域中有一个或多个活动接口，每个域有一个组件。路由器还有一个组件间的“警报调度器”，我们将在第3节中介绍。
o Only one multicast routing protocol is active per interface (we do not consider mixed multicast protocol LANs). Each interface on which multicast is enabled is thus "owned" by exactly one of the components.
o 每个接口只有一个多播路由协议是有效的（我们不考虑混合多播协议LAN）。因此，启用多播的每个接口仅由一个组件“拥有”。
o All components share a common forwarding cache of (S,G) entries, which are created when data packets are received, and can be deleted at any time. Only the component owning an interface may change information about that interface in the forwarding cache. Each forwarding cache entry has a single incoming interface (iif) and a list of outgoing interfaces (oiflist). Each component typically keeps a separate multicast routing table with any type of entries.
o 所有组件共享（S，G）条目的公共转发缓存，这些条目在接收数据包时创建，并可随时删除。只有拥有接口的组件才能在转发缓存中更改有关该接口的信息。每个转发缓存项都有一个传入接口（iif）和一个传出接口列表（oiflist）。每个组件通常保留一个单独的多播路由表，其中包含任何类型的条目。
Note that the guidelines in this document are implementation-independent. The same rules given in Section 2 apply in some form, regardless of the implementation. For example, they apply to each of the following architectural models:
请注意，本文件中的指南与实施无关。第2节中给出的相同规则以某种形式适用，无论实施情况如何。例如，它们适用于以下每个建筑模型：
o Single process (e.g., GateD): Several routing components in the same user-space process, running on top of a multicast-capable kernel.
o 单进程（例如，选通）：同一用户空间进程中的多个路由组件，运行在支持多播的内核之上。
o Multiple peer processes: Several routing components, each as a separate user-space process, all sitting on top of a multicast-capable kernel, with N*(N-1) interaction channels.
o 多个对等进程：几个路由组件，每个组件作为一个单独的用户空间进程，都位于支持多播的内核之上，具有N*（N-1）个交互通道。
o Multiple processes with arbiter: Multiple independent peer routing component processes which interact with each other and with the kernel solely through an independent arbitration daemon.
o 带仲裁器的多进程：多个独立的对等路由组件进程，通过独立的仲裁守护进程彼此交互并与内核交互。
o Monolith: Several routing components which are part of the "kernel" itself.
o Monolith：几个路由组件，它们是“内核”本身的一部分。
We describe all interactions between components in terms of "alerts". The nature of an alert is implementation-dependent (e.g., it may consist of a simple function call, writing to shared memory, use of IPC, or some other method) but alerts of some form exist in every model. Similarly, the originator of an alert is also implementation-dependent; for example, alerts may be originated by a component effecting a change, by an independent arbiter, or by the kernel.
我们用“警报”来描述组件之间的所有交互。警报的性质取决于实现（例如，它可能包括简单的函数调用、写入共享内存、使用IPC或其他方法），但每个模型中都存在某种形式的警报。同样，警报的发起人也依赖于实施；例如，警报可能由影响更改的组件、独立仲裁器或内核发出。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119中的说明进行解释。
To insure that a MBR fitting the above assumptions exhibits correct interdomain routing behavior, each MBR component MUST adhere to the following rules:
为确保符合上述假设的MBR表现出正确的域间路由行为，每个MBR组件必须遵守以下规则：
Rule 1: All components must agree on which component owns the incoming interface (iif) for a forwarding cache entry. This component, which we call the "iif owner" is determined by the dispatcher (see Section 3). The incoming component may select ANY interface it owns as the iif according to its own rules.
规则1：所有组件必须就哪个组件拥有转发缓存项的传入接口（iif）达成一致。这个组件，我们称之为“iif所有者”，由调度器确定（参见第3节）。传入组件可以根据自己的规则选择其拥有的任何接口作为iif。
When a routing change occurs which causes the iif to change to an interface owned by a different component, both the component previously owning the entry's iif and the component afterwards owning the entry's iif MUST notice the change (so the first can prune upstream and the second can join/graft upstream, for example). Typically, noticing such changes will happen as a result of normal protocol behavior.
当发生导致iif更改为其他组件所拥有的接口的路由更改时，先前拥有条目的iif的组件和之后拥有条目的iif的组件都必须注意到该更改（例如，第一个组件可以向上游修剪，第二个组件可以向上游连接/移植）。通常，注意到这些更改是正常协议行为的结果。
Rule 2: The component owning an interface specifies the criteria for which packets received on that interface are to be accepted or dropped (e.g., whether to perform an RPF check, and what scoped boundaries exist on that interface). Once a packet is accepted, however, it is processed according to the forwarding rules of all components.
规则2：拥有接口的组件指定接受或丢弃该接口上接收的数据包的标准（例如，是否执行RPF检查，以及该接口上存在哪些范围边界）。然而，一旦数据包被接受，它将根据所有组件的转发规则进行处理。
Furthermore, some multicast routing protocols (e.g. PIM) also require the ability to react to packets received on the "wrong" interface. To support these protocols, an MBR must allow a component to place any of its interfaces in "WrongIf Alert Mode". If a packet arrives on such an interface, and is not accepted according to Rule 2, then the component owning the interface MUST be alerted [(S,G) WrongIf alert]. Typically, WrongIf alerts must be rate-limited.
此外，一些多播路由协议（例如PIM）还要求能够对在“错误”接口上接收的数据包做出反应。为了支持这些协议，MBR必须允许组件将其任何接口置于“错误警报模式”。如果数据包到达此类接口，并且根据规则2未被接受，则必须向拥有该接口的组件发出警报[（S，G）Errorif alert]。通常情况下，错误IF警报必须具有速率限制。
Rule 3: Whenever a new (S,G) forwarding cache entry is to be created (e.g., upon accepting a packet destined to a non-local group), all components MUST be alerted [(S,G) Creation alert] so that they can set the forwarding state on their own outgoing interfaces (oifs) before the packet is forwarded.
规则3：每当要创建一个新的（S，G）转发缓存条目时（例如，在接受发送到非本地组的数据包时），必须向所有组件发出警报[（S，G）创建警报]，以便它们可以在转发数据包之前在自己的传出接口（OIF）上设置转发状态。
Note that (S,G) Creation alerts are not necessarily generated by one of the protocol components themselves.
请注意，（S，G）创建警报不一定由协议组件本身生成。
Rule 4: When a component removes the last oif from an (S,G) forwarding cache entry whose iif is owned by another component, or when such an (S,G) forwarding cache entry is created with an empty oif list, the component owning the iif MUST be alerted [(S,G) Prune alert] (so it can send a prune, for example).
规则4：当一个组件从iif属于另一个组件的（S，G）转发缓存项中删除最后一个oif时，或者当使用空oif列表创建这样的（S，G）转发缓存项时，必须向拥有iif的组件发出警报[（S，G）删减警报]（例如，它可以发送删减）。
Rule 5: When the first oif is added to an (S,G) forwarding cache entry whose iif is owned by another component, the component owning the iif MUST be alerted [(S,G) Join alert] (so it can send a join or graft, for example).
规则5：将第一个oif添加到iif由另一个组件拥有的（S，G）转发缓存项时，必须向拥有iif的组件发出警报[（S，G）加入警报]（例如，它可以发送加入或嫁接）。
The oif list in rules 4 and 5 must also logically include any virtual encapsulation interfaces such as those used for tunneling or for sending encapsulated packets to an RP/core.
规则4和5中的oif列表在逻辑上还必须包括任何虚拟封装接口，例如用于隧道传输或用于向RP/core发送封装包的接口。
Rule 6: Unless a component reports the aggregate group membership in the direction of its interfaces, it MUST be a "wildcard receiver" for all sources whose RPF interface is owned by another component ("externally-reached" sources). In addition, a component MUST be a "wildcard receiver" for all sources whose RPF interface is owned by that component ("internally-reached" sources) if any other component of the MBR is a wildcard receiver for externally-reached sources; this will happen naturally as a result of Rule 5 when it receives a (*,*) Join alert.
规则6：除非组件报告其接口方向的聚合组成员身份，否则它必须是RPF接口由另一个组件拥有的所有源的“通配符接收器”（“外部到达的”源）。此外，如果MBR的任何其他组件是外部到达源的通配符接收器，则该组件必须是RPF接口归该组件所有的所有源的“通配符接收器”（“内部到达的”源）；根据规则5，当它收到（*，*）加入警报时，这将自然发生。
For example, if the backbone does not keep global membership information, all MBR components in the backbone in a tree topology of domains, as well as all components owning the RPF interface towards the backbone are wildcard receivers for externally-reached sources.
例如，如果主干网不保留全局成员资格信息，则域树状拓扑中主干网中的所有MBR组件以及拥有通向主干网的RPF接口的所有组件都是外部到达源的通配符接收器。
MBRs need not be wildcard receivers (for internally- or externally-reached sources) if a higher-level routing protocol, such as BGMP, is used for routing between domains.
如果更高级别的路由协议（如BGMP）用于域之间的路由，则MBR不需要是通配符接收器（用于内部或外部到达的源）。
Special care must be taken to follow Rules 4 and 5 when forwarding cache entries can be deleted at will. Specifically, a component must be able to determine when the combined oiflist for (S,G) goes from null to non-null, and vice versa.
当可以随意删除转发缓存项时，必须特别注意遵守规则4和5。具体来说，组件必须能够确定（S，G）的组合oiflist何时从null变为非null，反之亦然。
This can be done in any implementation-specific manner, including, but not limited to, the following possibilities:
这可以通过任何特定于实现的方式实现，包括但不限于以下可能性：
o Whenever a component would modify the oiflist of a single forwarding cache entry if one existed, one is first created. The oiflist is then modified and Rules 4 and 5 applied after an (S,G) Creation alert is sent to all components and all components have updated the oiflist. OR,
o 每当组件修改单个转发缓存项（如果存在）的oiflist时，首先创建一个转发缓存项。然后，在向所有组件发送（S，G）创建警报并且所有组件都更新了oiflist之后，修改oiflist并应用规则4和5。或
o When a forwarding cache entry is to be deleted, a new alert [(S,G) Deletion alert] is sent to all components, and the entry is only deleted if all components then grant permission. Each component could then grant permission only if it had no (S,G) route table entry.
o 当要删除转发缓存条目时，将向所有组件发送新警报[（S，G）删除警报]，并且仅当所有组件随后授予权限时，才会删除该条目。然后，每个组件只有在没有（S，G）路由表条目时才能授予权限。
Using (*,G) Join alerts and (*,G) Prune alerts can reduce bandwidth usage by avoiding broadcast-and-prune behavior among domains when it is unnecessary. This optimization requires that each component be able to determine which other components are interested in any given group.
使用（*，G）加入警报和（*，G）删减警报可以避免不必要的域间广播和删减行为，从而减少带宽使用。这种优化要求每个组件能够确定在任何给定组中对哪些其他组件感兴趣。
Although this may be done in any implementation-dependent method, one example would be to maintain a common table (which we call the Component-Group Table) indexed by group-prefix, listing which components are interested in each group(prefix). Thus, any components which are wildcard receivers for externally-reached sources (i.e., those whose RPF interface is owned by another component) would be listed in all entries of this table, including a default entry. This table is thus loosely analogous to a forwarding cache of (*,G) entries, except that no distinction is made between incoming and outgoing interfaces.
尽管这可以在任何依赖于实现的方法中完成，但一个示例是维护一个按组前缀索引的公共表（我们称之为组件组表），列出每个组（前缀）中感兴趣的组件。因此，作为外部到达源的通配符接收器的任何组件（即，其RPF接口由另一个组件拥有的组件）都将列在该表的所有条目中，包括默认条目。因此，该表大致类似于（*，G）项的转发缓存，只是传入接口和传出接口之间没有区别。
We assume that each MBR has an "alert dispatcher". The dispatcher is responsible for selecting, for each (S,G) entry in the shared forwarding cache, the component owning the iif. It is also responsible for selecting to which component(s) a given alert should be sent.
我们假设每个MBR都有一个“警报调度器”。dispatcher负责为共享转发缓存中的每个（S，G）条目选择拥有iif的组件。它还负责选择应向哪些组件发送给定警报。
We describe here rules that may be used in the absence of any inter-domain multicast routing protocol, to enable interoperability in a tree topology of domains. If an inter-domain multicast routing protocol is in use, another dispatcher should be used instead. The Interop dispatcher does not own any interfaces.
我们在这里描述了在没有任何域间多播路由协议的情况下可以使用的规则，以实现域树拓扑中的互操作性。如果正在使用域间多播路由协议，则应使用另一个调度程序。互操作调度器不拥有任何接口。
To select the iif of an (S,G) entry, the iif owner is the component owning the next-hop interface towards S in the multicast RIB.
要选择（S，G）项的iif，iif所有者是拥有多播RIB中指向S的下一跳接口的组件。
The "iif owner" of (*,G) and (*,*) entries is the Interop dispatcher itself. This allows the Interop dispatcher to receive relevant alerts without owning any interfaces.
（*，G）和（*，*）项的“iif所有者”是互操作调度器本身。这允许Interop dispatcher在不拥有任何接口的情况下接收相关警报。
If the Interop dispatcher receives an (S,G) Creation alert, it adds no interfaces to the entry's oif list, since it owns none.
如果Interop dispatcher收到（S，G）创建警报，则不会向条目的oif列表添加任何接口，因为它不拥有任何接口。
When the Interop dispatcher receives a (*,G) Prune alert, the following actions are taken, depending on the number of components N which want to receive data for G. If N has just changed from 2 to 1, a (*,G) Prune alert is sent to the remaining component. If N has just changed from 1 to 0, a (*,G) Prune alert is sent to ALL components other than the 1.
当Interop dispatcher接收到（*，G）修剪警报时，将根据要接收G数据的组件N的数量采取以下操作。如果N刚从2更改为1，则（*，G）修剪警报将发送到其余组件。如果N刚从1更改为0，则会向除1之外的所有组件发送（*，G）修剪警报。
When the Interop dispatcher receives a (*,G) Join alert, the following actions are taken, depending on the number of components N which want to receive data for G. If N has just changed from 0 to 1, a (*,G) Join alert is sent to ALL components other than the 1. If N has just changed from 1 to 2, a (*,G) Join alert is sent to the original (1) component.
当Interop dispatcher收到（*，G）连接警报时，将根据要接收G数据的组件N的数量采取以下操作。如果N刚从0更改为1，则（*，G）连接警报将发送到除1之外的所有组件。如果N刚从1更改为2，则会向原始（1）组件发送（*，G）连接警报。
This dispatcher can be used with an inter-domain multicast routing protocol (such as BGMP) which allows global (S,G) and (*,G) trees.
此调度器可与域间多播路由协议（如BGMP）一起使用，该协议允许全局（S，G）和（*，G）树。
The iif owner of an (S,G) entry is the component owning the next-hop interface towards S in the multicast RIB.
（S，G）项的iif所有者是拥有多播RIB中指向S的下一跳接口的组件。
The iif owner of a (*,G) entry is the component owning the next-hop interface towards G in the multicast RIB.
（*，G）项的iif所有者是拥有多播RIB中指向G的下一跳接口的组件。
This dispatcher simply forwards all (S,G) and (*,G) alerts to the iif owner of the associated entry.
此调度器只需将所有（S，G）和（*，G）警报转发给相关条目的iif所有者。
In this section, we describe how the rules in section 2 apply to current versions of various protocols. Future versions, and additional protocols, should describe how these rules apply in a separate document.
在本节中，我们将描述第2节中的规则如何应用于各种协议的当前版本。未来版本和附加协议应在单独的文档中描述这些规则的应用方式。
In this section we describe how the rules in section 2 apply to DVMRP. We assume that the reader is familiar with normal DVMRP behavior as specified in [2].
在本节中，我们将介绍第2节中的规则如何应用于DVMRP。我们假设读者熟悉[2]中规定的正常DVMRP行为。
As with all broadcast-and-prune protocols, DVMRP components are automatically wildcard receivers for internally-reached sources. Unless some form of Domain-Wide-Reports (DWRs) [10] (synonymous with Regional-Membership-Reports as described in [1]) are added to DVMRP in the future, all DVMRP components also act as wildcard receivers for externally-reached sources. If DWRs are available for the domain, then a DVMRP component acts as a wildcard receiver for externally-reached sources only if internally-reached domains exist which do not support some form of DWRs.
与所有广播和删减协议一样，DVMRP组件自动成为内部到达源的通配符接收器。除非将来向DVMRP添加某种形式的域范围报告（DWR）[10]（与[1]中所述的区域成员报告同义），否则所有DVMRP组件还充当外部到达源的通配符接收器。如果DWR可用于域，则DVMRP组件仅当存在不支持某种形式DWR的内部到达域时，才充当外部到达源的通配符接收器。
One simple heuristic to approximate DWRs is to assume that if there are any internally-reached members, then at least one of them is a sender. With this heuristic, the presense of any (S,G) state for internally-reached sources can be used instead. Sending a data packet to a group is then equivalent to sending a DWR for the group.
近似DWR的一个简单启发式方法是假设如果有任何内部到达的成员，那么其中至少有一个是发送者。通过这种启发式，可以使用内部到达的源的任何（S，G）状态的存在。向组发送数据包相当于为组发送DWR。
A (*,*) Join alert is sent to the iif owner of the (*,*) entry (e.g., the Interop dispatcher) when the first component becomes a wildcard receiver for external sources. This may occur when a DVMRP component starts up which does not support some form of DWRs.
当第一个组件成为外部源的通配符接收器时，会向（*，*）项的iif所有者（例如，互操作调度器）发送（*，*）连接警报。这可能发生在DVMRP组件启动时，该组件不支持某种形式的DWR。
A (*,*) Prune alert is sent to the iif owner of the (*,*) entry (e.g., the Interop dispatcher) when all components are no longer wildcard receivers for external sources. This may occur when a DVMRP component which does not support some form of DWRs shuts down.
当所有组件不再是外部源的通配符接收器时，会向（*，*）条目的iif所有者（例如Interop dispatcher）发送（*，*）修剪警报。当不支持某种形式DWR的DVMRP组件关闭时，可能会发生这种情况。
An (S,G) Prune alert is sent to the component owning the iif for a forwarding cache entry whenever the last oif is removed from the entry, and the iif is owned by another component. In DVMRP, this may happen when:
每当从条目中删除最后一个oif，并且iif由另一个组件拥有时，就会向拥有转发缓存条目iif的组件发送（S，G）修剪警报。在DVMRP中，这可能发生在以下情况：
o A DVMRP (S,G) Prune message is received on the logical interface.
o 在逻辑接口上接收DVMRP（S，G）删减消息。
An (S,G) Join alert is sent to the component owning the iif for a forwarding cache entry whenever the first logical oif is added to an entry, and the iif is owned by another component. In DVMRP, this may happen when any of the following occur:
每当将第一个逻辑oif添加到条目，并且iif由另一个组件拥有时，就会向拥有转发缓存条目iif的组件发送（S，G）加入警报。在DVMRP中，当发生以下任一情况时，可能会发生这种情况：
o The oif's prune timer expires, or o A DVMRP (S,G) Graft message is received on the logical interface, or o IGMP [7] notifies DVMRP that directly-connected members of G now exist on the interface.
o oif的删减计时器过期，或o在逻辑接口上收到DVMRP（s，G）嫁接消息，或o IGMP[7]通知DVMRP接口上现在存在G的直接连接成员。
When it is known, for a group G, that there are no longer any members in the DVMRP domain which receive data for externally-reached sources from the local router, a (*,G) Prune alert is sent to the "iif owner" for (*,G) according to the dispatcher. In DVMRP, this may happen when:
当知道对于组G，DVMRP域中不再有任何成员从本地路由器接收外部到达源的数据时，根据调度程序向（*，G）的“iif所有者”发送（*，G）删减警报。在DVMRP中，这可能发生在以下情况：
o The DWR for G times out, or o The members-are-senders approximation is being used and the last (S,G) entry for G is timed out.
o G的DWR超时，或o正在使用成员是发送者近似值，并且G的最后一个（S，G）条目超时。
When it is first known that there are members of a group G in the DVMRP domain, a (*,G) Join alert is sent to the "iif owner" of (*,G). In DVMRP, this may happen when either of the following occurs:
当首次知道DVMRP域中存在组G的成员时，会向（*，G）的“iif所有者”发送（*，G）加入警报。在DVMRP中，当发生以下任一情况时，可能会发生这种情况：
o A DWR is received for G, or o The members-are-senders approximation is being used and a data packet for G is received on one of the component's interfaces.
o 为G接收DWR，或o成员为发送者。当使用近似值时，在组件的一个接口上接收G的数据包。
When a DVMRP component receives an (S,G) Creation alert, it adds all the component's interfaces to the entry's oif list (according to normal DVMRP behavior) EXCEPT:
当DVMRP组件收到（S，G）创建警报时，它会将该组件的所有接口添加到条目的oif列表中（根据正常DVMRP行为），除了：
o the iif, o interfaces without local members of the entry's group, and for which DVMRP (S,G) Prune messages have been received from all downstream dependent neighbors. o interfaces for which the router is not the designated forwarder for S, o and interfaces with scoped boundaries covering the group.
o iif，o接口没有入口组的本地成员，并且已从所有下游依赖邻居接收到DVMRP（s，G）删减消息。o路由器不是S、o的指定转发器的接口，以及范围边界覆盖组的接口。
When a DVMRP component receives an (S,G) Prune alert, and the forwarding cache entry's oiflist is empty, it sends a DVMRP (S,G) Prune message to the upstream neighbor according to normal DVMRP behavior.
当DVMRP组件收到（S，G）删减警报，且转发缓存项的oiflist为空时，它将根据正常DVMRP行为向上游邻居发送DVMRP（S，G）删减消息。
When a DVMRP component receives a (*,G) or (*,*) Prune alert, it is treated as if an (S,G) Prune alert were received for every existing DVMRP (S,G) entry covered. In addition, if DWRs are being used, a DWR Leave message is sent within its domain.
当DVMRP组件收到（*，G）或（*，*）删减警报时，它将被视为针对涵盖的每个现有DVMRP（S，G）条目收到（S，G）删减警报。此外，如果正在使用DWR，则会在其域内发送DWR离开消息。
When a DVMRP component receives an (S,G) Join alert, and a prune was previously sent upstream, it sends a DVMRP (S,G) Graft message to the upstream neighbor according to normal DVMRP behavior.
当DVMRP组件收到（S，G）加入警报，并且之前向上游发送了修剪时，它会根据正常的DVMRP行为向上游邻居发送DVMRP（S，G）嫁接消息。
When a DVMRP component receives a (*,G) or (*,*) Join alert, it is treated as if an (S,G) Join alert were received for every existing DVMRP (S,G) entry covered. In addition, if DWRs are being used, the component sends a DWR Join message within its domain.
当DVMRP组件收到（*，G）或（*，*）加入警报时，它将被视为针对涵盖的每个现有DVMRP（S，G）条目收到（S，G）加入警报。此外，如果正在使用DWR，组件将在其域内发送DWR连接消息。
In this section we describe how the rules in section 2 apply to MOSPF. We assume that the reader is familiar with normal MOSPF behavior as specified in [3]. We note that MOSPF allows joining and pruning entire groups, but not individual sources within groups.
在本节中，我们将介绍第2节中的规则如何应用于MOSPF。我们假设读者熟悉[3]中规定的正常MOSPF行为。我们注意到，MOSPF允许加入和删减整个组，但不允许加入组内的单个源。
Although interoperability between MOSPF and dense-mode protocols (such as DVMRP) is specified in [3], we describe here how an MOSPF implementation may interoperate with all other multicast routing protocols.
尽管在[3]中规定了MOSPF和密集模式协议（如DVMRP）之间的互操作性，但我们在这里描述了MOSPF实现如何与所有其他多播路由协议互操作。
An MOSPF component acts as a wildcard receiver for internally-reached sources if and only if any other component is a wildcard receiver for externally-reached sources. An MOSPF component acts as a wildcard receiver for externally-reached sources only if internally-reached domains exist which do not support some form of Domain-Wide-Reports (DWRs) [10]. Since MOSPF floods membership information throughout the domain, MOSPF itself is considered to support a form of DWRs natively.
当且仅当任何其他组件是外部到达源的通配符接收器时，MOSPF组件充当内部到达源的通配符接收器。仅当存在不支持某种形式的域范围报告（DWR）的内部到达域时，MOSPF组件才充当外部到达源的通配符接收器[10]。由于MOSPF在整个域中大量传播成员信息，因此MOSPF本身被认为在本地支持DWR的一种形式。
A (*,*) Join alert is sent to the iif owner of the (*,*) entry (e.g., the Interop dispatcher) when the first component becomes a wildcard receiver for external sources. This may occur when an MOSPF component starts up and decides to act in this role.
当第一个组件成为外部源的通配符接收器时，会向（*，*）项的iif所有者（例如，互操作调度器）发送（*，*）连接警报。当MOSPF组件启动并决定扮演此角色时，可能会发生这种情况。
A (*,*) Prune alert is sent to the iif owner of the (*,*) entry (e.g., the Interop dispatcher) when all components are no longer wildcard receivers for external sources. This may occur when an MOSPF component which was acting in this role shuts down.
当所有组件不再是外部源的通配符接收器时，会向（*，*）条目的iif所有者（例如Interop dispatcher）发送（*，*）修剪警报。当担任此角色的MOSPF组件关闭时，可能会发生这种情况。
When it is known that there are no longer any members of a group G in the MOSPF domain, a (*,G) Prune alert is sent to the "iif owner" for (*,G) according to the dispatcher. In MOSPF, this may happen when either:
当已知在MOSPF域中不再有组G的任何成员时，将根据调度程序向（*，G）的“iif所有者”发送（*，G）修剪警报。在MOSPF中，这可能发生在以下情况之一：
o IGMP notifies MOSPF that there are no longer any directly-connected group members on an interface, or o Any router's group-membership-LSA for G is aged out.
o IGMP通知MOSPF接口上不再有任何直接连接的组成员，或者G的任何路由器组成员LSA已过期。
When it is first known that there are members of a group G in the MOSPF domain, a (*,G) Join alert is sent to the "iif owner" of (*,G), according to the dispatcher. In MOSPF, this may happen when any of the following occur:
根据调度程序，当第一次知道MOSPF域中存在组G的成员时，会向（*，G）的“iif所有者”发送（*，G）加入警报。在MOSPF中，当出现以下情况时，可能会发生这种情况：
o IGMP notifies MOSPF that directly-connected group members now exist on the interface, or o A group-membership-LSA is received for G.
o IGMP通知MOSPF接口上现在存在直接连接的组成员，或者接收到G的组成员LSA。
When an MOSPF component receives an (S,G) Creation alert, it calculates the shortest path tree for the MOSPF domain, and adds the downstream interfaces to the entry's oif list according to normal MOSPF behavior.
当MOSPF组件收到（S，G）创建警报时，它会计算MOSPF域的最短路径树，并根据正常的MOSPF行为将下游接口添加到条目的oif列表中。
When an MOSPF component receives an (S,G) Prune alert, the alert is ignored, since MOSPF can only prune entire groups at a time.
当MOSPF组件收到（S，G）修剪警报时，该警报将被忽略，因为MOSPF一次只能修剪整个组。
When an MOSPF component receives a (*,G) Prune alert, and there are no directly-connected members on any MOSPF interface, the router "prematurely ages" out its group-membership-LSA for G in the MOSPF domain according to normal MOSPF behavior.
当MOSPF组件收到（*，G）删减警报，并且任何MOSPF接口上都没有直接连接的成员时，路由器会根据正常的MOSPF行为“提前老化”MOSPF域中G的组成员LSA。
When an MOSPF component receives either an (S,G) Join alert or a (*,G) Join alert, and G was not previously included in the router's group-membership-LSA (and the component is not a wildcard multicast receiver), it originates a group-membership-LSA in the MOSPF domain according to normal MOSPF behavior.
当MOSPF组件收到（S，G）加入警报或（*，G）加入警报，且G之前未包含在路由器的组成员LSA中（且该组件不是通配符多播接收器）时，它会根据正常MOSPF行为在MOSPF域中发起组成员LSA。
When an MOSPF component receives a (*,*) Prune alert, it ceases to be a wildcard multicast receiver in its domain.
当MOSPF组件收到（*，*）删减警报时，它不再是其域中的通配符多播接收器。
When an MOSPF component receives a (*,*) Join alert, it becomes a wildcard multicast receiver in its domain.
当MOSPF组件收到（*，*）加入警报时，它将成为其域中的通配符多播接收器。
In this section we describe how the rules in section 2 apply to Dense-mode PIM. We assume that the reader is familiar with normal PIM-DM behavior as specified in [6].
在本节中，我们将介绍第2节中的规则如何应用于密集模式PIM。我们假设读者熟悉[6]中规定的正常PIM-DM行为。
As with all broadcast-and-prune protocols, PIM-DM components are automatically wildcard receivers for internally-reached sources. Unless some form of Domain-Wide-Reports (DWRs) [10] are added to PIM-DM in the future, all PIM-DM components also act as wildcard receivers for externally-reached sources. If DWRs are available for the domain, then a PIM-DM component acts as a wildcard receiver for externally-reached sources only if internally-reached domains exist which do not support some form of DWRs.
与所有广播和删减协议一样，PIM-DM组件自动成为内部到达源的通配符接收器。除非将来在PIM-DM中添加某种形式的域范围报告（DWR）[10]，否则所有PIM-DM组件还充当外部到达源的通配符接收器。如果DWR可用于域，则仅当存在不支持某种形式DWR的内部到达域时，PIM-DM组件才充当外部到达源的通配符接收器。
One simple heuristic to approximate DWRs is to assume that if there are any internally-reached members, then at least one of them is a sender. With this heuristic, the presense of any (S,G) state for internally-reached sources can be used instead. Sending a data packet to a group is then equivalent to sending a DWR for the group.
近似DWR的一个简单启发式方法是假设如果有任何内部到达的成员，那么其中至少有一个是发送者。通过这种启发式，可以使用内部到达的源的任何（S，G）状态的存在。向组发送数据包相当于为组发送DWR。
A (*,*) Join alert is sent to the iif owner of the (*,*) entry (e.g., the Interop dispatcher) when the first component becomes a wildcard receiver for external sources. This may occur when a PIM-DM component starts up which does not support some form of DWRs.
当第一个组件成为外部源的通配符接收器时，会向（*，*）项的iif所有者（例如，互操作调度器）发送（*，*）连接警报。当不支持某种DWR形式的PIM-DM组件启动时，可能会发生这种情况。
A (*,*) Prune alert is sent to the iif owner of the (*,*) entry (e.g., the Interop dispatcher) when all components are no longer wildcard receivers for external sources. This may occur when a PIM-DM component which does not support some form of DWRs shuts down.
当所有组件不再是外部源的通配符接收器时，会向（*，*）条目的iif所有者（例如Interop dispatcher）发送（*，*）修剪警报。当不支持某种形式DWR的PIM-DM组件关闭时，可能会发生这种情况。
A (S,G) Prune alert is sent to the component owning the iif for a forwarding cache entry whenever the last oif is removed from the forwarding cache entry, and the iif is owned by another component. In PIM-DM, this may happen when:
每当从转发缓存项中删除最后一个oif，并且iif由另一个组件拥有时，就会向拥有转发缓存项iif的组件发送（S，G）修剪警报。在PIM-DM中，这可能发生在以下情况：
o A PIM (S,G) Join/Prune message with S in the prune list is received on a point-to-point interface. o The Oif-Timer in an (S,G) route table entry expires. o A PIM (S,G) Assert message from a preferred neighbor is received on the interface.
o 在点到点接口上接收到修剪列表中有S的PIM（S，G）加入/修剪消息。o（S，G）路由表条目中的Oif计时器过期。o接口上接收到来自首选邻居的PIM（S，G）断言消息。
A (S,G) Join alert is sent to the component owning the iif for a forwarding cache entry whenever the first oif is added to an entry, and the iif is owned by another component. In PIM-DM, this may happen when any of the following occur:
每当将第一个oif添加到条目，并且iif由另一个组件拥有时，就会向拥有转发缓存条目iif的组件发送（S，G）加入警报。在动力传动系接口模块（PIM-DM）中，当发生以下任一情况时，可能会发生这种情况：
o The oif's prune timer expires, or o A PIM-DM (S,G) Graft message is received on the interface, or o IGMP notifies PIM-DM that directly-connected group members now exist on the interface.
o oif的修剪计时器过期，或o接口上收到PIM-DM（s，G）嫁接消息，或o IGMP通知PIM-DM接口上现在存在直接连接的组成员。
When it is known that there are no longer any members of a group G in the PIM-DM domain which receive data for externally-reached sources from the local router, a (*,G) Prune alert is sent to the "iif owner" for (*,G) according to the dispatcher. In PIM-DM, this may happen when:
当已知PIM-DM域中不再有任何G组成员从本地路由器接收外部到达源的数据时，根据调度程序向（*，G）的“iif所有者”发送（*，G）删减警报。在PIM-DM中，这可能发生在以下情况：
o The DWR for G times out. o The members-are-senders approximation is being used and PIM-DM's last (S,G) entry for G is timed out.
o G的DWR超时。o正在使用成员为发送者近似值，PIM-DM的最后一个（s，G）G条目超时。
When it is first known that there are members of a group G in the PIM-DM domain, a (*,G) Join alert is sent to the "iif owner" of (*,G), according to the dispatcher. In PIM-DM, this may happen when either of the following occurs:
根据调度程序，当第一次知道PIM-DM域中存在组G的成员时，会向（*，G）的“iif所有者”发送（*，G）加入警报。在动力传动系接口模块（PIM-DM）中，当发生以下任一情况时，可能会发生这种情况：
o A DWR is received for G. o The members-are-senders approximation is being used and a data packet for G is received on one of the component's interfaces.
o 为G接收DWR。使用成员为发送者的近似值，并在组件的一个接口上接收G的数据包。
When a PIM-DM component receives an (S,G) Creation alert, it adds the component's interfaces to the entry's oif list (according to normal PIM-DM behavior) EXCEPT:
当PIM-DM组件收到（S，G）创建警报时，它会将组件的接口添加到条目的oif列表中（根据正常PIM-DM行为），但以下情况除外：
o the iif, o leaf networks without local members of the entry's group, o and interfaces with scoped boundaries covering the group.
o 没有入口组本地成员的iif，o叶网络，o和范围边界覆盖该组的接口。
When a PIM-DM component receives an (S,G) Prune alert, and the forwarding cache entry's oiflist is empty, it sends a PIM-DM (S,G) Prune message to the upstream neighbor according to normal PIM-DM behavior.
当PIM-DM组件收到（S，G）删减警报，且转发缓存项的oiflist为空时，它将根据正常PIM-DM行为向上游邻居发送PIM-DM（S，G）删减消息。
When a PIM-DM component receives a (*,G) or (*,*) Prune alert, it is treated as if an (S,G) Prune alert were received for every matching (S,G) entry.
当PIM-DM组件收到（*，G）或（*，*）修剪警报时，它被视为每个匹配（S，G）条目都收到（S，G）修剪警报。
When a PIM-DM component receives an (S,G) Join alert, and an (S,G) prune was previously sent upstream, it sends a PIM-DM (S,G) Graft message to the upstream neighbor according to normal PIM-DM behavior.
当PIM-DM组件接收到（S，G）连接警报，并且（S，G）剪枝之前已向上游发送时，它会根据正常的PIM-DM行为向上游邻居发送PIM-DM（S，G）嫁接消息。
When a PIM-DM component receives a (*,G) or (*,*) Join alert, then for each matching (S,G) entry in the PIM-DM routing table for which a prune was previously sent upstream, it sends a PIM-DM (S,G) Graft message to the upstream neighbor according to normal PIM-DM behavior. In addition, if DWR's are being used, the component sends a DWR Join message within its domain.
当PIM-DM组件收到（*，G）或（*，*）连接警报时，对于PIM-DM路由表中先前向上游发送修剪的每个匹配（S，G）条目，它将根据正常PIM-DM行为向上游邻居发送PIM-DM（S，G）嫁接消息。此外，如果正在使用DWR，组件将在其域内发送DWR连接消息。
In this section we describe how the rules in section 2 apply to Sparse-mode PIM. We assume that the reader is familiar with normal PIM-SM behavior, as specified in [4].
在本节中，我们将介绍第2节中的规则如何应用于稀疏模式PIM。我们假设读者熟悉[4]中规定的正常PIM-SM行为。
To achieve correct PIM-SM behavior within the domain, the PIM-SM domain MUST be convex so that Bootstrap messages reach all routers in the domain. That is, the shortest-path route from any internal router to any other internal router must lie entirely within the PIM domain.
为了在域内实现正确的PIM-SM行为，PIM-SM域必须是凸的，以便引导消息到达域中的所有路由器。也就是说，从任何内部路由器到任何其他内部路由器的最短路径路由必须完全位于PIM域内。
Unless some form of Domain-Wide-Reports (DWRs) [10] are added to PIM-SM in the future, all PIM-SM components act as wildcard receivers for externally-reached sources. If DWRs are available for the domain, then a PIM-SM component acts as a wildcard receiver for externally-reached sources only if internally-reached domains exist which do not support some form of DWRs.
除非将来在PIM-SM中添加某种形式的域范围报告（DWR）[10]，否则所有PIM-SM组件都充当外部到达源的通配符接收器。如果DWR可用于域，则PIM-SM组件仅当存在不支持某种形式DWR的内部到达域时，才充当外部到达源的通配符接收器。
A PIM-SM component acts as a wildcard receiver for internally-reached sources if and only if any other component is a wildcard receiver for externally-reached sources. It does this by periodically sending (*,*,RP) Joins to all RPs for non-local groups (for example, 239.x.x.x is considered locally-scoped, and PIM-SM components do not send (*,*,RP) Joins to RPs supporting only that portion of the address space). The period is set according to standard PIM-SM rules for periodic Join/Prune messages.
当且仅当任何其他组件是外部到达源的通配符接收器时，PIM-SM组件充当内部到达源的通配符接收器。它通过定期向非本地组的所有RPs发送（*，*，RP）联接来实现这一点（例如，239.x.x.x被认为是本地范围的，PIM-SM组件不向仅支持该部分地址空间的RPs发送（*，*，RP）联接）。周期根据定期加入/删除消息的标准PIM-SM规则设置。
To properly instantiate Rule 1, whenever PIM creates a PIM (S,G) entry for an externally-reached source, and the next hop towards S is reached via an interface owned by another component, the iif should always point towards S and not towards the RP for G. In addition, the Border-bit is set in all PIM Register messages for this entry.
为了正确地实例化规则1，每当PIM为外部到达的源创建一个PIM（S，G）条目，并且通过另一个组件拥有的接口到达到S的下一个跃点时，iif应始终指向S，而不是指向G的RP。此外，在该条目的所有PIM寄存器消息中设置边界位。
Finally, the PIM-SM component acts as a DR for externally-reached receivers in terms of being able to switch to the shortest-path tree for internally-reached sources.
最后，PIM-SM组件作为外部到达接收器的DR，能够切换到内部到达源的最短路径树。
A (*,*) Join alert is sent to the iif owner of the (*,*) entry (e.g., the Interop dispatcher) when the first component becomes a wildcard receiver for external sources. This may occur when a PIM-SM component starts up and decides to act in this role.
当第一个组件成为外部源的通配符接收器时，会向（*，*）项的iif所有者（例如，互操作调度器）发送（*，*）连接警报。当PIM-SM组件启动并决定担任此角色时，可能会发生这种情况。
A (*,*) Prune alert is sent to the iif owner of the (*,*) entry (e.g., the Interop dispatcher) when all components are no longer wildcard receivers for external sources. This may occur when a PIM-SM component which was acting in this role shuts down.
当所有组件不再是外部源的通配符接收器时，会向（*，*）条目的iif所有者（例如Interop dispatcher）发送（*，*）修剪警报。当扮演此角色的PIM-SM组件关闭时，可能会发生这种情况。
A (S,G) Prune alert is sent to the component owning the iif for a forwarding cache entry whenever the last oif is removed from the entry and the iif is owned by another component. In PIM-SM, this may happen when:
每当从条目中删除最后一个oif且iif归另一个组件所有时，将向拥有转发缓存条目iif的组件发送（S，G）修剪警报。在PIM-SM中，这可能发生在以下情况：
o A PIM (S,G) Join/Prune message with S in the prune list is received on a point-to-point interface, or o A PIM (S,G) Assert from a preferred neighbor was received on the interface, or o A PIM Register-Stop message is received for (S,G), or o The interface's Oif-Timer for PIM's (S,G) route table entry expires. o The Entry-Timer for PIM's (S,G) route table entry expires.
o 在点到点接口上接收到修剪列表中带有S的PIM（S，G）连接/修剪消息，或在接口上接收到来自首选邻居的PIM（S，G）断言，或接收到（S，G）的PIM寄存器停止消息，或接口的Oif计时器（PIM的（S，G）路由表条目过期。o PIM（s，G）路由表条目的条目计时器过期。
When it is known that there are no longer any members of a group G in the PIM-SM domain which receive data for externally-reached sources from the local router, a (*,G) Prune alert is sent to the "iif owner" for (*,G) according to the dispatcher. In PIM-SM, this may happen when:
当已知PIM-SM域中不再有任何G组成员从本地路由器接收外部到达源的数据时，根据调度程序向（*，G）的“iif所有者”发送（*，G）删减警报。在PIM-SM中，这可能发生在以下情况：
o A PIM (*,G) Join/Prune message with G in the prune list is received on a point-to-point interface, or o A PIM (*,G) Assert from a preferred neighbor was received on the interface, or o IGMP notifies PIM-SM that directly-connected members no longer exist on the interface. o The Entry-Timer for PIM's (*,G) route table entry expires.
o 在点到点接口上接收到Prune列表中带有G的PIM（*，G）Join/Prune消息，或者在接口上接收到来自首选邻居的PIM（*，G）断言，或者o IGMP通知PIM-SM接口上不再存在直接连接的成员。o PIM（*，G）路由表条目的条目计时器过期。
A (S,G) Join alert is sent to the component owning the iif for a forwarding cache entry whenever the first logical oif is added to an entry and the iif is owned by another component. In PIM-SM, this may happen when any of the following occur:
每当将第一个逻辑oif添加到条目且iif由另一个组件拥有时，将向拥有转发缓存条目iif的组件发送（S，G）加入警报。在PIM-SM中，当发生以下任一情况时，可能会发生这种情况：
o A PIM (S,G) Join/Prune message is received on the interface, or o The Register-Suppression-Timer for (S,G) expires, or o The Entry-Timer for an (S,G) negative-cache state route table entry expires.
o 接口上接收到PIM（S，G）加入/删减消息，或o（S，G）的寄存器抑制计时器过期，或o（S，G）负缓存状态路由表条目的条目计时器过期。
When it is first known that there are members of a group G in the PIM-SM domain, a (*,G) Join alert is sent to the "iif owner" of (*,G), according to the dispatcher. In PIM-SM, this may happen when any of the following occur:
当第一次知道PIM-SM域中存在组G的成员时，根据调度程序，会向（*，G）的“iif所有者”发送（*，G）加入警报。在PIM-SM中，当发生以下任一情况时，可能会发生这种情况：
o A PIM (*,G) Join/Prune message is received on the interface, or o A PIM (*,*,RP) Join/Prune message is received on the interface, or o (*,G) negative cache state expires, or o IGMP notifies PIM that directly-connected group members now exist on the interface.
o 接口上接收到PIM（*，G）加入/删减消息，或接口上接收到o PIM（*，*，RP）加入/删减消息，或o（*，G）负缓存状态过期，或o IGMP通知PIM接口上现在存在直接连接的组成员。
When a PIM-SM component receives an (S,G) Creation alert, it does a longest match search ((S,G), then (*,G), then (*,*,RP)) in its multicast routing table. All outgoing interfaces of that entry are then added to the forwarding cache entry. Unless the PIM-SM component owns the iif, the oiflist is also modified to support sending PIM Registers with the Border-bit set to the corresponding RP.
当PIM-SM组件收到（S，G）创建警报时，它在其多播路由表中执行最长匹配搜索（（S，G），然后（*，G），然后（*，*，RP））。然后将该条目的所有传出接口添加到转发缓存条目中。除非PIM-SM组件拥有iif，否则还将修改oiflist以支持将边界位设置为相应RP的PIM寄存器发送。
When a PIM-SM component receives an (S,G) Prune alert, and the forwarding cache entry's oiflist is empty, then for each PIM (S,G) state entry covered, it sends an (S,G) Join/Prune message with S in the prune list to the upstream neighbor according to normal PIM-SM behavior.
当PIM-SM组件收到（S，G）删减警报，且转发缓存项的oiflist为空时，则对于覆盖的每个PIM（S，G）状态项，它将根据正常PIM-SM行为向上游邻居发送（S，G）加入/删减消息，其中删减列表中有S。
When a PIM-SM component receives a (*,G) Prune alert, it sends a (*,G) Join/Prune message with G in the prune list to the upstream neighbor towards the RP for G, according to normal PIM-SM behavior.
当PIM-SM组件收到（*，G）修剪警报时，根据正常的PIM-SM行为，它向RP for G的上游邻居发送修剪列表中带有G的（*，G）加入/修剪消息。
When a PIM-SM component receives an (S,G) Join alert, it sends an (S,G) Join/Prune message to the next-hop neighbor towards S, and resets the (S,G) Entry-timer, according to normal PIM-SM behavior.
当PIM-SM组件接收到（S，G）加入警报时，它将（S，G）加入/删减消息发送到下一跳邻居，并根据正常PIM-SM行为重置（S，G）进入计时器。
When a PIM-SM component receives a (*,G) Join alert, then it sends a (*,G) Join/Prune message to the next-hop neighbor towards the RP for G, and resets the (*,G) Entry-timer, according to normal PIM-SM behavior.
当PIM-SM组件收到（*，G）加入警报时，它会向RP for G的下一跳邻居发送（*，G）加入/删减消息，并根据正常PIM-SM行为重置（*，G）进入计时器。
When a PIM-SM component receives a (*,*) Join alert, then it sends (*,*,RP) Join/Prune messages towards each RP.
当PIM-SM组件收到（*，*）连接警报时，它会向每个RP发送（*，*，RP）连接/删除消息。
When a PIM-SM component receives a (*,*) Prune alert, then it sends a (*,*,RP) Prune towards each RP.
当PIM-SM组件收到（*，*）修剪警报时，它会向每个RP发送（*，*，RP）修剪。
In this section we describe how the rules in section 2 apply to CBTv2. We assume that the reader is familiar with normal CBTv2 behavior as specified in [5]. We note that, like MOSPF, CBTv2 allows joining and pruning entire groups, but not individual sources within groups.
在本节中，我们将介绍第2节中的规则如何应用于CBTv2。我们假设读者熟悉[5]中规定的正常CBTv2行为。我们注意到，与MOSPF一样，CBTv2允许加入和删减整个组，但不允许加入组内的单个源。
Interoperability between a single CBTv2 stub domain and a DVMRP backbone is outlined in [8]. Briefly, CBTv2 MBR components are statically configured such that, whenever an external route exists between two or more MBRs, one is designated as the primary, and the others act as non-forwarding (to prevent duplicate packets) backups. Thus, a CBTv2 domain must not serve as transit between two domains if another route between them exists.
[8]概述了单个CBTv2存根域和DVMRP主干网之间的互操作性。简而言之，CBTv2 MBR组件是静态配置的，因此，每当两个或多个MBR之间存在外部路由时，其中一个被指定为主MBR，而另一个被指定为非转发（以防止重复数据包）备份。因此，如果两个域之间存在另一条路由，则CBTv2域不得用作两个域之间的传输。
We now describe how a CBTv2 implementation may extend this to interoperate with all other multicast routing protocols. A CBTv2 component acts as a wildcard receiver for internally-reached sources if and only if any other component is a wildcard receiver for externally-reached sources. It does this by sending JOIN-REQUESTs for all non-local group ranges to all known cores, as described in [8].
现在，我们将描述CBTv2实现如何将其扩展到与所有其他多播路由协议的互操作。当且仅当任何其他组件是外部到达源的通配符接收器时，CBTv2组件充当内部到达源的通配符接收器。它通过向所有已知的核心发送所有非本地组范围的加入请求来实现这一点，如[8]中所述。
Unless some form of Domain-Wide-Reports (DWRs) [10] are added to CBTv2 in the future, all CBTv2 components act as wildcard receivers for externally-reached sources. If DWRs are available for the domain, then a CBTv2 component acts as a wildcard receiver for externally-reached sources only if internally-reached domains exist which do not support some form of DWRs.
除非将来向CBTv2添加某种形式的域范围报告（DWR）[10]，否则所有CBTv2组件都充当外部到达源的通配符接收器。如果DWR可用于域，则CBTv2组件仅当存在不支持某种形式DWR的内部到达域时，才充当外部到达源的通配符接收器。
A (*,*) Join alert is sent to the iif owner of the (*,*) entry (e.g., the Interop dispatcher) when the first component becomes a wildcard receiver for external sources. This may occur when a PIM-SM component starts up and decides to act in this role.
当第一个组件成为外部源的通配符接收器时，会向（*，*）项的iif所有者（例如，互操作调度器）发送（*，*）连接警报。当PIM-SM组件启动并决定担任此角色时，可能会发生这种情况。
A (*,*) Prune alert is sent to the iif owner of the (*,*) entry (e.g., the Interop dispatcher) when all components are no longer wildcard receivers for external sources. This may occur when a PIM-SM component which was acting in this role shuts down.
当所有组件不再是外部源的通配符接收器时，会向（*，*）条目的iif所有者（例如Interop dispatcher）发送（*，*）修剪警报。当扮演此角色的PIM-SM组件关闭时，可能会发生这种情况。
When the last oif is removed from the core tree for G, a (*,G) Prune alert is sent to the "iif owner" for (*,G) according to the dispatcher. Since CBTv2 always sends all data to the core, the only time this can occur after the entry is created is when the MBR is the core. In this case, the last oif is removed from the entry when:
当从G的核心树中删除最后一个oif时，将根据调度程序向（*，G）的“iif所有者”发送（*，G）修剪警报。由于CBTv2始终将所有数据发送到core，因此在创建条目后，只有当MBR是core时才会发生这种情况。在这种情况下，在以下情况下，最后一个oif将从条目中删除：
o A QUIT-REQUEST is received on the logical interface, and there are no directly-connected members present on the interface, or o IGMP notifies CBT that there are no longer directly-connected members present on the interface, and the interface is not a CBT child interface for group G.
o 逻辑接口上接收到退出请求，并且接口上没有直接连接的成员，或者o IGMP通知CBT接口上不再有直接连接的成员，并且该接口不是组G的CBT子接口。
When the first CBT outgoing interface is added to an existing core tree, a (*,G) Join alert is sent to the "iif owner" of (*,G) according to the dispatcher. Since CBTv2 always sends all data to the core, the only time these can occur, other than when the entry is created, is when the MBR is the core. In this case, the first logical oif is added to an entry when:
将第一个CBT传出接口添加到现有核心树时，将根据调度程序向（*，G）的“iif所有者”发送（*，G）加入警报。由于CBTv2始终将所有数据发送到core，因此除了创建条目外，这些数据唯一可能发生的时间是MBR作为core时。在这种情况下，第一个逻辑oif将在以下情况下添加到条目：
o A JOIN-REQUEST for G is received on the interface, or o IGMP notifies CBT that directly-connected group members now exist on the interface.
o 接口上接收到G的加入请求，或者o IGMP通知CBT接口上现在存在直接连接的组成员。
When a CBTv2 component receives an (S,G) Creation alert, and the router is functioning as the designated BR, any CBT interfaces which are on the tree for G are added to the forwarding cache entry's oif list (according to normal CBTv2 behavior).
当CBTv2组件收到（S，G）创建警报，并且路由器作为指定的BR运行时，G树上的任何CBT接口都将添加到转发缓存项的oif列表中（根据正常CBTv2行为）。
When a CBTv2 component receives an (S,G) Prune alert, the alert is ignored, since CBTv2 cannot prune specific sources. Thus, it will continue to receive packets from S since it must receive packets from other sources in group G.
当CBTv2组件收到（S，G）删减警报时，警报将被忽略，因为CBTv2无法删减特定源。因此，它将继续从S接收数据包，因为它必须从G组中的其他源接收数据包。
When a CBTv2 component receives a (*,G) Prune alert, and the router is not the primary core for G, and the only CBT on-tree interface is the interface towards the core, it sends a QUIT-REQUEST to the next-hop neighbor towards the core, according to normal CBTv2 behavior.
当CBTv2组件接收到（*，G）删减警报时，路由器不是G的主核心，并且树上唯一的CBT接口是指向核心的接口，它根据正常的CBTv2行为向指向核心的下一跳邻居发送退出请求。
When a CBTv2 component receives either an (S,G) Join alert or a (*,G) Join alert, and the router is not the primary core for G, and the router is not already on the core-tree for G, it sends a CBT (*,G) JOIN-REQUEST to the next-hop neighbor towards the core, according to normal CBTv2 behavior.
当CBTv2组件接收到（S，G）加入警报或（*，G）加入警报，并且路由器不是G的主核心，并且路由器不在G的核心树上时，根据正常CBTv2行为，它向核心的下一跳邻居发送CBT（*，G）加入请求。
In this section we describe how the rules in section 2 apply to a link which is not within any routing domain, and hence no routing protocol messages are exchanged and the interface is not owned by any multicast routing protocol component. We assume that the reader is familiar with normal IGMP behavior as specified in [7]. We note that IGMPv2 allows joining and pruning entire groups, but not individual sources within groups.
在本节中，我们将描述第2节中的规则如何应用于不在任何路由域内的链路，因此不交换路由协议消息，并且接口不属于任何多播路由协议组件。我们假设读者熟悉[7]中规定的正常IGMP行为。我们注意到，IGMPv2允许加入和修剪整个组，但不允许加入组内的单个源。
An IGMP-only "component" may only own a single interface; hence an IGMP-only domain only consists of a single link. Since an IGMP-only component can only act as a wildcard receiver for internally-reached sources if all internally-reached sources are directly-connected, then either the IGMP-only domain (link) must be a stub domain, or else there must be no other components which are wildcard receivers for externally-reached sources.
仅IGMP的“组件”只能拥有一个接口；因此，仅IGMP域仅由单个链路组成。由于如果所有内部到达的源都直接连接，则仅IGMP组件只能充当内部到达源的通配符接收器，因此仅IGMP域（链路）必须是存根域，否则不得有其他组件作为外部到达源的通配符接收器。
When it is known that there are no longer any directly-connected members of a group G on the IGMP-only interface, a (*,G) Prune alert is sent to the "iif owner" for (*,G) according to the dispatcher. In IGMP, this may happen when:
当知道在IGMP only接口上不再存在组G的任何直接连接成员时，根据调度程序向（*，G）的“iif所有者”发送（*，G）删减警报。在IGMP中，这可能发生在以下情况：
o The group membership times out.
o 组成员身份超时。
When it is first known that there are directly-connected members of a group G on the interface, a (*,G) Join alert is sent to the "iif owner" of (*,G), according to the dispatcher. In IGMP, this may happen when any of the following occur:
当第一次知道接口上有组G的直接连接成员时，根据调度程序，会向（*，G）的“iif所有者”发送（*，G）加入警报。在IGMP中，当发生以下任一情况时，可能会发生这种情况：
o A Membership Report is received for G.
o 收到G的成员报告。
When an IGMP-only component receives an (S,G) Creation alert, and there are directly-connected members of G present on its interface, it adds the interface to the entry's oif list.
当仅IGMP组件收到（S，G）创建警报，且其接口上存在直接连接的G成员时，它会将该接口添加到条目的oif列表中。
When an IGMP-only component receives an (S,G) Prune alert, the alert is ignored, since IGMP can only prune entire groups at a time.
当仅IGMP组件收到（S，G）修剪警报时，该警报将被忽略，因为IGMP一次只能修剪整个组。
When an IGMP-only component receives a (*,G) Prune alert, the router leaves the group G, sending an IGMP Leave message if it was the last reporter, according to normal IGMPv2 behavior.
当仅IGMP组件收到（*，G）删减警报时，路由器离开组G，根据正常的IGMPv2行为，如果它是最后一个报告者，则发送IGMP离开消息。
When an IGMP-only component receives a (*,*) Prune alert, it leaves promiscuous multicast mode.
当仅IGMP组件收到（*，*）删除警报时，它将离开混杂多播模式。
When an IGMP-only component receives either an (S,G) Join alert or a (*,G) Join alert, and the component was not previously a member of G on the IGMP-only interface (and the component is not a wildcard receiver for internally reached sources), it joins the group on the interface, causing it to send an unsolicited Membership Report according to normal IGMP behavior.
当仅IGMP组件收到（S，G）加入警报或（*，G）加入警报，且该组件以前不是仅IGMP接口上的G成员（且该组件不是内部到达源的通配符接收器），它将加入接口上的组，使其根据正常的IGMP行为发送未经请求的成员资格报告。
When an IGMP-only component receives a (*,*) Join alert, it enters promiscuous multicast mode.
当仅IGMP组件收到（*，*）加入警报时，它将进入混杂多播模式。
All operations described herein are internal to multicast border routers. The rules described herein do not change the security issues underlying individual multicast routing protcols. Allowing different protocols to interact, however, means that security weaknesses of any particular protocol may also apply to the other protocols as a result.
本文描述的所有操作都是多播边界路由器的内部操作。本文描述的规则不会改变单个多播路由协议背后的安全问题。然而，允许不同的协议进行交互意味着任何特定协议的安全弱点也可能因此适用于其他协议。
[1] Ajit S. Thyagarajan and Stephen E. Deering. Hierarchical distance-vector multicast routing for the MBone. In "Proceedings of the ACM SIGCOMM", pages 60--66, October 1995.
[1] Ajit S.Thyagarajan和Stephen E.Deering。MBone的分层距离向量多播路由。在“ACM SIGCOMM会议录”中，第60-66页，1995年10月。
[2] Pusateri, T., "Distance Vector Multicast Routing Protocol", Work in Progress.
[2] “距离向量多播路由协议”，正在进行中。
[3] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994.
[3] Moy，J.，“OSPF的多播扩展”，RFC1584，1994年3月。
[4] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Liu, C., Sharma, P. and L. Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998.
[4] Estrin，D.，Farinaci，D.，Helmy，A.，Thaler，D.，Deering，S.，Handley，M.，Jacobson，V.，Liu，C.，Sharma，P.和L.Wei，“协议独立多播稀疏模式（PIM-SM）：协议规范”，RFC 2362，1998年6月。
[5] Ballardie, A., "Core Based Trees (CBT version 2) Multicast Routing", RFC 2189, September 1997.
[5] Ballardie，A.，“基于核心的树（CBT版本2）多播路由”，RFC2189，1997年9月。
[6] Estrin, Farinacci, Helmy, Jacobson, and Wei, "Protocol Independent Multicast (PIM), Dense Mode Protocol Specification", Work in Progress.
[6] Estrin、Farinaci、Helmy、Jacobson和Wei，“协议独立多播（PIM），密集模式协议规范”，工作正在进行中。
[7] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[7] Fenner，W.，“互联网组管理协议，第2版”，RFC 2236，1997年11月。
[8] Ballardie, A., "Core Based Tree (CBT) Multicast Border Router Specification", Work in Progress.
[8] Ballardie，A.，“基于核心的树（CBT）多播边界路由器规范”，正在进行中。
[9] Thaler, D., Estrin, D. and D. Meyer, "Border Gateway Multicast Protocol (BGMP): Protocol Specification", Work in Progress.
[9] Thaler，D.，Estrin，D.和D.Meyer，“边界网关多播协议（BGMP）：协议规范”，正在进行的工作。
[10] Fenner, W., "Domain Wide Multicast Group Membership Reports", Work in Progress.
[10] Fenner，W.，“域范围多播组成员报告”，正在进行中。
Dave Thaler Microsoft One Microsoft Way Redmond, WA 98052
Dave Thaler Microsoft One Microsoft Way Redmond，WA 98052
Phone: (425) 703-8835 EMail: dthaler@microsoft.com
电话：（425）703-8835电子邮件：dthaler@microsoft.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。