[要約] RFC 2362は、PIM-SMプロトコルの仕様を定義しており、マルチキャスト通信における効率的なデータ転送を実現するためのプロトコルです。目的は、ネットワーク上の複数のホストに対して、効率的かつスケーラブルなマルチキャスト通信を提供することです。
Network Working Group D. Estrin
Request for Comments: 2362 USC
Obsoletes: 2117 D. Farinacci
Category: Experimental CISCO
A. Helmy
USC
D. Thaler
UMICH
S. Deering
XEROX
M. Handley
UCL
V. Jacobson
LBL
C. Liu
USC
P. Sharma
USC
L. Wei
CISCO
June 1998
Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification
Protocol Independent Multicast-Sparse Mode（PIM-SM）：Protocol Specification
Status of this Memo
本文書の状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準も規定していません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
1 Introduction
1はじめに
This document describes a protocol for efficiently routing to multicast groups that may span wide-area (and inter-domain) internets. We refer to the approach as Protocol Independent Multicast--Sparse Mode (PIM-SM) because it is not dependent on any particular unicast routing protocol, and because it is designed to support sparse groups as defined in [1][2]. This document describes the protocol details. For the motivation behind the design and a description of the architecture, see [1][2]. Section 2 summarizes PIM-SM operation. It describes the protocol from a network perspective, in particular, how the participating routers interact to create and maintain the multicast distribution tree. Section 3 describes PIM-SM operations from the perspective of a single router implementing the protocol; this section constitutes the main body of the protocol specification. It is organized according to PIM-SM message type; for each message type we describe its contents, its generation, and its processing.
このドキュメントでは、広域（およびドメイン間）インターネットにまたがるマルチキャストグループに効率的にルーティングするためのプロトコルについて説明します。このアプローチは、特定のユニキャストルーティングプロトコルに依存せず、[1] [2]で定義されているスパースグループをサポートするように設計されているため、プロトコル独立マルチキャスト-スパースモード（PIM-SM）と呼びます。このドキュメントでは、プロトコルの詳細について説明します。設計の動機とアーキテクチャの説明については、[1] [2]を参照してください。セクション2では、PIM-SMの動作をまとめています。ネットワークの観点からプロトコルを説明します。特に、参加するルーターがマルチキャスト配信ツリーを作成および維持するためにどのように相互作用するかについて説明します。セクション3では、プロトコルを実装する単一のルーターの観点からPIM-SMの動作について説明します。このセクションは、プロトコル仕様の本体を構成します。 PIM-SMメッセージタイプに従って編成されます。各メッセージタイプについて、その内容、生成、および処理について説明します。
Sections 3.8 and 3.9 summarize the timers and flags referred to throughout this document. Section 4 provides packet format details.
セクション3.8と3.9は、このドキュメント全体で参照されるタイマーとフラグをまとめたものです。セクション4では、パケット形式の詳細について説明します。
The most significant functional changes since the January '95 version involve the Rendezvous Point-related mechanisms, several resulting simplifications to the protocol, and removal of the PIM-DM protocol details to a separate document [3] (for clarity).
'95年1月バージョン以降の最も重要な機能変更には、ランデブーポイント関連のメカニズム、プロトコルに対するいくつかの単純化、およびPIM-DMプロトコルの詳細の個別のドキュメントへの削除[3]（明確化のため）が含まれます。
2 PIM-SM Protocol Overview
2 PIM-SMプロトコルの概要
In this section we provide an overview of the architectural components of PIM-SM.
このセクションでは、PIM-SMのアーキテクチャコンポーネントの概要を説明します。
A router receives explicit Join/Prune messages from those neighboring routers that have downstream group members. The router then forwards data packets addressed to a multicast group, G, only onto those interfaces on which explicit joins have been received. Note that all routers mentioned in this document are assumed to be PIM-SM capable, unless otherwise specified.
ルーターは、ダウンストリームグループメンバーを持つ隣接ルーターから明示的なJoin / Pruneメッセージを受信します。次に、ルーターは、マルチキャストグループG宛てのデータパケットを、明示的な結合が受信されたインターフェイスにのみ転送します。このドキュメントに記載されているすべてのルーターは、特に指定がない限り、PIM-SM対応であると想定されています。
A Designated Router (DR) sends periodic Join/Prune messages toward a group-specific Rendezvous Point (RP) for each group for which it has active members. Each router along the path toward the RP builds a wildcard (any-source) state for the group and sends Join/Prune messages on toward the RP. We use the term route entry to refer to the state maintained in a router to represent the distribution tree. A route entry may include such fields as the source address, the group address, the incoming interface from which packets are accepted, the list of outgoing interfaces to which packets are sent, timers, flag bits, etc. The wildcard route entry's incoming interface points toward the RP; the outgoing interfaces point to the neighboring downstream routers that have sent Join/Prune messages toward the RP. This state creates a shared, RP-centered, distribution tree that reaches all group members. When a data source first sends to a group, its DR unicasts Register messages to the RP with the source's data packets encapsulated within. If the data rate is high, the RP can send source-specific Join/Prune messages back towards the source and the source's data packets will follow the resulting forwarding state and travel unencapsulated to the RP. Whether they arrive encapsulated or natively, the RP forwards the source's decapsulated data packets down the RP-centered distribution tree toward group members. If the data rate warrants it, routers with local receivers can join a source-specific, shortest path, distribution tree, and prune this source's packets off of the shared RP-centered tree. For low data rate sources, neither the RP, nor last-hop routers need join a source-specific shortest path tree and data packets can be delivered via the shared, RP-tree.
指定ルーター（DR）は、アクティブメンバーが存在するグループごとに、グループ固有のランデブーポイント（RP）に向けて定期的にJoin / Pruneメッセージを送信します。 RPへのパスに沿った各ルーターは、グループのワイルドカード（任意の送信元）状態を構築し、Join / PruneメッセージをRPに送信します。ルートエントリという用語は、配布ツリーを表すためにルーターで維持される状態を指すために使用します。ルートエントリには、送信元アドレス、グループアドレス、パケットの受け入れ元の着信インターフェイス、パケットの送信先の発信インターフェイスのリスト、タイマー、フラグビットなどのフィールドを含めることができます。ワイルドカードルートエントリの着信インターフェイスポイントRPに向けて;発信インターフェイスは、RPに向けてJoin / Pruneメッセージを送信した隣接するダウンストリームルータを指します。この状態では、すべてのグループメンバーに到達する共有のRP中心の配布ツリーが作成されます。データソースが最初にグループに送信すると、そのDRはソースのデータパケットをカプセル化してRPにRegisterメッセージをユニキャストします。データレートが高い場合、RPは送信元固有のJoin / Pruneメッセージを送信元に送り返すことができ、送信元のデータパケットは結果の転送状態に従い、カプセル化されずにRPに送信されます。カプセル化された状態で到着するかネイティブで到着するかに関係なく、RPはソースのカプセル化解除されたデータパケットをRP中心の配布ツリーからグループメンバーに転送します。データレートが保証する場合、ローカルレシーバーを持つルーターは、ソース固有の最短パス、配布ツリーに参加し、このRP中心の共有ツリーからこのソースのパケットをプルーニングできます。低データレートソースの場合、RPルーターもラストホップルータもソース固有の最短パスツリーに参加する必要はなく、データパケットは共有のRPツリーを介して配信できます。
The following subsections describe SM operation in more detail, in particular, the control messages, and the actions they trigger.
次のサブセクションでは、SMの動作、特に制御メッセージとそれらがトリガーするアクションについて詳しく説明します。
In order to join a multicast group, G, a host conveys its membership information through the Internet Group Management Protocol (IGMP), as specified in [4][5], (see figure 1). From this point on we refer to such a host as a receiver, R, (or member) of the group G.
マルチキャストグループGに参加するために、ホストは、[4] [5]で指定されているように、インターネットグループ管理プロトコル（IGMP）を通じてメンバーシップ情報を伝達します（図1を参照）。この時点から、このようなホストをグループGのレシーバーR（またはメンバー）と呼びます。
Note that all figures used in this section are for illustration and are not intended to be complete. For complete and detailed protocol action see Section 3.
このセクションで使用されている図はすべて説明のためのものであり、完全なものではありません。完全で詳細なプロトコルアクションについては、セクション3を参照してください。
[Figures are present only in the postscript version] Fig. 1 Example: how a receiver joins, and sets up shared tree
[図はポストスクリプトバージョンにのみ存在します]図1例：受信者が参加し、共有ツリーを設定する方法
When a DR (e.g., router A in figure 1) gets a membership indication from IGMP for a new group, G, the DR looks up the associated RP. The DR creates a wildcard multicast route entry for the group, referred to here as a (*,G) entry; if there is no more specific match for a particular source, the packet will be forwarded according to this entry.
DR（図1のルーターAなど）がIGMPから新しいグループGのメンバーシップの指示を取得すると、DRは関連するRPを検索します。 DRは、ここでは（*、G）エントリと呼ばれる、グループのワイルドカードマルチキャストルートエントリを作成します。特定のソースに一致する具体的なものがなければ、このエントリに従ってパケットが転送されます。
The RP address is included in a special field in the route entry and is included in periodic upstream Join/Prune messages. The outgoing interface is set to that included in the IGMP membership indication for the new member. The incoming interface is set to the interface used to send unicast packets to the RP.
RPアドレスはルートエントリの特別なフィールドに含まれ、定期的なアップストリームのJoin / Pruneメッセージに含まれます。発信インターフェイスは、新しいメンバーのIGMPメンバーシップ表示に含まれるインターフェイスに設定されます。着信インターフェイスは、ユニキャストパケットをRPに送信するために使用されるインターフェイスに設定されます。
When there are no longer directly connected members for the group, IGMP notifies the DR. If the DR has neither local members nor downstream receivers, the (*,G) state is deleted.
グループに直接接続されたメンバーがなくなると、IGMPはDRに通知します。 DRにローカルメンバーもダウンストリームレシーバーもない場合、（*、G）状態は削除されます。
Triggered by the (*,G) state, the DR creates a Join/Prune message with the RP address in its join list and the the wildcard bit (WC-bit) and RP-tree bit (RPT-bit) set to 1. The WC-bit indicates that any source may match and be forwarded according to this entry if there is no longer match; the RPT-bit indicates that this join is being sent up the shared, RP-tree. The prune list is left empty. When the RPT-bit is set to 1 it indicates that the join is associated with the shared RP-tree and therefore the Join/Prune message is propagated along the RP-tree. When the WC-bit is set to 1 it indicates that the address is an RP and the downstream receivers expect to receive packets from all sources via this (shared tree) path. The term RPT-bit is used to refer to both the RPT-bit flags associated with route entries, and the RPT-bit included in each encoded address in a Join/Prune message.
（*、G）状態によってトリガーされると、DRは、結合リストにRPアドレスがあり、ワイルドカードビット（WCビット）とRPツリービット（RPTビット）が1に設定された結合/除去メッセージを作成します。 WCビットは、ソースが一致し、一致しなくなった場合にこのエントリに従って転送されることを示します。 RPTビットは、この結合が共有のRPツリーに送信されていることを示します。プルーンリストは空のままです。 RPTビットが1に設定されている場合は、結合が共有RPツリーに関連付けられているため、Join / PruneメッセージがRPツリーに沿って伝播されます。 WCビットが1に設定されている場合は、アドレスがRPであり、ダウンストリームレシーバーはこの（共有ツリー）パスを介してすべてのソースからパケットを受信することを期待しています。 RPTビットという用語は、ルートエントリに関連付けられたRPTビットフラグと、Join / Pruneメッセージの各エンコードされたアドレスに含まれるRPTビットの両方を指すために使用されます。
Each upstream router creates or updates its multicast route entry for (*,G) when it receives a Join/Prune with the RPT-bit and WC-bit set. The interface on which the Join/Prune message arrived is added to the list of outgoing interfaces (oifs) for (*,G). Based on this entry each upstream router between the receiver and the RP sends a Join/Prune message in which the join list includes the RP. The packet payload contains Multicast-Address=G, Join=RP,WC-bit,RPT-bit, Prune=NULL.
各アップストリームルータは、RPTビットとWCビットが設定されたJoin / Pruneを受信すると、（*、G）のマルチキャストルートエントリを作成または更新します。 Join / Pruneメッセージが到着したインターフェースは、（*、G）の発信インターフェース（OIF）のリストに追加されます。このエントリに基づいて、レシーバとRPの間の各アップストリームルータは、Join / Pruneメッセージを送信します。このメッセージには、JoinリストにRPが含まれています。パケットペイロードには、Multicast-Address = G、Join = RP、WC-bit、RPT-bit、Prune = NULLが含まれています。
When a host starts sending multicast data packets to a group, initially its DR must deliver each packet to the RP for distribution down the RP-tree (see figure 2). The sender's DR initially encapsulates each data packet in a Register message and unicasts it to the RP for that group. The RP decapsulates each Register message and forwards the enclosed data packet natively to downstream members on the shared RP-tree.
ホストがグループへのマルチキャストデータパケットの送信を開始すると、最初にそのDRは各パケットをRPに配信して、RPツリーに配信する必要があります（図2を参照）。送信者のDRは、最初に各データパケットをRegisterメッセージにカプセル化し、それをそのグループのRPにユニキャストします。 RPは各Registerメッセージのカプセル化を解除し、囲まれたデータパケットを共有RPツリーのダウンストリームメンバーにネイティブに転送します。
[Figures are present only in the postscript version] Fig. 2 Example: a host sending to a group
[図はポストスクリプトバージョンにのみ存在する]図2例：ホストがグループに送信する
If the data rate of the source warrants the use of a source-specific shortest path tree (SPT), the RP may construct a new multicast route entry that is specific to the source, hereafter referred to as (S,G) state, and send periodic Join/Prune messages toward the source. Note that over time, the rules for when to switch can be modified without global coordination. When and if the RP does switch to the SPT, the routers between the source and the RP build and maintain (S,G) state in response to these messages and send (S,G) messages upstream toward the source.
ソースのデータレートがソース固有の最短パスツリー（SPT）の使用を保証している場合、RPは、ソースに固有の新しいマルチキャストルートエントリを構築します。これを（S、G）状態と呼びます。定期的にJoin / Pruneメッセージをソースに送信します。時間の経過とともに、切り替えるタイミングのルールはグローバルな調整なしで変更できることに注意してください。 RPがSPTに切り替わる場合、ソースとRPの間のルーターは、これらのメッセージに応答して（S、G）状態を構築および維持し、ソースに向けて（S、G）メッセージをアップストリームに送信します。
The source's DR must stop encapsulating data packets in Registers when (and so long as) it receives Register-Stop messages from the RP. The RP triggers Register-Stop messages in response to Registers, if the RP has no downstream receivers for the group (or for that particular source), or if the RP has already joined the (S,G) tree and is receiving the data packets natively. Each source's DR maintains, per (S,G), a Register-Suppression-timer. The Register-Suppression-timer is started by the Register-Stop message; upon expiration, the source's DR resumes sending data packets to the RP, encapsulated in Register messages.
送信元のDRは、RPからRegister-Stopメッセージを受信したとき（およびそれが続く限り）、レジスター内のデータパケットのカプセル化を停止する必要があります。 RPがグループ（またはその特定のソース）のダウンストリームレシーバーを持たない場合、またはRPが既に（S、G）ツリーに参加してデータパケットを受信している場合、RPはレジスターに応答してRegister-Stopメッセージをトリガーしますネイティブ。各ソースのDRは、（S、G）ごとにRegister-Suppressionタイマーを維持します。 Register-Suppression-timerは、Register-Stopメッセージによって開始されます。期限切れになると、送信元のDRはRPへのデータパケットの送信を再開し、Registerメッセージにカプセル化されます。
2.4 Switching from shared tree (RP-tree) to shortest path tree (SP-tree)}
2.4 共有ツリー（RPツリー）から最短パスツリー（SPツリー）への切り替え}
A router with directly-connected members first joins the shared RP-tree. The router can switch to a source's shortest path tree (SP-tree) after receiving packets from that source over the shared RP-tree. The recommended policy is to initiate the switch to the SP-tree after receiving a significant number of data packets during a specified time interval from a particular source. To realize this policy the router can monitor data packets from sources for which it has no source-specific multicast route entry and initiate such an entry when the data rate exceeds the configured threshold. As shown in figure 3, router `A' initiates a (S,G) state.
直接接続されたメンバーを持つルータは、最初に共有RPツリーに参加します。ルータは、ソースから共有RPツリーを介してパケットを受信した後、ソースの最短パスツリー（SPツリー）に切り替えることができます。推奨されるポリシーは、特定のソースから指定された時間間隔中に大量のデータパケットを受信した後で、SPツリーへの切り替えを開始することです。このポリシーを実現するために、ルーターは、送信元固有のマルチキャストルートエントリがない送信元からのデータパケットを監視し、データレートが構成されたしきい値を超えたときにそのようなエントリを開始できます。図3に示すように、ルータ「A」は（S、G）状態を開始します。
[Figures are present only in the postscript version] Fig. 3 Example: Switching from shared tree to shortest path tree
[図はポストスクリプト版にのみ存在する]図3例：共有ツリーから最短パスツリーへの切り替え
When a (S,G) entry is activated (and periodically so long as the state exists), a Join/Prune message is sent upstream towards the source, S, with S in the join list. The payload contains Multicast-Address=G, Join=S, Prune=NULL. When the (S,G) entry is created, the outgoing interface list is copied from (*,G), i.e., all local shared tree branches are replicated in the new shortest path tree. In this way when a data packet from S arrives and matches on this entry, all receivers will continue to receive the source's packets along this path. (In more complicated scenarios, other entries in the router have to be considered, as described in Section 3). Note that (S,G) state must be maintained in each last-hop router that is responsible for initiating and maintaining an SP-tree. Even when (*,G) and (S,G) overlap, both states are needed to trigger the source-specific Join/Prune messages. (S,G) state is kept alive by data packets arriving from that source. A timer, Entry-timer, is set for the (S,G) entry and this timer is restarted whenever data packets for (S,G) are forwarded out at least one oif, or Registers are sent. When the Entry-timer expires, the state is deleted. The last-hop router is the router that delivers the packets to their ultimate end-system destination. This is the router that monitors if there is group membership and joins or prunes the appropriate distribution trees in response. In general the last-hop router is the Designated Router (DR) for the LAN. However, under various conditions described later, a parallel router connected to the same LAN may take over as the last-hop router in place of the DR.
（S、G）エントリがアクティブ化されると（状態が存在する限り定期的に）、Join / PruneメッセージがソースSに向かってアップストリームに送信され、Sはジョインリストに含まれます。ペイロードには、Multicast-Address = G、Join = S、Prune = NULLが含まれています。 （S、G）エントリが作成されると、発信インターフェイスリストが（*、G）からコピーされます。つまり、すべてのローカル共有ツリーブランチが新しい最短パスツリーに複製されます。このようにして、Sからのデータパケットが到着し、このエントリに一致すると、すべての受信者がこのパスに沿って送信元のパケットを受信し続けます。 （より複雑なシナリオでは、セクション3で説明されているように、ルーターの他のエントリを考慮する必要があります）。 （S、G）状態は、SPツリーの開始と維持を担当する各最終ホップルーターで維持する必要があることに注意してください。 （*、G）と（S、G）がオーバーラップしている場合でも、ソース固有のJoin / Pruneメッセージをトリガーするには両方の状態が必要です。 （S、G）状態は、そのソースから到着するデータパケットによって維持されます。タイマーEntry-timerは（S、G）エントリーに設定され、このタイマーは（S、G）のデータパケットが少なくとも1つのoifに転送されるか、レジスターが送信されるたびに再起動されます。エントリータイマーが期限切れになると、状態は削除されます。ラストホップルータは、最終的なエンドシステムの宛先にパケットを配信するルータです。これは、グループメンバーシップがあるかどうかを監視し、それに応じて適切な配布ツリーに参加またはプルーニングするルーターです。一般に、ラストホップルーターは、LANの指定ルーター（DR）です。ただし、後で説明するさまざまな状況下では、同じLANに接続されているパラレルルーターが、DRの代わりにラストホップルーターとして機能する場合があります。
Only the RP and routers with local members can initiate switching to the SP-tree; intermediate routers do not. Consequently, last-hop routers create (S,G) state in response to data packets from the source, S; whereas intermediate routers only create (S,G) state in response to Join/Prune messages from downstream that have S in the Join list.
RPとローカルメンバーを持つルータだけが、SPツリーへの切り替えを開始できます。中間ルーターにはありません。その結果、ラストホップルーターは、送信元Sからのデータパケットに応答して（S、G）状態を作成します。一方、中間ルーターは（JoinリストにSがあるダウンストリームからのJoin / Pruneメッセージに応答して（S、G）状態のみを作成します。
The (S,G) entry is initialized with the SPT-bit cleared, indicating that the shortest path tree branch from S has not yet been setup completely, and the router can still accept packets from S that arrive on the (*,G) entry's indicated incoming interface (iif). Each PIM multicast entry has an associated incoming interface on which packets are expected to arrive.
（S、G）エントリはSPTビットがクリアされた状態で初期化されます。これは、Sからの最短パスツリーブランチがまだ完全にセットアップされておらず、ルータが（*、G）に到着したSからのパケットを受け入れることができることを示します。エントリの指定された着信インターフェイス（iif）。各PIMマルチキャストエントリには、パケットの到着が予想される着信インターフェイスが関連付けられています。
When a router with a (S,G) entry and a cleared SPT-bit starts to receive packets from the new source S on the iif for the (S,G) entry, and that iif differs from the (*,G) entry's iif, the router sets the SPT-bit, and sends a Join/Prune message towards the RP, indicating that the router no longer wants to receive packets from S via the shared RP-tree. The Join/Prune message sent towards the RP includes S in the prune list, with the RPT-bit set indicating that S's packets must not be forwarded down this branch of the shared tree. If the router receiving the Join/Prune message has (S,G) state (with or without the route entry's RPT-bit flag set), it deletes the arriving interface from the (S,G) oif list. If the router has only (*,G) state, it creates an entry with the RPT-bit flag set to 1. For brevity we refer to an (S,G) entry that has the RPT-bit flag set to 1 as an (S,G)RPT-bit entry. This notational distinction is useful to point out the different actions taken for (S,G) entries depending on the setting of the RPT-bit flag. Note that a router can have no more than one active (S,G) entry for any particular S and G, at any particular time; whether the RPT-bit flag is set or not. In other words, a router never has both an (S,G) and an (S,G)RPT-bit entry for the same S and G at the same time. The Join/Prune message payload contains Multicast-Address=G, Join=NULL, Prune=S,RPT-bit.
（S、G）エントリとクリアされたSPTビットを持つルーターが、（S、G）エントリのiifで新しいソースSからパケットを受信し始め、そのiifが（*、G）エントリと異なる場合iifの場合、ルータはSPTビットを設定し、RPに向けてJoin / Pruneメッセージを送信します。これは、ルータが共有RPツリーを介してSからパケットを受信する必要がなくなったことを示します。 RPに向けて送信されたJoin / Pruneメッセージには、プルーンリストにSが含まれており、RPTビットセットは、Sのパケットを共有ツリーのこのブランチに転送してはならないことを示しています。 Join / Pruneメッセージを受信するルーターが（S、G）状態（ルートエントリのRPTビットフラグが設定されているかどうかにかかわらず）を持っている場合、（S、G）oifリストから着信インターフェイスを削除します。ルータの状態が（*、G）のみの場合、RPTビットフラグが1に設定されたエントリを作成します。簡潔にするため、RPTビットフラグが1に設定された（S、G）エントリを、 （S、G）RPTビットエントリ。この表記上の違いは、RPTビットフラグの設定に応じて、（S、G）エントリに対して実行されるさまざまなアクションを示すのに役立ちます。ルーターは、特定のSおよびGに対して、特定の時間にアクティブな（S、G）エントリを1つしか持つことができないことに注意してください。 RPTビットフラグが設定されているかどうか。言い換えると、ルーターは、同じSとGに対して同時に（S、G）と（S、G）RPTビットの両方のエントリを持つことはありません。 Join / Pruneメッセージのペイロードには、Multicast-Address = G、Join = NULL、Prune = S、RPT-bitが含まれています。
A new receiver may join an existing RP-tree on which source-specific prune state has been established (e.g., because downstream receivers have switched to SP-trees). In this case the prune state must be eradicated upstream of the new receiver to bring all sources' data packets down to the new receiver. Therefore, when a (*,G) Join arrives at a router that has any (Si,G)RPT-bit entries (i.e., entries that cause the router to send source-specific prunes toward the RP), these entries must be updated upstream of the router so as to bring all sources' packets down to the new member. To accomplish this, each router that receives a (*,G) Join/Prune message updates all existing (S,G)RPT-bit entries. The router may also trigger a (*,G) Join/Prune message upstream to cause the same updating of RPT-bit settings upstream and pull down all active sources' packets. If the arriving (*,G) join has some sources included in its prune list, then the corresponding (S,G)RPT-bit entries are left unchanged (i.e., the RPT-bit remains set and no oif is added).
新しいレシーバーは、ソース固有のプルーン状態が確立されている既存のRPツリーに参加できます（たとえば、ダウンストリームレシーバーがSPツリーに切り替わったため）。この場合、すべてのソースのデータパケットを新しいレシーバーに送るために、プルーン状態を新しいレシーバーの上流で根絶する必要があります。したがって、（*、G）Joinが（Si、G）RPTビットエントリ（つまり、ルータにソース固有のプルーンをRPに送信させるエントリ）があるルータに到着した場合、これらのエントリを更新する必要があります。すべてのソースのパケットを新しいメンバーに送るために、ルーターの上流。これを実現するために、（*、G）Join / Pruneメッセージを受信する各ルーターは、既存のすべての（S、G）RPTビットエントリを更新します。また、ルーターは（*、G）アップストリームのJoin / Pruneメッセージをトリガーして、アップストリームのRPTビット設定を同じように更新し、すべてのアクティブなソースのパケットをプルダウンすることもできます。到着する（*、G）結合のプルーンリストにいくつかのソースが含まれている場合、対応する（S、G）RPTビットエントリは変更されません（つまり、RPTビットは設定されたままで、oifは追加されません）。
In the steady state each router sends periodic Join/Prune messages for each active PIM route entry; the Join/Prune messages are sent to the neighbor indicated in the corresponding entry. These messages are sent periodically to capture state, topology, and membership changes. A Join/Prune message is also sent on an event-triggered basis each time a new route entry is established for some new source (note that some damping function may be applied, e.g., a short delay to allow for merging of new Join information). Join/Prune messages do not elicit any form of explicit acknowledgment; routers recover from lost packets using the periodic refresh mechanism.
定常状態では、各ルータはアクティブなPIMルートエントリごとに定期的にJoin / Pruneメッセージを送信します。 Join / Pruneメッセージは、対応するエントリに示されているネイバーに送信されます。これらのメッセージは、状態、トポロジ、およびメンバーシップの変更をキャプチャするために定期的に送信されます。また、Join / Pruneメッセージは、新しいルートエントリが新しいソースに対して確立されるたびに、イベントトリガーベースで送信されます（新しい結合情報のマージを可能にするための短い遅延など、いくつかのダンピング機能が適用される場合があります）。 。 Join / Pruneメッセージは、いかなる形式の明示的な確認も引き出しません。ルーターは、定期的な更新メカニズムを使用して、失われたパケットから回復します。
To obtain the RP information, all routers within a PIM domain collect Bootstrap messages. Bootstrap messages are sent hop-by-hop within the domain; the domain's bootstrap router (BSR) is responsible for originating the Bootstrap messages. Bootstrap messages are used to carry out a dynamic BSR election when needed and to distribute RP information in steady state.
RP情報を取得するために、PIMドメイン内のすべてのルーターはブートストラップメッセージを収集します。ブートストラップメッセージは、ドメイン内でホップバイホップで送信されます。ドメインのブートストラップルーター（BSR）は、ブートストラップメッセージの発信を担当します。ブートストラップメッセージは、必要に応じて動的BSR選定を実行し、RP情報を定常状態で配布するために使用されます。
A domain in this context is a contiguous set of routers that all implement PIM and are configured to operate within a common boundary defined by PIM Multicast Border Routers (PMBRs). PMBRs connect each PIM domain to the rest of the internet.
このコンテキストのドメインは、すべてPIMを実装し、PIMマルチキャストボーダールーター（PMBR）で定義された共通の境界内で動作するように構成されたルーターの連続したセットです。 PMBRは、各PIMドメインを残りのインターネットに接続します。
Routers use a set of available RPs (called the RP-Set) distributed in Bootstrap messages to get the proper Group to RP mapping. The following paragraphs summarize the mechanism; details of the mechanism may be found in Sections 3.6 and Appendix 6.2. A (small)
ルーターは、ブートストラップメッセージで配布される利用可能なRPのセット（RP-Setと呼ばれます）を使用して、適切なグループからRPへのマッピングを取得します。以下の段落はメカニズムを要約しています。メカニズムの詳細は、セクション3.6および付録6.2に記載されています。小さな）
set of routers, within a domain, are configured as candidate BSRs and, through a simple election mechanism, a single BSR is selected for that domain. A set of routers within a domain are also configured as candidate RPs (C-RPs); typically these will be the same routers that are configured as C-BSRs. Candidate RPs periodically unicast Candidate-RP-Advertisement messages (C-RP-Advs) to the BSR of that domain. C-RP-Advs include the address of the advertising C-RP, as well as an optional group address and a mask length field, indicating the group prefix(es) for which the candidacy is advertised. The BSR then includes a set of these Candidate-RPs (the RP-Set), along with the corresponding group prefixes, in Bootstrap messages it periodically originates. Bootstrap messages are distributed hop-by-hop throughout the domain.
ドメイン内のルーターのセットは候補BSRとして構成され、単純な選択メカニズムにより、そのドメインに対して単一のBSRが選択されます。ドメイン内の一連のルーターも候補RP（C-RP）として構成されます。通常、これらはC-BSRとして構成されているのと同じルーターになります。候補RPは、そのドメインのBSRに定期的にCandidate-RP-Advertisementメッセージ（C-RP-Advs）をユニキャストします。 C-RP-Advsには、アドバタイズがアドバタイズされるグループプレフィクスを示す、オプションのグループアドレスとマスク長フィールドに加えて、アドバタイジングC-RPのアドレスが含まれます。次に、BSRは、これらのCandidate-RPのセット（RP-Set）を、対応するグループプレフィックスとともに、定期的に発信するブートストラップメッセージに含めます。ブートストラップメッセージは、ドメイン全体にホップバイホップで分散されます。
Routers receive and store Bootstrap messages originated by the BSR. When a DR gets a membership indication from IGMP for (or a data packet from) a directly connected host, for a group for which it has no entry, the DR uses a hash function to map the group address to one of the C-RPs whose Group-prefix includes the group (see Section 3.7). The DR then sends a Join/Prune message towards (or unicasts Registers to) that RP.
ルータは、BSRから発信されたブートストラップメッセージを受信して保存します。直接接続されたホストのIGMPから（またはデータパケットから）メンバーシップの指示をDRが取得すると、DRはエントリがないグループに対して、ハッシュ関数を使用してグループアドレスをC-RPの1つにマッピングします。そのグループ接頭辞にはグループが含まれます（セクション3.7を参照）。次に、DRはそのRPに向けてJoin / Pruneメッセージを送信します（またはレジスタをユニキャストします）。
The Bootstrap message indicates liveness of the RPs included therein. If an RP is included in the message, then it is tagged as `up' at the routers; while RPs not included in the message are removed from the list of RPs over which the hash algorithm acts. Each router continues to use the contents of the most recently received Bootstrap message until it receives a new Bootstrap message.
ブートストラップメッセージは、そこに含まれるRPの活性を示します。 RPがメッセージに含まれている場合、ルーターで「up」のタグが付けられます。メッセージに含まれていないRPは、ハッシュアルゴリズムが機能するRPのリストから削除されます。各ルーターは、新しいブートストラップメッセージを受信するまで、最後に受信したブートストラップメッセージの内容を使用し続けます。
If a PIM domain partitions, each area separated from the old BSR will elect its own BSR, which will distribute an RP-Set containing RPs that are reachable within that partition. When the partition heals, another election will occur automatically and only one of the BSRs will continue to send out Bootstrap messages. As is expected at the time of a partition or healing, some disruption in packet delivery may occur. This time will be on the order of the region's round-trip time and the bootstrap router timeout value.
PIMドメインがパーティション分割される場合、古いBSRから分離された各エリアは独自のBSRを選出し、そのパーティション内で到達可能なRPを含むRPセットを配布します。パーティションが回復すると、別の選択が自動的に行われ、BSRの1つだけが引き続きブートストラップメッセージを送信します。パーティション化または修復の際に予想されるように、パケット配信に何らかの障害が発生する可能性があります。この時間は、リージョンの往復時間とブートストラップルーターのタイムアウト値のオーダーになります。
In order to interoperate with networks that run dense-mode, broadcast and prune, protocols, such as DVMRP, all packets generated within a PIM-SM region must be pulled out to that region's PIM Multicast Border Routers (PMBRs) and injected (i.e., broadcast) into the DVMRP network. A PMBR is a router that sits at the boundary of a PIM-SM domain and interoperates with other types of multicast routers such as those that run DVMRP. Generally a PMBR would speak both protocols and implement interoperability functions not required by regular PIM routers. To support interoperability, a special entry type, referred to as (*,*,RP), must be supported by all PIM routers. For this reason we include details about (*,*,RP) entry handling in this general PIM specification.
DVMRPなどのデンスモード、ブロードキャスト、プルーンプロトコルを実行するネットワークと相互運用するには、PIM-SMリージョン内で生成されたすべてのパケットをそのリージョンのPIMマルチキャストボーダールーター（PMBR）に引き出して挿入する必要があります（つまり、ブロードキャスト）をDVMRPネットワークに送信します。 PMBRは、PIM-SMドメインの境界に位置し、DVMRPを実行するルーターなど、他のタイプのマルチキャストルーターと相互運用するルーターです。一般に、PMBRは両方のプロトコルを話し、通常のPIMルーターには不要な相互運用機能を実装します。相互運用性をサポートするには、（*、*、RP）と呼ばれる特別なエントリタイプがすべてのPIMルーターでサポートされている必要があります。このため、この一般的なPIM仕様には、（*、*、RP）エントリ処理の詳細が含まれています。
A data packet will match on a (*,*,RP) entry if there is no more specific entry (such as (S,G) or (*,G)) and the destination group address in the packet maps to the RP listed in the (*,*,RP) entry. In this sense, a (*,*,RP) entry represents an aggregation of all the groups that hash to that RP. PMBRs initialize (*,*,RP) state for each RP in the domain's RPset. The (*,*,RP) state causes the PMBRs to send (*,*,RP) Join/Prune messages toward each of the active RPs in the domain. As a result distribution trees are built that carry all data packets originated within the PIM domain (and sent to the RPs) down to the PMBRs.
特定のエントリ（（S、G）や（*、G）など）がなく、パケット内の宛先グループアドレスがリストされているRPにマッピングされている場合、データパケットは（*、*、RP）エントリで一致します（*、*、RP）エントリ内。この意味で、（*、*、RP）エントリは、そのRPにハッシュされるすべてのグループの集約を表します。 PMBRは、ドメインのRPset内の各RPの（*、*、RP）状態を初期化します。 （*、*、RP）状態は、PMBRがドメイン内のアクティブな各RPに向けて（*、*、RP）結合/プルーニングメッセージを送信するようにします。その結果、PIMドメイン内から発信された（RPに送信された）すべてのデータパケットをPMBRに運ぶ配信ツリーが構築されます。
PMBRs are also responsible for delivering externally-generated packets to routers within the PIM domain. To do so, PMBRs initially encapsulate externally-originated packets (i.e., received on DVMRP interfaces) in Register messages and unicast them to the corresponding RP within the PIM domain. The Register message has a bit indicating that it was originated by a border router and the RP caches the originating PMBR's address in the route entry so that duplicate Registers from other PMBRs can be declined with a Register-Stop message.
PMBRは、外部で生成されたパケットをPIMドメイン内のルーターに配信する役割も果たします。これを行うために、PMBRは最初に外部から発信されたパケット（つまり、DVMRPインターフェイスで受信されたパケット）をRegisterメッセージにカプセル化し、PIMドメイン内の対応するRPにユニキャストします。登録メッセージには、それがボーダールータによって発信されたことを示すビットがあり、RPがルートエントリに発信PMBRのアドレスをキャッシュするため、他のPMBRからの重複するレジスタをRegister-Stopメッセージで拒否できます。
All PIM routers must be capable of supporting (*,*,RP) state and interpreting associated Join/Prune messages. We describe the handling of (*,*,RP) entries and messages throughout this document; however, detailed PIM Multicast Border Router (PMBR) functions will be specified in a separate interoperability document (see directory, http://catarina.usc.edu/pim/interop/).
すべてのPIMルーターは、（*、*、RP）状態をサポートし、関連するJoin / Pruneメッセージを解釈できる必要があります。このドキュメントでは、（*、*、RP）エントリとメッセージの処理について説明します。ただし、詳細なPIMマルチキャストボーダールーター（PMBR）機能は、個別の相互運用性ドキュメントで指定されます（ディレクトリhttp://catarina.usc.edu/pim/interop/を参照）。
Data packets are processed in a manner similar to other multicast schemes. A router first performs a longest match on the source and group address in the data packet. A (S,G) entry is matched first if one exists; a (*,G) entry is matched otherwise. If neither state exists, then a (*,*,RP) entry match is attempted as follows: the router hashes on G to identify the RP for group G, and looks for a (*,*,RP) entry that has this RP address associated with it. If none of the above exists, then the packet is dropped. If a state is matched, the router compares the interface on which the packet arrived to the incoming interface field in the matched route entry. If the iif check fails the packet is dropped, otherwise the packet is forwarded to all interfaces listed in the outgoing interface list.
データパケットは、他のマルチキャスト方式と同様の方法で処理されます。ルータは最初に、データパケットの送信元アドレスとグループアドレスで最長一致を実行します。 （S、G）エントリが存在する場合は、最初に一致します。それ以外の場合は（*、G）エントリが一致します。どちらの状態も存在しない場合、（*、*、RP）エントリの一致が次のように試行されます。ルーターはGをハッシュしてグループGのRPを識別し、このRPを持つ（*、*、RP）エントリを探します関連付けられたアドレス。上記のいずれも存在しない場合、パケットはドロップされます。状態が一致すると、ルーターは、パケットが到着したインターフェイスを、一致したルートエントリの着信インターフェイスフィールドと比較します。 iifチェックに失敗した場合、パケットはドロップされます。失敗した場合、パケットは発信インターフェイスリストにリストされているすべてのインターフェイスに転送されます。
Some special actions are needed to deliver packets continuously while switching from the shared to shortest-path tree. In particular, when a (S,G) entry is matched, incoming packets are forwarded as follows:
共有から最短パスツリーに切り替える間、パケットを継続的に配信するには、いくつかの特別なアクションが必要です。特に、（S、G）エントリが一致すると、着信パケットは次のように転送されます。
1 If the SPT-bit is set, then:
1 SPTビットが設定されている場合：
1 if the incoming interface is the same as a matching (S,G) iif, the packet is forwarded to the oif-list of (S,G).
着信インターフェースが一致する（S、G）と同じ場合は1、パケットは（S、G）のoig-listに転送されます。
2 if the incoming interface is different than a matching (S,G) iif , the packet is discarded.
2着信インターフェースが一致する（S、G）iifと異なる場合、パケットは破棄されます。
2 If the SPT-bit is cleared, then:
2 SPTビットがクリアされている場合：
1 if the incoming interface is the same as a matching (S,G) iif, the packet is forwarded to the oif-list of (S,G). In addition, the SPT bit is set for that entry if the incoming interface differs from the incoming interface of the (*,G) or (*,*,RP) entry.
1着信インターフェースが一致する（S、G）iifと同じ場合、パケットは（S、G）のoif-listに転送されます。さらに、着信インターフェースが（*、G）または（*、*、RP）エントリーの着信インターフェースと異なる場合、SPTビットがそのエントリーに設定されます。
2 if the incoming interface is different than a matching (S,G) iif, the incoming interface is tested against a matching (*,G) or (*,*,RP) entry. If the iif is the same as one of those, the packet is forwarded to the oif-list of the matching entry.
2着信インターフェースが一致する（S、G）iifと異なる場合、着信インターフェースは一致する（*、G）または（*、*、RP）エントリーに対してテストされます。 iifがそれらのいずれかと同じ場合、パケットは一致するエントリのoif-listに転送されます。
3 Otherwise the iif does not match any entry for G and the packet is discarded.
3それ以外の場合、iifはGのどのエントリとも一致せず、パケットは破棄されます。
Data packets never trigger prunes. However, data packets may trigger actions that in turn trigger prunes. For example, when router B in figure 3 decides to switch to SP-tree at step 3, it creates a (S,G) entry with SPT-bit set to 0. When data packets from S arrive at interface 2 of B, B sets the SPT-bit to 1 since the iif for (*,G) is different than that for (S,G). This triggers the sending of prunes towards the RP.
データパケットがプルーンをトリガーすることはありません。ただし、データパケットはプルーニングをトリガーするアクションをトリガーする場合があります。たとえば、図3のルータBがステップ3でSPツリーに切り替えることを決定すると、SPTビットが0に設定された（S、G）エントリが作成されます。SからのデータパケットがB、Bのインターフェイス2に到着すると（*、G）のiifは（S、G）のiifと異なるため、SPTビットを1に設定します。これにより、RPへのプルーンの送信がトリガーされます。
This section describes a few additional protocol mechanisms needed to operate PIM over multi-access networks: Designated Router election, Assert messages to resolve parallel paths, and the Join/Prune-Suppression-Timer to suppress redundant Joins on multi-access networks.
このセクションでは、マルチアクセスネットワーク上でPIMを操作するために必要ないくつかの追加のプロトコルメカニズムについて説明します。指定ルーターの選択、並列パスを解決するためのメッセージのアサート、およびマルチアクセスネットワークでの冗長な結合を抑制するための結合/プルーニングタイマー。
Designated router election:
指定ルーターの選択：
When there are multiple routers connected to a multi-access network, one of them must be chosen to operate as the designated router (DR) at any point in time. The DR is responsible for sending triggered Join/Prune and Register messages toward the RP.
マルチアクセスネットワークに複数のルーターが接続されている場合、いずれかの時点で代表ルーター（DR）として動作するルーターを1つ選択する必要があります。 DRは、トリガーされたJoin / PruneおよびRegisterメッセージをRPに送信します。
A simple designated router (DR) election mechanism is used for both SM and traditional IP multicast routing. Neighboring routers send Hello messages to each other. The sender with the largest network layer address assumes the role of DR. Each router connected to the multi-access LAN sends the Hellos periodically in order to adapt to changes in router status.
SMと従来のIPマルチキャストルーティングの両方で、単純な代表ルーター（DR）の選択メカニズムが使用されます。隣接するルータは互いにHelloメッセージを送信します。最大のネットワーク層アドレスを持つ送信者がDRの役割を引き受けます。マルチアクセスLANに接続されている各ルーターは、ルーターの状態の変化に対応するために定期的にHelloを送信します。
Parallel paths to a source or the RP--Assert process:
ソースまたはRPへの並列パス-アサートプロセス：
If a router receives a multicast datagram on a multi-access LAN from a source whose corresponding (S,G) outgoing interface list includes the interface to that LAN, the packet must be a duplicate. In this case a single forwarder must be elected. Using Assert messages addressed to `224.0.0.13' (ALL-PIM-ROUTERS group) on the LAN, upstream routers can resolve which one will act as the forwarder. Downstream routers listen to the Asserts so they know which one was elected, and therefore where to send subsequent Joins. Typically this is the same as the downstream router's RPF (Reverse Path Forwarding) neighbor; but there are circumstances where this might not be the case, e.g., when using multiple unicast routing protocols on that LAN. The RPF neighbor for a particular source (or RP) is the next-hop router to which packets are forwarded en route to that source (or RP); and therefore is considered a good path via which to accept packets from that source.
ルーターが、対応する（S、G）発信インターフェイスリストにそのLANへのインターフェイスが含まれているソースからマルチアクセスLAN上のマルチキャストデータグラムを受信する場合、パケットは重複している必要があります。この場合、単一のフォワーダーを選択する必要があります。 LAN上の「224.0.0.13」（ALL-PIM-ROUTERSグループ）宛のアサートメッセージを使用して、アップストリームルータは、フォワーダとして機能するルータを解決できます。ダウンストリームルーターはアサートをリッスンするので、どちらが選ばれたか、したがって後続の結合の送信先を知ることができます。通常、これはダウンストリームルータのRPF（Reverse Path Forwarding）ネイバーと同じです。ただし、これが当てはまらない場合もあります。たとえば、そのLANで複数のユニキャストルーティングプロトコルを使用する場合などです。特定の送信元（またはRP）のRPFネイバーは、その送信元（またはRP）への途中でパケットが転送されるネクストホップルータです。したがって、そのソースからのパケットを受け入れるための適切なパスと見なされます。
The upstream router elected is the one that has the shortest distance to the source. Therefore, when a packet is received on an outgoing interface a router sends an Assert message on the multi-access LAN indicating what metric it uses to reach the source of the data packet. The router with the smallest numerical metric (with ties broken by highest address) will become the forwarder. All other upstream routers will delete the interface from their outgoing interface list. The downstream routers also do the comparison in case the forwarder is different than the RPF neighbor.
選択されたアップストリームルータは、送信元までの距離が最も短いルータです。したがって、発信インターフェイスでパケットが受信されると、ルータはマルチアクセスLANでAssertメッセージを送信し、データパケットの送信元に到達するために使用するメトリックを示します。数値メトリックが最小のルータ（タイが最大アドレスで分割されている）がフォワーダになります。他のすべての上流ルーターは、発信インターフェースリストからインターフェースを削除します。フォワーダーがRPFネイバーと異なる場合は、ダウンストリームルーターも比較を行います。
Associated with the metric is a metric preference value. This is provided to deal with the case where the upstream routers may run different unicast routing protocols. The numerically smaller metric preference is always preferred. The metric preference is treated as the high-order part of an assert metric comparison. Therefore, a metric value can be compared with another metric value provided both metric preferences are the same. A metric preference can be assigned per unicast routing protocol and needs to be consistent for all routers on the multi-access network.
メトリックには、メトリック設定値が関連付けられています。これは、上流ルーターが異なるユニキャストルーティングプロトコルを実行する場合に対処するために提供されています。数値的に小さいメトリック設定が常に優先されます。メトリック設定は、アサートメトリック比較の上位部分として扱われます。したがって、両方のメトリック設定が同じであれば、メトリック値を別のメトリック値と比較できます。メトリック設定は、ユニキャストルーティングプロトコルごとに割り当てることができ、マルチアクセスネットワーク上のすべてのルーターで一貫している必要があります。
Asserts are also needed for (*,G) entries since an RP-Tree and an SP-Tree for the same group may both cross the same multi-access network. When an assert is sent for a (*,G) entry, the first bit in the metric preference (RPT-bit) is always set to 1 to indicate that this path corresponds to the RP tree, and that the match must be done on (*,G) if it exists. Furthermore, the RPT-bit is always cleared for metric preferences that refer to SP-tree entries; this causes an SP-tree path to always look better than an RP-tree path. When the SP-tree and RPtree cross the same LAN, this mechanism eliminates the duplicates that would otherwise be carried over the LAN.
同じグループのRPツリーとSPツリーが両方とも同じマルチアクセスネットワークを通過する可能性があるため、（*、G）エントリにもアサートが必要です。 （*、G）エントリに対してアサートが送信されると、メトリック設定の最初のビット（RPTビット）は常に1に設定され、このパスがRPツリーに対応し、一致が行われる必要があることを示します（*、G）存在する場合。さらに、SPツリーエントリを参照するメトリック設定のRPTビットは常にクリアされます。これにより、SPツリーパスは常にRPツリーパスよりもきれいに見えます。 SPツリーとRPツリーが同じLANを横断する場合、このメカニズムにより、LANを介して伝送される重複が排除されます。
In case the packet, or the Assert message, matches on oif for (*,*,RP) entry, a (*,G) entry is created, and asserts take place as if the matching state were (*,G).
パケットまたはアサートメッセージが（*、*、RP）エントリのoifで一致する場合、（*、G）エントリが作成され、一致する状態が（*、G）であるかのようにアサートが行われます。
The DR may lose the (*,G) Assert process to another router on the LAN if there are multiple paths to the RP through the LAN. From then on, the DR is no longer the last-hop router for local receivers and removes the LAN from its (*,G) oif list. The winning router becomes the last-hop router and is responsible for sending (*,G) join messages to the RP.
LANを介してRPへのパスが複数ある場合、DRはLAN上の別のルーターへの（*、G）アサートプロセスを失う可能性があります。それ以降、DRはローカルレシーバーの最終ホップルーターではなくなり、LANを（*、G）oifリストから削除します。優勝したルーターはラストホップルーターになり、RPへの（*、G）参加メッセージの送信を担当します。
Join/Prune suppression:
結合/プルーニング抑制：
Join/Prune suppression may be used on multi-access LANs to reduce duplicate control message overhead; it is not required for correct performance of the protocol. If a Join/Prune message arrives and matches on the incoming interface for an existing (S,G), (*,G), or (*,*,RP) route entry, and the Holdtime included in the Join/Prune message is greater than the recipient's own [Join/Prune-Holdtime] (with ties resolved in favor of the higher network layer address), a timer (the Join/Prune-Suppression-timer) in the recipient's route entry may be started to suppress further Join/Prune messages. After this timer expires, the recipient triggers a Join/Prune message, and resumes sending periodic Join/Prunes, for this entry. The Join/Prune-Suppression-timer should be restarted each time a Join/Prune message is received with a higher Holdtime.
加入/プルーン抑制は、マルチアクセスLANで使用され、重複する制御メッセージのオーバーヘッドを削減できます。プロトコルの正しいパフォーマンスには必要ありません。 Join / Pruneメッセージが到着し、既存の（S、G）、（*、G）、または（*、*、RP）ルートエントリの着信インターフェイスに一致し、Join / Pruneメッセージに含まれるHoldtimeが受信者自身の[Join / Prune-Holdtime]よりも大きい（タイが上位のネットワークレイヤーアドレスを優先して解決される）場合、受信者のルートエントリのタイマー（Join / Prune-Suppression-timer）を開始して、それ以上のJoinを抑制できます。 /プルーンメッセージ。このタイマーの期限が切れると、受信者はJoin / Pruneメッセージをトリガーし、このエントリの定期的なJoin / Prunesの送信を再開します。 Join / Prune-Suppression-timerは、Join / Pruneメッセージがより長いホールドタイムで受信されるたびに再起動する必要があります。
When unicast routing changes, an RPF check is done on all active (S,G), (*,G) and (*,*,RP) entries, and all affected expected incoming interfaces are updated. In particular, if the new incoming interface appears in the outgoing interface list, it is deleted from the outgoing interface list. The previous incoming interface may be added to the outgoing interface list by a subsequent Join/Prune from downstream. Join/Prune messages received on the current incoming interface are ignored. Join/Prune messages received on new interfaces or existing outgoing interfaces are not ignored. Other outgoing interfaces are left as is until they are explicitly pruned by downstream routers or are timed out due to lack of appropriate Join/Prune messages. If the router has a (S,G) entry with the SPT-bit set, and the updated iif(S,G) does not differ from iif(*,G) or iif(*,*,RP), then the router resets the SPT-bit.
ユニキャストルーティングが変更されると、すべてのアクティブな（S、G）、（*、G）および（*、*、RP）エントリに対してRPFチェックが行われ、影響を受けるすべての着信インターフェイスが更新されます。特に、新しい着信インターフェイスが発信インターフェイスリストに表示される場合、発信インターフェイスリストから削除されます。前の着信インターフェースは、ダウンストリームからの後続の結合/プルーニングによって発信インターフェースリストに追加できます。現在の着信インターフェイスで受信された参加/プルーニングメッセージは無視されます。新しいインターフェイスまたは既存の発信インターフェイスで受信されたJoin / Pruneメッセージは無視されません。他の発信インターフェイスは、ダウンストリームルータによって明示的にプルーニングされるか、適切なJoin / Pruneメッセージがないためにタイムアウトになるまで、そのまま残されます。ルータにSPTビットが設定された（S、G）エントリがあり、更新されたiif（S、G）がiif（*、G）またはiif（*、*、RP）と変わらない場合、ルータはSPTビットをリセットします。
The router must send a Join/Prune message with S in the Join list out any new incoming interfaces to inform upstream routers that it expects multicast datagrams over the interface. It may also send a Join/Prune message with S in the Prune list out the old incoming interface, if the link is operational, to inform upstream routers that this part of the distribution tree is going away.
ルータは、JoinリストにSが含まれるJoin / Pruneメッセージを新しい着信インターフェイスから送信して、インターフェイスを介したマルチキャストデータグラムを予期していることを上流のルータに通知する必要があります。また、リンクが機能している場合は、PruneリストにSが含まれるJoin / Pruneメッセージを古い着信インターフェイスから送信して、配信ツリーのこの部分がなくなることを上流のルーターに通知することもできます。
Future documents will address the use of PIM-SM as a backbone inter-domain multicast routing protocol. Design choices center primarily around the distribution and usage of RP information for wide area, inter-domain groups.
今後のドキュメントでは、バックボーンドメイン間マルチキャストルーティングプロトコルとしてのPIM-SMの使用について取り上げます。設計の選択は、主に広域ドメイン間グループのRP情報の配布と使用を中心にしています。
All PIM control messages may use IPsec [6] to address security concerns. Security mechanisms are likely to be enhanced in the near future.
すべてのPIM制御メッセージは、セキュリティの問題に対処するためにIPsec [6]を使用できます。セキュリティメカニズムは近い将来強化されるでしょう。
3 Detailed Protocol Description
3詳細なプロトコルの説明
This section describes the protocol operations from the perspective of an individual router implementation. In particular, for each message type we describe how it is generated and processed.
このセクションでは、個々のルーター実装の観点からプロトコル操作について説明します。特に、メッセージタイプごとに、メッセージの生成方法と処理方法について説明します。
Hello messages are sent so neighboring routers can discover each other.
Helloメッセージが送信されるので、隣接するルーターがお互いを検出できます。
Hello messages are sent periodically between PIM neighbors, every [Hello-Period] seconds. This informs routers what interfaces have PIM neighbors. Hello messages are multicast using address 224.0.0.13 (ALL-PIM-ROUTERS group). The packet includes a Holdtime, set to [Hello-Holdtime], for neighbors to keep the information valid. Hellos are sent on all types of communication links.
Helloメッセージは、[Hello-Period]秒ごとにPIMネイバー間で定期的に送信されます。これにより、PIMネイバーを持つインターフェイスがルータに通知されます。 Helloメッセージは、アドレス224.0.0.13（ALL-PIM-ROUTERSグループ）を使用してマルチキャストされます。パケットには、ネイバーが情報を有効に保つための[Hello-Holdtime]に設定されたホールドタイムが含まれています。 Helloは、すべてのタイプの通信リンクで送信されます。
When a router receives a Hello message, it stores the network layer address for that neighbor, sets its Neighbor-timer for the Hello sender to the Holdtime included in the Hello, and determines the Designated Router (DR) for that interface. The highest addressed system is elected DR. Each Hello received causes the DR's address to be updated.
ルーターは、Helloメッセージを受信すると、そのネイバーのネットワークレイヤーアドレスを格納し、Hello送信者のNeighborタイマーをHelloに含まれるHoldtimeに設定し、そのインターフェイスの代表ルーター（DR）を決定します。最も高いアドレス指定されたシステムがDRとして選出されます。 Helloを受信するたびに、DRのアドレスが更新されます。
When a router that is the active DR receives a Hello from a new neighbor (i.e., from an address that is not yet in the DRs neighbor table), the DR unicasts its most recent RP-set information to the new neighbor.
アクティブなDRであるルーターが新しいネイバーから（つまり、DRネイバーテーブルにまだないアドレスから）Helloを受信すると、DRは最新のRPセット情報を新しいネイバーにユニキャストします。
A periodic process is run to time out PIM neighbors that have not sent Hellos. If the DR has gone down, a new DR is chosen by scanning all neighbors on the interface and selecting the new DR to be the one with the highest network layer address. If an interface has gone down, the router may optionally time out all PIM neighbors associated with the interface.
Helloを送信していないPIMネイバーをタイムアウトにする定期的なプロセスが実行されます。 DRがダウンした場合、新しいDRは、インターフェイス上のすべてのネイバーをスキャンし、新しいDRを選択して、ネットワーク層アドレスが最も高いものにします。インターフェイスがダウンした場合、ルータはオプションで、そのインターフェイスに関連付けられているすべてのPIMネイバーをタイムアウトにすることがあります。
Join/Prune messages are sent to join or prune a branch off of the multicast distribution tree. A single message contains both a join and prune list, either one of which may be null. Each list contains a set of source addresses, indicating the source-specific trees or shared tree that the router wants to join or prune.
Join / Pruneメッセージは、マルチキャスト配信ツリーのブランチに参加またはプルーニングするために送信されます。 1つのメッセージには、結合リストとプルーニングリストの両方が含まれ、どちらか一方がnullになる場合があります。各リストには、ルーターが参加またはプルーニングする送信元固有のツリーまたは共有ツリーを示す一連の送信元アドレスが含まれています。
Join/Prune messages are merged such that a message sent to a particular upstream neighbor, N, includes all of the current joined and pruned sources that are reached via N; according to unicast routing Join/Prune messages are multicast to all routers on multi-access networks with the target address set to the next hop router towards S or RP. Join/Prune messages are sent every [Join/Prune-Period] seconds. In the future we will introduce mechanisms to rate-limit this control traffic on a hop by hop basis, in order to avoid excessive overhead on small links. In addition, certain events cause triggered Join/Prune messages to be sent.
Join / Pruneメッセージは、特定のアップストリームネイバーNに送信されるメッセージに、Nを介して到達する現在のJoinおよびプルーニングされたソースがすべて含まれるようにマージされます。ユニキャストルーティングによれば、Join / Pruneメッセージは、ターゲットアドレスがSまたはRPへのネクストホップルーターに設定されたマルチアクセスネットワーク上のすべてのルーターにマルチキャストされます。 Join / Pruneメッセージは、[Join / Prune-Period]秒ごとに送信されます。将来的には、小さなリンクでの過度のオーバーヘッドを回避するために、ホップバイホップでこの制御トラフィックをレート制限するメカニズムを導入します。さらに、特定のイベントにより、トリガーされたJoin / Pruneメッセージが送信されます。
Periodic Join/Prune Messages:
定期的な参加/整理メッセージ：
A router sends a periodic Join/Prune message to each distinct RPF neighbor associated with each (S,G), (*,G) and (*,*,RP) entry. Join/Prune messages are only sent if the RPF neighbor is a PIM neighbor. A periodic Join/Prune message sent to a particular RPF neighbor is constructed as follows:
ルーターは定期的に参加/削除メッセージを各（S、G）、（*、G）、（*、*、RP）エントリに関連付けられた個別のRPFネイバーに送信します。 Join / Pruneメッセージは、RPFネイバーがPIMネイバーである場合にのみ送信されます。特定のRPFネイバーに送信される定期的なJoin / Pruneメッセージは、次のように構築されます。
1 Each router determines the RP for a (*,G) entry by using the hash function described. The RP address (with RPT and WC bits set) is included in the join list of a periodic Join/Prune message under the following conditions:
1各ルータは、説明されているハッシュ関数を使用して、（*、G）エントリのRPを決定します。 RPアドレス（RPTおよびWCビットが設定されている）は、次の条件下で定期的なJoin / Pruneメッセージの結合リストに含まれています。
1 The Join/Prune message is being sent to the RPF neighbor toward the RP for an active (*,G) or (*,*,RP) entry, and
1 Join / Pruneメッセージは、アクティブな（*、G）または（*、*、RP）エントリのRPに向けてRPFネイバーに送信されます。
2 The outgoing interface list in the (*,G) or (*,*,RP) entry is non-NULL, or the router is the DR on the same interface as the RPF neighbor.
2（*、G）または（*、*、RP）エントリの発信インターフェイスリストがNULLでないか、ルータがRPFネイバーと同じインターフェイスのDRです。
2 A particular source address, S, is included in the join list with the RPT and WC bits cleared under the following conditions:
2特定の送信元アドレスSは、RPTおよびWCビットが次の条件下でクリアされた状態で、結合リストに含まれています。
1 The Join/Prune message is being sent to the RPF neighbor toward S, and
1 Join / PruneメッセージがSに向けてRPFネイバーに送信され、
2 There exists an active (S,G) entry with the RPT-bit flag cleared, and
2 RPTビットフラグがクリアされたアクティブな（S、G）エントリが存在します。
3 The oif list in the (S,G) entry is not null.
3（S、G）エントリのoifリストがnullではありません。
3 A particular source address, S, is included in the prune list with the RPT and WC bits cleared under the following conditions:
3特定の送信元アドレスSがプルーニングリストに含まれ、RPTおよびWCビットは次の条件でクリアされます。
1 The Join/Prune message is being sent to the RPF neighbor toward S, and
1 Join / PruneメッセージがSに向けてRPFネイバーに送信され、
2 There exists an active (S,G) entry with the RPT-bit flag cleared, and
2 RPTビットフラグがクリアされたアクティブな（S、G）エントリが存在します。
3 The oif list in the (S,G) entry is null.
3（S、G）エントリのoifリストがnullです。
4 A particular source address, S, is included in the prune list with the RPT-bit set and the WC bit cleared under the following conditions:
4特定の送信元アドレスSは、RPTビットが設定され、WCビットが以下の条件でクリアされた状態でプルーンリストに含まれています。
1 The Join/Prune message is being sent to the RPF neighbor toward the RP and there exists a (S,G) entry with the RPT-bit flag set and null oif list, or
1 Join / PruneメッセージがRPに向かうRPFネイバーに送信されており、RPTビットフラグセットとヌルoifリストを持つ（S、G）エントリが存在する、または
2 The Join/Prune message is being sent to the RPF neighbor toward the RP, there exists a (S,G) entry with the RPT-bit flag cleared and SPT-bit set, and the incoming interface toward S is different than the incoming interface toward the RP, or
2 Join / PruneメッセージがRPに向けてRPFネイバーに送信され、RPTビットフラグがクリアされ、SPTビットが設定された（S、G）エントリが存在し、Sへの着信インターフェイスが着信と異なるRPへのインターフェイス、または
3 The Join/Prune message is being sent to the RPF neighbor toward the RP, and there exists a (*,G) entry and (S,G) entry for a directly connected source.
3 Join / PruneメッセージがRPに向かうRPFネイバーに送信されており、直接接続されたソースの（*、G）エントリと（S、G）エントリが存在します。
5 The RP address (with RPT and WC bits set) is included in the prune list if:
5 RPアドレス（RPTおよびWCビットが設定されている）は、次の場合にプルーンリストに含まれます。
1 The Join/Prune message is being sent to the RPF neighbor toward the RP and there exists a (*,G) entry with a null oif list (see Section 3.5.2).
1 Join / PruneメッセージがRPに向けてRPFネイバーに送信されており、oifリストがnullの（*、G）エントリが存在します（セクション3.5.2を参照）。
Triggered Join/Prune Messages:
トリガーされた参加/整理メッセージ：
In addition to periodic messages, the following events will trigger Join/Prune messages if as a result, a) a new entry is created, or b) the oif list changes from null to non-null or non-null to null. The contents of triggered messages are the same as the periodic, described above.
定期的なメッセージに加えて、次のイベントにより、Join / Pruneメッセージがトリガーされます。その結果、a）新しいエントリが作成されるか、b）oifリストがnullからnon-nullまたはnon-nullからnullに変更されます。トリガーされたメッセージの内容は、上記の定期的なメッセージと同じです。
1 Receipt of an indication from IGMP that the state of directly-connected-membership has changed (i.e., new members have just joined `membership indication' or all members have left), for a group G, may cause the last-hop router to build or modify corresponding (*,G) state. When IGMP indicates that there are no longer directly connected members, the oif is removed from the oif list if the oif-timer is not running. A Join/Prune message is triggered if and only if a) a new entry is created, or b) the oif list changes from null to non-null or non-null to null, as follows:
1グループGについて、直接接続されたメンバーシップの状態が変化した（つまり、新しいメンバーが「メンバーシップの表示」に参加した、またはすべてのメンバーが去った）IGMPからの指示を受信すると、ラストホップルーターが対応する（*、G）状態を構築または変更します。直接接続されたメンバーがなくなったことをIGMPが示すとき、oifタイマーが実行されていない場合、oifはoifリストから削除されます。次のように、a）新しいエントリが作成された場合、またはb）oifリストがnullからnull以外に、またはnull以外からnullに変更された場合にのみ、Join / Pruneメッセージがトリガーされます。
1 If the receiving router does not have a route entry for G the router creates a (*,G) entry, copies the oif list from the corresponding (*,*,RP) entry (if it exists), and includes the interface included in the IGMP membership indication in the oif list; as always, the router never includes the entry's iif in the oif list. The router sends a Join/Prune message towards the RP with the RP address and RPT-bit and WC-bits set in the join list. Or,
1受信ルーターにGのルートエントリがない場合、ルーターは（*、G）エントリを作成し、対応する（*、*、RP）エントリからoifリストをコピーし（存在する場合）、含まれているインターフェイスを含めますoifリストのIGMPメンバーシップの表示。いつものように、ルーターはエントリのiifをoifリストに含めません。ルータは、参加リストに設定されたRPアドレスとRPTビットおよびWCビットを使用して、RPに向けてJoin / Pruneメッセージを送信します。または、
2 If a (S,G)RPT-bit or (*,G) entry already exists, the interface included in the IGMP membership indication is added to the oif list (if it was not included already).
2（S、G）RPTビットまたは（*、G）エントリがすでに存在する場合、IGMPメンバーシップ表示に含まれるインターフェイスがoifリストに追加されます（まだ含まれていない場合）。
2 Receipt of a Join/Prune message for (S,G), (*,G) or (*,*,RP) will cause building or modifying corresponding state, and subsequent triggering of upstream Join/Prune messages, in the following cases:
2（S、G）、（*、G）または（*、*、RP）のJoin / Pruneメッセージを受信すると、対応する状態が構築または変更され、その後、次の場合に上流のJoin / Pruneメッセージがトリガーされます。 ：
1 When there is no current route entry, the RP address included in the Join/Prune message is checked against the local RP-Set information. If it matches, an entry will be created and the new entry will in turn trigger an upstream Join/Prune message. If the router has no RP-Set information it may discard the message, or optionally use the RP address included in the message.
1現在のルートエントリがない場合、Join / Pruneメッセージに含まれるRPアドレスがローカルRP-Set情報と照合されます。一致する場合、エントリが作成され、新しいエントリが上流のJoin / Pruneメッセージをトリガーします。ルーターにRP-Set情報がない場合、ルーターはメッセージを破棄するか、オプションでメッセージに含まれているRPアドレスを使用します。
2 When the outgoing interface list of an (S,G)RPT-bit entry becomes null, the triggered Join/Prune message will contain S in the prune list.
2（S、G）RPTビットエントリの発信インターフェイスリストがnullになると、トリガーされたJoin / PruneメッセージのプルーンリストにSが含まれます。
3 When there exists a (S,G)RPT-bit with null oif list, and an (*,G) Join/Prune message is received, the arriving interface is added to the oif list and a (*,G) Join/Prune message is triggered upstream.
3 oifリストがnullの（S、G）RPTビットが存在し、（*、G）Join / Pruneメッセージが受信されると、到着したインターフェイスがoifリストに追加され、（*、G）Join /プルーンメッセージがアップストリームでトリガーされます。
4 When there exists a (*,G) with null oif list, and a (*,*,RP) Join/Prune message is received, the receiving interface is added to the oif list and a (*,*,RP) Join/Prune message is triggered upstream.
4ヌルのoifリストを持つ（*、G）が存在し、（*、*、RP）Join / Pruneメッセージが受信されると、受信インターフェースがoifリストに追加され、（*、*、RP）Join / Pruneメッセージは上流でトリガーされます。
3 Receipt of a packet that matches on a (S,G) entry whose SPT-bit is cleared triggers the following if the packet arrived on the correct incoming interface and there is a (*,G) or (*,*,RP) entry with a different incoming interface: a) the router sets the SPT-bit on the (S,G) entry, and b) the router sends a Join/Prune message towards the RP with S in the prune list and the RPT-bit set.
3 SPTビットがクリアされている（S、G）エントリに一致するパケットを受信すると、パケットが正しい着信インターフェイスに到着し、（*、G）または（*、*、RP）がある場合、次のトリガーがかかります異なる着信インターフェイスを持つエントリ：a）ルーターが（S、G）エントリーにSPTビットを設定し、b）ルーターが参加/プルーンメッセージをRPに送信し、プルーニングリストにSとRPTビットを含めますセットする。
4 Receipt of a packet at the DR from a directly connected source S, on the subnet containing the address S, triggers a Join/Prune message towards the RP with S in the prune list and the RPT-bit set under the following conditions: a) there is no matching (S,G) state, and b) there exists a (*,G) or (*,*,RP) for which the DR is not the RP.
4直接接続されたソースSからDRでパケットを受信すると、アドレスSを含むサブネット上で、次の条件下で、プルーンリストにSがあり、RPTビットが設定されているRPに向けて、Join / Pruneメッセージがトリガーされます。 ）一致する（S、G）状態がなく、b）DRがRPではない（*、G）または（*、*、RP）が存在する。
5 When a Join/Prune message is received for a group G, the prune list is checked. If the prune list contains a source or RP for which the receiving router has a corresponding active (S,G), (*,G) or (*,*,RP) entry, and whose iif is that on which the Join/Prune was received, then a join for (S,G), (*,G) or (*,*,RP) is triggered to override the prune, respectively. (This is necessary in the case of parallel downstream routers connected to a multi-access network.)
5グループGのJoin / Pruneメッセージを受信すると、プルーンリストがチェックされます。プルーニングリストに、受信側ルーターに対応するアクティブな（S、G）、（*、G）または（*、*、RP）エントリがあるソースまたはRPが含まれ、そのiifが結合/プルーニングの対象である場合受信された後、（S、G）、（*、G）または（*、*、RP）の結合がトリガーされ、それぞれプルーンをオーバーライドします。 （これは、マルチアクセスネットワークに接続された並列ダウンストリームルーターの場合に必要です。）
6 When the RP fails, the RP will not be included in the Bootstrap messages sent to all routers in that domain. This triggers the DRs to send (*,G) Join/Prune messages towards the new RP for the group, as determined by the RP-Set and the hash function. As described earlier, PMBRs trigger (*,*,RP) joins towards each RP in the RP-Set.
6 RPに障害が発生した場合、そのドメイン内のすべてのルーターに送信されるブートストラップメッセージにRPは含まれません。これにより、DRがトリガーされ、RP-Setおよびハッシュ関数によって決定された、グループの新しいRPに向けて（*、G）Join / Pruneメッセージを送信します。前述のように、PMBRは（*、*、RP）結合をRPセット内の各RPに向けてトリガーします。
7 When an entry's Join/Prune-Suppression timer expires, a Join/Prune message is triggered upstream corresponding to that entry, even if the outgoing interface has not transitioned between null and non-null states.
7エントリのJoin / Prune-Suppressionタイマーが期限切れになると、発信インターフェイスがヌル状態と非ヌル状態の間で移行していなくても、そのエントリに対応するアップストリームのJoin / Prune抑制メッセージがトリガーされます。
8 When the RPF neighbor changes (whether due to an Assert or changes in unicast routing), the router sets a random delay timer (the Random-Delay-Join-Timer) whose expiration triggers sending of a Join/Prune message for the asserted route entry to the Assert winner (if the Join/Prune Suppression timer has expired.)
8 RPFネイバーが変更されると（アサートまたはユニキャストルーティングの変更にかかわらず）、ルーターはランダム遅延タイマー（Random-Delay-Join-Timer）を設定します。アサート勝者へのエントリ（結合/プルーニング抑制タイマーが期限切れの場合）。
We do not trigger prunes onto interfaces based on data packets. Data packets that arrive on the wrong incoming interface are silently dropped. However, on point-to-point interfaces triggered prunes may be sent as an optimization.
データパケットに基づいてプルーニングをインターフェイスにトリガーすることはありません。間違った着信インターフェイスに到着したデータパケットは、通知なしでドロップされます。ただし、ポイントツーポイントインターフェイスでは、トリガーされたプルーンが最適化として送信される場合があります。
aragraphFragmentation It is possible that a Join/Prune message constructed according to the preceding rules could exceed the MTU of a network. In this case, the message can undergo semantic fragmentation whereby information corresponding to different groups can be sent in different messages. However, if a Join/Prune message must be fragmented the complete prune list corresponding to a group G must be included in the same Join/Prune message as the associated RP-tree Join for G. If such semantic fragmentation is not possible, IP fragmentation should be used between the two neighboring hops.
aragraphFragmentation前述のルールに従って構築されたJoin / PruneメッセージがネットワークのMTUを超える可能性があります。この場合、メッセージはセマンティックフラグメンテーションを受ける可能性があり、それにより、異なるグループに対応する情報を異なるメッセージで送信できます。ただし、Join / Pruneメッセージをフラグメント化する必要がある場合は、グループGに対応する完全なプルーンリストを、Gの関連するRPツリーJoinと同じJoin / Pruneメッセージに含める必要があります。このようなセマンティックフラグメンテーションが不可能な場合、IPフラグメンテーション2つの隣接するホップ間で使用する必要があります。
3.2.2 Receiving Join/Prune Messages When a router receives Join/Prune message, it processes it as follows.
3.2.2 Join / Pruneメッセージの受信ルータは、Join / Pruneメッセージを受信すると、次のように処理します。
The receiver of the Join/Prune notes the interface on which the PIM message arrived, call it I. The receiver then checks to see if the Join/Prune message was addressed to the receiving router itself (i.e., the router's address appears in the Unicast Upstream Neighbor Router field of the Join/Prune message). (If the router is connected to a multiaccess LAN, the message could be intended for a different router.) If the Join/Prune is for this router the following actions are taken.
Join / Pruneの受信者は、PIMメッセージが到着したインターフェイスをメモし、Iと呼びます。次に、受信者は、Join / Pruneメッセージが受信ルーター自体に宛てられたものかどうかを確認します（つまり、ルーターのアドレスがユニキャストに表示されます） Join / Pruneメッセージのアップストリームネイバールータフィールド）。 （ルーターがマルチアクセスLANに接続されている場合、メッセージは別のルーターを対象としている可能性があります。）このルーターに対する参加/プルーニングの場合、次のアクションが実行されます。
For each group address G, in the Join/Prune message, the associated join list is processed as follows. We refer to each address in the join list as Sj; Sj refers to the RP if the RPT-bit and WC-bit are both set. For each Sj in the join list of the Join/Prune message:
グループアドレスGごとに、Join / Pruneメッセージで、関連付けられた参加リストが次のように処理されます。結合リストの各アドレスをSjと呼びます。 RPTビットとWCビットの両方が設定されている場合、SjはRPを指します。 Join / Pruneメッセージの参加リスト内の各Sjについて：
1 If an address, Sj, in the join list of the Join/Prune message has the RPT-bit and WC-bit set, then Sj is the RP address used by the downstream router(s) and the following actions are taken:
1 Join / Pruneメッセージの参加リストのアドレスSjにRPTビットとWCビットが設定されている場合、Sjはダウンストリームルーターが使用するRPアドレスであり、次のアクションが実行されます。
1 If Sj is not the same as the receiving router's RP mapping for G, the receiving router may ignore the Join/Prune message with respect to that group entry. If the router does not have any RP-Set information, it may use the address Sj included in the Join/Prune message as the RP for the group.
1 Sjが受信ルーターのGに対するRPマッピングと同じでない場合、受信ルーターはそのグループエントリに関するJoin / Pruneメッセージを無視することがあります。ルータにRP-Set情報がない場合、Join / Pruneメッセージに含まれるアドレスSjをグループのRPとして使用できます。
2 If Sj is the same as the receiving router's RP mapping for G, the receiving router adds I to the outgoing interface list of the (*,G) route entry (if there is no (*,G) entry, the router creates one first) and sets the Oif-timer for that interface to the Holdtime specified in the Join/Prune message. In addition, the Oif-Deletion-Delay for that interface is set to 1/3rd the Holdtime specified in the Join/Prune message. If a (*,*,RP) entry exists, for the RP associated with G, then the oif list of the newly created (*,G) entry is copied from that (*,*,RP) entry.
2 Sjが受信ルーターのGに対するRPマッピングと同じである場合、受信ルーターは（*、G）ルートエントリの送信インターフェイスリストにIを追加します（（*、G）エントリがない場合、ルーターは1を作成します最初に）、そのインターフェイスのOifタイマーを、Join / Pruneメッセージで指定されたHoldtimeに設定します。さらに、そのインターフェースのOif-Deletion-Delayは、Join / Pruneメッセージで指定されたHoldtimeの1/3に設定されています。 （*、*、RP）エントリが存在する場合、Gに関連付けられたRPに対して、新しく作成された（*、G）エントリのoifリストがその（*、*、RP）エントリからコピーされます。
3 For each (Si,G) entry associated with group G: i) if Si is not included in the prune list, ii) if I is not on the same subnet as the address Si, and iii) if I is not the iif, then interface I is added to the oif list and the Oif-timer for that interface in each affected entry is increased (never decreased) to the Holdtime included in the Join/Prune message. In addition, if the Oif-timer for that interface is increased, the Oif-Deletion-Delay for that interface is set to 1/3rd the Holdtime specified in the Join/Prune message.
3グループGに関連付けられた（Si、G）エントリごとに、i）Siがプルーンリストに含まれていない場合、ii）IがアドレスSiと同じサブネット上にない場合、iii）iifでない場合次に、インターフェイスIがoifリストに追加され、影響を受ける各エントリのそのインターフェイスのOifタイマーが、Join / Pruneメッセージに含まれるHoldtimeまで増加します（減少しません）。さらに、そのインターフェースのOifタイマーが増加すると、そのインターフェースのOif-Deletion-Delayは、Join / Pruneメッセージで指定されたHoldtimeの3分の1に設定されます。
If the group address in the Join/Prune message is `*' then every (*,G) and (S,G) entry, whose group address hashes to the RP indicated in the (*,*,RP) Join/Prune message, is updated accordingly. A `*' in the group field of the Join/Prune is represented by a group address 224.0.0.0 and a group mask length of 4, indicating a (*,*,RP) Join.
Join / Pruneメッセージのグループアドレスが「*」の場合、（*、*、RP）Join / Pruneメッセージに示されているRPにグループアドレスがハッシュするすべての（*、G）および（S、G）エントリ、それに応じて更新されます。 Join / Pruneのグループフィールドの「*」は、グループアドレス224.0.0.0およびグループマスク長4で表され、（*、*、RP）結合を示します。
4 If the (Si,G) entry has its RPT-bit flag set to 1, and its oif list is the same as the (*,G) oif list, then the (Si,G)RPT-bit entry is deleted,
4（Si、G）エントリのRPTビットフラグが1に設定されており、そのoifリストが（*、G）oifリストと同じである場合、（Si、G）RPTビットエントリは削除されます。
5 The incoming interface is set to the interface used to send unicast packets to the RP in the (*,G) route entry, i.e., RPF interface toward the RP.
5着信インターフェイスは、（*、G）ルートエントリでRPにユニキャストパケットを送信するために使用されるインターフェイス、つまりRPへのRPFインターフェイスに設定されます。
2 For each address, Sj, in the join list whose RPT-bit and WC-bit are not set, and for which there is no existing (Sj,G) route entry, the router initiates one. The router creates a (S,G) entry and copies all outgoing interfaces from the (S,G)RPT-bit entry, if it exists. If there is no (S,G) entry, the oif list is copied from the (*,G) entry; and if there is no (*,G) entry, the oif list is copied from the (*,*,RP) entry, if it exists. In all cases, the iif of the (S,G) entry is always excluded from the oif list.
2 RPTビットとWCビットが設定されておらず、既存の（Sj、G）ルートエントリが存在しないジョインリスト内の各アドレスSjについて、ルーターがアドレスを開始します。ルータは（S、G）エントリを作成し、存在する場合は、（S、G）RPTビットエントリからすべての発信インターフェイスをコピーします。 （S、G）エントリがない場合、oifリストは（*、G）エントリからコピーされます。 （*、G）エントリがない場合、（*、*、RP）エントリからoifリストがコピーされます（存在する場合）。すべての場合において、（S、G）エントリのiifは常にoifリストから除外されます。
1 The outgoing interface for (Sj,G) is set to I. The incoming interface for (Sj,G) is set to the interface used to send unicast packets to Sj (i.e., the RPF neighbor).
1（Sj、G）の発信インターフェイスはIに設定されています。（Sj、G）の着信インターフェイスは、ユニキャストパケットをSjに送信するために使用されるインターフェイス（つまり、RPFネイバー）に設定されています。
2 If the interface used to reach Sj, is the same as I, this represents an error (or a unicast routing change) and the Join/Prune must not be processed.
2 Sjに到達するために使用されるインターフェースがIと同じである場合、これはエラー（またはユニキャストルーティングの変更）を表し、Join / Pruneを処理してはなりません。
3 For each address, Sj, in the join list of the Join/Prune message, for which there is an existing (Sj,G) route entry,
3既存の（Sj、G）ルートエントリがある、Join / Pruneメッセージの結合リスト内の各アドレスSjについて、
1 If the RPT-bit is not set for Sj listed in the Join/Prune message, but the RPT-bit flag is set on the existing (Sj,G) entry, the router clears the RPT-bit flag on the (Sj,G) entry, sets the incoming interface to point towards Sj for that (Sj,G) entry, and sends a Join/Prune message corresponding to that entry through the new incoming interface; and
1 RPTビットがJoin / PruneメッセージにリストされているSjに設定されていないが、RPTビットフラグが既存の（Sj、G）エントリに設定されている場合、ルータは（Sj、 G）エントリ。着信インターフェイスをその（Sj、G）エントリのSjを指すように設定し、そのエントリに対応するJoin / Pruneメッセージを新しい着信インターフェイスを介して送信します。そして
2 If I is not the same as the existing incoming interface, the router adds I to the list of outgoing interfaces.
2私が既存の着信インターフェイスと同じでない場合、ルータは発信インターフェイスのリストにIを追加します。
3 The Oif-timer for I is increased (never decreased) to the Holdtime included in the Join/Prune message. In addition, if the Oif-timer for that interface is increased, the Oif-Deletion-Delay for that interface is set to 1/3rd the Holdtime specified in the Join/Prune message.
3 IのOifタイマーは、Join / Pruneメッセージに含まれるHoldtimeまで増加します（減少しません）。さらに、そのインターフェースのOifタイマーが増加すると、そのインターフェースのOif-Deletion-Delayは、Join / Pruneメッセージで指定されたHoldtimeの3分の1に設定されます。
4 The (Sj,G) entry's SPT bit is cleared until data comes down the shortest path tree.
4（Sj、G）エントリのSPTビットは、データが最短パスツリーを下るまでクリアされます。
For each group address G, in the Join/Prune message, the associated prune list is processed as follows. We refer to each address in the prune list as Sp; Sp refers to the RP if the RPT-bit and WC-bit are both set. For each Sp in the prune list of the Join/Prune message:
グループアドレスGごとに、Join / Pruneメッセージで、関連付けられたプルーンリストが次のように処理されます。プルーンリストの各アドレスをSpと呼びます。 RPTビットとWCビットの両方が設定されている場合、SpはRPを指します。 Join / Pruneメッセージのプルーンリスト内の各Spについて：
1 For each address, Sp, in the prune list whose RPT-bit and WC-bit are cleared:
1プルーンリスト内の各アドレスSpに対して、RPTビットとWCビットがクリアされます。
1 If there is an existing (Sp,G) route entry, the router lowers the entry's Oif-timer for I to its Oif-Deletion-Delay, allowing for other downstream routers on a multi-access LAN to override the prune. However, on point-to-point links, the oif-timer is expired immediately.
1既存の（Sp、G）ルートエントリがある場合、ルーターはエントリのOifタイマーをIのOif-Deletion-Delayまで下げ、マルチアクセスLAN上の他のダウンストリームルーターがプルーンを無効にできるようにします。ただし、ポイントツーポイントリンクでは、oifタイマーはすぐに期限切れになります。
2 If the router has a current (*,G), or (*,*,RP), route entry, and if the existing (Sp,G) entry has its RPT-bit flag set to 1, then this (Sp,G)RPT-bit entry is maintained (not deleted) even if its outgoing interface list is null.
2ルーターに現在の（*、G）または（*、*、RP）のルートエントリがあり、既存の（Sp、G）エントリのRPTビットフラグが1に設定されている場合、これは（Sp、 G）RPTビットエントリは、その発信インターフェイスリストがnullであっても維持されます（削除されません）。
2 For each address, Sp, in the prune list whose RPT-bit is set and whose WC-bit cleared:
2プルーンリスト内の各アドレスSpについて、RPTビットが設定され、WCビットがクリアされます。
1 If there is an existing (Sp,G) route entry, the router lowers the entry's Oif-timer for I to its Oif-Deletion-Delay, allowing for other downstream routers on a multi-access LAN to override the prune. However, on point-to-point links, the oif-timer is expired immediately.
1既存の（Sp、G）ルートエントリがある場合、ルーターはエントリのOifタイマーをIのOif-Deletion-Delayまで下げ、マルチアクセスLAN上の他のダウンストリームルーターがプルーンを無効にできるようにします。ただし、ポイントツーポイントリンクでは、oifタイマーはすぐに期限切れになります。
2 If the router has a current (*,G), or (*,*,RP), route entry, and if the existing (Sp,G) entry has its RPT-bit flag set to 1, then this (Sp,G)RPT-bit entry is not deleted, and the Entry-timer is restarted, even if its outgoing interface list is null.
2ルーターに現在の（*、G）または（*、*、RP）のルートエントリがあり、既存の（Sp、G）エントリのRPTビットフラグが1に設定されている場合、これは（Sp、 G）RPTビットエントリは削除されず、エントリタイマーは、その発信インターフェイスリストがnullであっても再起動されます。
3 If (*,G), or corresponding (*,*,RP), state exists, but there is no (Sp,G) entry, an (Sp,G)RPT-bit entry is created . The outgoing interface list is copied from the (*,G), or (*,*,RP), entry, with the interface, I, on which the prune was received, is deleted. Packets from the pruned source, Sp, match on this state and are not forwarded toward the pruned receivers.
3（*、G）または対応する（*、*、RP）状態は存在するが、（Sp、G）エントリがない場合は、（Sp、G）RPTビットエントリが作成されます。発信インターフェースリストは、（*、G）または（*、*、RP）エントリからコピーされ、プルーンを受信したインターフェースIが削除されます。プルーニングされたソースSpからのパケットはこの状態で一致し、プルーニングされたレシーバーに転送されません。
4 If there exists a (Sp,G) entry, with or without the RPT-bit set, the oif-timer for I is expired, and the Entry-timer is restarted.
4 RPTビットが設定されているかどうかに関係なく、（Sp、G）エントリが存在する場合、Iのoif-timerが期限切れになり、Entry-timerが再起動されます。
3 For each address, Sp, in the prune list whose RPT-bit and WC-bit are both set:
3プルーンリスト内の各アドレスSpに対して、RPTビットとWCビットの両方が設定されています。
1 If there is an existing (*,G) entry, with Sp as the RP for G, the router lowers the entry's Oif-timer for I to its Oif-Deletion-Delay, allowing for other downstream routers on a multi-access LAN to override the prune. However, on point-to-point links, the oif-timer is expired immediately.
1既存の（*、G）エントリがあり、GのRPがSpの場合、ルータはエントリのOif-timerをIのOif-Deletion-Delayに下げ、マルチアクセスLAN上の他のダウンストリームルータを許可します。プルーンをオーバーライドします。ただし、ポイントツーポイントリンクでは、oifタイマーはすぐに期限切れになります。
2 If the corresponding (*,*,RP) state exists, but there is no (*,G) entry, a (*,G) entry is created. The outgoing interface list is copied from (*,*,RP) entry, with the interface, I, on which the prune was received, deleted.
2対応する（*、*、RP）状態は存在するが（*、G）エントリがない場合は、（*、G）エントリが作成されます。発信インターフェースリストは（*、*、RP）エントリからコピーされ、プルーンを受信したインターフェースIは削除されます。
For any new (S,G), (*,G) or (*,*,RP) entry created by an incoming Join/Prune message, the SPT-bit is cleared (and if a Join/Prune-Suppression timer is used, it is left off.)
着信結合/プルーンメッセージによって作成された新しい（S、G）、（*、G）または（*、*、RP）エントリの場合、SPTビットがクリアされます（結合/プルーン抑制タイマーが使用されている場合） 、省略されます。）
If the entry has a Join/Prune-Suppression timer associated with it, and if the received Join/Prune does not indicate the router as its target, then the receiving router examines the join and prune lists to see if any addresses in the list `completely-match' existing (S,G), (*,G), or (*,*,RP) state for which the receiving router currently schedules Join/Prune messages. An element on the join or prune list `completely-matches' a route entry only if both the addresses and RPT-bit flag are the same. If the incoming Join/Prune message completely matches an existing (S,G), (*,G), or (*,*,RP) entry and the Join/Prune arrived on the iif for that entry, then the router compares the Holdtime included in the Join/Prune message, to its own [Join/Prune-Holdtime]. If its own [Join/Prune-Holdtime] is lower, the Join/Prune-Suppression-timer is started at the [Join/Prune-Suppression-Timeout]. If the [Join/Prune-Holdtime] is equal, the tie is resolved in favor of the Join/Prune Message originator that has the higher network layer address. When the Join/Prune timer expires, the router triggers a Join/Prune message for the corresponding entry(ies).
エントリにJoin / Prune-Suppressionタイマーが関連付けられていて、受信したJoin / Pruneがルーターをターゲットとして示していない場合、受信側ルーターは、結合リストとプルーニングリストを調べて、リストにアドレスがあるかどうかを確認します `受信側ルーターが現在Join / Pruneメッセージをスケジュールしている既存の（S、G）、（*、G）、または（*、*、RP）状態を完全に一致させます。結合リストまたはプルーニングリストの要素は、アドレスとRPTビットフラグの両方が同じ場合にのみ、ルートエントリに「完全に一致」します。着信Join / Pruneメッセージが既存の（S、G）、（*、G）、または（*、*、RP）エントリと完全に一致し、Join / Pruneがそのエントリのiifに到着した場合、ルーターは独自の[Join / Prune-Holdtime]へのJoin / Pruneメッセージに含まれるホールドタイム。独自の[Join / Prune-Holdtime]が小さい場合、Join / Prune-Suppression-timerは[Join / Prune-Suppression-Timeout]で開始されます。 [Join / Prune-Holdtime]が等しい場合、より高いネットワーク層アドレスを持つJoin / Prune Message発信者が優先されて、タイが解決されます。 Join / Pruneタイマーが期限切れになると、ルータは対応するエントリのJoin / Pruneメッセージをトリガーします。
When a source first starts sending to a group its packets are encapsulated in Register messages and sent to the RP. If the data rate warrants source-specific paths, the RP sets up source specific state and starts sending (S,G) Join/Prune messages toward the source, with S in the join list.
ソースが最初にグループへの送信を開始すると、そのパケットは登録メッセージにカプセル化され、RPに送信されます。データレートが送信元固有のパスを保証する場合、RPは送信元固有の状態を設定し、（S、G）のJoin / Pruneメッセージを送信元に向けて送信します（Sは参加リストにあります）。
Register messages are sent as follows:
登録メッセージは次のように送信されます。
1 When a DR receives a packet from a directly connected source, S, on the subnet containing the address S,
1 DRがアドレスSを含むサブネット上の直接接続されたソースSからパケットを受信すると、
1 If there is no corresponding (S,G) entry, and the router has RP-Set information, and the DR is not the RP for G, the DR creates an (S,G) entry with the Register-Suppression-timer turned off and the RP address set according to the hash function mapping for the corresponding group. The oif list is copied from existing (*,G) or (*,*,RP) entries, if they exist. The iif of the (S,G) entry is always excluded from the oif list. If there exists a (*,G) or (*,*,RP) entry, the DR sends a Join/Prune message towards the RP with S in the prune list and the RPT-bit set.
1対応する（S、G）エントリがなく、ルーターにRP-Set情報があり、DRがGのRPでない場合、DRは（S、G）エントリを作成し、Register-Suppression-timerをオンにしますoff、および対応するグループのハッシュ関数マッピングに従って設定されたRPアドレス。 oifリストは、存在する場合、既存の（*、G）または（*、*、RP）エントリからコピーされます。 （S、G）エントリのiifは常にoifリストから除外されます。 （*、G）または（*、*、RP）エントリが存在する場合、DRは、プルーンリスト内のSとRPTビットセットを使用して、RPに向けてJoin / Pruneメッセージを送信します。
2 If there is a (S,G) entry in existence, the DR simply restarts the corresponding Entry-timer.
2（S、G）エントリが存在する場合、DRは対応するエントリタイマーを再起動するだけです。
When a PMBR (e.g., a router that connects the PIM-SM region to a dense mode region running DVMRP or PIM-DM) receives a packet from a source in the dense mode region, the router treats the packet as if it were from a directly connected source. A separate document will describe the details of interoperability.
PMBR（たとえば、PIM-SMリージョンをDVMRPまたはPIM-DMを実行しているデンスモードリージョンに接続するルーター）がデンスモードリージョンのソースからパケットを受信すると、ルーターはそのパケットを直接接続されたソース。相互運用性の詳細については、別のドキュメントで説明します。
2 If the new or previously-existing (S,G) entry's Register-Suppression-timer is not running, the data packet is encapsulated in a Register message and unicast to the RP for that group. The data packet is also forwarded according to (S,G) state in the DR if the oif list is not null; since a receiver may join the SP-tree while the DR is still registering to the RP.
2新規または既存の（S、G）エントリのRegister-Suppression-timerが実行されていない場合、データパケットはRegisterメッセージにカプセル化され、そのグループのRPにユニキャストされます。 oifリストがnullでない場合、データパケットもDRの（S、G）状態に従って転送されます。 DRがまだRPに登録している間にレシーバがSPツリーに参加する可能性があるためです。
3 If the (S,G) entry's Register-Suppression-timer is running, the data packet is not sent in a Register message, it is just forwarded according to the (S,G) oif list.
3（S、G）エントリのRegister-Suppression-timerが実行中の場合、データパケットはRegisterメッセージで送信されず、（S、G）oifリストに従って転送されるだけです。
When the DR receives a Register-Stop message, it restarts the Register-Suppression-timer in the corresponding (S,G) entry(ies) at [Register-Suppression-Timeout] seconds. If there is data to be registered, the DR may send a null Register (a Register message with a zero-length data portion in the inner packet) to the RP, [Probe-Time] seconds before the Register-Suppression-timer expires, to avoid sending occasional bursts of traffic to an RP unnecessarily.
DRがRegister-Stopメッセージを受信すると、対応する（S、G）エントリのRegister-Suppression-timerを[Register-Suppression-Timeout]秒で再起動します。登録するデータがある場合、DRはヌルレジスタ（内部パケットに長さゼロのデータ部分を含むレジスタメッセージ）をRPに送信する場合があります。[プローブ時間]秒後にRegister-Suppressionタイマーが期限切れになります。トラフィックの不定期なバーストをRPに不必要に送信しないようにします。
When a router (i.e., the RP) receives a Register message, the router does the following:
ルーター（つまり、RP）が登録メッセージを受信すると、ルーターは次のことを行います。
1 Decapsulates the data packet, and checks for a corresponding (S,G) entry.
1データパケットのカプセル化を解除し、対応する（S、G）エントリをチェックします。
1 If a (S,G) entry with cleared (0) SPT bit exists, and the received Register does not have the Null-Register-Bit set to 1, the packet is forwarded; and the SPT bit is left cleared (0). If the SPT bit is 1, the packet is dropped, and Register-Stop messages are triggered. Register-Stops should be rate-limited (in an implementation-specific manner) so that no more than a few are sent per round trip time. This prevents a high datarate stream of packets from triggering a large number of Register-Stop messages between the time that the first packet is received and the time when the source receives the first Register-Stop.
1 SPTビットがクリアされた（S、G）エントリが存在し、受信したレジスタのNull-Register-Bitが1に設定されていない場合、パケットは転送されます。 SPTビットはクリアされたままです（0）。 SPTビットが1の場合、パケットはドロップされ、Register-Stopメッセージがトリガーされます。 Register-Stopsは（実装固有の方法で）レート制限する必要があり、ラウンドトリップ時間ごとに送信される数が少ないようにします。これにより、最初のパケットが受信されてからソースが最初のRegister-Stopを受信するまでの間に、パケットの高いデータレートストリームが多数のRegister-Stopメッセージをトリガーするのを防ぎます。
2 If there is no (S,G) entry, but there is a (*,G) entry, and the received Register does not have the Null-Register-Bit set to 1, the packet is forwarded according to the (*,G) entry.
2（S、G）エントリはないが（*、G）エントリがあり、受信したレジスタでNull-Register-Bitが1に設定されていない場合、パケットは（*、G）に従って転送されます。 G）エントリ。
3 If there is a (*,*,RP) entry but no (*,G) entry, and the Register received does not have the Null-Register-Bit set to 1, a (*,G) or (S,G) entry is created and the oif list is copied from the (*,*,RP) entry to the new entry. The packet is forwarded according to the created entry.
3（*、*、RP）エントリはあるが（*、G）エントリがなく、受信したレジスタのNull-Register-Bitが1に設定されていない場合、（*、G）または（S、G ）エントリが作成され、oifリストが（*、*、RP）エントリから新しいエントリにコピーされます。作成されたエントリに従ってパケットが転送されます。
4 If there is no G or (*,*,RP) entry corresponding to G, the packet is dropped, and a Register-Stop is triggered.
4 GまたはGに対応する（*、*、RP）エントリがない場合、パケットはドロップされ、Register-Stopがトリガーされます。
5 A "Border bit" bit is added to the Register message, to facilitate interoperability mechanisms. PMBRs set this bit when registering for external sources (see Section 2.7). If the "Border bit" is set in the Register, the RP does the following:
5相互運用性メカニズムを容易にするために、「境界ビット」ビットがレジスタメッセージに追加されます。 PMBRは、外部ソースの登録時にこのビットを設定します（セクション2.7を参照）。レジスタで「ボーダービット」が設定されている場合、RPは次のことを行います。
1 If there is no matching (S,G) state, but there exists (*,G) or (*,*,RP) entry, the RP creates a (S,G) entry, with a `PMBR' field. This field holds the source of the Register (i.e. the outer network layer address of the register packet). The RP triggers a (S,G) join towards the source of the data packet, and clears the SPT bit for the (S,G) entry. If the received Register is not a `null Register' the packet is forwarded according to the created state. Else,
1一致する（S、G）状態はないが、（*、G）または（*、*、RP）エントリが存在する場合、RPは「PMBR」フィールドを持つ（S、G）エントリを作成します。このフィールドは、レジスタのソース（つまり、レジスタパケットの外部ネットワーク層アドレス）を保持します。 RPは、データパケットの送信元に向けて（S、G）加入をトリガーし、（S、G）エントリのSPTビットをクリアします。受信したレジスタが「ヌルレジスタ」でない場合、パケットは作成された状態に従って転送されます。そうしないと、
2 If the `PMBR' field for the corresponding (S,G) entry matches the source of the Register packet, and the received Register is not a `null Register', the decapsulated packet is forwarded to the oif list of that entry. Else,
2対応する（S、G）エントリの「PMBR」フィールドがレジスタパケットのソースと一致し、受信したレジスタが「ヌルレジスタ」でない場合、カプセル化解除されたパケットはそのエントリのoifリストに転送されます。そうしないと、
3 If the `PMBR' field for the corresponding (S,G) entry matches the source of the Register packet, the decapsulated packet is forwarded to the oif list of that entry, else
3対応する（S、G）エントリの「PMBR」フィールドがレジスタパケットのソースと一致する場合、カプセル化解除されたパケットはそのエントリのoifリストに転送され、それ以外の場合は
4 The packet is dropped, and a Register-stop is triggered towards the source of the Register.
4パケットがドロップされ、レジスタのソースに向けてレジスタ停止がトリガーされます。
The (S,G) Entry-timer is restarted by Registers arriving from that source to that group.
（S、G）エントリタイマーは、そのソースからそのグループに到着するレジスタによって再起動されます。
2 If the matching (S,G) or (*,G) state contains a null oif list, the RP unicasts a Register-Stop message to the source of the Register message; in the latter case, the source-address field, within the Register-Stop message, is set to the wildcard value (all 0's). This message is not processed by intermediate routers, hence no (S,G) state is constructed between the RP and the source.
2一致する（S、G）または（*、G）状態にヌルのoifリストが含まれている場合、RPはRegister-StopメッセージをRegisterメッセージのソースにユニキャストします。後者の場合、Register-Stopメッセージ内のsource-addressフィールドは、ワイルドカード値（すべて0）に設定されます。このメッセージは中間ルーターでは処理されないため、RPと送信元の間に（S、G）状態は構築されません。
3 If the Register message arrival rate warrants it and there is no existing (S,G) entry, the RP sets up a (S,G) route entry with the outgoing interface list, excluding iif(S,G), copied from the (*,G) outgoing interface list, its SPT-bit is initialized to 0. If a (*,G) entry does not exist, but there exists a (*,*,RP) entry with the RP corresponding to G , the oif list for (S,G) is copied - excluding the iif - from that (*,*,RP) entry.
3 Registerメッセージの到着率がそれを保証し、既存の（S、G）エントリがない場合、RPは、iif（S、G）を除く発信インターフェイスリストを使用して、（S、G）ルートエントリを設定します。 （*、G）発信インターフェイスリスト、そのSPTビットは0に初期化されます。（*、G）エントリは存在しないが、Gに対応するRPを持つ（*、*、RP）エントリが存在する場合、 （S、G）のoifリストが、（*、*、RP）エントリからコピーされます（iifを除く）。
A timer (Entry-timer) is set for the (S,G) entry and this timer is restarted by receipt of data packets for (S,G). The (S,G) entry causes the RP to send a Join/Prune message for the indicated group towards the source of the register message.
タイマー（Entry-timer）が（S、G）エントリーに設定され、このタイマーは（S、G）のデータパケットの受信によって再起動されます。 （S、G）エントリにより、RPは指定されたグループのJoin / Pruneメッセージを登録メッセージの送信元に送信します。
If the (S,G) oif list becomes null, Join/Prune messages will not be sent towards the source, S.
（S、G）oifリストがnullになると、Join / PruneメッセージはソースSに送信されません。
Processing a multicast data packet involves the following steps:
マルチキャストデータパケットの処理には、次の手順が含まれます。
1 Lookup route state based on a longest match of the source address, and an exact match of the destination address in the data packet. If neither S, nor G, find a longest match entry, and the RP for the packet's destination group address has a corresponding (*,*,RP) entry, then the longest match does not require an exact match on the destination group address. In summary, the longest match is performed in the following order: (1) (S,G), (2) (*,G). If neither is matched, then a lookup is performed on (*,*,RP) entries.
1送信元アドレスの最長一致、およびデータパケット内の宛先アドレスの完全一致に基づくルックアップルート状態。 SもGも最長一致エントリを検出せず、パケットの宛先グループアドレスのRPに対応する（*、*、RP）エントリがある場合、最長一致は宛先グループアドレスの完全一致を必要としません。要約すると、最長一致は（1）（S、G）、（2）（*、G）の順序で実行されます。どちらも一致しない場合、（*、*、RP）エントリに対して検索が実行されます。
2 If the packet arrived on the interface found in the matching-entry's iif field, and the oif list is not null:
2パケットがmatching-entryのiifフィールドにあるインターフェースに到着し、oifリストがnullでない場合：
1 Forward the packet to the oif list for that entry, excluding the subnet containing S, and restart the Entry-timer if the matching entry is (S,G). Optionally, the (S,G) Entry-timer may be restarted by periodic checking of the matching packet count.
1 Sを含むサブネットを除いて、そのエントリのoifリストにパケットを転送し、一致するエントリが（S、G）の場合はエントリタイマーを再起動します。必要に応じて、（S、G）エントリタイマーは、一致するパケット数を定期的にチェックすることで再起動できます。
2 If the entry is a (S,G) entry with a cleared SPT-bit, and a (*,G) or associated (*,*,RP) also exists whose incoming interface is different than that for (S,G), set the SPT-bit for the (S,G) entry and trigger an (S,G) RPT-bit prune towards the RP.
2エントリがSPTビットがクリアされた（S、G）エントリであり、（*、G）または関連する（*、*、RP）も存在し、その着信インターフェイスが（S、G）のインターフェイスと異なる場合、（S、G）エントリのSPTビットを設定し、RPに向けて（S、G）RPTビットプルーンをトリガーします。
3 If the source of the packet is a directly-connected host and the router is the DR on the receiving interface, check the Register-Suppression-timer associated with the (S,G) entry. If it is not running, then the router encapsulates the data packet in a register message and sends it to the RP.
3パケットの送信元が直接接続されたホストであり、ルーターが受信インターフェイスのDRである場合、（S、G）エントリに関連付けられたRegister-Suppression-timerを確認します。実行されていない場合、ルータはデータパケットを登録メッセージにカプセル化し、それをRPに送信します。
This covers the common case of a packet arriving on the RPF interface to the source or RP and being forwarded to all joined branches. It also detects when packets arrive on the SP-tree, and triggers their pruning from the RP-tree. If it is the DR for the source, it sends data packets encapsulated in Registers to the RPs.
これは、RPFインターフェイスで送信元またはRPに到着し、結合されたすべてのブランチに転送されるパケットの一般的なケースをカバーしています。また、パケットがSPツリーに到着したことを検出し、RPツリーからのプルーニングをトリガーします。ソースのDRの場合は、レジスタにカプセル化されたデータパケットをRPに送信します。
3 If the packet matches to an entry but did not arrive on the interface found in the entry's iif field, check the SPT-bit of the entry. If the SPT-bit is set, drop the packet. If the SPT-bit is cleared, then lookup the (*,G), or (*,*,RP), entry for G. If the packet arrived on the iif found in (*,G), or the corresponding (*,*,RP), forward the packet to the oif list of the matching entry. This covers the case when a data packet matches on a (S,G) entry for which the SP-tree has not yet been completely established upstream.
3パケットがエントリと一致するが、エントリのiifフィールドで見つかったインターフェイスに到着しなかった場合は、エントリのSPTビットを確認します。 SPTビットが設定されている場合は、パケットをドロップします。 SPTビットがクリアされている場合は、Gの（*、G）または（*、*、RP）エントリを検索します。パケットが（*、G）または対応する（* 、*、RP）、パケットを一致するエントリのoifリストに転送します。これは、SPツリーがまだ完全に上流に確立されていない（S、G）エントリでデータパケットが一致する場合をカバーしています。
4 If the packet does not match any entry, but the source of the data packet is a local, directly-connected host, and the router is the DR on a multi-access LAN and has RP-Set information, the DR uses the hash function to determine the RP associated with the destination group, G. The DR creates a (S,G) entry, with the Register-Suppression-timer not running, encapsulates the data packet in a Register message and unicasts it to the RP.
4パケットがどのエントリとも一致しないが、データパケットのソースがローカルで直接接続されたホストであり、ルーターがマルチアクセスLAN上のDRであり、RP-Set情報を持っている場合、DRはハッシュを使用します宛先グループGに関連付けられたRPを決定する関数。DRは（S、G）エントリを作成し、Register-Suppression-timerが実行されていない状態で、データパケットをRegisterメッセージにカプセル化し、RPにユニキャストします。
5 If the packet does not match to any entry, and it is not a local host or the router is not the DR, drop the packet.
5パケットがどのエントリとも一致せず、ローカルホストでもルーターでもない場合は、パケットをドロップします。
Different criteria can be applied to trigger switching over from the RP-based shared tree to source-specific, shortest path trees.
さまざまな基準を適用して、RPベースの共有ツリーからソース固有の最短パスツリーへの切り替えをトリガーできます。
One proposed example is to do so based on data rate. For example, when a (*,G), or corresponding (*,*,RP), entry is created, a data rate counter may be initiated at the last-hop routers. The counter is incremented with every data packet received for directly connected members of an SM group, if the longest match is (*,G) or (*,*,RP). If and when the data rate for the group exceeds a certain configured threshold (t1), the router initiates `source-specific' data rate counters for the following data packets. Then, each counter for a source, is incremented when packets matching on (*,G), or (*,*,RP), are received from that source. If the data rate from the particular source exceeds a configured threshold (t2), a (S,G) entry is created and a Join/Prune message is sent towards the source. If the RPF interface for (S,G) is not the same as that for (*,G) -or (*,*,RP), then the SPT-bit is cleared in the (S,G) entry.
提案されている例の1つは、データレートに基づいてこれを行うことです。たとえば、（*、G）または対応する（*、*、RP）エントリが作成されると、データレートカウンターがラストホップルーターで開始されます。最長一致が（*、G）または（*、*、RP）の場合、カウンターは、SMグループの直接接続されたメンバーに対して受信されたすべてのデータパケットで増分されます。グループのデータレートが設定された特定のしきい値（t1）を超えると、ルータは次のデータパケットに対して「ソース固有」のデータレートカウンタを開始します。次に、（*、G）または（*、*、RP）に一致するパケットがそのソースから受信されると、ソースの各カウンターが増加します。特定のソースからのデータレートが構成済みのしきい値（t2）を超えると、（S、G）エントリが作成され、Join / Pruneメッセージがソースに送信されます。 （S、G）のRPFインターフェイスが（*、G）または（*、*、RP）のRPFインターフェイスと同じでない場合、SPTビットは（S、G）エントリでクリアされます。
Other configured rules may be enforced to cause or prevent establishment of (S,G) state.
（S、G）状態の確立を引き起こしたり防止したりするために、他の構成されたルールが適用される場合があります。
Asserts are used to resolve which of the parallel routers connected to a multi-access LAN is responsible for forwarding packets onto the LAN.
アサートは、マルチアクセスLANに接続されているどのパラレルルーターがパケットをLANに転送するかを決定するために使用されます。
The following Assert rules are provided when a multicast packet is received on an outgoing multi-access interface "I" of an existing active (S,G), (*,G) or (*,*,RP) entry:
既存のアクティブな（S、G）、（*、G）または（*、*、RP）エントリの発信マルチアクセスインターフェイス "I"でマルチキャストパケットを受信すると、次のアサートルールが提供されます。
1 Do unicast routing table lookup on source address from data packet, and send assert on interface "I" for source address in data packet; include metric preference of routing protocol and metric from routing table lookup.
1データパケットの送信元アドレスでユニキャストルーティングテーブルルックアップを実行し、データパケットの送信元アドレスのインターフェイス "I"でアサートを送信します。ルーティングプロトコルのメトリック設定とルーティングテーブルルックアップからのメトリックが含まれます。
2 If route is not found, use metric preference of 0x7fffffff and metric 0xffffffff.
2ルートが見つからない場合は、メトリックプリファレンス0x7fffffffおよびメトリック0xffffffffを使用します。
When an assert is sent for a (*,G) entry, the first bit in the metric preference (the RPT-bit) is set to 1, indicating the data packet is routed down the RP-tree.
（*、G）エントリに対してアサートが送信されると、メトリックプリファレンスの最初のビット（RPTビット）が1に設定され、データパケットがRPツリーにルーティングされることを示します。
Asserts should be rate-limited in an implementation-specific manner.
アサートは、実装固有の方法でレート制限する必要があります。
When an Assert is received the router performs a longest match on the source and group address in the Assert message, only active entries -- that have packet forwarding state -- are matched. The router checks the first bit of the metric preference (RPT-bit).
アサートが受信されると、ルータはアサートメッセージの送信元アドレスとグループアドレスに対して最長の一致を実行し、アクティブなエントリ（パケット転送状態を持つ）のみが一致します。ルータは、メトリックプリファレンスの最初のビット（RPTビット）をチェックします。
1 If the RPT-bit is set, the router first does a match on (*,G), or (*,*,RP), entries; if no matching entry is found, it ignores the Assert.
1 RPTビットが設定されている場合、ルーターは最初に（*、G）または（*、*、RP）エントリを照合します。一致するエントリが見つからない場合、アサートは無視されます。
2 If the RPT-bit is not set in the Assert, the router first does a match on (S,G) entries; if no matching entry is found, the router matches (*,G) or (*,*,RP) entries.
2 RPTビットがアサートに設定されていない場合、ルータは最初に（S、G）エントリを照合します。一致するエントリが見つからない場合、ルーターは（*、G）または（*、*、RP）エントリに一致します。
Receiving Asserts on an entry's outgoing interface:
エントリの発信インターフェースでのアサートの受信：
If the interface that received the Assert message is in the oif list of the matched entry, then this Assert is processed by this router as follows:
アサートメッセージを受信したインターフェイスが一致したエントリのoifリストにある場合、このアサートはこのルータによって次のように処理されます。
1 If the Assert's RPT-bit is set and the matching entry is (*,*,RP), the router creates a (*,G) entry. If the Assert's RPT-bit is cleared and the matching entry is (*,G), or (*,*,RP), the router creates a (S,G)RPT-bit entry. Otherwise, no new entry is created in response to the Assert.
1アサートのRPTビットが設定されていて、一致するエントリが（*、*、RP）の場合、ルーターは（*、G）エントリを作成します。アサートのRPTビットがクリアされ、一致するエントリが（*、G）または（*、*、RP）の場合、ルーターは（S、G）RPTビットエントリを作成します。それ以外の場合、アサートに応答して新しいエントリは作成されません。
2 The router then compares the metric values received in the Assert with the metric values associated with the matched entry. The RPT-bit and metric preference (in that order) are treated as the high-order part of an Assert metric comparison. If the value in the Assert is less than the router's value (with ties broken by the IP address, where higher network layer address wins), delete the interface from the entry. When the deletion occurs for a (*,G) or (*,*,RP) entry , the interface is also deleted from any associated (S,G)RPT-bit or (*,G) entries, respectively. The Entry-timer for the affected entries is restarted.
2次に、ルータはアサートで受信したメトリック値を、一致したエントリに関連付けられたメトリック値と比較します。 RPTビットとメトリック設定（この順序で）は、Assertメトリック比較の上位部分として扱われます。アサートの値がルーターの値よりも小さい場合（タイがIPアドレスによって破壊され、上位のネットワーク層アドレスが優先される場合）、エントリからインターフェイスを削除します。 （*、G）または（*、*、RP）エントリの削除が発生すると、関連する（S、G）RPTビットまたは（*、G）エントリからもそれぞれインターフェイスが削除されます。影響を受けるエントリのエントリタイマーが再起動されます。
3 If the router has won the election the router keeps the interface in its outgoing interface list. It acts as the forwarder for the LAN.
3ルーターが選挙に勝った場合、ルーターはそのインターフェースを発信インターフェースリストに保持します。 LANのフォワーダーとして機能します。
The winning router sends an Assert message containing its own metric to that outgoing interface. This will cause other routers on the LAN to prune that interface from their route entries. The winning router sets the RPT-bit in the Assert message if a (*,G) or (S,G)RPT-bit entry was matched.
優勝したルーターは、独自のメトリックを含むAssertメッセージをその発信インターフェイスに送信します。これにより、LAN上の他のルーターは、そのインターフェイスをルートエントリからプルーニングします。勝利したルーターは、（*、G）または（S、G）RPTビットエントリが一致した場合、アサートメッセージにRPTビットを設定します。
Receiving Asserts on an entry's incoming interface
エントリの着信インターフェースでのアサートの受信
If the Assert arrived on the incoming interface of an existing (S,G), (*,G), or (*,*,RP) entry, the Assert is processed as follows. If the Assert message does not match the entry, exactly, it is ignored; i.e, longest-match is not used in this case. If the Assert message does match exactly, then:
アサートが既存の（S、G）、（*、G）、または（*、*、RP）エントリの着信インターフェイスに到着した場合、アサートは次のように処理されます。 Assertメッセージがエントリと正確に一致しない場合、それは無視されます。つまり、この場合、最長一致は使用されません。 Assertメッセージが完全に一致する場合は、次のようになります。
1 Downstream routers will select the upstream router with the smallest metric preference and metric as their RPF neighbor. If two metrics are the same, the highest network layer address is chosen to break the tie. This is important so that downstream routers send subsequent Joins/Prunes (in SM) to the correct neighbor. An Assert-timer is initiated when changing the RPF neighbor to the Assert winner. When the timer expires, the router resets its RPF neighbor according to its unicast routing tables to capture network dynamics and router failures.
1ダウンストリームルータは、メトリックプリファレンスとメトリックが最小のアップストリームルータをRPFネイバーとして選択します。 2つのメトリックが同じである場合、最上位のネットワークレイヤーアドレスが選択され、同点が解消されます。これは、ダウンストリームルータが後続のJoin / Prunes（SM内）を正しいネイバーに送信するために重要です。 RPFネイバーをアサート勝者に変更すると、アサートタイマーが開始されます。タイマーの期限が切れると、ルーターはユニキャストルーティングテーブルに従ってRPFネイバーをリセットし、ネットワークダイナミクスとルーターの障害をキャプチャします。
2 If the downstream routers have downstream members, and if the Assert caused the RPF neighbor to change, the downstream routers must trigger a Join/Prune message to inform the upstream router that packets are to be forwarded on the multi-access network.
2ダウンストリームルーターにダウンストリームメンバーがあり、アサートによってRPFネイバーが変更された場合、ダウンストリームルーターはJoin / Pruneメッセージをトリガーして、マルチアクセスネットワークでパケットが転送されることをアップストリームルーターに通知する必要があります。
Candidate-RP-Advertisements (C-RP-Advs) are periodic PIM messages unicast to the BSR by those routers that are configured as Candidate-RPs (C-RPs).
Candidate-RP-Advertisements（C-RP-Advs）は、Candidate-RP（C-RP）として構成されているルーターによってBSRにユニキャストされる定期的なPIMメッセージです。
Bootstrap messages are periodic PIM messages originated by the Bootstrap router (BSR) within a domain, and forwarded hop-by-hop to distribute the current RP-set to all routers in that domain.
ブートストラップメッセージは、ドメイン内のブートストラップルーター（BSR）によって発信され、ホップバイホップで転送されて現在のRPセットをそのドメイン内のすべてのルーターに配信する定期的なPIMメッセージです。
The Bootstrap messages also support a simple mechanism by which the Candidate BSR (C-BSR) with the highest BSR-priority and address (referred to as the preferred BSR) is elected as the BSR for the domain. We recommend that each router configured as a C-RP also be configured as a C-BSR. Sections 3.6.2 and 3.6.3 describe the combined function of Bootstrap messages as the vehicle for BSR election and RP-Set distribution.
ブートストラップメッセージは、最高のBSR優先度とアドレス（優先BSRと呼ばれる）を持つ候補BSR（C-BSR）がドメインのBSRとして選出されるという単純なメカニズムもサポートします。 C-RPとして構成された各ルーターをC-BSRとしても構成することをお勧めします。セクション3.6.2および3.6.3は、BSR選出およびRP-Set配布の手段としてのBootstrapメッセージの複合機能について説明しています。
A Finite State Machine description of the BSR election and RP-Set distribution mechanisms is included in Appendix II.
BSR選出およびRP-Set配布メカニズムの有限状態マシンの説明は、付録IIに含まれています。
C-RPs periodically unicast C-RP-Advs to the BSR for that domain. The interval for sending these messages is subject to local configuration at the C-RP.
C-RPは定期的にそのドメインのBSRにC-RP-Advsをユニキャストします。これらのメッセージを送信する間隔は、C-RPでのローカル構成の影響を受けます。
Candidate-RP-Advertisements carry group address and group mask fields. This enables the advertising router to limit the advertisement to certain prefixes or scopes of groups. The advertising router may enforce this scope acceptance when receiving Registers or Join/Prune messages. C-RPs should send C-RP-Adv messages with the `Priority' field set to `0'.
Candidate-RP-Advertisementsには、グループアドレスとグループマスクのフィールドがあります。これにより、アドバタイジングルータは、アドバタイズを特定のプレフィックスまたはグループのスコープに制限できます。アドバタイズルータは、RegistersまたはJoin / Pruneメッセージを受信したときに、このスコープの受け入れを強制する場合があります。 C-RPは、「Priority」フィールドが「0」に設定されたC-RP-Advメッセージを送信する必要があります。
Upon receiving a C-RP-Adv, a router does the following:
C-RP-Advを受信すると、ルーターは次のことを行います。
1 If the router is not the elected BSR, it ignores the message, else
1ルータが選出されたBSRではない場合、メッセージは無視されます。
2 The BSR adds the RP address to its local pool of candidate RPs, according to the associated group prefix(es) in the C-RP-Adv message. The Holdtime in the C-RP-Adv message is also stored with the corresponding RP, to be included later in the Bootstrap message. The BSR may apply a local policy to limit the number of Candidate RPs included in the Bootstrap message. The BSR may override the prefix indicated in a C-RP-Adv unless the `Priority' field is not zero.
2 BSRは、C-RP-Advメッセージ内の関連するグループプレフィックスに従って、候補RPのローカルプールにRPアドレスを追加します。 C-RP-AdvメッセージのHoldtimeも対応するRPとともに保存され、後でBootstrapメッセージに含まれます。 BSRはローカルポリシーを適用して、ブートストラップメッセージに含まれる候補RPの数を制限する場合があります。 BSRは、「優先度」フィールドがゼロでない限り、C-RP-Advに示されているプレフィックスをオーバーライドする場合があります。
The BSR keeps an RP-timer per RP in its local RP-set. The RP-timer is initialized to the Holdtime in the RP's C-RP-Adv. When the timer expires, the corresponding RP is removed from the RP-set. The RP-timer is restarted by the C-RP-Advs from the corresponding RP.
BSRは、RPごとのRPタイマーをローカルRPセットに保持します。 RPタイマーは、RPのC-RP-Advのホールドタイムに初期化されます。タイマーが期限切れになると、対応するRPがRPセットから削除されます。 RPタイマーは、対応するRPからのC-RP-Advsによって再起動されます。
The BSR also uses its Bootstrap-timer to periodically send Bootstrap messages. In particular, when the Bootstrap-timer expires, the BSR originates a Bootstrap message on each of its PIM interfaces. To reduce the bootstrap message overhead during partition healing, the BSR should set a random time (as a function of the priority and address) after which the Bootstrap message is originated only if no other preferred Bootstrap message is received. For details see appendix 6.2. The message is sent with a TTL of 1 to the `ALL-PIM-ROUTERS' group. In steady state, the BSR originates Bootstrap messages periodically. At startup, the Bootstrap-timer is initialized to [Bootstrap-Timeout], causing the first Bootstrap message to be originated only when and if the timer expires. For timer details, see Section 3.6.3. A DR unicasts a Bootstrap message to each new PIM neighbor, i.e., after the DR receives the neighbor's Hello message (it does so even if the new neighbor becomes the DR).
BSRはまた、Bootstrapタイマーを使用して、Bootstrapメッセージを定期的に送信します。特に、Bootstrap-timerが期限切れになると、BSRは各PIMインターフェイスでBootstrapメッセージを発信します。パーティションの修復中のブートストラップメッセージのオーバーヘッドを減らすには、BSRがランダムな時間を（優先度とアドレスの関数として）設定してから、他の優先するBootstrapメッセージが受信されない場合にのみ、Bootstrapメッセージが発信されるようにします。詳細については、付録6.2を参照してください。メッセージは、TTLが1の `ALL-PIM-ROUTERS 'グループに送信されます。定常状態では、BSRは定期的にBootstrapメッセージを発信します。起動時に、Bootstrap-timerは[Bootstrap-Timeout]に初期化され、最初のBootstrapメッセージはタイマーが期限切れになった場合にのみ発生するようになります。タイマーの詳細については、セクション3.6.3を参照してください。 DRは、Bootstrapメッセージを新しいPIMネイバーごとにユニキャストします。つまり、DRがネイバーのHelloメッセージを受信した後です（新しいネイバーがDRになった場合でもそうです）。
The Bootstrap message is subdivided into sets of group-prefix,RP-Count,RP-addresses. For each RP-address, the corresponding Holdtime is included in the "RP-Holdtime" field. The format of the Bootstrap message allows `semantic fragmentation', if the length of the original Bootstrap message exceeds the packet maximum boundaries (see Section 4). However, we recommend against configuring a large number of routers as C-RPs, to reduce the semantic fragmentation required.
ブートストラップメッセージは、グループプレフィックス、RPカウント、RPアドレスのセットに細分されます。 RPアドレスごとに、対応するHoldtimeが[RP-Holdtime]フィールドに含まれています。ブートストラップメッセージの形式では、元のブートストラップメッセージの長さがパケットの最大境界を超える場合に、「セマンティックフラグメンテーション」が可能です（セクション4を参照）。ただし、必要なセマンティックフラグメンテーションを減らすために、C-RPとして多数のルーターを構成しないことをお勧めします。
Each router keeps a Bootstrap-timer, initialized to [Bootstrap-Timeout] at startup.
各ルーターは、起動時に[Bootstrap-Timeout]に初期化されたブートストラップタイマーを保持します。
When a router receives Bootstrap message sent to `ALL-PIM-ROUTERS' group, it performs the following:
ルータは「ALL-PIM-ROUTERS」グループに送信されたブートストラップメッセージを受信すると、次のことを実行します。
1 If the message was not sent by the RPF neighbor towards the BSR address included, the message is dropped. Else
1含まれているBSRアドレスに向けてRPFネイバーからメッセージが送信されなかった場合、メッセージはドロップされます。そうしないと
2 If the included BSR is not preferred over, and not equal to, the currently active BSR:
2含まれているBSRが現在アクティブなBSRよりも優先されず、等しくない場合：
1 If the Bootstrap-timer has not yet expired, or if the receiving router is a C-BSR, then the Bootstrap message is dropped. Else
1ブートストラップタイマーがまだ期限切れになっていない場合、または受信ルータがC-BSRである場合、ブートストラップメッセージはドロップされます。そうしないと
2 If the Bootstrap-timer has expired and the receiving router is not a C-BSR, the receiving router stores the RP-Set and BSR address and priority found in the message, and restarts the timer by setting it to [Bootstrap-Timeout]. The Bootstrap message is then forwarded out all PIM interfaces, excluding the one over which the message arrived, to `ALL-PIM-ROUTERS' group, with a TTL of 1.
2ブートストラップタイマーの期限が切れ、受信側ルーターがC-BSRでない場合、受信側ルーターはメッセージにあるRP-SetとBSRアドレスおよび優先度を保存し、[Bootstrap-Timeout]に設定してタイマーを再起動します。ブートストラップメッセージは、メッセージが到着したものを除くすべてのPIMインターフェイスから、TTLが1の `ALL-PIM-ROUTERS 'グループに転送されます。
3 If the Bootstrap message includes a BSR address that is preferred over, or equal to, the currently active BSR, the router restarts its Bootstrap-timer at [Bootstrap-Timeout] seconds. and stores the BSR address and RP-Set information.
3 Bootstrapメッセージに、現在アクティブなBSR以上のBSRアドレスが含まれている場合、ルーターは[Bootstrap-Timeout]秒でBootstrap-timerを再起動します。 BSRアドレスとRP-Set情報を保存します。
The Bootstrap message is then forwarded out all PIM interfaces, excluding the one over which the message arrived, to `ALL-PIM-ROUTERS' group, with a TTL of 1.
ブートストラップメッセージは、メッセージが到着したものを除くすべてのPIMインターフェイスから、TTLが1の `ALL-PIM-ROUTERS 'グループに転送されます。
4 If the receiving router has no current RP set information and the Bootstrap was unicast to it from a directly connected neighbor, the router stores the information as its new RP-set. This covers the startup condition when a newly booted router obtains the RP-Set and BSR address from its DR.
4受信ルーターに現在のRPセット情報がなく、ブートストラップが直接接続されたネイバーからユニキャストされた場合、ルーターはその情報を新しいRPセットとして保存します。これは、新しく起動したルーターがDRからRP-SetおよびBSRアドレスを取得するときの起動条件をカバーします。
When a router receives a new RP-Set, it checks if each of the RPs referred to by existing state (i.e., by (*,G), (*,*,RP), or (S,G)RPT-bit entries) is in the new RP-Set. If an RP is not in the new RP-set, that RP is considered unreachable and the hash algorithm (see below) is re-performed for each group with locally active state that previously hashed to that RP. This will cause those groups to be distributed among the remaining RPs. When the new RP-Set contains a new RP, the value of the new RP is calculated for each group covered by that C-RP's Group-prefix. Any group for which the new RP's value is greater than the previously active RP's value is switched over to the new RP.
ルータは新しいRP-Setを受信すると、既存の状態（つまり（*、G）、（*、*、RP）、または（S、G）RPTビットエントリ）によって参照されている各RPがあるかどうかをチェックします）は新しいRP-Setにあります。 RPが新しいRPセットにない場合、そのRPは到達不能と見なされ、以前にそのRPにハッシュされたローカルでアクティブな状態の各グループに対してハッシュアルゴリズム（下記参照）が再実行されます。これにより、これらのグループが残りのRPに分散されます。新しいRP-Setに新しいRPが含まれている場合、新しいRPの値は、そのC-RPのグループプレフィックスでカバーされるグループごとに計算されます。新しいRPの値が以前のアクティブなRPの値より大きいグループは、新しいRPに切り替えられます。
The hash function is used by all routers within a domain, to map a group to one of the C-RPs from the RP-Set. For a particular group, G, the hash function uses only those C-RPs whose Group-prefix covers G. The algorithm takes as input the group address, and the addresses of the Candidate RPs, and gives as output one RP address to be used.
ハッシュ関数は、ドメイン内のすべてのルーターによって使用され、RP-SetのC-RPの1つにグループをマップします。特定のグループGでは、ハッシュ関数は、グループプレフィックスがGに対応するC-RPのみを使用します。アルゴリズムは、グループアドレスと候補RPのアドレスを入力として受け取り、使用する1つのRPアドレスを出力として提供します。
The protocol requires that all routers hash to the same RP within a domain (except for transients). The following hash function must be used in each router:
このプロトコルでは、すべてのルーターがドメイン内の同じRPにハッシュする必要があります（一時的なものを除く）。各ルーターで次のハッシュ関数を使用する必要があります。
1 For RP addresses in the RP-Set, whose Group-prefix covers G, select the RPs with the highest priority (i.e. lowest `Priority' value), and compute a value:
1 RPセット内のRPアドレスで、グループプレフィックスがGに対応している場合は、優先度が最も高い（つまり、「優先度」の値が最も低い）RPを選択し、値を計算します。
Value(G,M,C(i))=
(1103515245 * ((1103515245 * (G&M)+12345) XOR C(i)) + 12345) mod 2^31
where C_i is the RP address and M is a hash-mask included in Bootstrap messages. The hash-mask allows a small number of consecutive groups (e.g., 4) to always hash to the same RP. For instance, hierarchically-encoded data can be sent on consecutive group addresses to get the same delay and fate-sharing characteristics.
ここで、C_iはRPアドレス、Mはブートストラップメッセージに含まれるハッシュマスクです。ハッシュマスクを使用すると、少数の連続したグループ（4など）が常に同じRPにハッシュできます。たとえば、階層的にエンコードされたデータを連続したグループアドレスに送信して、同じ遅延と運命共有の特性を得ることができます。
For address families other than IPv4, a 32-bit digest to be used as C_i must first be derived from the actual RP address. Such a digest method must be used consistently throughout the PIM domain. For IPv6 addresses, we recommend using the equivalent IPv4 address for an IPv4-compatible address, and the CRC-32 checksum [7] of all other IPv6 addresses.
IPv4以外のアドレスファミリの場合、C_iとして使用される32ビットのダイジェストは、最初に実際のRPアドレスから派生する必要があります。このようなダイジェスト方式は、PIMドメイン全体で一貫して使用する必要があります。 IPv6アドレスの場合、IPv4互換アドレスには同等のIPv4アドレスを使用し、他のすべてのIPv6アドレスのCRC-32チェックサム[7]を使用することをお勧めします。
2 From the RPs with the highest priority (i.e. lowest `Priority' value), the candidate with the highest resulting value is then chosen as the RP for that group, and its identity and hash value are stored with the entry created.
2最も高い優先度（つまり、「優先度」の値が最も低い）のRPから、結果の値が最も高い候補がそのグループのRPとして選択され、そのIDとハッシュ値が作成されたエントリと共に保存されます。
Ties between RPs having the same hash value and priority, are broken in advantage of the highest address.
同じハッシュ値と優先度を持つRP間のタイは、最高のアドレスを利用して分割されます。
The hash function algorithm is invoked by a DR, upon reception of a packet, or IGMP membership indication, for a group, for which the DR has no entry. It is invoked by any router that has (*,*,RP) state when a packet is received for which there is no corresponding (S,G) or (*,G) entry. Furthermore, the hash function is invoked by all routers upon receiving a (*,G) or (*,*,RP) Join/Prune message.
ハッシュ関数アルゴリズムは、DRがエントリを持たないグループに対して、パケットまたはIGMPメンバーシップ表示を受信すると、DRによって呼び出されます。対応する（S、G）または（*、G）エントリのないパケットを受信すると、（*、*、RP）状態のルーターによって呼び出されます。さらに、ハッシュ関数は、（*、G）または（*、*、RP）Join / Pruneメッセージを受信すると、すべてのルーターによって呼び出されます。
In this subsection, we enumerate all timers that have been discussed or implied. Since some critical timer events are not associated with the receipt or sending of messages, they are not fully covered by earlier subsections.
このサブセクションでは、説明または暗示されているすべてのタイマーを列挙します。一部の重要なタイマーイベントは、メッセージの受信または送信に関連付けられていないため、前のサブセクションでは完全にカバーされていません。
Timers are implemented in an implementation-specific manner. For example, a timer may count up or down, or may simply expire at a specific time. Setting a timer to a value T means that it will expire after T seconds.
タイマーは実装固有の方法で実装されます。たとえば、タイマーはカウントアップまたはカウントダウンするか、特定の時間に単に期限切れになる場合があります。タイマーを値Tに設定すると、タイマーはT秒後に期限切れになります。
Each (S,G), (*,G), and (*,*,RP) route entry has multiple timers associated with it: one for each interface in the outgoing interface list, one for the multicast routing entry itself, and one optional Join/Prune-Suppression-Timer. Each (S,G) and (*,G) entry also has an Assert-timer and a Random-Delay-Join-Timer for use with Asserts. In addition, DR's have a Register-Suppression-timer for each (S,G) entry and every router has a single Join/Prune-timer. (A router may optionally keep separate Join/Prune-timers for different interfaces or route entries if different Join/Prune periods are desired.)
（S、G）、（*、G）、および（*、*、RP）の各ルートエントリには複数のタイマーが関連付けられています。1つは発信インターフェイスリストの各インターフェイス用、もう1つはマルチキャストルーティングエントリ自体用、および1つです。オプションのJoin / Prune-Suppression-Timer。 （S、G）および（*、G）の各エントリには、Assertsで使用するAssert-timerとRandom-Delay-Join-Timerもあります。さらに、DRには（S、G）エントリごとにRegister-Suppression-timerがあり、すべてのルーターには単一のJoin / Pruneタイマーがあります。 （ルーターは、異なるJoin / Prune期間が必要な場合、オプションで、異なるインターフェースまたはルートエントリに対して別々のJoin / Pruneタイマーを保持できます。）
* [Join/Prune-Timer] This timer is used for periodically sending aggregate Join/Prune messages. To avoid synchronization among routers booting simultaneously, it is initially set to a random value between 1 and [Join/Prune-Period]. When it expires, the timer is immediately restarted to [Join/Prune-Period]. A Join/Prune message is then sent out each interface. This timer should not be restarted by other events.
* [Join / Prune-Timer]このタイマーは、定期的に集約Join / Pruneメッセージを送信するために使用されます。同時に起動するルータ間の同期を回避するために、最初は1から[Join / Prune-Period]の間のランダムな値に設定されています。有効期限が切れると、タイマーはすぐに[Join / Prune-Period]まで再開されます。次に、Join / Pruneメッセージが各インターフェイスに送信されます。このタイマーは他のイベントによって再開されるべきではありません。
* [Join/Prune-Suppression-Timer (kept per route entry)] A route entry's (optional) Join/Prune-Suppression-Timer may be used to suppress duplicate joins from multiple downstream routers on the same LAN. When a Join message is received from a neighbor on the entry's incoming interface in which the included Holdtime is higher than the router's own [Join/Prune-Holdtime] (with ties broken by higher network layer address), the timer is set to [Join/Prune-Suppression-Timeout], with some random jitter introduced to avoid synchronization of triggered Join/Prune messages on expiration. (The random timeout value must be < 1.5 * [Join/Prune-Period] to prevent losing data after 2 dropped Join/Prunes.) The timer is restarted every time a subsequent Join/Prune message (with higher Holdtime/IP address) for the entry is received on its incoming interface. While the timer is running, Join/Prune messages for the entry are not sent. This timer is idle (not running) for point-to-point links.
* [Join / Prune-Suppression-Timer（ルートエントリごとに保持）]ルートエントリの（オプション）Join / Prune-Suppression-Timerを使用して、同じLAN上の複数のダウンストリームルーターからの重複結合を抑制できます。含まれているHoldtimeがルーター自身の[Join / Prune-Holdtime]よりも大きいエントリ（結合は上位のネットワークレイヤーアドレスによって壊れている）のエントリの着信インターフェイスのネイバーからJoinメッセージを受信すると、タイマーは[Join]に設定されます。 / Prune-Suppression-Timeout]、ランダムなジッターが導入され、期限切れ時にトリガーされたJoin / Pruneメッセージの同期を回避します。 （ランダムタイムアウト値は、<1.5 * [Join / Prune-Period]である必要があります。これは、2つのJoin / Prunesがドロップされた後のデータの損失を防ぐためです。）の後続のJoin / Pruneメッセージ（Holdtime / IPアドレスが大きい）のたびにタイマーが再起動されます。エントリは着信インターフェイスで受信されます。タイマーの実行中は、エントリのJoin / Pruneメッセージは送信されません。このタイマーは、ポイントツーポイントリンクではアイドル（実行されていない）です。
* [Oif-Timer (kept per oif for each route entry)] A timer for each oif of a route entry is used to time out that oif. Because some of the outgoing interfaces in an (S,G) entry are copied from the (*,G) outgoing interface list, they may not have explicit (S,G) join messages from some of the downstream routers (i.e., where members are joining to the (*,G) tree only). Thus, when an Oif-timer is restarted in a (*,G) entry, the Oif-timer is restarted for that interface in each existing (S,G) entry whose oif list contains that interface. The same rule applies to (*,G) and (S,G) entries when restarting an Oif-timer on a (*,*,RP) entry.
* [Oif-Timer（各ルートエントリのoifごとに保持）]ルートエントリの各oifのタイマーは、そのoifをタイムアウトするために使用されます。 （S、G）エントリの一部の発信インターフェイスは（*、G）発信インターフェイスリストからコピーされるため、一部のダウンストリームルーターからの明示的な（S、G）参加メッセージがない場合があります（つまり、メンバー（*、G）ツリーのみに参加しています）。したがって、（*、G）エントリでOif-timerが再起動されると、oifリストにそのインターフェイスが含まれている既存の（S、G）エントリごとに、そのインターフェイスのOif-timerが再起動されます。 （*、*、RP）エントリでOif-timerを再起動する場合、同じルールが（*、G）および（S、G）エントリに適用されます。
The following table shows its usage when first adding the oif to the entry's oiflist, when it should be restarted (unless it is already higher), and when it should be decreased (unless it is already lower).
次の表は、oifをエントリのoiflistに最初に追加するとき、再起動する必要がある場合（既に高い場合を除く）、および減らす場合（既に低い場合を除く）を示しています。
Set to | When | Applies to
included Holdtime | adding oif off Join/Prune | (S,G) (*,G)
| | (*,*,RP)
Increased (only) to | When | Applies to
included Holdtime | received Join/Prune | (S,G) (*,G)
| | (*,*,RP)
(*,*,RP) oif-timer value | (*,*,RP) oif-timer restarted | (S,G) (*,G)
(*,G) oif-timer value | (*,G) oif-timer restarted | (S,G)
When the timer expires, the oif is removed from the oiflist if there are no directly-connected members. When deleted, the oif is also removed in any associated (S,G) or (*,G) entries.
タイマーが期限切れになると、直接接続されたメンバーがない場合、oifはoiflistから削除されます。削除すると、関連する（S、G）または（*、G）エントリのoifも削除されます。
* [Entry-Timer (kept per route entry)] A timer for each route entry is used to time out that entry. The following table summarizes its usage when first adding the oif to the entry's oiflist, and when it should be restarted (unless it is already higher).
* [Entry-Timer（ルートエントリごとに保持）]各ルートエントリのタイマーは、そのエントリのタイムアウトに使用されます。次の表は、最初にoifをエントリのoiflistに追加するとき、およびそれを再起動する必要があるとき（それがすでに高い場合を除く）の使用法をまとめたものです。
Set to | When | Applies to [Data-Timeout] | created off data packet | (S,G) included Holdtime | created off Join/Prune | (S,G) (*,G) (*,*,RP)
|に設定いつ| [Data-Timeout]に適用されます。データパケットから作成| （S、G）含まれるホールドタイム| Join / Pruneから作成されました| （S、G）（*、G）（*、*、RP）
Increased (only) to | When | Applies to
[Data-Timeout] | receiving data packets | (S,G)no RPT-bit
oif-timer value | any oif-timer restarted | (S,G)RPT-bit (*,G)
| | (*,*,RP)
[Assert-Timeout] | assert received | (S,G)RPT-bit (*,G)
| | w/null oif
When the timer expires, the route entry is deleted; if the entry is a (*,G) or (*,*,RP) entry, all associated (S,G)RPT-bit entries are also deleted.
タイマーが切れると、ルートエントリが削除されます。エントリが（*、G）または（*、*、RP）エントリの場合、関連するすべての（S、G）RPTビットエントリも削除されます。
* [Register-Suppression-Timer (kept per (S,G) route entry)] An (S,G) route entry's Register-Suppression-Timer is used to suppress registers when the RP is receiving data packets natively. When a Register-Stop message for the entry is received from the RP, the timer is set to a random value in the range 0.5 * [Register-Suppression-Timeout] to 1.5 * [Register-Suppression-Timeout]. While the timer is running, Registers for that entry will be suppressed. If null registers are used, a null register is sent [Probe-Time] seconds before the timer expires.
* [Register-Suppression-Timer（kept per（S、G）route entry）]（S、G）ルートエントリのRegister-Suppression-Timerは、RPがデータパケットをネイティブに受信しているときにレジスタを抑制するために使用されます。エントリのRegister-StopメッセージがRPから受信されると、タイマーは0.5 * [Register-Suppression-Timeout]から1.5 * [Register-Suppression-Timeout]の範囲のランダムな値に設定されます。タイマーの実行中、そのエントリのレジスタは抑制されます。 nullレジスタが使用される場合、nullレジスタはタイマーが期限切れになる[Probe-Time]秒前に送信されます。
* [Assert-Timer (per (S,G) or (*,G) route entry)] The Assert-Timer for an (S,G) or (*,G) route entry is used for timing out Asserts received. When an Assert is received and the RPF neighbor is changed to the Assert winner, the Assert-Timer is set to [Assert-Timeout], and is restarted to this value every time a subsequent Assert for the entry is received on its incoming interface. When the timer expires, the router resets its RPF neighbor according to its unicast routing table.
* [アサートタイマー（（S、G）または（*、G）ルートエントリごと）]（S、G）または（*、G）ルートエントリのアサートタイマーは、受信したアサートのタイムアウトに使用されます。 Assertが受信され、RPFネイバーがAssert勝者に変更されると、Assert-Timerは[Assert-Timeout]に設定され、エントリの後続のAssertが着信インターフェイスで受信されるたびにこの値に再起動されます。タイマーが期限切れになると、ルータはユニキャストルーティングテーブルに従ってRPFネイバーをリセットします。
* [Random-Delay-Join-Timer (per (S,G) or (*,G) route entry)] The Random-Delay-Join-Timer for an (S,G) or (*,G) route entry is used to prevent synchronization among downstream routers on a LAN when their RPF neighbor changes. When the RPF neighbor changes, this timer is set to a random value between 0 and [Random-Delay-Join-Timeout] seconds. When the timer expires, a triggered Join/Prune message is sent for the entry unless its Join/Prune-Suppression-Timer is running.
* [Random-Delay-Join-Timer（per（S、G）or（*、G）route entry）]（S、G）または（*、G）ルートエントリのRandom-Delay-Join-Timerが使用されますRPFネイバーが変更されたときに、LAN上のダウンストリームルータ間の同期を防止します。 RPFネイバーが変更されると、このタイマーは0〜[Random-Delay-Join-Timeout]秒のランダムな値に設定されます。タイマーが期限切れになると、Join / Prune-Suppression-Timerが実行されていない限り、トリガーされたJoin / Pruneメッセージがエントリに送信されます。
* [Hello-Timer] This timer is used to periodically send Hello messages. To avoid synchronization among routers booting simultaneously, it is initially set to a random value between 1 and [Hello-Period]. When it expires, the timer is immediately restarted to [Hello-Period]. A Hello message is then sent out each interface. This timer should not be restarted by other events.
* [Hello-Timer]このタイマーは、定期的にHelloメッセージを送信するために使用されます。同時に起動するルータ間の同期を回避するために、最初は1〜[Hello-Period]のランダムな値に設定されています。期限が切れると、タイマーはすぐに[Hello-Period]に再起動されます。その後、Helloメッセージが各インターフェイスに送信されます。このタイマーは他のイベントによって再開されるべきではありません。
* [Neighbor-Timer (kept per neighbor)] A Neighbor-Timer for each neighbor is used to time out the neighbor state. When a Hello message is received from a new neighbor, the timer is initially set to the Holdtime included in the Hello message (which is equal to the neighbor's value of [Hello-Holdtime]). Every time a subsequent Hello is received from that neighbor, the timer is restarted to the Holdtime in the Hello. When the timer expires, the neighbor state is removed.
* [ネイバータイマー（ネイバーごとに保持）]各ネイバーのネイバータイマーは、ネイバー状態をタイムアウトするために使用されます。 Helloメッセージが新しいネイバーから受信されると、タイマーは、Helloメッセージに含まれるHoldtime（ネイバーの[Hello-Holdtime]の値に等しい）に最初に設定されます。そのネイバーから後続のHelloを受信するたびに、Helloのホールドタイムまでタイマーが再起動されます。タイマーが期限切れになると、ネイバーステートが削除されます。
* [C-RP-Adv-Timer (C-RP's only)] Routers configured as candidate RP's use this timer to periodically send C-RP-Adv messages. To avoid synchronization among routers booting simultaneously, the timer is initially set to a random value between 1 and [C-RP-Adv-Period]. When it expires, the timer is immediately restarted to [C-RP-Adv-Period]. A C-RP-Adv message is then sent to the elected BSR. This timer should not be restarted by other events.
* [C-RP-Adv-Timer（C-RPのみ）]候補RPとして構成されたルーターは、このタイマーを使用してC-RP-Advメッセージを定期的に送信します。同時に起動するルータ間の同期を回避するために、タイマーは最初、1〜[C-RP-Adv-Period]の間のランダムな値に設定されます。期限が切れると、タイマーはすぐに[C-RP-Adv-Period]に再起動されます。次に、C-RP-Advメッセージが、選択されたBSRに送信されます。このタイマーは他のイベントによって再開されるべきではありません。
* [RP-Timer (BSR only, kept per RP in RP-Set)] The BSR uses a timer per RP in the RP-Set to monitor liveness. When a C-RP is added to the RP-Set, its timer is set to the Holdtime included in the C-RP-Adv message from that C-RP (which is equal to the C-RP's value of [RP-Holdtime]). Every time a subsequent C-RP-Adv is received from that RP, its timer is restarted to the Holdtime in the C-RP-Adv. When the timer expires, the RP is removed from the RP-Set included in Bootstrap messages.
* [RPタイマー（BSRのみ、RPセット内のRPごとに保持）] BSRは、RPセット内のRPごとにタイマーを使用して、活性を監視します。 C-RPがRP-Setに追加されると、そのタイマーは、そのC-RPからのC-RP-Advメッセージに含まれるHoldtimeに設定されます（これは、C-RPの[RP-Holdtime]の値と同じです） ）。後続のC-RP-AdvがそのRPから受信されるたびに、そのタイマーはC-RP-Advのホールドタイムまで再開されます。タイマーが期限切れになると、ブートストラップメッセージに含まれるRP-SetからRPが削除されます。
* [Bootstrap-Timer] This timer is used by the BSR to periodically originate Bootstrap messages, and by other routers to time out the BSR (see 3.6.3). This timer is initially set to [Bootstrap-Timeout]. A C-BSR restarts this timer to [Bootstrap-Timeout] upon receiving a Bootstrap message from a preferred router, and originates a Bootstrap message and restarts the timer to [Bootstrap-Period] when it expires. Routers not configured as C-BSR's restart this timer to [Bootstrap-Timeout] upon receiving a Bootstrap message from the elected or a more preferred BSR, and ignore Bootstrap messages from non-preferred C-BSRs while it is running.
* [Bootstrap-Timer]このタイマーは、BSRが定期的にBootstrapメッセージを発信するため、および他のルーターがBSRをタイムアウトするために使用されます（3.6.3を参照）。このタイマーは、最初は[Bootstrap-Timeout]に設定されています。 C-BSRは、優先ルーターからBootstrapメッセージを受信すると、このタイマーを[Bootstrap-Timeout]に再起動し、Bootstrapメッセージを発信して、有効期限が切れると[Bootstrap-Period]にタイマーを再起動します。 C-BSRとして設定されていないルーターは、選択されたBSRまたはより優先されるBSRからBootstrapメッセージを受信すると、このタイマーを[Bootstrap-Timeout]に再起動し、実行中は非優先C-BSRからのBootstrapメッセージを無視します。
Most of the default timeout values for state information are 3.5 times the refresh period. For example, Hellos refresh Neighbor state and the default Hello-timer period is 30 seconds, so a default Neighbor-timer duration of 105 seconds is included in the Holdtime field of the Hellos. In order to improve convergence, however, the default timeout value for information related to RP liveness and Bootstrap messages is 2.5 times the refresh period.
状態情報のデフォルトのタイムアウト値のほとんどは、更新期間の3.5倍です。たとえば、Helloはネイバー状態を更新し、デフォルトのHelloタイマー期間は30秒です。したがって、デフォルトのネイバータイマー期間である105秒は、HelloのHoldtimeフィールドに含まれています。ただし、収束を改善するために、RPの活性とブートストラップメッセージに関連する情報のデフォルトのタイムアウト値は、リフレッシュ周期の2.5倍です。
In this version of the spec, we suggest particular numerical timer settings. A future version of the specification will specify a mechanism for timer values to be scaled based upon observed network parameters.
このバージョンの仕様では、特定の数値タイマー設定をお勧めします。仕様の将来のバージョンでは、監視されたネットワークパラメータに基づいてタイマー値をスケーリングするメカニズムを指定する予定です。
* [Join/Prune-Period] This is the interval between sending Join/Prune messages. Default: 60 seconds. This value may be set to take into account such things as the configured bandwidth and expected average number of multicast route entries for the attached network or link (e.g., the period would be longer for lower-speed links, or for routers in the center of the network that expect to have a larger number of entries). In addition, a router could modify this value (and corresponding Join/Prune-Holdtime value) if the number of route entries changes significantly (e.g., by an order of magnitude). For example, given a default minimum Join/Prune-Period value, if the number of route entries with a particular iif increases from N to N*100, the router could increase its Join/Prune-Period (and Join/Prune-Holdtime), for that interface, by a factor of 10; and if/when the number of entries decreases back to N, the Join/Prune-Period (and Join/Prune-Holdtime) could be decreased to its previous value. If the Join/Prune-Period is modified, these changes should be made relatively infrequently and the router should continue to refresh at its previous Join/Prune-Period for at least Join/Prune-Holdtime, in order to allow the upstream router to adapt.
* [Join / Prune-Period]これは、Join / Pruneメッセージを送信する間隔です。デフォルト：60秒。この値は、接続されているネットワークまたはリンクの構成済みの帯域幅や予想されるマルチキャストルートエントリの平均数などを考慮して設定できます（たとえば、低速リンクの場合、または中央のルーターの場合、期間は長くなります）エントリの数が多いと予想されるネットワーク）。さらに、ルートエントリの数が大幅に変化した場合（たとえば、1桁程度）、ルーターはこの値（および対応するJoin / Prune-Holdtime値）を変更する可能性があります。たとえば、デフォルトの最小のJoin / Prune-Period値が指定されている場合、特定のiifを持つルートエントリの数がNからN * 100に増加すると、ルーターはそのJoin / Prune-Period（およびJoin / Prune-Holdtime）を増やすことができます、そのインターフェースの場合、10倍。また、エントリの数がNに戻った場合は、Join / Prune-Period（およびJoin / Prune-Holdtime）を以前の値に減らすことができます。 Join / Prune-Periodが変更された場合、これらの変更は比較的頻繁に行われるべきではなく、上流のルーターが適応できるようにするために、ルーターは以前のJoin / Prune-Periodで少なくともJoin / Prune-Holdtimeの間リフレッシュし続ける必要があります。
* [Join-Prune Holdtime] This is the Holdtime specified in Join/Prune messages, and is used to time out oifs. This should be set to 3.5 * [Join/Prune-Period]. Default: 210 seconds.
* [Join-Prune Holdtime]これは、Join / Pruneメッセージで指定されたHoldtimeであり、oifのタイムアウトに使用されます。これは3.5 * [Join / Prune-Period]に設定する必要があります。デフォルト：210秒。
* [Join/Prune-Suppression-Timeout] This is the mean interval between receiving a Join/Prune with a higher Holdtime (with ties broken by higher network layer address) and allowing duplicate Join/Prunes to be sent again. This should be set to approximately 1.25 * [Join/Prune-Period]. Default: 75 seconds.
* [Join / Prune-Suppression-Timeout]これは、より高いホールドタイムの結合/プルーンを受信し（タイがより高いネットワークレイヤーアドレスで壊れている）、重複した結合/プルーンを再度送信できるようにするまでの平均間隔です。これは約1.25 * [Join / Prune-Period]に設定する必要があります。デフォルト：75秒。
* [Data-Timeout] This is the time after which (S,G) state for a silent source will be deleted. Default: 210 seconds.
* [Data-Timeout]これは、サイレントソースの（S、G）状態が削除されるまでの時間です。デフォルト：210秒。
* [Register-Suppression-Timeout] This is the mean interval between receiving a Register-Stop and allowing Registers to be sent again. A lower value means more frequent register bursts at RP, while a higher value means longer join latency for new receivers. Default: 60 seconds. (Note that if null Registers are sent [Probe-Time] seconds before the timeout, register bursts are prevents, and [Register-Suppression-Timeout] may be lowered to decrease join latency.)
* [Register-Suppression-Timeout]これは、Register-Stopを受信してから、Registerの再送信を許可するまでの平均間隔です。値が小さいほどRPでのレジスタバーストの頻度が高くなり、値が大きいほど新しいレシーバーの結合レイテンシが長くなります。デフォルト：60秒。 （nullのレジスタがタイムアウトの[Probe-Time]秒前に送信された場合、レジスタのバーストが防止され、[Register-Suppression-Timeout]を低くして結合の待ち時間を短縮できることに注意してください。）
* [Probe-Time] When null Registers are used, this is the time between sending a null Register and the Register-Suppression-Timer expiring unless it is restarted by receiving a Register-Stop. Thus, a null Register would be sent when the Register-Suppression-Timer reaches this value. Default: 5 seconds.
* [Probe-Time] nullレジスタが使用されている場合、これは、Register-Stopを受信して再起動されない限り、nullレジスタを送信してからRegister-Suppression-Timerが期限切れになるまでの時間です。したがって、Register-Suppression-Timerがこの値に達すると、nullレジスタが送信されます。デフォルト：5秒。
* [Assert-Timeout] This is the interval between the last time an Assert is received, and the time at which the assert is timed out. Default: 180 seconds.
* [Assert-Timeout]これは、最後にアサートを受信してから、アサートがタイムアウトするまでの時間です。デフォルト：180秒。
* [Random-Delay-Join-Timeout] This is the maximum interval between the time when the RPF neighbor changes, and the time at which a triggered Join/Prune message is sent. Default: 4.5 seconds.
* [Random-Delay-Join-Timeout]これは、RPFネイバーが変更されてから、トリガーされたJoin / Pruneメッセージが送信されるまでの最大間隔です。デフォルト：4.5秒。
* [Hello-Period] This is the interval between sending Hello messages. Default: 30 seconds.
* [Hello-Period]これは、Helloメッセージを送信する間隔です。デフォルト：30秒。
* [Hello-Holdtime] This is the Holdtime specified in Hello messages, after which neighbors will time out their neighbor entries for the router. This should be set to 3.5 * [Hello-Period]. Default: 105 seconds.
* [Hello-Holdtime]これは、Helloメッセージで指定されたホールドタイムです。その後、ネイバーはルータのネイバーエントリをタイムアウトします。これは3.5 * [Hello-Period]に設定する必要があります。デフォルト：105秒。
* [C-RP-Adv-Period] For C-RPs, this is the interval between sending C-RP-Adv messages. Default: 60 seconds.
* [C-RP-Adv-Period] C-RPの場合、これはC-RP-Advメッセージを送信する間隔です。デフォルト：60秒。
* [RP-Holdtime] For C-RPs, this is the Holdtime specified in C-RP-Adv messages, and is used by the BSR to time out RPs. This should be set to 2.5 * [C-RP-Adv-Period]. Default: 150 seconds.
* [RP-Holdtime] C-RPの場合、これはC-RP-Advメッセージで指定されたホールドタイムであり、RPをタイムアウトするためにBSRによって使用されます。これは、2.5 * [C-RP-Adv-Period]に設定する必要があります。デフォルト：150秒。
* [Bootstrap-Period] At the elected BSR, this is the interval between originating Bootstrap messages, and should be equal to 60 seconds.
* [Bootstrap-Period]選出されたBSRでは、これは、Bootstrapメッセージを生成する間隔であり、60秒に等しい必要があります。
* [Bootstrap-Timeout] This is the time after which the elected BSR will be assumed unreachable when Bootstrap messages are not received from it. This should be set to `2 * [Bootstrap-Period] + 10'. Default: 130 seconds.
* [Bootstrap-Timeout]これは、ブートストラップメッセージが受信されない場合に、選択されたBSRが到達不能であると見なされるまでの時間です。これは `2 * [Bootstrap-Period] + 10 'に設定する必要があります。デフォルト：130秒。
Following is a summary of all the flags used in our scheme.
以下は、このスキームで使用されるすべてのフラグの要約です。
Bit | Used in | Definition
ビット| |で使用定義
Border | Register | Register for external sources is coming from PIM multicast border router Null | Register | Register sent as Probe of RP, the encapsulated IP data packet should not be forwarded RPT | Route entry | Entry represents state on the RP-tree RPT | Join/Prune | Join is associated with the shared tree and therefore the Join/Prune message is propagated along the RP-tree (source encoded is an RP address) RPT | Assert | The data packet was routed down the shared tree; thus, the path indicated corresponds to the RP tree SPT | (S,G) entry | Packets have arrived on the iif towards S, and the iif is different from the (*,G) iif WC |Join | The receiver expects to receive packets from all sources via this (shared tree) path. Thus, the Join/Prune applies to a (*,G) entry WC | Route entry | Wildcard entry; if there is no more specific match for a particular source, packets will be forwarded according to this entry
ボーダー|登録|外部ソースの登録はPIMマルチキャストボーダールーターから来ていますNull |登録| RPのプローブとして送信されるレジスタ、カプセル化されたIPデータパケットはRPTで転送されません。ルートエントリー|エントリは、RPツリーRPTの状態を表します。参加/剪定|結合は共有ツリーに関連付けられているため、結合/プルーンメッセージはRPツリーに沿って伝搬されます（エンコードされたソースはRPアドレスです）。アサート|データパケットは共有ツリーにルーティングされました。したがって、示されたパスはRPツリーSPT |に対応しています。 （S、G）エントリー|パケットがSに向けてiifに到着しましたが、iifは（*、G）iifとは異なりますWC | Join |受信者は、この（共有ツリー）パスを介してすべてのソースからパケットを受信することを期待しています。したがって、Join / Pruneは（*、G）エントリーWCに適用されます。ルートエントリー|ワイルドカードエントリ。特定のソースに一致する特定のものが存在しない場合、パケットはこのエントリに従って転送されます
All PIM control messages may use IPsec [6] to address security concerns.
すべてのPIM制御メッセージは、セキュリティの問題に対処するためにIPsec [6]を使用できます。
4 Packet Formats
4パケット形式
This section describes the details of the packet formats for PIM control messages.
このセクションでは、PIM制御メッセージのパケット形式の詳細について説明します。
All PIM control messages have protocol number 103.
すべてのPIM制御メッセージのプロトコル番号は103です。
Basically, PIM messages are either unicast (e.g. Registers and Register-Stop), or multicast hop-by-hop to `ALL-PIM-ROUTERS' group `224.0.0.13' (e.g. Join/Prune, Asserts, etc.).
基本的に、PIMメッセージはユニキャスト（例：RegistersとRegister-Stop）、または「ALL-PIM-ROUTERS」グループ「224.0.0.13」へのホップバイホップのマルチキャスト（例：Join / Prune、Assertsなど）です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Ver PIM Version number is 2.
PIM Ver PIMバージョン番号は2です。
Type Types for specific PIM messages. PIM Types are:
タイプ特定のPIMメッセージのタイプ。 PIMタイプは次のとおりです。
0 = Hello 1 = Register 2 = Register-Stop 3 = Join/Prune 4 = Bootstrap 5 = Assert 6 = Graft (used in PIM-DM only) 7 = Graft-Ack (used in PIM-DM only) 8 = Candidate-RP-Advertisement
0 = Hello 1 = Register 2 = Register-Stop 3 = Join / Prune 4 = Bootstrap 5 = Assert 6 = Graft（PIM-DMのみで使用）7 = Graft-Ack（PIM-DMのみで使用）8 = Candidate- RPアドバタイズメント
Reserved set to zero. Ignored upon receipt.
予約済みはゼロに設定されています。受領時に無視されます。
Checksum The checksum is the 16-bit one's complement of the one's complement sum of the entire PIM message, (excluding the data portion in the Register message). For computing the checksum, the checksum field is zeroed.
チェックサムチェックサムは、PIMメッセージ全体（レジスタメッセージのデータ部分を除く）の1の補数の合計の16ビットの1の補数です。チェックサムを計算する場合、チェックサムフィールドはゼロに設定されます。
1 Encoded-Unicast-address: Takes the following format:
1 Encoded-Unicast-address：次の形式を取ります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type | Unicast Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++++++
Addr Family The address family of the `Unicast Address' field of this address.
Addr Familyこのアドレスの「ユニキャストアドレス」フィールドのアドレスファミリ。
Here is the address family numbers assigned by IANA:
IANAによって割り当てられたアドレスファミリー番号は次のとおりです。
Number Description
-------- ---------------------------------------------------------
0 Reserved
1 IP (IP version 4)
2 IP6 (IP version 6)
3 NSAP
4 HDLC (8-bit multidrop)
5 BBN 1822
6 802 (includes all 802 media plus Ethernet "canonical format")
7 E.163
8 E.164 (SMDS, Frame Relay, ATM)
9 F.69 (Telex)
10 X.121 (X.25, Frame Relay)
11 IPX
12 Appletalk
13 Decnet IV
14 Banyan Vines
15 E.164 with NSAP format subaddress
Encoding Type The type of encoding used within a specific Address Family. The value `0' is reserved for this field, and represents the native encoding of the Address Family.
エンコーディングタイプ特定のアドレスファミリ内で使用されるエンコーディングのタイプ。値「0」はこのフィールド用に予約されており、アドレスファミリのネイティブエンコーディングを表します。
Unicast Address The unicast address as represented by the given Address Family and Encoding Type.
ユニキャストアドレス指定されたアドレスファミリとエンコーディングタイプで表されるユニキャストアドレス。
2 Encoded-Group-Address: Takes the following format:
2 Encoded-Group-Address：次の形式を取ります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type | Reserved | Mask Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group multicast Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Addr Family described above.
上記のアドレスファミリ。
Encoding Type described above.
上記のエンコードタイプ。
Reserved Transmitted as zero. Ignored upon receipt.
予約済みゼロとして送信されます。受領時に無視されます。
Mask Len The Mask length is 8 bits. The value is the number of contiguous bits left justified used as a mask which describes the address. It is less than or equal to the address length in bits for the given Address Family and Encoding Type. If the message is sent for a single group then the Mask length must equal the address length in bits for the given Address Family and Encoding Type. (e.g. 32 for IPv4 native encoding and 128 for IPv6 native encoding).
マスク長マスク長は8ビットです。値は、アドレスを記述するマスクとして使用される左揃えされた連続ビットの数です。指定されたアドレスファミリとエンコーディングタイプのアドレス長（ビット単位）以下です。メッセージが単一のグループに送信される場合、マスクの長さは、指定されたアドレスファミリとエンコーディングタイプのビット単位のアドレス長と等しくなければなりません。 （たとえば、IPv4ネイティブエンコーディングの場合は32、IPv6ネイティブエンコーディングの場合は128）。
Group multicast Address contains the group address.
グループマルチキャストアドレスには、グループアドレスが含まれます。
3 Encoded-Source-Address: Takes the following format:
3 Encoded-Source-Address：次の形式を取ります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type | Rsrvd |S|W|R| Mask Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Addr Family described above.
上記のアドレスファミリ。
Encoding Type described above.
上記のエンコードタイプ。
Reserved Transmitted as zero, ignored on receipt.
予約済みゼロとして送信され、受信時に無視されます。
S,W,R See Section 4.5 for details.
S、W、R詳細については、セクション4.5を参照してください。
Mask Length Mask length is 8 bits. The value is the number of contiguous bits left justified used as a mask which describes the address. The mask length must be less than or equal to the address length in bits for the given Address Family and Encoding Type. If the message is sent for a single group then the Mask length must equal the address length in bits for the given Address Family and Encoding Type. In version 2 of PIM, it is strongly recommended that this field be set to 32 for IPv4 native encoding.
マスク長マスク長は8ビットです。値は、アドレスを記述するマスクとして使用される左揃えされた連続ビットの数です。マスク長は、指定されたアドレスファミリとエンコーディングタイプのビット単位のアドレス長以下でなければなりません。メッセージが単一のグループに送信される場合、マスクの長さは、指定されたアドレスファミリとエンコーディングタイプのビット単位のアドレス長と等しくなければなりません。 PIMのバージョン2では、IPv4ネイティブエンコーディングの場合、このフィールドを32に設定することを強くお勧めします。
Source Address The source address.
送信元アドレス送信元アドレス。
It is sent periodically by routers on all interfaces.
これは、すべてのインターフェース上のルーターによって定期的に送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OptionType | OptionLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OptionValue |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OptionType | OptionLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OptionValue |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++
PIM Version, Type, Reserved, Checksum Described above.
上記のPIMバージョン、タイプ、予約済み、チェックサム。
OptionType The type of the option given in the following OptionValue field.
OptionType次のOptionValueフィールドで指定されるオプションのタイプ。
OptionLength The length of the OptionValue field in bytes.
OptionLengthバイト単位のOptionValueフィールドの長さ。
OptionValue A variable length field, carrying the value of the option.
OptionValueオプションの値を保持する可変長フィールド。
The Option fields may contain the following values:
オプションフィールドには、次の値が含まれる場合があります。
* OptionType = 1; OptionLength = 2; OptionValue = Holdtime; where Holdtime is the amount of time a receiver must keep the neighbor reachable, in seconds. If the Holdtime is set to `0xffff', the receiver of this message never times out the neighbor. This may be used with ISDN lines, to avoid keeping the link up with periodic Hello messages. Furthermore, if the Holdtime is set to `0', the information is timed out immediately.
* OptionType = 1; OptionLength = 2; OptionValue = Holdtime;ここで、Holdtimeは、レシーバーがネイバーに到達可能な状態を維持する必要のある時間（秒単位）です。 Holdtimeが「0xffff」に設定されている場合、このメッセージの受信者はネイバーをタイムアウトすることはありません。 ISDN回線でこれを使用すると、定期的なHelloメッセージでリンクがアップ状態に保たれるのを回避できます。さらに、Holdtimeが「0」に設定されている場合、情報はすぐにタイムアウトになります。
* OptionType 2 to 16: reserved
* OptionType 2から16：予約済み
* The rest of the OptionTypes are defined in another document.
* 残りのOptionTypeは別のドキュメントで定義されています。
In general, options may be ignored; but a router must not ignore the
一般に、オプションは無視されます。しかし、ルーターは
A Register message is sent by the DR or a PMBR to the RP when a multicast packet needs to be transmitted on the RP-tree. Source address is set to the address of the DR, destination address is to the RP's address.
Registerメッセージは、RPツリーでマルチキャストパケットを送信する必要がある場合に、DRまたはPMBRによってRPに送信されます。送信元アドレスはDRのアドレスに設定され、宛先アドレスはRPのアドレスに設定されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B|N| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
Multicast data packet
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Type, Reserved, Checksum Described above. Note that the checksum for Registers is done only on the PIM header, excluding the data packet portion.
上記のPIMバージョン、タイプ、予約済み、チェックサム。レジスタのチェックサムは、データパケット部分を除いて、PIMヘッダーでのみ実行されることに注意してください。
B The Border bit. If the router is a DR for a source that it is directly connected to, it sets the B bit to 0. If the router is a PMBR for a source in a directly connected cloud, it sets the B bit to 1.
Bボーダービット。ルーターは、直接接続されているソースのDRの場合、Bビットを0に設定します。ルーターが直接接続されたクラウドのソースのPMBRの場合、Bビットを1に設定します。
N The Null-Register bit. Set to 1 by a DR that is probing the RP before expiring its local Register-Suppression timer. Set to 0 otherwise.
N Nullレジスタビット。ローカルのレジスタ抑制タイマーが期限切れになる前にRPをプローブしているDRによって1に設定されます。それ以外の場合は0に設定します。
Multicast data packet The original packet sent by the source.
マルチキャストデータパケットソースによって送信された元のパケット。
For (S,G) null Registers, the Multicast data packet portion contains only a dummy header with S as the source address, G as the destination address, and a data length of zero.
（S、G）nullレジスタの場合、マルチキャストデータパケット部分には、送信元アドレスとしてS、宛先アドレスとしてG、データ長がゼロのダミーヘッダーのみが含まれます。
A Register-Stop is unicast from the RP to the sender of the Register message. Source address is the address to which the register was addressed. Destination address is the source address of the register message.
Register-Stopは、RPからRegisterメッセージの送信者へのユニキャストです。ソースアドレスは、レジスタがアドレス指定されたアドレスです。宛先アドレスは、登録メッセージの送信元アドレスです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Unicast-Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Type, Reserved, Checksum Described above.
上記のPIMバージョン、タイプ、予約済み、チェックサム。
Encoded-Group Address Format described above. Note that for Register-Stops the Mask Len field contains full address length * 8 (e.g. 32 for IPv4 native encoding), if the message is sent for a single group.
上記のエンコードされたグループアドレスの形式。 Register-Stopsの場合、メッセージが単一のグループに送信される場合、Mask Lenフィールドには完全なアドレス長* 8（IPv4ネイティブエンコーディングの場合は32）が含まれることに注意してください。
Encoded-Unicast-Source Address host address of source from multicast data packet in register. The format for this address is given in the Encoded-Unicast-Address in 4.1. A special wild card value (0's), can be used to indicate any source.
エンコードされたユニキャストソースアドレスレジスタ内のマルチキャストデータパケットからのソースのホストアドレス。このアドレスの形式は、4.1のEncoded-Unicast-Addressに示されています。特別なワイルドカード値（0）を使用して、任意のソースを示すことができます。
A Join/Prune message is sent by routers towards upstream sources and RPs. Joins are sent to build shared trees (RP trees) or source trees (SPT). Prunes are sent to prune source trees when members leave groups as well as sources that do not use the shared tree.
Join / Pruneメッセージは、上流のソースとRPに向けてルーターから送信されます。結合は、共有ツリー（RPツリー）またはソースツリー（SPT）を構築するために送信されます。メンバーがグループを離れると、プルーンはソースツリーとプルーニングソースツリーに送信され、ソースは共有ツリーを使用しません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Unicast-Upstream Neighbor Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Num groups | Holdtime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Multicast Group Address-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Joined Sources | Number of Pruned Sources |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Joined Source Address-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Joined Source Address-n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Pruned Source Address-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Pruned Source Address-n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Multicast Group Address-n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Joined Sources | Number of Pruned Sources |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Joined Source Address-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Joined Source Address-n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Pruned Source Address-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Pruned Source Address-n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Type, Reserved, Checksum Described above.
上記のPIMバージョン、タイプ、予約済み、チェックサム。
Encoded-Unicast Upstream Neighbor Address The address of the RPF or upstream neighbor. The format for this address is given in the Encoded-Unicast-Address in 4.1. .IP "Reserved" Transmitted as zero, ignored on receipt.
エンコードされたユニキャストアップストリームネイバーアドレスRPFまたはアップストリームネイバーのアドレス。このアドレスの形式は、4.1のEncoded-Unicast-Addressに示されています。 .IP "予約済み"ゼロとして送信され、受信時に無視されます。
Holdtime The amount of time a receiver must keep the Join/Prune state alive, in seconds. If the Holdtime is set to `0xffff', the receiver of this message never times out the oif. This may be used with ISDN lines, to avoid keeping the link up with periodical Join/Prune messages. Furthermore, if the Holdtime is set to `0', the information is timed out immediately.
HoldtimeレシーバーがJoin / Prune状態を維持する必要のある時間（秒単位）。 Holdtimeが `0xffff 'に設定されている場合、このメッセージの受信者はoifをタイムアウトしません。これはISDN回線で使用して、定期的なJoin / Pruneメッセージでリンクを維持し続けることを回避できます。さらに、Holdtimeが「0」に設定されている場合、情報はすぐにタイムアウトになります。
Number of Groups The number of multicast group sets contained in the message.
グループ数メッセージに含まれるマルチキャストグループセットの数。
Encoded-Multicast group address For format description see Section 4.1. A wild card group in the (*,*,RP) join is represented by a 224.0.0.0 in the group address field and `4' in the mask length field. A (*,*,RP) join also has the WC-bit and the RPT-bit set.
エンコードマルチキャストグループアドレスフォーマットの説明については、セクション4.1を参照してください。 （*、*、RP）結合のワイルドカードグループは、グループアドレスフィールドの224.0.0.0とマスク長フィールドの「4」で表されます。 （*、*、RP）結合には、WCビットとRPTビットも設定されています。
Number of Joined Sources Number of join source addresses listed for a given group.
参加ソースの数特定のグループにリストされている参加ソースアドレスの数。
Join Source Address-1 .. n This list contains the sources that the sending router will forward multicast datagrams for if received on the interface this message is sent on.
Join Source Address-1 .. nこのリストには、このメッセージが送信されるインターフェイスで受信された場合に、送信ルーターがマルチキャストデータグラムを転送するソースが含まれます。
See format section 4.1. The fields explanation for the Encoded-Source-Address format follows:
フォーマットセクション4.1を参照してください。 Encoded-Source-Address形式のフィールドの説明は次のとおりです。
Reserved Described above.
上記で説明済み。
S The Sparse bit is a 1 bit value, set to 1 for PIM-SM. It is used for PIM v.1 compatibility.
Sスパースビットは1ビット値で、PIM-SMの場合は1に設定されます。 PIM v.1互換性のために使用されます。
W The WC bit is a 1 bit value. If 1, the join or prune applies to the (*,G) or (*,*,RP) entry. If 0, the join or prune applies to the (S,G) entry where S is Source Address. Joins and prunes sent towards the RP must have this bit set.
W WCビットは1ビット値です。 1の場合、結合またはプルーニングは（*、G）または（*、*、RP）エントリーに適用されます。 0の場合、結合またはプルーニングは（S、G）エントリに適用されます。Sは送信元アドレスです。 RPに送信される結合とプルーンには、このビットが設定されている必要があります。
R The RPT-bit is a 1 bit value. If 1, the information about (S,G) is sent towards the RP. If 0, the information must be sent toward S, where S is the Source Address.
R RPTビットは1ビット値です。 1の場合、（S、G）に関する情報がRPに送信されます。 0の場合、情報はSに送信される必要があります。Sは送信元アドレスです。
Mask Length, Source Address Described above.
マスク長、送信元アドレス上記で説明。
Represented in the form of < WC-bit >< RPT-bit ><Mask length >< Source address>:
<WC-bit> <RPT-bit> <Mask length> <Source address>の形式で表されます：
A source address could be a host IPv4 native encoding address :
送信元アドレスは、ホストIPv4ネイティブエンコーディングアドレスである可能性があります。
< 0 >< 0 >< 32 >< 192.1.1.17 >
A source address could be the RP's IP address :
送信元アドレスはRPのIPアドレスである可能性があります。
< 1 >< 1 >< 32 >< 131.108.13.111 >
A source address could be a subnet address to prune from the RP-tree :
送信元アドレスは、RPツリーからプルーニングするサブネットアドレスにすることができます。
< 0 >< 1 >< 28 >< 192.1.1.16 >
A source address could be a general aggregate :
送信元アドレスは、一般的な集約である可能性があります。
< 0 >< 0 >< 16 >< 192.1.0.0 >
Number of Pruned Sources Number of prune source addresses listed for a group.
Number of Pruned Sourcesグループにリストされているプルーニング送信元アドレスの数。
Prune Source Address-1 .. n This list contains the sources that the sending router does not want to forward multicast datagrams for when received on the interface this message is sent on. If the Join/Prune message boundary exceeds the maximum packet size, then the join and prune lists for the same group must be included in the same packet.
Prune Source Address-1 .. nこのリストには、このメッセージが送信されるインターフェイスで受信されたときに、送信ルーターがマルチキャストデータグラムを転送したくないソースが含まれます。 Join / Pruneメッセージの境界が最大パケットサイズを超える場合は、同じグループのJoinリストとPruneリストを同じパケットに含める必要があります。
The Bootstrap messages are multicast to `ALL-PIM-ROUTERS' group, out all interfaces having PIM neighbors (excluding the one over which the message was received). Bootstrap messages are sent with TTL value of 1. Bootstrap messages originate at the BSR, and are forwarded by intermediate routers.
ブートストラップメッセージは、PIMネイバーを持つすべてのインターフェイス（メッセージの受信に使用されたものを除く）から、「ALL-PIM-ROUTERS」グループにマルチキャストされます。ブートストラップメッセージはTTL値1で送信されます。ブートストラップメッセージはBSRから発信され、中間ルーターによって転送されます。
Bootstrap message is divided up into `semantic fragments', if the original message exceeds the maximum packet size boundaries.
元のメッセージが最大パケットサイズの境界を超えた場合、ブートストラップメッセージは「セマンティックフラグメント」に分割されます。
The semantics of a single `fragment' is given below:
単一の「フラグメント」のセマンティクスを以下に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment Tag | Hash Mask len | BSR-priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Unicast-BSR-Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Group Address-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP-Count-1 | Frag RP-Cnt-1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Unicast-RP-Address-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP1-Holdtime | RP1-Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Unicast-RP-Address-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP2-Holdtime | RP2-Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Unicast-RP-Address-m |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPm-Holdtime | RPm-Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Group Address-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Group Address-n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP-Count-n | Frag RP-Cnt-n | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Unicast-RP-Address-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP1-Holdtime | RP1-Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Unicast-RP-Address-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP2-Holdtime | RP2-Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Unicast-RP-Address-m |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPm-Holdtime | RPm-Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Type, Reserved, Checksum Described above.
上記のPIMバージョン、タイプ、予約済み、チェックサム。
Fragment Tag A randomly generated number, acts to distinguish the fragments belonging to different Bootstrap messages; fragments belonging to same Bootstrap message carry the same `Fragment Tag'.
Fragment Tagランダムに生成された番号で、異なるBootstrapメッセージに属するフラグメントを区別する働きをします。同じブートストラップメッセージに属するフラグメントは、同じ「フラグメントタグ」を持ちます。
Hash Mask len The length (in bits) of the mask to use in the hash function. For IPv4 we recommend a value of 30. For IPv6 we recommend a value of 126.
Hash Mask lenハッシュ関数で使用するマスクの長さ（ビット単位）。 IPv4の場合は30の値をお勧めします。IPv6の場合は126の値をお勧めします。
BSR-priority Contains the BSR priority value of the included BSR. This field is considered as a high order byte when comparing BSR addresses.
BSR-priority含まれているBSRのBSR優先度値が含まれます。このフィールドは、BSRアドレスを比較するときに上位バイトと見なされます。
Encoded-Unicast-BSR-Address The address of the bootstrap router for the domain. The format for this address is given in the Encoded-Unicast-Address in 4.1. .IP "Encoded-Group Address-1..n" The group prefix (address and mask) with which the Candidate RPs are associated. Format previously described.
Encoded-Unicast-BSR-Addressドメインのブートストラップルーターのアドレス。このアドレスの形式は、4.1のEncoded-Unicast-Addressに示されています。 .IP "Encoded-Group Address-1..n"候補RPが関連付けられているグループプレフィックス（アドレスとマスク）。前述のフォーマット。
RP-Count-1..n The number of Candidate RP addresses included in the whole Bootstrap message for the corresponding group prefix. A router does not replace its old RP-Set for a given group prefix until/unless it receives `RP-Count' addresses for that prefix; the addresses could be carried over several fragments. If only part of the RP-Set for a given group prefix was received, the router discards it, without updating that specific group prefix's RP-Set.
RP-Count-1..n対応するグループプレフィックスのブートストラップメッセージ全体に含まれる候補RPアドレスの数。ルーターは、その接頭辞の「RP-Count」アドレスを受信するまで、その接頭辞の古いRP-Setを置き換えません。アドレスはいくつかのフラグメントにまたがって運ばれる可能性があります。特定のグループプレフィックスのRP-Setの一部のみが受信された場合、ルーターはその特定のグループプレフィックスのRP-Setを更新せずに、それを破棄します。
Frag RP-Cnt-1..m The number of Candidate RP addresses included in this fragment of the Bootstrap message, for the corresponding group prefix. The `Frag RP-Cnt' field facilitates parsing of the RP-Set for a given group prefix, when carried over more than one fragment.
Frag RP-Cnt-1..m対応するグループプレフィックスの、Bootstrapメッセージのこのフラグメントに含まれるCandidate RPアドレスの数。 「Frag RP-Cnt」フィールドは、複数のフラグメントに渡って運ばれた場合に、特定のグループプレフィックスのRP-Setの解析を容易にします。
Encoded-Unicast-RP-address-1..m The address of the Candidate RPs, for the corresponding group prefix. The format for this address is given in the Encoded-Unicast-Address in 4.1. .IP "RP1..m-Holdtime" The Holdtime for the corresponding RP. This field is copied from the `Holdtime' field of the associated RP stored at the BSR.
Encoded-Unicast-RP-address-1..m対応するグループプレフィックスの候補RPのアドレス。このアドレスの形式は、4.1のEncoded-Unicast-Addressに示されています。 .IP "RP1..m-Holdtime"対応するRPのホールドタイム。このフィールドは、BSRに格納されている関連するRPの「Holdtime」フィールドからコピーされます。
RP1..m-Priority The `Priority' of the corresponding RP and Encoded-Group Address. This field is copied from the `Priority' field stored at the BSR when receiving a Candidate-RP-Advertisement. The highest priority is `0' (i.e. the lower the value of the `Priority' field, the higher). Note that the priority is per RP per Encoded-Group Address.
RP1..m-Priority対応するRPおよびエンコードされたグループアドレスの「優先度」。このフィールドは、Candidate-RP-Advertisementを受信したときにBSRに保存されている「Priority」フィールドからコピーされます。最高の優先度は「0」です（つまり、「優先度」フィールドの値が低いほど高くなります）。優先順位は、RPごと、エンコードされたグループアドレスごとであることに注意してください。
The Assert message is sent when a multicast data packet is received on an outgoing interface corresponding to the (S,G) or (*,G) associated with the source.
ソースに関連付けられた（S、G）または（*、G）に対応する発信インターフェイスでマルチキャストデータパケットが受信されると、Assertメッセージが送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Unicast-Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Metric Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Type, Reserved, Checksum Described above.
上記のPIMバージョン、タイプ、予約済み、チェックサム。
Encoded-Group Address The group address to which the data packet was addressed, and which triggered the Assert. Format previously described.
エンコードされたグループアドレスデータパケットが宛てられ、アサートをトリガーしたグループアドレス。前述のフォーマット。
Encoded-Unicast-Source Address Source address from multicast datagram that triggered the Assert packet to be sent. The format for this address is given in the Encoded-Unicast-Address in 4.1. .IP "R" RPT-bit is a 1 bit value. If the multicast datagram that triggered the Assert packet is routed down the RP tree, then the RPT-bit is 1; if the multicast datagram is routed down the SPT, it is 0.
エンコードされたユニキャストソースアドレスアサートパケットの送信をトリガーしたマルチキャストデータグラムのソースアドレス。このアドレスの形式は、4.1のEncoded-Unicast-Addressに示されています。 .IP "R" RPT-bitは1ビットの値です。アサートパケットをトリガーしたマルチキャストデータグラムがRPツリーの下にルーティングされる場合、RPTビットは1です。マルチキャストデータグラムがSPTにルーティングされる場合、0です。
Metric Preference Preference value assigned to the unicast routing protocol that provided the route to Host address.
メトリックプリファレンスホストアドレスへのルートを提供するユニキャストルーティングプロトコルに割り当てられたプリファレンス値。
Metric The unicast routing table metric. The metric is in units applicable to the unicast routing protocol used.
メトリックユニキャストルーティングテーブルのメトリック。メトリックは、使用されるユニキャストルーティングプロトコルに適用可能な単位です。
Used in dense-mode. Refer to PIM dense mode specification.
密モードで使用されます。 PIMデンスモードの仕様を参照してください。
Used in dense-mode. Refer to PIM dense mode specification.
密モードで使用されます。 PIMデンスモードの仕様を参照してください。
Candidate-RP-Advertisements are periodically unicast from the C-RPs to the BSR.
Candidate-RP-Advertisementsは、C-RPからBSRに定期的にユニキャストされます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix-Cnt | Priority | Holdtime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Unicast-RP-Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Group Address-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Group Address-n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Type, Reserved, Checksum Described above.
上記のPIMバージョン、タイプ、予約済み、チェックサム。
Prefix-Cnt The number of encoded group addresses included in the message; indicating the group prefixes for which the C-RP is advertising. A Prefix-Cnt of `0' implies a prefix of 224.0.0.0 with mask length of 4; i.e. all multicast groups. If the C-RP is not configured with Group-prefix information, the C-RP puts a default value of `0' in this field.
Prefix-Cntメッセージに含まれるエンコードされたグループアドレスの数。 C-RPが通知するグループプレフィックスを示します。 Prefix-Cntが「0」の場合は、マスク長4のプレフィックス224.0.0.0を意味します。つまり、すべてのマルチキャストグループ。 C-RPにグループプレフィックス情報が設定されていない場合、C-RPはこのフィールドにデフォルト値「0」を入力します。
Priority The `Priority' of the included RP, for the corresponding Encoded-Group Address (if any). highest priority is `0' (i.e. the lower the value of the `Priority' field, the higher the priority). This field is stored at the BSR upon receipt along with the RP address and corresponding Encoded-Group Address.
優先度対応するエンコードされたグループアドレス（存在する場合）に対する、含まれるRPの「優先度」。最高の優先度は「0」です（つまり、「優先度」フィールドの値が低いほど優先度が高くなります）。このフィールドは、RPアドレスおよび対応するエンコードされたグループアドレスとともに、受信時にBSRに格納されます。
Holdtime The amount of time the advertisement is valid. This field allows advertisements to be aged out.
Holdtimeアドバタイズが有効な時間。このフィールドを使用すると、広告を期限切れにすることができます。
Encoded-Unicast-RP-Address The address of the interface to advertise as a Candidate RP. The format for this address is given in the Encoded-Unicast-Address in 4.1. .IP "Encoded-Group Address-1..n" The group prefixes for which the C-RP is advertising. Format previously described.
Encoded-Unicast-RP-Address Candidate RPとしてアドバタイズするインターフェイスのアドレス。このアドレスの形式は、4.1のEncoded-Unicast-Addressに示されています。 .IP "Encoded-Group Address-1..n" C-RPが通知するグループプレフィックス。前述のフォーマット。
5 Acknowledgments
5謝辞
Tony Ballardie, Scott Brim, Jon Crowcroft, Bill Fenner, Paul Francis, Joel Halpern, Horst Hodel, Polly Huang, Stephen Ostrowski, Lixia Zhang and Girish Chandranmenon provided detailed comments on previous drafts. The authors of CBT [8] and membership of the IDMR WG provided many of the motivating ideas for this work and useful feedback on design details.
Tony Ballardie、Scott Brim、Jon Crowcroft、Bill Fenner、Paul Francis、Joel Halpern、Horst Hodel、Polly Huang、Stephen Ostrowski、Lixia Zhang、Girish Chandranmenonは、以前のドラフトについて詳細なコメントを提供しました。 CBTの作成者[8]とIDMR WGのメンバーは、この作業の動機付けとなるアイデアの多くと、設計の詳細に関する有用なフィードバックを提供しました。
This work was supported by the National Science Foundation, ARPA, cisco Systems and Sun Microsystems.
この作品は、National Science Foundation、ARPA、cisco Systems、およびSun Microsystemsによってサポートされていました。
6 Appendices
6付録
This appendix populates the major changes in the specification document as compared to `draft-ietf-idmr-pim-spec-01.ps,txt'.
この付録では、「draft-ietf-idmr-pim-spec-01.ps、txt」と比較して、仕様書に大きな変更が加えられています。
bsubsection*Major Changes
bsubsection *主な変更点
List of changes since March '96 IETF:
'96年3月IETF以降の変更のリスト：
1. (*,*,RP) Joins state and data forwarding check; replaces (*,G-Prefix) Joins state for interoperability. (*,G) negative cache introduced for the (*,*,RP) state supporting mechanisms.
1. （*、*、RP）結合状態とデータ転送チェック。置換（*、G-Prefix）相互運用性のために状態を結合します。 （*、G）状態をサポートするメカニズムのために導入された（*、G）ネガティブキャッシュ。
2. Semantic fragmentation for the Bootstrap message.
2. ブートストラップメッセージのセマンティックフラグメンテーション。
3. Refinement of Assert details.
3. アサートの詳細の改良。
4. Addition and refinement of Join/Prune suppression and Register suppression (introduction of null Registers).
4. 結合/プルーン抑制とレジスタ抑制の追加と改良（nullレジスタの導入）。
5. Editorial changes and clarifications to the timers section.
5. タイマーセクションの編集上の変更と説明。
6. Addition of Appendix II (BSR Election and RP-Set Distribution), and Appendix III (Glossary of Terms).
6. 付録II（BSRの選択とRPセットの配布）、および付録III（用語集）の追加。
7. Addition of table of contents.
7. 目次の追加。
List of changes incurred since version 1 of the spec.:
仕様のバージョン1以降に発生した変更のリスト：
1. Proposal and refinement of bootstrap router (BSR) election mechanisms
1. ブートストラップルーター（BSR）選択メカニズムの提案と改良
2. Introduction of hash functions for Group to RP mapping
2. グループからRPへのマッピングのためのハッシュ関数の紹介
3. New RP-liveness indication mechanisms based upon the the Bootstrap Router (BSR) and the Bootstrap messages.
3. Bootstrap Router（BSR）およびBootstrapメッセージに基づく新しいRP活性表示メカニズム。
4. Removal of reachability messages, RP reports and multiple RPs per group.
4. 到達可能性メッセージ、RPレポート、およびグループごとの複数のRPの削除。
*Packet Format Changes
*パケット形式の変更
Packet Format incurred updates to accommodate different address lengths, and address aggregation.
パケット形式では、さまざまなアドレス長とアドレス集約に対応するために更新が発生しました。
1 The `Addr Family' and `Encoding Type' fields were added to the packet formats.
1「Addr Family」および「Encoding Type」フィールドがパケット形式に追加されました。
2 The Encoded source and group address formats were introduced, with the use of a `Mask length' field to allow aggregation, section 4.1.
2暗号化された送信元およびグループアドレス形式が導入され、集約を可能にする「マスク長」フィールドが使用されています（セクション4.1）。
3 Packet formats are no longer IGMP messages; rather PIM messages.
3パケット形式はIGMPメッセージではなくなりました。むしろPIMメッセージ。
PIM message types and formats were also modified:
PIMメッセージのタイプと形式も変更されました。
[Note: most changes were made to the May 95 version, unless otherwise specified].
[注記：ほとんどの変更は、特に指定のない限り、95年5月のバージョンに加えられました]。
1 Obsolete messages:
1廃止されたメッセージ：
Register-Ack [Feb. 96]
Register-Ack [Feb. 96]
Poll and Poll Response [Feb. 96]
世論調査と世論調査の応答[Feb. 96]
RP-Reachability [Feb. 96]
RP到達可能性[2月96]
RPlist-Mapping [Feb. 96]
RPlist-Mapping [2月96]
2 New messages:
2新しいメッセージ：
Candidate-RP-Advertisement [change made in October 95] RP-Set [Feb. 96]
Candidate-RP-Advertisement [95年10月に変更] RP-Set [Feb. 96]
3 Modified messages:
3変更されたメッセージ：
Join/Prune [Feb. 96]
Register [Feb. 96]
Register-Stop [Feb. 96]
Hello (addition of OptionTypes) [Aug 96]
4 Renamed messages:
4名前が変更されたメッセージ：
Query messages are renamed as Hello messages [Aug. 96] RP-Set messages are renamed as Bootstrap messages [Aug. 96]
クエリメッセージの名前がHelloメッセージに変更されました[8月96] RP-Setメッセージの名前がBootstrapメッセージに変更されました。 96]
For simplicity, the bootstrap message is used in both the BSR election and the RP-Set distribution mechanisms. These mechanisms are described by the following state machine, illustrated in figure 4. The protocol transitions for a Candidate-BSR are given in state diagram (a). For routers not configured as Candidate-BSRs, the protocol transitions are given in state diagram (b).
簡単にするために、ブートストラップメッセージは、BSR選択メカニズムとRP-Set配布メカニズムの両方で使用されます。これらのメカニズムは、図4に示す次のステートマシンで説明されています。候補BSRのプロトコル遷移は、状態図（a）に示されています。候補BSRとして構成されていないルーターの場合、プロトコル遷移は状態図（b）に示されています。
[Figures are present only in the postscript version] Fig. 4 State Diagram for the BSR election and RP-Set distribution
[図はポストスクリプトバージョンにのみ存在します]図4 BSRの選択とRP-Setの配布の状態図
Each PIM router keeps a bootstrap-timer, initialized to [Bootstrap-Timeout], in addition to a local BSR field `LclBSR' (initialized to a local address if Candidate-BSR, or to 0 otherwise), and a local RP-Set `LclRP-Set' (initially empty). The main stimuli to the state machine are timer events and arrival of bootstrap messages:
各PIMルーターは、ローカルBSRフィールド `LclBSR '（Candidate-BSRの場合はローカルアドレスに、それ以外の場合は0に初期化）、およびローカルRP-Setに加えて、[Bootstrap-Timeout]に初期化されたブートストラップタイマーを保持します`LclRP-Set '（最初は空）。ステートマシンの主な刺激は、タイマーイベントとブートストラップメッセージの到着です。
bsubsection*Initial States and Timer Events
bsubsection *初期状態とタイマーイベント
1
１
2 If the router is a Candidate-BSR:
2ルーターがCandidate-BSRの場合：
1
１
2 The router operates initially in the `CandBSR' state, where it does not originate any bootstrap messages.
2ルータは最初は「CandBSR」状態で動作し、ブートストラップメッセージを発信しません。
3 If the bootstrap-timer expires, and the current state is `CandBSR', the router originates a bootstrap message carrying the local RP-Set and its own BSR priority and address, restarts the bootstrap-timer at [Bootstrap-Period] seconds, and transits into the `ElectedBSR' state. Note that the actual sending of the bootstrap message may be delayed by a random value to reduce transient control overhead. To obtain best results, the random value is set such that the preferred BSR is the first to originate a bootstrap message. We propose the following as an efficient implementation of the random value delay (in seconds):
3ブートストラップタイマーが期限切れになり、現在の状態が「CandBSR」である場合、ルータはローカルRP-Setと独自のBSR優先度およびアドレスを運ぶブートストラップメッセージを発信し、[Bootstrap-Period]秒でブートストラップタイマーを再起動します。そして、「ElectedBSR」状態に遷移します。ブートストラップメッセージの実際の送信は、一時的な制御オーバーヘッドを削減するためにランダムな値によって遅延される場合があることに注意してください。最良の結果を得るには、優先BSRが最初にブートストラップメッセージを発信するようにランダムな値を設定します。ランダム値遅延（秒単位）の効率的な実装として、以下を提案します。
Delay = 5 + 2 * log_2(1 + bestPriority - myPriority) + AddrDelay
where myPriority is the Candidate-BSR's configured priority, and bestPriority equals:
ここで、myPriorityはCandidate-BSRに構成された優先度であり、bestPriorityは次の値に等しい
bestPriority = Max(storedPriority, myPriority) ]
bestPriority = Max（storedPriority、myPriority）]
and AddrDelay is given by the following:
そしてAddrDelayは以下によって与えられます：
1 if ( bestPriority equals myPriority) then
[AddrDelay = log_2(bestAddr - myAddr) / 16, ]
2 else [AddrDelay = 2 - (myAddr / 2^31) ]
where myAddr is the Candidate-BSR's address, and bestAddr is the stored BSR's address.
ここで、myAddrは候補BSRのアドレスであり、bestAddrは保存されているBSRのアドレスです。
4 If the bootstrap-timer expires, and the current state is `ElectedBSR', the router originates a bootstrap message, and restarts the RP-Set timer at [Bootstrap-Period]. No state transition is incurred.
4ブートストラップタイマーが期限切れになり、現在の状態が「ElectedBSR」である場合、ルータはブートストラップメッセージを発信し、RP-Setタイマーを[Bootstrap-Period]で再起動します。状態遷移は発生しません。
This way, the elected BSR originates periodic bootstrap messages every [Bootstrap-Period].
このようにして、選出されたBSRは、[Bootstrap-Period]ごとに定期的なブートストラップメッセージを発信します。
3 If a router is not a Candidate-BSR:
3ルーターが候補BSRではない場合：
1
１
2 The router operates initially in the `AxptAny' state. In such state, a router accepts the first bootstrap message from the The Reverse Path Forwarding (RPF) neighbor toward the included BSR. The RPF neighbor in this case is the next hop router en route to the included BSR.
2ルータは最初、「AxptAny」状態で動作します。このような状態では、ルーターは、逆経路転送（RPF）ネイバーから含まれているBSRへの最初のブートストラップメッセージを受け入れます。この場合のRPFネイバーは、含まれているBSRへの途中のネクストホップルータです。
3 If the bootstrap-timer expires, and the current state is `AxptPref'-- where the router accepts only preferred bootstrap messages (those that carry BSR-priority and address higher than, or equal to, `LclBSR') from the RPF neighbor toward the included BSR-- the router transits into the `AxptAny' state.
3ブートストラップタイマーが期限切れになり、現在の状態が「AxptPref」である場合、ルータはRPFネイバーからの優先ブートストラップメッセージ（BSRプライオリティと「LclBSR」以上のアドレスを含むメッセージ）のみを受け入れます含まれているBSRに向かって-ルータは「AxptAny」状態に移行します。
In this case, if an elected BSR becomes unreachable, the routers start accepting bootstrap messages from another Candidate-BSR after the bootstrap-timer expires. All PIM routers within a domain converge on the preferred reachable Candidate-BSR.
この場合、選択されたBSRに到達できなくなると、ブートストラップタイマーの期限が切れた後、ルーターは別のCandidate-BSRからのブートストラップメッセージの受け入れを開始します。ドメイン内のすべてのPIMルーターは、優先的に到達可能なCandidate-BSRに収束します。
Receiving Bootstrap Message:
ブートストラップメッセージの受信：
To avoid loops, an RPF check is performed on the included BSR address. Upon receiving a bootstrap message from the RPF neighbor toward the included BSR, the following actions are taken:
ループを回避するために、含まれているBSRアドレスに対してRPFチェックが実行されます。 RPFネイバーから含まれているBSRへのブートストラップメッセージを受信すると、次のアクションが実行されます。
1 If the router is not a Candidate-BSR:
1ルーターが候補BSRではない場合：
1 If the current state is `AxptAny', the router accepts the bootstrap message, and transits into the `AxptPref' state.
1現在の状態が「AxptAny」の場合、ルータはブートストラップメッセージを受け入れ、「AxptPref」状態に遷移します。
2 If the current state is `AxptPref', and the bootstrap message is preferred, the message is accepted. No state transition is incurred.
2現在の状態が「AxptPref」であり、ブートストラップメッセージが優先される場合、メッセージは受け入れられます。状態遷移は発生しません。
2 If the router is a Candidate-BSR, and the bootstrap message is preferred, the message is accepted. Further, if this happens when the current state is `Elected BSR', the router transits into the `CandBSR' state.
2ルータがCandidate-BSRであり、ブートストラップメッセージが優先される場合、メッセージは受け入れられます。さらに、現在の状態が「選択されたBSR」であるときにこれが発生した場合、ルータは「CandBSR」状態に移行します。
When a bootstrap message is accepted, the router restarts the bootstrap-timer at [Bootstrap-Timeout], stores the received BSR priority and address in `LclBSR', and the received RP-Set in `LclRP-Set', and forwards the bootstrap message out all interfaces except the receiving interface.
ブートストラップメッセージが受け入れられると、ルータは[Bootstrap-Timeout]でブートストラップタイマーを再起動し、受信したBSRプライオリティとアドレスを「LclBSR」に、受信したRP-Setを「LclRP-Set」に格納し、ブートストラップを転送します。受信インターフェースを除くすべてのインターフェースからメッセージを送信します。
If a bootstrap message is rejected, no state transitions are triggered.
ブートストラップメッセージが拒否された場合、状態遷移はトリガーされません。
Following is an alphabetized list of terms and definitions used throughout this specification.
以下は、この仕様全体で使用される用語と定義のアルファベット順のリストです。
* { Bootstrap router (BSR)}. A BSR is a dynamically elected router within a PIM domain. It is responsible for constructing the RP-Set and originating Bootstrap messages.
* {ブートストラップルーター（BSR）}。 BSRは、PIMドメイン内で動的に選択されるルーターです。これは、RP-Setの作成とBootstrapメッセージの発信を担当します。
* { Candidate-BSR (C-BSR)}. A C-BSR is a router configured to participate in the BSR election and act as BSRs if elected.
* {Candidate-BSR（C-BSR）}。 C-BSRは、BSR選定に参加し、選定された場合はBSRとして機能するように構成されたルーターです。
* { Candidate RP (C-RP)}. A C-RP is a router configured to send periodic Candidate-RP-Advertisement messages to the BSR, and act as an RP when it receives Join/Prune or Register messages for the advertised group prefix.
* {候補RP（C-RP）}。 C-RPは、BSRに定期的なCandidate-RP-Advertisementメッセージを送信し、アドバタイズされたグループプレフィックスのJoin / PruneまたはRegisterメッセージを受信したときにRPとして機能するように構成されたルーターです。
* { Designated Router (DR)}. The DR sets up multicast route entries and sends corresponding Join/Prune and Register messages on behalf of directly-connected receivers and sources, respectively. The DR may or may not be the same router as the IGMP Querier. The DR may or may not be the long-term, last-hop router for the group; a router on the LAN that has a lower metric route to the data source, or to the group's RP, may take over the role of sending Join/Prune messages.
* {指定ルーター（DR）}。 DRは、マルチキャストルートエントリをセットアップし、対応するJoin / PruneおよびRegisterメッセージを、それぞれ直接接続されたレシーバーおよびソースに代わって送信します。 DRはIGMPクエリアと同じルーターである場合も、そうでない場合もあります。 DRは、グループの長期的な最終ホップルーターである場合とそうでない場合があります。データソースまたはグループのRPへのメトリックルートが低いLAN上のルーターが、Join / Pruneメッセージを送信する役割を引き継ぐ場合があります。
* { Incoming interface (iif)}. The iif of a multicast route entry indicates the interface from which multicast data packets are accepted for forwarding. The iif is initialized when the entry is created.
* {受信インターフェイス（iif）}。マルチキャストルートエントリのiifは、マルチキャストデータパケットが転送のために受け入れられるインターフェイスを示します。 iifは、エントリの作成時に初期化されます。
* Join list. The Join list is one of two lists of addresses that is included in a Join/Prune message; each address refers to a source or RP. It indicates those sources or RPs to which downstream receiver(s) wish to join.
* リストに参加します。 Joinリストは、Join / Pruneメッセージに含まれる2つのアドレスリストの1つです。各アドレスは、送信元またはRPを指します。これは、ダウンストリームレシーバが参加するソースまたはRPを示します。
* { Last-hop router}. The last-hop router is the last router to receive multicast data packets before they are delivered to directly-connected member hosts. In general the last-hop router is the DR for the LAN. However, under various conditions described in this document a parallel router connected to the same LAN may take over as the last-hop router in place of the DR.
* {ラストホップルーター}。ラストホップルーターは、マルチキャストデータパケットが直接接続されたメンバーホストに配信される前に受信する最後のルーターです。一般に、最終ホップルーターはLANのDRです。ただし、このドキュメントで説明されているさまざまな状況では、同じLANに接続されているパラレルルーターが、DRの代わりにラストホップルーターとして機能する場合があります。
* { Outgoing interface (oif) list}. Each multicast route entry has an oif list containing the outgoing interfaces to which multicast packets should be forwarded.
* {発信インターフェース（oif）リスト}。各マルチキャストルートエントリには、マルチキャストパケットの転送先となる発信インターフェイスを含むoifリストがあります。
* Prune List. The Prune list is the second list of addresses that is included in a Join/Prune message. It indicates those sources or RPs from which downstream receiver(s) wish to prune.
* プルーンリスト。プルーンリストは、Join / Pruneメッセージに含まれるアドレスの2番目のリストです。これは、ダウンストリームレシーバがプルーニングしたい送信元またはRPを示します。
* { PIM Multicast Border Router (PMBR)}. A PMBR connects a PIM domain to other multicast routing domain(s).
* {PIMマルチキャストボーダールーター（PMBR）}。 PMBRは、PIMドメインを他のマルチキャストルーティングドメインに接続します。
* { Rendezvous Point (RP)}. Each multicast group has a shared-tree via which receivers hear of new sources and new receivers hear of all sources. The RP is the root of this per-group shared tree, called the RP-Tree.
* {ランデブーポイント（RP）}。各マルチキャストグループには共有ツリーがあり、それを介してレシーバは新しいソースを聞き、新しいレシーバはすべてのソースを聞きます。 RPは、RP-Treeと呼ばれるこのグループごとの共有ツリーのルートです。
* { RP-Set}. The RP-Set is a set of RP addresses constructed by the BSR based on Candidate-RP advertisements received. The RP-Set information is distributed to all PIM routers in the BSR's PIM domain.
* {RPセット}。 RP-Setは、受信したCandidate-RPアドバタイズに基づいてBSRによって構築されたRPアドレスのセットです。 RP-Set情報は、BSRのPIMドメイン内のすべてのPIMルーターに配布されます。
* { Reverse Path Forwarding (RPF)}. RPF is used to select the appropriate incoming interface for a multicast route entry . The RPF neighbor for an address X is the the next-hop router used to forward packets toward X. The RPF interface is the interface to that RPF neighbor. In the common case this is the next hop used by the unicast routing protocol for sending unicast packets toward X. For example, in cases where unicast and multicast routes are not congruent, it can be different.
* {リバースパス転送（RPF）}。 RPFは、マルチキャストルートエントリに適切な着信インターフェイスを選択するために使用されます。アドレスXのRPFネイバーは、パケットをXに転送するために使用されるネクストホップルータです。RPFインターフェイスは、そのRPFネイバーへのインターフェイスです。一般的なケースでは、これは、ユニキャストパケットをXに送信するためにユニキャストルーティングプロトコルで使用されるネクストホップです。たとえば、ユニキャストルートとマルチキャストルートが一致しない場合、異なる可能性があります。
* { Route entry.} A multicast route entry is state maintained in a router along the distribution tree and is created, and updated based on incoming control messages. The route entry may be different from the forwarding entry; the latter is used to forward data packets in real time. Typically a forwarding entry is not created until data packets arrive, the forwarding entry's iif and oif list are copied from the route entry, and the forwarding entry may be flushed and recreated at will.
* {ルートエントリ。}マルチキャストルートエントリは、配布ツリーに沿ってルーターで維持される状態であり、着信制御メッセージに基づいて作成および更新されます。ルートエントリは転送エントリと異なる場合があります。後者は、データパケットをリアルタイムで転送するために使用されます。通常、転送エントリはデータパケットが到着するまで作成されません。転送エントリのiifおよびoifリストはルートエントリからコピーされ、転送エントリは任意にフラッシュおよび再作成できます。
* { Shortest path tree (SPT)}. The SPT is the multicast distribution tree created by the merger of all of the shortest paths that connect receivers to the source (as determined by unicast routing).
* {最短パスツリー（SPT）}。 SPTは、レシーバーをソースに接続するすべての最短パス（ユニキャストルーティングによって決定される）の結合によって作成されるマルチキャスト配信ツリーです。
* { Sparse Mode (SM)}. SM is one mode of operation of a multicast protocol. PIM SM uses explicit Join/Prune messages and Rendezvous points in place of Dense Mode PIM's and DVMRP's broadcast and prune mechanism.
* {希薄モード（SM）}。 SMは、マルチキャストプロトコルの動作モードの1つです。 PIM SMは、Dense Mode PIMおよびDVMRPのブロードキャストおよびプルーニングメカニズムの代わりに、明示的なJoin / PruneメッセージおよびRendezvousポイントを使用します。
* { Wildcard (WC) multicast route entry}. Wildcard multicast route entries are those entries that may be used to forward packets for any source sending to the specified group. Wildcard bots in the join list of a Join/Prune message represent either a (*,G) or (*,*,RP) join; in the prune list they represent a (*,G) prune.
* {ワイルドカード（WC）マルチキャストルートエントリ}。ワイルドカードマルチキャストルートエントリは、指定されたグループに送信する任意のソースのパケットを転送するために使用できるエントリです。 Join / Pruneメッセージの結合リスト内のワイルドカードボットは、（*、G）または（*、*、RP）結合を表します。プルーンリストでは、（*、G）プルーンを表します。
* { (S,G) route entry}. (S,G) is a source-specific route entry. It may be created in response to data packets, Join/Prune messages, or Asserts. The (S,G) state in routers creates a source-rooted, shortest path (or reverse shortest path) distribution tree. (S,G)RPT bit entries are source-specific entries on the shared RP-Tree; these entries are used to prune particular sources off of the shared tree.
* {（S、G）ルートエントリ}。 （S、G）は、ソース固有のルートエントリです。データパケット、Join / Pruneメッセージ、またはAssertsに応答して作成される場合があります。ルーターの（S、G）状態は、ソースをルートとする最短パス（または逆最短パス）の配布ツリーを作成します。 （S、G）RPTビットエントリは、共有RPツリー上のソース固有のエントリです。これらのエントリは、共有ツリーから特定のソースを削除するために使用されます。
* { (*,G) route entry}. Group members join the shared RP-Tree for a particular group. This tree is represented by (*,G) multicast route entries along the shortest path branches between the RP and the group members.
* {（*、G）ルートエントリ}。グループメンバーは、特定のグループの共有RPツリーに参加します。このツリーは、RPとグループメンバー間の最短パスブランチに沿った（*、G）マルチキャストルートエントリで表されます。
* { (*,*,RP) route entry}. (*,*,RP) refers to any source and any multicast group that maps to the RP included in the entry. The routers along the shortest path branches between a domain's RP(s) and its PMBRs keep (*,*,RP) state and use it to determine how to deliver packets toward the PMBRs if data packets arrive for which there is not a longer match. The wildcard group in the (*,*,RP) route entry is represented by a group address of 224.0.0.0 and a mask length of 4 bits.
* {（*、*、RP）ルートエントリ}。 （*、*、RP）は、エントリに含まれるRPにマップされる任意のソースおよびマルチキャストグループを指します。ドメインのRPとそのPMBRの間の最短パスブランチに沿ったルーターは、（*、*、RP）状態を保持し、それを使用して、一致しないデータパケットが到着した場合にPMBRにパケットを配信する方法を決定します。 。 （*、*、RP）ルートエントリのワイルドカードグループは、グループアドレス224.0.0.0およびマスク長4ビットで表されます。
References
参考文献
1. Deering, S., Estrin, D., Farinacci, D., Jacobson, V., Liu, C., Wei, L., Sharma, P., and A. Helmy, "Protocol Independent Multicast (pim): Motivation and Architecture", Work in Progress.
1. Deering、S.、Estrin、D.、Farinacci、D.、Jacobson、V.、Liu、C.、Wei、L.、Sharma、P.、and A. Helmy、 "Protocol Independent Multicast（pim）：Motivation and建築」、進行中の作業。
2. S. Deering, D. Estrin, D. Farinacci, V. Jacobson, C. Liu, and L. Wei. The pim architecture for wide-area multicast routing. ACM Transactions on Networks, April 1996.
2. S.ディアリング、D。エストリン、D。ファリナッチ、V。ヤコブソン、C。リュー、L。ウェイ。広域マルチキャストルーティング用のPIMアーキテクチャ。 ACM Transactions on Networks、1996年4月。
3. Estrin, D., Farinacci, D., Jacobson, V., Liu, C., Wei, L., Sharma, P., and A. Helmy, "Protocol Independent Multicast-dense Mode (pim-dm): Protocol Specification", Work in Progress.
3. Estrin、D.、Farinacci、D.、Jacobson、V.、Liu、C.、Wei、L.、Sharma、P。、およびA. Helmy、「Protocol Independent Multicast-dense Mode（pim-dm）：Protocol Specification "、進行中の作業。
4. Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
4. Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
5. Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
5. Fenner、W。、「インターネットグループ管理プロトコル、バージョン2」、RFC 2236、1997年11月。
6. Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, August 1995.
6. Atkinson、R。、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 1825、1995年8月。
7. Mark R. Nelson. File verification using CRC. Dr. Dobb's Journal, May 1992.
7. マーク・R・ネルソン。 CRCを使用したファイル検証。ドブズジャーナル博士、1992年5月。
8. A.J. Ballardie, P.F. Francis, and J.Crowcroft. Core based trees. In Proceedings of the ACM SIGCOMM, San Francisco, 1993.
8. A.J. Ballardie、P.F.フランシス、そしてJ.クロウクロフト。コアベースのツリー。 ACM SIGCOMMの議事録、サンフランシスコ、1993年。
Authors' Addresses
著者のアドレス
NOTE: The author list has been reordered to reflect the involvement in detailed editorial work on this specification document. The first four authors are the primary editors and are listed alphabetically. The rest of the authors, also listed alphabetically, participated in all aspects of the architectural and detailed design but managed to get away without hacking the latex!
注：著者リストは、この仕様書に関する詳細な編集作業への関与を反映するように並べ替えられています。最初の4人の著者は編集者であり、アルファベット順にリストされています。残りの作者も、アルファベット順にリストされており、建築および詳細設計のすべての側面に参加しましたが、ラテックスをハックすることなくなんとか逃げることができました！
Deborah Estrin Computer Science Dept/ISI University of Southern Calif. Los Angeles, CA 90089
デボラエストリンコンピュータサイエンス部/ ISI南カリフォルニア大学ロサンゼルス、カリフォルニア90089
EMail: estrin@usc.edu
Dino Farinacci Cisco Systems Inc. 170 West Tasman Drive, San Jose, CA 95134
Dino Farinacci Cisco Systems Inc. 170 West Tasman Drive、San Jose、CA 95134
EMail: dino@cisco.com
Ahmed Helmy Computer Science Dept. University of Southern Calif. Los Angeles, CA 90089
南カリフォルニア大学アーメッドヘルミーコンピュータサイエンス学部。ロサンゼルス、カリフォルニア90089
EMail: ahelmy@catarina.usc.edu
David Thaler EECS Department University of Michigan Ann Arbor, MI 48109
デビッドターラーEECS部門ミシガン大学アナーバー、MI 48109
EMail: thalerd@eecs.umich.edu Stephen Deering Xerox PARC 3333 Coyote Hill Road Palo Alto, CA 94304
Eメール：thalerd@eecs.umich.edu Stephen Deering Xerox PARC 3333 Coyote Hill Road Palo Alto、CA 94304
EMail: deering@parc.xerox.com
Mark Handley Department of Computer Science University College London Gower Street London, WC1E 6BT UK
マークハンドラリーコンピューターサイエンスユニバーシティカレッジロンドンGower Streetロンドン、WC1E 6BT英国
EMail: m.handley@cs.ucl.ac.uk
Van Jacobson Lawrence Berkeley Laboratory 1 Cyclotron Road Berkeley, CA 94720
Van Jacobson Lawrence Berkeley Laboratory 1 Cyclotron Road Berkeley、CA 94720
EMail: van@ee.lbl.gov
Ching-gung Liu Computer Science Dept. University of Southern Calif. Los Angeles, CA 90089
Ching-gung Liuコンピューターサイエンス部、南カリフォルニア大学ロサンゼルス、カリフォルニア90089
EMail: charley@catarina.usc.edu
Puneet Sharma Computer Science Dept. University of Southern Calif. Los Angeles, CA 90089
南カリフォルニア大学プネートシャルマコンピュータサイエンス学部。ロサンゼルス、カリフォルニア90089
EMail: puneet@catarina.usc.edu
Liming Wei Cisco Systems Inc. 170 West Tasman Drive, San Jose, CA 95134
Liming Wei Cisco Systems Inc. 170 West Tasman Drive、San Jose、CA 95134
EMail: lwei@cisco.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。