[要約] 要約：RFC 2715は、マルチキャストルーティングプロトコルの相互運用性ルールに関するガイドラインです。 目的：このRFCの目的は、異なるマルチキャストルーティングプロトコル間の相互運用性を確保し、ネットワークの効率と信頼性を向上させることです。
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.
Copyright（c）The Internet Society（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）。隣接するドメインの各ペアは、1つ以上のMBRで接続されています。ドメインの各サブツリーのルートは、サブツリー内のどこかで発信されるすべてのグローバルにスコープされたトラフィックを受け取り、必要に応じて親と子供にトラフィックを転送します。各親ドメインのMBRはデフォルトのルートを子ドメインに注入し、子ドメインのMBRは実際に（ただし潜在的に集約された）ルートを親ドメインに注入します。したがって、図の矢印は、デフォルトのルートがポイントする方向と、すべてのグローバルにスコープしたトラフィックが送信される方向の両方を示しています。
+--------+
+----| |----+
+---+ +---+ | ===> <=== |
| | | | +----| # |----+
| | | # | +-----#------+
| # | +---#-------| 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]などのより高いレベル（ドメイン間）ルーティングプロトコルを使用して、ドメイン間のパスを計算するために使用されます。隣接するドメインの各ペアは、1つ以上の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）潜在的なプロトコル相互作用から相互運用性の問題を減らします。同じ不変ルールのセット。このドキュメントは、次の仮定を満たすマルチキャストボーダールーター（MBRS）に特に適用されます。
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は、2つ以上のアクティブなマルチキャストルーティングコンポーネントで構成され、それぞれがいくつかのマルチキャストルーティングプロトコルのインスタンスを実行しています。マルチキャストルーティングプロトコルの種類（たとえば、ブロードキャストとプルーネ対明示的参加）、または「コンポーネント」の性質については仮定は行われません。同じプロトコルを実行している複数のコンポーネントが許可されています。
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 ルーターは、2つ以上の独立したドメイン間でパケットを転送するように構成されています。ルーターには、各ドメインに1つ以上のアクティブインターフェイスがあり、ドメインごとに1つのコンポーネントがあります。ルーターには、セクション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 インターフェイスごとにアクティブなマルチキャストルーティングプロトコルは1つだけです（混合マルチキャストプロトコルLANSを考慮しません）。したがって、マルチキャストが有効になっている各インターフェイスは、コンポーネントの1つによって「所有」されます。
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 モノリス：「カーネル」自体の一部であるいくつかのルーティングコンポーネント。
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.
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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を所有していたコンポーネントの両方が変更に気付く必要があります（したがって、1つ目は上流と2番目たとえば、上流に結合/接ぎ木することができます）。通常、そのような変更に気づくのは、通常のプロトコル挙動の結果として発生します。
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）不正なアラート]にアラートする必要があります。通常、不正なアラートは料金制限されている必要があります。
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）作成アラートは、プロトコルコンポーネント自体の1つによって必ずしも生成されるわけではないことに注意してください。
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が別のコンポーネントによって所有されているAN（S、G）転送エントリから最後のOIFを削除する場合、またはそのような（S、G）転送キャッシュエントリが空のOIFリストで作成された場合、コンポーネントはコンポーネントを作成します。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：IIFが別のコンポーネントによって所有されている（s、g）転送キャッシュエントリに最初のOIFが追加された場合、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/コアに送信するために使用されるものなどの仮想カプセル化インターフェイスも論理的に含める必要があります。
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.
MBRは、BGMPなどの高レベルのルーティングプロトコルがドメイン間のルーティングに使用される場合、ワイルドカードレシーバー（内部または外部に到達したソースの場合）である必要はありません。
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から非ヌルに移動する時期を決定できる必要があります。
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を変更する場合、最初に作成されます。その後、OIFLISTが変更され、（s、g）作成アラートがすべてのコンポーネントに送信され、すべてのコンポーネントがOIFLISTを更新した後に適用されます。または、
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.
これは、実装依存の方法で実行される場合がありますが、1つの例は、グループ-Prefixによってインデックス付けされた共通のテーブル（コンポーネントグループテーブルと呼ばれる）を維持することです。したがって、外部に到達したソース（つまり、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には「アラートディスパッチャー」があると仮定します。ディスパッチャーは、共有転送キャッシュの各（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.
ドメインのツリートポロジーの相互運用性を可能にするために、ドメイン間マルチキャストルーティングプロトコルがない場合に使用できるルールについて説明します。ドメイン間マルチキャストルーティングプロトコルが使用されている場合、代わりに別のディスパッチャーを使用する必要があります。Interop Dispatcherはインターフェイスを所有していません。
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の所有者は、マルチキャストリブの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自体です。これにより、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）Pruneアラートを受信すると、Gのデータを受信するコンポーネントnの数に応じて、次のアクションが実行されます。）プルーンアラートは、残りのコンポーネントに送信されます。nが1から0に変更されたばかりの場合、a（*、g）プルーンアラートが1以外のすべてのコンポーネントに送信されます。
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がa（*、g）結合アラートを受信すると、Gのデータを受信するコンポーネントnの数に応じて、次のアクションが実行されます。nが0から1に変更された場合、a（*、g）結合アラートは、1以外のすべてのコンポーネントに送信されます。Nが1から2に変更されたばかりの場合、A（*、g）結合アラートは元の（1）コンポーネントに送信されます。
This dispatcher can be used with an inter-domain multicast routing protocol (such as BGMP) which allows global (S,G) and (*,G) trees.
このディスパッチャーは、グローバル（s、g）および（*、g）ツリーを許可するドメイン間マルチキャストルーティングプロトコル（BGMPなど）で使用できます。
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所有者は、マルチキャストリブのSに向かってネクストホップインターフェイスを所有するコンポーネントです。
The iif owner of a (*,G) entry is the component owning the next-hop interface towards G in the multicast RIB.
A（*、g）エントリのIIF所有者は、マルチキャストリブのGに向かってNext-Hopインターフェイスを所有するコンポーネントです。
This dispatcher simply forwards all (S,G) and (*,G) alerts to the iif owner of the associated entry.
このディスパッチャーは、関連するエントリのIIF所有者にすべて（s、g）および（*、g）アラートを単純に転送します。
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コンポーネントは、内部に到達したソース用の自動的にワイルドカードレシーバーです。何らかの形のドメイン全体のレポート（DWR）[10]（[1]で説明されている地域メンバーシップレポートと同義）が将来DVMRPに追加されない限り、すべての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を概算するための単純なヒューリスティックの1つは、内部に到達したメンバーがいる場合、少なくともそのうちの1つが送信者であると仮定することです。このヒューリスティックでは、内部に到達したソースの（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.
最初のコンポーネントが外部ソースのワイルドカードレシーバーになったとき、A（*、*）結合アラートは（*、*）エントリ（例：Interop Dispatcher）の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.
（*、*）プルーンアラートは、すべてのコンポーネントが外部ソース用のワイルドカード受信機ではなくなった場合に、（*、*）エントリ（例：Interop Dispatcher）のIIF所有者に送信されます。これは、何らかの形の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:
（s、g）プルーンアラートは、最後のOIFがエントリから削除され、IIFが別のコンポーネントが所有するときはいつでも、転送キャッシュエントリのためにIIFを所有するコンポーネントに送信されます。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:
（s、g）結合アラートは、最初の論理OIFがエントリに追加され、IIFが別のコンポーネントが所有するときはいつでも、転送キャッシュエントリのためにIIFを所有するコンポーネントに送信されます。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）グラフトメッセージが論理インターフェイスで受信されます。
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 Times OutのDWR、またはメンバーARE-SENDERS近似が使用されており、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のメンバーがいることが最初に知られている場合、A（*、g）結合アラートは（*、g）の「IIF所有者」に送信されます。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コンポーネントがA（*、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はグループ全体に参加して剪定することを可能にしますが、グループ内の個々のソースを使用することはできません。
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.
MOSPFと密なモードプロトコル（DVMRPなど）の相互運用性は[3]で指定されていますが、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コンポーネントは、他のコンポーネントが外部に到達したソースのワイルドカードレシーバーである場合にのみ、内部に到達したソースのワイルドカードレシーバーとして機能します。MOSPFコンポーネントは、何らかの形のドメイン全体のレポート（DWR）をサポートしていない内部に到達したドメインが存在する場合にのみ、外部に到達したソースのワイルドカードレシーバーとして機能します[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.
最初のコンポーネントが外部ソースのワイルドカードレシーバーになったとき、A（*、*）結合アラートは（*、*）エントリ（例：Interop Dispatcher）の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.
（*、*）プルーンアラートは、すべてのコンポーネントが外部ソース用のワイルドカード受信機ではなくなった場合に、（*、*）エントリ（例：Interop Dispatcher）のIIF所有者に送信されます。これは、この役割で作用していたモスフコンポーネントがシャットダウンしたときに発生する可能性があります。
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のメンバーがなくなったことがわかっている場合、ディスパッチャーによると、A（*、g）プルーンアラートは（*、g）の「IIF所有者」に送信されます。モスプでは、これは次の場合に起こる可能性があります。
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は、インターフェイスに直接接続されたグループメンバーがなくなったこと、またはGのルーターのグループメンバーシップLSAが老化していることをMOSPFに通知します。
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のメンバーがいることが最初に知られている場合、ディスパッチャーによると、A（*、g）結合アラートは（*、g）の「IIF所有者」に送信されます。モスポでは、これは次のいずれかが発生したときに発生する可能性があります。
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に、直接接続されたグループメンバーがインターフェイスに存在するようになったことを通知します。
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ドメインの最短パスツリーを計算し、通常のモスポの動作に応じてエントリの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.
モスフコンポーネントが（s、g）プルーンアラートを受信すると、モスフは一度にグループ全体を剪定することができるため、アラートは無視されます。
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インターフェイスに直接接続されたメンバーがいない場合、ルーターは通常のモスフによると、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コンポーネントがAN（s、g）結合アラートまたはa（*、g）結合アラートのいずれかを受信した場合、Gは以前にルーターのグループメンバーシップLSAに含まれていませんでした（およびコンポーネントはワイルドカードマルチキャストレシーバーではありません）、それは、通常のモスフの行動に応じて、モスフドメインのグループメンバーシップ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コンポーネントは、内部に到達したソース用の自動的にワイルドカードレシーバーです。将来、何らかの形のドメイン全体のレポート（DWR）[10]がPIM-DMに追加されない限り、すべてのPIM-DMコンポーネントは、外部に到達したソースのワイルドカードレシーバーとしても機能します。DWRがドメインで利用可能である場合、PIM-DMコンポーネントは、何らかの形の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を概算するための単純なヒューリスティックの1つは、内部に到達したメンバーがいる場合、少なくともそのうちの1つが送信者であると仮定することです。このヒューリスティックでは、内部に到達したソースの（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.
最初のコンポーネントが外部ソースのワイルドカードレシーバーになったとき、A（*、*）結合アラートは（*、*）エントリ（例：Interop Dispatcher）のIIF所有者に送信されます。これは、PIM-DMコンポーネントが起動したときに発生する可能性があり、何らかの形の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 PIM-DM component which does not support some form of DWRs shuts down.
（*、*）プルーンアラートは、すべてのコンポーネントが外部ソース用のワイルドカード受信機ではなくなった場合に、（*、*）エントリ（例：Interop Dispatcher）のIIF所有者に送信されます。これは、何らかの形の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:
a（s、g）pruneアラートは、最後のOIFが転送キャッシュエントリから削除され、IIFが別のコンポーネントによって所有されている場合、転送キャッシュエントリのためにIIFを所有するコンポーネントに送信されます。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 PruneリストにSを使用したPIM（S、G）結合/プルーンメッセージは、ポイントツーポイントインターフェイスで受信されます。o（s、g）ルートテーブルのエントリのoif-timerの有効期限が切れます。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:
a（s、g）結合アラートは、最初のOIFがエントリに追加され、IIFが別のコンポーネントが所有するときはいつでも、転送キャッシュエントリのためにIIFを所有するコンポーネントに送信されます。 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 Times OutのDWR。oメンバー - センダーの近似が使用されており、GのPIM-DMの最後（s、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のメンバーがいることが最初に知られている場合、A（*、g）結合アラートは（*、g）の「IIF所有者」に送信されます。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 DWRはGに対して受信されます。Oメンバーアレンダーの近似が使用されており、Gのデータパケットがコンポーネントのインターフェイスの1つで受信されます。
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リーフネットワーク、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）結合アラートを受信すると、以前に上流でpruneが送信された場合、通常のpimに従って上流の隣人にpim-dm（s、g）グラフトメッセージを送信します-DM動作。
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コンポーネントがA（*、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動作を実現するには、Bootstrapメッセージがドメイン内のすべてのルーターに到達するように、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.
将来、何らかの形のドメイン全体のレポート（DWR）[10]がPIM-SMに追加されない限り、すべての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コンポーネントは、他のコンポーネントが外部に到達したソースのワイルドカードレシーバーである場合にのみ、内部に届くソースのワイルドカードレシーバーとして機能します。これは、定期的に（*、*、RP）が非ローカルグループのすべてのRPSに結合することによって行われます（たとえば、239.x.x.xはローカルスコープと見なされ、PIM-SMコンポーネントは送信されません（*、*、RP）アドレス空間のその部分のみをサポートするRPSに結合します）。期間は、定期的な結合/プルーンメッセージの標準の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への次のホップは別のコンポーネントが所有するインターフェイスを介して到達します。さらに、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.
最初のコンポーネントが外部ソースのワイルドカードレシーバーになったとき、A（*、*）結合アラートは（*、*）エントリ（例：Interop Dispatcher）の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.
（*、*）プルーンアラートは、すべてのコンポーネントが外部ソース用のワイルドカード受信機ではなくなった場合に、（*、*）エントリ（例：Interop Dispatcher）のIIF所有者に送信されます。これは、この役割で作用していた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:
a（s、g）プルーンアラートは、最後のOIFがエントリから削除され、IIFが別のコンポーネントが所有するときはいつでも、転送キャッシュエントリのためにIIFを所有するコンポーネントに送信されます。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 PruneリストのSを使用したPIM（S、G）結合メッセージは、ポイントツーポイントインターフェイスで受信されます。（s、g）に対してPIMレジスタストップメッセージが受信され、o oインターフェイスのoif-timer for 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）結合/プルーンメッセージは、ポイントツーポイントインターフェイスで受信されます。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:
a（s、g）結合アラートは、最初の論理OIFがエントリに追加され、IIFが別のコンポーネントが所有するときはいつでも、転送キャッシュエントリのためにIIFを所有するコンポーネントに送信されます。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）結合/プルーンメッセージはインターフェイスで受信されます。ルートテーブルエントリは期限切れになります。
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のメンバーがいることが最初に知られている場合、ディスパッチャーによると、A（*、g）結合アラートは（*、g）の「IIF所有者」に送信されます。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 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）状態エントリごとにカバーされている場合、（s、g）結合/プルーンメッセージが送信されます。sをプルーンリストに載せて、通常のPIM-SMの動作に応じて上流の隣接します。
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によると、Pruneリストのgを上流隣のGでgでgでgでa/pruneメッセージを送信します。行動。
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）結合/プルーンメッセージをnext-hopの隣人にSに向けて送信し、（s、g）エントリタイマーをリセットします。通常のPIM-SMの動作に。
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コンポーネントがa（*、g）結合アラートを受信すると、gのRPに向かって次のホップネイバーに（*、g）結合メッセージを送信し、（*、g）エントリをリセットします-timer、通常のpim-smの動作によると。
When a PIM-SM component receives a (*,*) Join alert, then it sends (*,*,RP) Join/Prune messages towards each RP.
PIM-SMコンポーネントがAlertを受信すると、Alertが接合されると、各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.
単一のCBTV2スタブドメインとDVMRPバックボーン間の相互運用性は、[8]で概説されています。簡単に言えば、CBTV2 MBRコンポーネントは、2つ以上のMBRの間に外部ルートが存在する場合、1つがプライマリとして指定され、その他は非軌道（パケットの重複を防ぐため）として機能するように静的に構成されています。したがって、CBTV2ドメインは、それらの間に別のルートが存在する場合、2つのドメイン間のトランジットとして機能してはなりません。
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]に記載されているように、すべての非ローカルグループ範囲のJoin-Requestsをすべての既知のコアに送信することによって行われます。
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.
将来、何らかの形のドメイン全体のレポート（DWR）[10]がCBTV2に追加されない限り、すべての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.
最初のコンポーネントが外部ソースのワイルドカードレシーバーになったとき、A（*、*）結合アラートは（*、*）エントリ（例：Interop Dispatcher）の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.
（*、*）プルーンアラートは、すべてのコンポーネントが外部ソース用のワイルドカード受信機ではなくなった場合に、（*、*）エントリ（例：Interop Dispatcher）のIIF所有者に送信されます。これは、この役割で作用していた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が削除されると、A（*、g）Pruneアラートは、ディスパッチャーに従って（*、g）の「IIF所有者」に送信されます。CBTV2は常にすべてのデータをコアに送信するため、エントリが作成された後に発生する可能性があるのは、MBRがコアである場合です。この場合、次の場合、最後の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 Quit-Requestは論理インターフェイスで受信され、インターフェイスに直接接続されたメンバーが存在するか、O IGMPがインターフェイスに直接接続されたメンバーがもう存在しなくなったことをCBTに通知し、インターフェイスはCBTではありませんグループGの子インターフェース。
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発信インターフェイスが既存のコアツリーに追加されると、ディスパッチャーによると、A（*、g）結合アラートは（*、g）の「IIF所有者」に送信されます。CBTV2は常にすべてのデータをコアに送信するため、エントリが作成されたときを除いて、これらが発生するのはMBRがコアである場合です。この場合、最初の論理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のJoin-Requestがインターフェイスで受信されるか、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が特定のソースをプルンできないため、アラートは無視されます。したがって、グループGの他のソースからパケットを受信する必要があるため、Sからパケットを受け取り続けます。
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コンポーネントがAN（s、g）結合アラートまたはa（*、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のみのインターフェイスにグループGの直接接続されたメンバーがなくなったことがわかっている場合、（*、g）プルーンアラートは、（*、g）のために「IIF所有者」に送信されます。発車係。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の直接接続メンバーがいることが最初に知られている場合、ディスパッチャーによると、A（*、g）結合アラートは（*、g）の「IIF所有者」に送信されます。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のみのコンポーネントがAN（s、g）結合アラートまたはa（*、g）結合アラートのいずれかを受信すると、コンポーネントは以前はIGMPのみのインターフェイスでGのメンバーではありませんでした（およびコンポーネントはワイルドカードではありません内部に到達したソースのレシーバー）は、インターフェイス上のグループに結合し、通常のIGMPの動作に応じて未承諾のメンバーシップレポートを送信します。
When an IGMP-only component receives a (*,*) Join alert, it enters promiscuous multicast mode.
IGMPのみのコンポーネントがAlertの結合を受信すると、無差別なマルチキャストモードに入ります。
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の議事録」、1995年10月60〜66ページ。
[2] Pusateri, T., "Distance Vector Multicast Routing Protocol", Work in Progress.
[2] プサテリ、T。、「距離ベクトルマルチキャストルーティングプロトコル」、進行中の作業。
[3] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994.
[3] Moy、J。、「OSPFへのマルチキャスト拡張」、RFC 1584、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.、Farinacci、D.、Helmy、A.、Thaler、D.、Deering、S.、Handley、M.、Jacobson、V.、Liu、C.、Sharma、P。and L. wei、 "Protocol Independent Multicast-Sparseモード（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）マルチキャストルーティング」、RFC 2189、1997年9月。
[6] Estrin, Farinacci, Helmy, Jacobson, and Wei, "Protocol Independent Multicast (PIM), Dense Mode Protocol Specification", Work in Progress.
[6] エストリン、ファリナッチ、ヘルミー、ジェイコブソン、および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。and D. Meyer、「Border Gateway Multicast Protocol（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.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。