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.
根と葉の間の枝のように根元のバックボーンドメインとツリー（またはスター）トポロジー（図1）、葉のスタブドメイン、およびおそらく「トランジット」ドメインO。隣接ドメインの各対は、一の以上の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]または[9] BGMPとしてより高いレベル（ドメイン間）ルーティングプロトコルが、使用される任意のトポロジは、ドメイン間の経路を計算します。隣接ドメインの各対は、一の以上の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]を許可するルールを記述し、のちょうどN（プロトコール1）インスタンスに、O（N ^ 2）電位プロトコル相互作用の相互運用性の問題を低減します不変の規則の同じセット。この文書は、具体的には、以下の前提条件を満たしているマルチキャスト境界ルータ（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.
MBRは、2つ以上のアクティブなマルチキャストルーティングコンポーネントで構成され、O、各々がいくつかのマルチキャストルーティングプロトコルのインスタンスを実行しています。何の仮定は、マルチキャストルーティングプロトコル任意のコンポーネントの実行（例えば、明示的なジョイン対ブロードキャスト・アンド・プルーン）、または「成分」の性質の種類についてなされていません。同じプロトコルを実行している複数の構成要素が許可されています。
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つまたは複数のアクティブなインターフェイス、およびドメインごとに一つの成分を有しています。ルータはまた、我々は第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：「カーネル」自体の一部であるいくつかのルーティングコンポーネント。
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.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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上流プルーニング及び第二することができ/移植片）は、例えば、上流の参加できます。典型的には、このような変化に着目すると、通常のプロトコルの動作の結果として起こります。
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は、コンポーネントが「WrongIfアラートモード」でそのインタフェースのいずれかを配置できるようにする必要があります。パケットは、インタフェースに到着、及び規則2に従って受け入れられない場合は、インタフェースを所有しているコンポーネントは、[（S、G）WrongIf警告]警告しなければなりません。一般的に、WrongIfアラートは、レート制限しなければなりません。
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）の作成警告]となるようパケットが転送される前に、彼らは自分の発信インターフェイス（oifs）に転送状態を設定することができます。
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を除去する、またはそのような（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：最初の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 /コアにカプセル化されたパケットを送信するために使用されるもののような任意の仮想カプセル化インターフェースを含んでいなければなりません。
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インターフェイス別のコンポーネント（「外部達し」ソース）によって所有されているすべてのソースについては、「ワイルドカードレシーバ」でなければなりません。また、コンポーネントは、RPFインターフェイスMBRの他の成分が外部に到達ソースのワイルドカードの受信機である場合（「内部的に到達」ソース）そのコンポーネントによって所有されているすべてのソースについては、「ワイルドカードレシーバ」でなければなりません。それは（*、*）に参加アラートを受信したときに、これはルール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としてより高いレベルのルーティングプロトコルは、ドメイン間ルーティングするために使用されている場合（internally-または外部達しソースの）ワイルドカード受信機である必要はありません。
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が非ヌルにヌルからなり、その逆ときを決定することができなければなりません。
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,
これには、任意の実装固有の方法で行わが、以下の可能性、これらに限定されないことができます：1が存在していた場合、コンポーネントは単一の転送キャッシュエントリのoiflistを修正するだろうたびO、1が最初に作成されます。 oiflistは、その後変性およびルール4および5は（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.
これは、任意の実装依存の方法で行うことができるが、一例では、グループプレフィックス、構成要素は、各グループ（接頭辞）に興味を持っているリストによってインデックス付け（我々は、コンポーネントグループテーブル呼び出し）共通のテーブルを維持するであろう。したがって、外部から到達ソースのワイルドカードの受信機である任意の構成要素（すなわち、その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が「警告ディスパッチャ」を持っていることを前提としています。ディスパッチャは、共有転送キャッシュ、IIFを所有しているコンポーネントの各（S、G）エントリのために、選択する責任があります。また、どのコンポーネント（複数可）指定されたアラートが送信されなければならないに選択する責任があります。
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所有者は、" 相互運用ディスパッチャ自体です。これは、相互運用ディスパッチャは任意のインタフェースを所有せずに、関連するアラートを受け取ることができます。
If the Interop dispatcher receives an (S,G) Creation alert, it adds no interfaces to the entry's oif list, since it owns none.
相互運用ディスパッチャは、（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.
相互運用ディスパッチャは、（*、G）プルーンアラートを受信した場合、以下のアクションがとられる、G.もしNのデータを受信するコンポーネントNの数に応じてちょうど（*、G、2から1に変更されてい）プルーンアラートは、残りのコンポーネントに送信されます。 Nはわずか1から0に変更された場合、（*、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.
相互運用ディスパッチャは、（*、G）が警告を参加受信した場合、以下のアクションがとられる、G.もしNのデータを受信するコンポーネントNの数に応じてちょうど（*、G、0から1に変化しました）Nがちょうど1から2に変更された場合、（*、G）アラートが1以外のすべてのコンポーネントに送信される参加警告が元の（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所有者はマルチキャスト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.
関連するエントリの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コンポーネントは自動的に内部-達し源のためのワイルドカードレシーバーです。ドメインワイドレポート（DWRs）の何らかの形でない限り[10]（地域-会員レポートと同義[1]に記載のように）将来DVMRPに追加され、すべてのDVMRP成分はまた、外部から到達するためのワイルドカードの受信機として機能しますソース。 DWRsドメインのために利用可能である場合には、DVMRP成分が内部に到達ドメインはDWRsのいくつかのフォームをサポートしていないが存在する場合にのみ、外部から到達源のためのワイルドカードの受信機として機能します。
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.
DWRsを近似する一つの簡単なヒューリスティックは、任意の内部-達しメンバーがある場合、それらの少なくとも1つが送信者であると仮定することです。このヒューリスティックで、内部に到達ソースの任意の（S、G）ステートのpresenseを代わりに使用することができます。グループにデータパケットを送信すると、そのグループのための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コンポーネントはDWRsのいくつかのフォームをサポートしていない起動時にこれが発生する可能性があります。
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所有者に送信されません。 DWRsのいくつかのフォームをサポートしていない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.
OIFのプルーンタイマが満了O、またはDVMRP（S、G）グラフトメッセージが論理インターフェイス上で受信されるO、またはIGMP O [7] Gの直接接続されたメンバーは、現在のインターフェイス上に存在DVMRPに通知します。
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:
それがローカルルータから外部に達しソースのデータを受信DVMRPドメイン内の任意のメンバーがもはや存在していることを、グループGのために、知られていない場合、（*、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.
アウトG時間のDWR O、又は会員である、送信者の近似が使用されており、Gの最後の（S、G）エントリはタイムアウトし、O。
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:
それが最初のグループGのメンバーは、DVMRPドメインに存在することが知られている場合には、（*、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 DWRはGのために受信され、又は会員である、送信者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）作成アラートを受信した場合、それ以外は（通常DVMRPの動作に応じて）エントリのOIFリストへのすべてのコンポーネントのインターフェイスを追加します。
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）プルーンメッセージは、すべての下流依存近隣から受信されたため。ルータはグループをカバーするスコープ境界を有するS、Oおよびインターフェイスの指定フォワーダされていない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）または（*、*）プルーンアラートを受信した場合、それは（S、G）プルーンアラートかのように扱われているすべての既存のDVMRP（S、G）エントリ被覆のために受信されました。 DWRsが使用されている場合に加えて、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）または（*、*）は、アラートに参加受信すると、（S、G）は、アラート参加かのように扱われているすべての既存のDVMRP（S、G）エントリ被覆のために受信されました。 DWRsが使用されている場合に加えて、コンポーネントは、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.
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成分の作用及び他のコンポーネントは、外部から到達ソースのワイルドカードの受信機である場合にのみ場合。ドメインワイドレポート（DWRs）のいくつかの形態[10]をサポートしていない内部に到達ドメインが存在する場合にのみ、外部から到達ソースのワイルドカードレシーバとしてMOSPF成分が作用します。 MOSPFは、ドメイン全体の会員情報をフラッディングするので、MOSPF自体はネイティブDWRsの形式をサポートするために考えられています。
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所有者に送信されません。この役割で行動していた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 oをエージアウトされます。
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:
それは第一のグループGのメンバーがMOSPFドメイン内に存在することが知られている場合、（*、G）は、警告を参加ディスパッチャによれば、（G、*）の「IIF所有者」に送られます。次のいずれかが発生したときに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は、直接接続されたグループのメンバーは現在、インタフェース上に存在する、またはOグループメンバーシップ-LSAはG.のために受信された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ドメインの最短経路ツリーを算出し、正常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ドメイン内のGのためにそのグループメンバーシップ-LSAアウト「早期年齢は、」正常MOSPFに従って動作。
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のルールは、denseモードの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に添加されるドメインワイドレポート（DWRs）[10]いくつかの形態がない限り、すべてのPIM-DM成分はまた、外部から到達ソースのワイルドカードレシーバとして作用します。 DWRsドメインのために利用可能である場合には、PIM-DM成分が内部に到達ドメインはDWRsのいくつかのフォームをサポートしていないが存在する場合にのみ、外部から到達源のためのワイルドカードの受信機として機能します。
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.
DWRsを近似する一つの簡単なヒューリスティックは、任意の内部-達しメンバーがある場合、それらの少なくとも1つが送信者であると仮定することです。このヒューリスティックで、内部に到達ソースの任意の（S、G）ステートのpresenseを代わりに使用することができます。グループにデータパケットを送信すると、そのグループのための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所有者に送信されます。 PIM-DM成分はDWRsのいくつかのフォームをサポートしていない起動時にこれが発生する可能性があります。
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所有者に送信されません。 DWRsのいくつかのフォームをサポートしていない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:
（S、G）プルーンアラートが最後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 PIM（S、G）は、ポイントツーポイントインターフェイスで受信されたプルーンリストにSと/プルーンメッセージに参加します。 （S、G）ルートテーブルエントリのOIF-Timerが満了し、O。 PIM（S、G）O好ましいネイバーをインターフェイス上で受信されるからメッセージをアサート。
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:
（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.
OIFのプルーンタイマが満了O、またはPIM-DM（S、G）グラフトメッセージがインターフェイス上で受信されるO、またはIGMP Oに直接接続されたグループのメンバーは現在、インタフェース上に存在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.
アウトG時間のDWR O。 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:
それは第一のグループGのメンバーは、PIM-DMドメイン内に存在することが知られている場合、（*、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が会員である、送信者近似oをG.のために受信され使用されており、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）作成アラートを受信した場合、それ以外は（通常のPIM-DMの動作に応じて）エントリのOIFリストにコンポーネントのインターフェイスを追加します。
o the iif, o leaf networks without local members of the entry's group, o and interfaces with scoped boundaries covering the group.
ローカルエントリのグループのメンバー、Oおよびグループをカバーするスコープ境界を有するインターフェース無しリーフネットワークO IIF、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（S、G）正常なPIMに従って上流隣接するグラフトメッセージを送信します-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成分は（*、G）を受信または（*、*）アラートに参加すると、その後、プルーンが以前上流送信された各マッチング（S、G）PIM-DMのルーティングテーブルのエントリのために、それが送信しますPIM-DM（S、G）グラフトメッセージ上流隣接する正常PIM-DMの動作に応じ。 DWR年代が使用されている場合はさらに、コンポーネントは、DWRは、そのドメイン内のJoinメッセージを送信します。
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に追加されるドメインワイドレポート（DWRs）[10]いくつかの形態がない限り、すべてのPIM-SMコンポーネントは、外部から到達ソースのワイルドカードレシーバとして作用します。 DWRsドメインのために利用可能である場合には、PIM-SMコンポーネントは、内部に到達ドメインはDWRsのいくつかのフォームをサポートしていないが存在する場合にのみ、外部から到達源のためのワイルドカードの受信機として機能します。
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）が非ローカルグループのためにすべてのRPに参加（例えば、ローカルスコープ239.xxxとみなされ、PIM-SMコンポーネントは（送信しない送信することにより、これを行う*、*、RP） ）のアドレス空間のその部分のみをサポートしているの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.
PIMは、外部から到達ソースのPIM（S、G）エントリを作成し、Sに向かって次のホップが別のコンポーネントによって所有インターフェースを介して到達するたびに適切にルール1をインスタンス化するために、IIFは、Sに向かってではなく向かって常に指すべきまたG.のためのRPは、ボーダービットは、このエントリのすべてのPIM Registerメッセージに設定されています。
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.
最後に、内部に到達ソースの最短パスツリーに切り替えることができるという点で、外部から到達受信機のためのDRとしてPIM-SMコンポーネント働きます。
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所有者に送信されません。この役割で行動していた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:
（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 PIM（S、G）は、プルーン・リストにSと/プルーンメッセージを参加は、ポイントツーポイントインターフェイス上で受信、またはPIM（S、G）Oインターフェース上で受信された好適なネイバーからアサートされるか、またはO PIMレジスタストップメッセージは（S、G）、またはPIMの（S、G）ルートテーブルエントリの有効期限が切れるためのインタフェースのOIF-タイマoを受信します。 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.
プルーンリストにおけるGとのPIM（*、G）参加/プルーンメッセージがポイント・ツー・ポイントインタフェース上、またはPIM（*、G）O受信されるO好ましい隣人がインターフェイス上で受信されたからアサート、又は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:
（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.
PIM（S、G）O参加/プルーンメッセージは（S、G）ネガティブキャッシュのインターフェイス上で、または期限切れに（S、G）のための登録抑制タイマO、またはエントリタイマoを受信します状態ルートテーブルのエントリが期限切れになります。
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:
なお、第1のグループGのメンバーは、PIM-SMドメイン、（*、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）が参加/プルーンメッセージは、インターフェイス上で受信され、またはPIM（*、*、RP）参加/プルーンメッセージOインターフェイス、またはO（*、G）負のキャッシュ状態が満了する上で受信されます、またはIGMP Oに直接接続されたグループのメンバーは現在、インタフェース上に存在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）は/プルーンメッセージに参加送信します通常のPIM-SMの動作に応じて上流隣接するプルーンリストに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によると、G用RPに向かって上流隣接するプルーンリストに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）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成分は（*、G）参加通知を受信すると、それは（*、G）はGのためのRPに向かうネクストホップネイバーに/プルーンメッセージに参加送信し、（*、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コンポーネントは、（*、*）に参加アラートを受信すると、それは（*、*、RP）/各RPへのプルーンJoinメッセージを送信します。
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の間に存在するときはいつでも、一つは一次として指定される、ように構成され、他は非フォワーディング（重複パケットを防ぐために）バックアップとして働きます。それらの間に別のルートが存在する場合はこのように、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-要求を送信することによってこれを行います。
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に追加されるドメインワイドレポート（DWRs）[10]いくつかの形態がない限り、すべてのCBTv2成分が外部に到達ソースのワイルドカードレシーバとして作用します。 DWRsドメインのために利用可能である場合、CBTv2成分が内部に到達ドメインはDWRsのいくつかのフォームをサポートしていないが存在する場合にのみ、外部から到達源のためのワイルドカードの受信機として機能します。
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所有者に送信されません。この役割で行動していた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:
最後OIFは、G用コアツリーから削除された場合、（*、G）プルーン警告がディスパッチャに応じては、「IIF所有者」（*、G）に送られます。 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 A QUIT-REQUEST論理インターフェイス上で受信されず、界面に存在する直接接続されたメンバーには存在する、またはIGMPがインターフェイス上に存在する直接接続されたメンバーは、もはや、インターフェイスではないことをCBTを通知しないoをグループ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）ディスパッチャに応じて警告が（*、G）の「IIF所有者」に送信される参加。 MBRは、コアであるときCBTv2は常にコアにすべてのデータを送信しているので、これらの唯一の時間は、エントリが作成されるとき以外に、発生する可能性があります、です。この場合、第一の論理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にツリーインターフェイスがコアに向かってインタフェースであり、それはネクストにQUIT-REQUESTを送信するとき通常の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専用インタフェース上のグループ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の直接接続されたメンバーは、インターフェイス上で存在することが知られている場合、（*、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）プルーンのアラートを受信した場合、ルータは通常のIGMPv2の行動に応じて、最後の記者だった場合、IGMP Leaveメッセージを送信し、グループGを残します。
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.
本明細書で説明するすべての操作は、マルチキャスト境界ルータの内部にあります。本明細書中に記載のルールは、個々のマルチキャストルーティングprotcolsの基礎となるセキュリティ上の問題を変更しないでください。異なるプロトコルが相互作用することができ、しかし、任意の特定のプロトコルのセキュリティ上の弱点も、結果として他のプロトコルに適用できることを意味します。
[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]アジットS. ThyagarajanとスティーブンE.デアリング。あるMBoneの階層距離ベクトルマルチキャストルーティング。 "ACM SIGCOMMの議事録"、ページ60--66、1995年10月。
[2] Pusateri, T., "Distance Vector Multicast Routing Protocol", Work in Progress.
[2] Pusateri、T.、 "距離ベクトルマルチキャストルーティングプロトコル" は進行中で働いています。
[3] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994.
[3]モイ、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.、ファリナッチ、D.、Helmy、A.、ターラー、D.、デアリング、S.、ハンドレー、M.、ヤコブソン、V.、劉、C.、シャルマ、P.、およびL.魏、 "プロトコル独立マルチキャスト - スパースモード（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] Estrin、ファリナッチ、Helmy、ヤコブソン、及びウェイ、 "プロトコル独立マルチキャスト（PIM）、稠密モードプロトコル仕様"、ProgressのWork。
[7] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[7]フェナー、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]ターレル、D.、Estrin、D.およびD.マイヤー、 "ボーダーゲートウェイマルチキャストプロトコル（BGMP）：プロトコル仕様"、ProgressのWork。
[10] Fenner, W., "Domain Wide Multicast Group Membership Reports", Work in Progress.
[10]フェナー、W.、「ドメインワイドマルチキャストグループメンバーシップレポート」が進行中で働いています。
Dave Thaler Microsoft One Microsoft Way Redmond, WA 98052
デーブターラーマイクロソフト1マイクロソフト道、レッドモンド、ワシントン98052
Phone: (425) 703-8835 EMail: dthaler@microsoft.com
電話：（425）703-8835 Eメール：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 Editor機能のための基金は現在、インターネット協会によって提供されます。