[要約] RFC 7761は、PIM-SMプロトコルの仕様を定めたものであり、マルチキャスト通信の効率的な実現を目指しています。このRFCは、PIM-SMプロトコルの動作やメッセージフォーマットなどの詳細を提供し、ネットワークエンジニアや開発者に役立つ情報を提供します。
Internet Engineering Task Force (IETF) B. Fenner
Request for Comments: 7761 Arista Networks
STD: 83 M. Handley
Obsoletes: 4601 UCL
Category: Standards Track H. Holbrook
ISSN: 2070-1721 I. Kouvelas
Arista Networks
R. Parekh
Cisco Systems, Inc.
Z. Zhang
Juniper Networks
L. Zheng
Huawei Technologies
March 2016
Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)
プロトコル非依存マルチキャスト-スパースモード（PIM-SM）：プロトコル仕様（改訂）
Abstract
概要
This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast-capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and it optionally creates shortest-path trees per source.
このドキュメントでは、プロトコルに依存しないマルチキャスト-スパースモード（PIM-SM）について説明します。 PIM-SMは、基盤となるユニキャストルーティング情報ベースまたは個別のマルチキャスト対応ルーティング情報ベースを使用できるマルチキャストルーティングプロトコルです。グループごとにランデブーポイント（RP）をルートとする単方向共有ツリーを構築し、オプションでソースごとに最短パスツリーを作成します。
This document obsoletes RFC 4601 by replacing it, addresses the errata filed against it, removes the optional (*,*,RP), PIM Multicast Border Router features and authentication using IPsec that lack sufficient deployment experience (see Appendix A), and moves the PIM specification to Internet Standard.
このドキュメントでは、RFC 4601を置き換えて廃止し、提出された正誤表に対処し、オプション（*、*、RP）、PIMマルチキャストボーダールーター機能、および十分な導入経験のないIPsecを使用した認証（付録Aを参照）を削除し、インターネット標準に対するPIM仕様。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7761.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7761で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................5
2. Terminology .....................................................5
2.1. Definitions ................................................5
2.2. Pseudocode Notation ........................................7
3. PIM-SM Protocol Overview ........................................7
3.1. Phase One: RP Tree .........................................8
3.2. Phase Two: Register-Stop ...................................9
3.3. Phase Three: Shortest-Path Tree ...........................10
3.4. Source-Specific Joins .....................................10
3.5. Source-Specific Prunes ....................................11
3.6. Multi-Access Transit LANs .................................11
3.7. RP Discovery ..............................................12
4. Protocol Specification .........................................12
4.1. PIM Protocol State ........................................13
4.1.1. General-Purpose State ..............................14
4.1.2. (*,G) State ........................................15
4.1.3. (S,G) State ........................................17
4.1.4. (S,G,rpt) State ....................................19
4.1.5. State Summarization Macros .........................20
4.2. Data Packet Forwarding Rules ..............................24
4.2.1. Last-Hop Switchover to the SPT .....................27
4.2.2. Setting and Clearing the (S,G) SPTbit ..............27
4.3. Designated Routers (DRs) and Hello Messages ...............29
4.3.1. Sending Hello Messages .............................29
4.3.2. DR Election ........................................31
4.3.3. Reducing Prune Propagation Delay on LANs ...........33
4.3.4. Maintaining Secondary Address Lists ................36
4.4. PIM Register Messages .....................................37
4.4.1. Sending Register Messages from the DR ..............38
4.4.2. Receiving Register Messages at the RP ..............43
4.5. PIM Join/Prune Messages ...................................44
4.5.1. Receiving (*,G) Join/Prune Messages ................45
4.5.2. Receiving (S,G) Join/Prune Messages ................50
4.5.3. Receiving (S,G,rpt) Join/Prune Messages ............54
4.5.4. Sending (*,G) Join/Prune Messages ..................61
4.5.5. Sending (S,G) Join/Prune Messages ..................65
4.5.6. (S,G,rpt) Periodic Messages ........................71
4.5.7. State Machine for (S,G,rpt) Triggered Messages .....72
4.6. PIM Assert Messages .......................................76
4.6.1. (S,G) Assert Message State Machine .................77
4.6.2. (*,G) Assert Message State Machine .................85
4.6.3. Assert Metrics .....................................93
4.6.4. AssertCancel Messages ..............................94
4.6.5. Assert State Macros ................................95
4.7. PIM Bootstrap and RP Discovery ............................98
4.7.1. Group-to-RP Mapping ................................99
4.7.2. Hash Function .....................................100
4.8. Source-Specific Multicast ................................101
4.8.1. Protocol Modifications for SSM Destination
Addresses .........................................102
4.8.2. PIM-SSM-Only Routers ..............................102
4.9. PIM Packet Formats .......................................104
4.9.1. Encoded Source and Group Address Formats ..........105
4.9.2. Hello Message Format ..............................108
4.9.3. Register Message Format ...........................111
4.9.4. Register-Stop Message Format ......................113
4.9.5. Join/Prune Message Format .........................114
4.9.5.1. Group Set Source List Rules ..............117
4.9.5.2. Group Set Fragmentation ..................120
4.9.6. Assert Message Format .............................121
4.10. PIM Timers ..............................................122
4.11. Timer Values ............................................124
5. IANA Considerations ...........................................130
5.1. PIM Address Family .......................................130
5.2. PIM Hello Options ........................................130
6. Security Considerations .......................................131
6.1. Attacks Based on Forged Messages .........................131
6.1.1. Forged Link-Local Messages ........................131
6.1.2. Forged Unicast Messages ...........................132
6.2. Non-cryptographic Authentication Mechanisms ..............132
6.3. Authentication ...........................................133
6.4. Denial-of-Service Attacks ................................133
7. References ....................................................133
7.1. Normative References .....................................133
7.2. Informative References ...................................134
Appendix A. Functionality Removed from RFC 4601 ..................136
Acknowledgements .................................................136
Authors' Addresses ...............................................136
List of Figures (Shown in Tabular Form)
Figure 1. Per-(S,G) Register State Machine at a DR ................39
Figure 2. Downstream Per-Interface (*,G) State Machine ............47
Figure 3. Downstream Per-Interface (S,G) State Machine ............51
Figure 4. Downstream Per-Interface (S,G,rpt) State Machine ........56
Figure 5. Upstream (*,G) State Machine ............................62
Figure 6. Upstream (S,G) State Machine ............................66
Figure 7. Upstream (S,G,rpt) State Machine for Triggered
Messages ................................................72
Figure 8. Per-Interface (S,G) Assert State Machine ................78
Figure 9. Per-interface (*,G) Assert State Machine ................87
This document specifies a protocol for efficiently routing multicast groups that may span wide-area (and inter-domain) internets. This protocol is called Protocol Independent Multicast - Sparse Mode (PIM-SM) because, although it may use the underlying unicast routing to provide reverse-path information for multicast tree building, it is not dependent on any particular unicast routing protocol.
このドキュメントは、広域（およびドメイン間）インターネットにまたがるマルチキャストグループを効率的にルーティングするためのプロトコルを指定します。このプロトコルは、プロトコルに依存しないマルチキャスト-スパースモード（PIM-SM）と呼ばれます。これは、基になるユニキャストルーティングを使用してマルチキャストツリー構築のリバースパス情報を提供する場合がありますが、特定のユニキャストルーティングプロトコルに依存しないためです。
PIM-SM Version 2 was specified in RFC 4601 as a Proposed Standard. This document is intended to address the reported errata and to remove the optional (*,*,RP), PIM Multicast Border Router features and authentication using IPsec that lacks sufficient deployment experience, to advance PIM-SM to Internet Standard.
PIM-SMバージョン2は、RFC 4601で提案された標準として指定されました。このドキュメントは、報告された正誤表に対処し、オプションの（*、*、RP）、PIMマルチキャストボーダールーター機能、および十分な導入経験のないIPsecを使用した認証を削除して、PIM-SMをインターネット標準に進めることを目的としています。
This document specifies the same protocol as RFC 4601, and implementations per the specification in this document will be able to interoperate successfully with implementations per RFC 4601.
このドキュメントでは、RFC 4601と同じプロトコルを指定しています。このドキュメントの仕様に基づく実装は、RFC 4601に基づく実装と正常に相互運用できます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [1]で説明されているように解釈されます。
The following terms have special significance for PIM-SM:
以下の用語は、PIM-SMにとって特別な意味を持っています。
Rendezvous Point (RP) An RP is a router that has been configured to be used as the root of the non-source-specific distribution tree for a multicast group. Join messages from receivers for a group are sent towards the RP, and data from senders is sent to the RP so that receivers can discover who the senders are and start to receive traffic destined for the group.
ランデブーポイント（RP）RPは、マルチキャストグループのソース固有ではない配布ツリーのルートとして使用されるように構成されたルーターです。グループの受信者からの参加メッセージはRPに送信され、送信者からのデータはRPに送信されるため、受信者は送信者が誰であるかを検出し、グループ宛のトラフィックの受信を開始できます。
Designated Router (DR) A shared-media LAN like Ethernet may have multiple PIM-SM routers connected to it. A single one of these routers, the DR, will act on behalf of directly connected hosts with respect to the PIM-SM protocol. A single DR is elected per interface (LAN or otherwise) using a simple election process.
指定ルーター（DR）イーサネットなどの共有メディアLANには、複数のPIM-SMルーターが接続されている場合があります。これらのルーターの1つであるDRは、PIM-SMプロトコルに関して、直接接続されたホストに代わって動作します。シンプルな選定プロセスを使用して、インターフェース（LANまたはその他）ごとに単一のDRが選定されます。
MRIB Multicast Routing Information Base. This is the multicast topology table, which is typically derived from the unicast routing table, or routing protocols such as Multiprotocol BGP (MBGP) that carry multicast-specific topology information. In PIM-SM, the MRIB is used to decide where to send Join/Prune messages. A secondary function of the MRIB is to provide routing metrics for destination addresses; these metrics are used when sending and processing Assert messages.
MRIBマルチキャストルーティング情報ベース。これは、通常、ユニキャストルーティングテーブルから派生するマルチキャストトポロジテーブル、またはマルチキャスト固有のトポロジ情報を伝達するマルチプロトコルBGP（MBGP）などのルーティングプロトコルです。 PIM-SMでは、MRIBを使用して、Join / Pruneメッセージの送信先を決定します。 MRIBの2番目の機能は、宛先アドレスのルーティングメトリックを提供することです。これらのメトリックは、アサートメッセージを送信および処理するときに使用されます。
RPF Neighbor RPF stands for "Reverse Path Forwarding". The RPF Neighbor of a router with respect to an address is the neighbor that the MRIB indicates should be used to forward packets to that address. In the case of a PIM-SM multicast group, the RPF neighbor is the router that a Join message for that group would be directed to, in the absence of modifying Assert state.
RPFネイバーRPFは「Reverse Path Forwarding」の略です。アドレスに関するルーターのRPFネイバーは、パケットをそのアドレスに転送するためにMRIBを使用する必要があることを示すネイバーです。 PIM-SMマルチキャストグループの場合、RPFネイバーは、Assert状態を変更しない場合に、そのグループのJoinメッセージが送信されるルータです。
TIB Tree Information Base. This is the collection of state at a PIM router that has been created by receiving PIM Join/Prune messages, PIM Assert messages, and Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) information from local hosts. It essentially stores the state of all multicast distribution trees at that router.
TIBツリー情報ベース。これは、ローカルホストからPIM Join / Pruneメッセージ、PIMアサートメッセージ、インターネットグループ管理プロトコル（IGMP）またはマルチキャストリスナー探索（MLD）情報を受信することによって作成されたPIMルーターでの状態のコレクションです。基本的には、そのルーターでのすべてのマルチキャスト配布ツリーの状態を格納します。
MFIB Multicast Forwarding Information Base. The TIB holds all the state that is necessary to forward multicast packets at a router. However, although this specification defines forwarding in terms of the TIB, to actually forward packets using the TIB is very inefficient. Instead, a real router implementation will normally build an efficient MFIB from the TIB state to perform forwarding. How this is done is implementation-specific and is not discussed in this document.
MFIBマルチキャスト転送情報ベース。 TIBは、ルーターでマルチキャストパケットを転送するために必要なすべての状態を保持します。ただし、この仕様ではTIBに関して転送を定義していますが、TIBを使用して実際にパケットを転送することは非常に非効率的です。代わりに、実際のルーター実装は通常、TIB状態から効率的なMFIBを構築して転送を実行します。これを行う方法は実装固有であり、このドキュメントでは説明しません。
Upstream Towards the root of the tree. The root of the tree may be either the source or the RP, depending on the context.
上流の木の根に向かって。ツリーのルートは、コンテキストに応じて、ソースまたはRPのいずれかになります。
Downstream Away from the root of the tree.
木の根元から離れた下流。
GenID Generation Identifier, used to detect reboots.
再起動の検出に使用されるGenID生成識別子。
We use set notation in several places in this specification.
この仕様では、いくつかの場所で集合表記法を使用しています。
A (+) B is the union of two sets, A and B.
A（+）Bは、AとBの2つのセットの和集合です。
A (-) B is the elements of set A that are not in set B.
A（-）Bは、セットBにないセットAの要素です。
NULL is the empty set or list.
NULLは空のセットまたはリストです。
In addition, we use C-like syntax:
さらに、Cのような構文を使用します。
= denotes assignment of a variable.
=は変数の代入を示します。
== denotes a comparison for equality.
==は、等しいかどうかの比較を示します。
!= denotes a comparison for inequality.
！=は、不等式の比較を示します。
Braces { and } are used for grouping.
ブレース{および}はグループ化に使用されます。
Unless otherwise noted, operations specified by statements having multiple (+) and (-) operators should be evaluated from left to right, i.e., A (+) B (-) C is the set resulting from union of sets A and B minus elements in set C.
特に明記されていない限り、複数の（+）および（-）演算子を含むステートメントで指定された演算は、左から右に評価する必要があります。セットC
This section provides an overview of PIM-SM behavior. It is intended as an introduction to how PIM-SM works, and it is NOT definitive. For the definitive specification, see Section 4.
このセクションでは、PIM-SMの動作の概要について説明します。これは、PIM-SMがどのように機能するかを紹介することを目的としており、確定的なものではありません。最終的な仕様については、セクション4を参照してください。
PIM relies on an underlying topology-gathering protocol to populate a routing table with routes. This routing table is called the Multicast Routing Information Base (MRIB). The routes in this table may be taken directly from the unicast routing table, or they may be different and provided by a separate routing protocol such as MBGP [10]. Regardless of how it is created, the primary role of the MRIB in the PIM protocol is to provide the next-hop router along a multicast-capable path to each destination subnet. The MRIB is used to determine the next-hop neighbor to which any PIM Join/Prune message is sent. Data flows along the reverse path of the Join messages. Thus, in contrast to the unicast RIB, which specifies the next hop that a data packet would take to get to some subnet, the MRIB gives reverse-path information and indicates the path that a multicast data packet would take from its origin subnet to the router that has the MRIB.
PIMは、基盤となるトポロジー収集プロトコルに依存して、ルーティングテーブルにルートを入力します。このルーティングテーブルは、マルチキャストルーティング情報ベース（MRIB）と呼ばれます。このテーブルのルートは、ユニキャストルーティングテーブルから直接取得することも、MBGPなどの別のルーティングプロトコルによって異なる[10]にすることもできます。作成方法に関係なく、PIMプロトコルにおけるMRIBの主な役割は、各宛先サブネットへのマルチキャスト対応パスに沿ってネクストホップルータを提供することです。 MRIBは、PIM Join / Pruneメッセージが送信されるネクストホップネイバーを決定するために使用されます。データは、Joinメッセージの逆のパスに沿って流れます。したがって、データパケットが一部のサブネットに到達するために使用するネクストホップを指定するユニキャストRIBとは対照的に、MRIBはリバースパス情報を提供し、マルチキャストデータパケットがその元のサブネットからMRIBがあるルータ。
Like all multicast routing protocols that implement the service model from RFC 1112 [3], PIM-SM must be able to route data packets from sources to receivers without either the sources or receivers knowing a priori of the existence of the others. This is essentially done in three phases, although as senders and receivers may come and go at any time, all three phases may occur simultaneously.
RFC 1112 [3]のサービスモデルを実装するすべてのマルチキャストルーティングプロトコルと同様に、PIM-SMは、送信元または受信者のいずれかが他の存在のアプリオリを知らなくても、送信元から受信者にデータパケットをルーティングできる必要があります。これは基本的に3つのフェーズで行われますが、送信側と受信側はいつでも行き来できるため、3つのフェーズすべてが同時に発生する可能性があります。
In phase one, a multicast receiver expresses its interest in receiving traffic destined for a multicast group. Typically, it does this using IGMP [2] or MLD [4], but other mechanisms might also serve this purpose. One of the receiver's local routers is elected as the Designated Router (DR) for that subnet. On receiving the receiver's expression of interest, the DR then sends a PIM Join message towards the RP for that multicast group. This Join message is known as a (*,G) Join because it joins group G for all sources to that group. The (*,G) Join travels hop-by-hop towards the RP for the group, and in each router it passes through, multicast tree state for group G is instantiated. Eventually, the (*,G) Join either reaches the RP or reaches a router that already has (*,G) Join state for that group. When many receivers join the group, their Join messages converge on the RP and form a distribution tree for group G that is rooted at the RP. This is known as the RP Tree (RPT), and is also known as the shared tree because it is shared by all sources sending to that group. Join messages are resent periodically so long as the receiver remains in the group. When all receivers on a leaf-network leave the group, the DR will send a PIM (*,G) Prune message towards the RP for that multicast group. However, if the Prune message is not sent for any reason, the state will eventually time out.
フェーズ1では、マルチキャストレシーバーは、マルチキャストグループ宛てのトラフィックの受信に関心を示します。通常、これはIGMP [2]またはMLD [4]を使用して行われますが、他のメカニズムもこの目的に役立つ場合があります。レシーバーのローカルルーターの1つが、そのサブネットの指定ルーター（DR）として選出されます。 DRは、受信者の関心のある表現を受信すると、そのマルチキャストグループのRPに向けてPIM加入メッセージを送信します。このグループへのすべてのソースのグループGに参加するため、この参加メッセージは（*、G）参加と呼ばれます。 （*、G）Joinは、グループのRPにホップバイホップで移動し、通過する各ルーターで、グループGのマルチキャストツリー状態がインスタンス化されます。最終的に、（*、G）加入はRPに到達するか、そのグループの（*、G）加入状態がすでにあるルーターに到達します。多くの受信者がグループに参加すると、その参加メッセージはRPに収束し、RPをルートとするグループGの配布ツリーを形成します。これはRPツリー（RPT）と呼ばれ、そのグループに送信するすべてのソースによって共有されるため、共有ツリーとも呼ばれます。参加メッセージは、受信者がグループに残っている限り、定期的に再送信されます。リーフネットワーク上のすべてのレシーバーがグループを離れると、DRはそのマルチキャストグループのRPに向けてPIM（*、G）Pruneメッセージを送信します。ただし、何らかの理由でPruneメッセージが送信されない場合、状態は最終的にタイムアウトになります。
A multicast data sender just starts sending data destined for a multicast group. The sender's local router (DR) takes those data packets, unicast-encapsulates them, and sends them directly to the RP. The RP receives these encapsulated data packets, decapsulates them, and forwards them onto the shared tree. The packets then follow the (*,G) multicast tree state in the routers on the RP Tree, being replicated wherever the RP Tree branches, and eventually reaching all the receivers for that multicast group. The process of encapsulating data packets to the RP is called registering, and the encapsulation packets are known as PIM Register packets.
マルチキャストデータセンダーは、マルチキャストグループ宛てのデータの送信を開始するだけです。送信側のローカルルーター（DR）は、これらのデータパケットを受け取り、それらをユニキャストカプセル化して、直接RPに送信します。 RPはこれらのカプセル化されたデータパケットを受信し、カプセル化を解除して、共有ツリーに転送します。次に、パケットはRPツリー上のルーターの（*、G）マルチキャストツリーステートに従い、RPツリーが分岐するところに複製され、最終的にそのマルチキャストグループのすべてのレシーバーに到達します。データパケットをRPにカプセル化するプロセスは登録と呼ばれ、カプセル化パケットはPIM Registerパケットと呼ばれます。
At the end of phase one, multicast traffic is flowing encapsulated to the RP, and then natively over the RP tree to the multicast receivers.
フェーズ1の終わりに、マルチキャストトラフィックはRPにカプセル化されて流れ、RPツリーを介してネイティブにマルチキャストレシーバーに流れます。
Register-encapsulation of data packets is inefficient for two reasons:
データパケットのレジスタカプセル化は、次の2つの理由で非効率的です。
o Encapsulation and decapsulation may be relatively expensive operations for a router to perform, depending on whether or not the router has appropriate hardware for these tasks.
o カプセル化とカプセル解放は、ルーターがこれらのタスクに適切なハードウェアを備えているかどうかによって、ルーターの実行に比較的コストのかかる操作になる場合があります。
o Traveling all the way to the RP, and then back down the shared tree may result in the packets traveling a relatively long distance to reach receivers that are close to the sender. For some applications, this increased latency or bandwidth consumption is undesirable.
o RPまで移動してから、共有ツリーを下に戻ると、パケットが比較的長い距離を移動して、送信者に近い受信者に到達することがあります。一部のアプリケーションでは、この遅延または帯域幅の消費の増加は望ましくありません。
Although Register-encapsulation may continue indefinitely, for these reasons, the RP will normally choose to switch to native forwarding. To do this, when the RP receives a register-encapsulated data packet from source S on group G, it will normally initiate an (S,G) source-specific Join towards S. This Join message travels hop-by-hop towards S, instantiating (S,G) multicast tree state in the routers along the path. (S,G) multicast tree state is used only to forward packets for group G if those packets come from source S. Eventually the Join message reaches S's subnet or a router that already has (S,G) multicast tree state, and then packets from S start to flow following the (S,G) tree state towards the RP. These data packets may also reach routers with (*,G) state along the path towards the RP; if they do, they can shortcut onto the RP tree at this point.
レジスタカプセル化は無期限に継続する場合がありますが、これらの理由により、RPは通常、ネイティブ転送に切り替えることを選択します。これを行うには、RPがグループGのソースSからレジスタカプセル化データパケットを受信すると、通常、Sに向けて（S、G）ソース固有のJoinを開始します。このJoinメッセージはSに向けてホップバイホップで移動します。パスに沿ったルーターで（S、G）マルチキャストツリーの状態をインスタンス化します。 （S、G）マルチキャストツリーステートは、それらのパケットがソースSから送信された場合、グループGのパケットを転送するためにのみ使用されます。最終的に、JoinメッセージはSのサブネットまたは（S、G）マルチキャストツリーステートを持つルーターに到達し、その後パケットSから（S、G）ツリー状態に従ってRPに向かってフローが開始します。これらのデータパケットは、RPへのパスに沿って（*、G）状態のルーターに到達することもあります。その場合、この時点でRPツリーにショートカットできます。
While the RP is in the process of joining the source-specific tree for S, the data packets will continue being encapsulated to the RP. When packets from S also start to arrive natively at the RP, the RP will be receiving two copies of each of these packets. At this point, the RP starts to discard the encapsulated copy of these packets, and it sends a Register-Stop message back to S's DR to prevent the DR from unnecessarily encapsulating the packets.
RPがSの送信元固有のツリーに参加している間、データパケットは引き続きRPにカプセル化されます。 SからのパケットもRPにネイティブに到着し始めると、RPはこれらの各パケットの2つのコピーを受信します。この時点で、RPはこれらのパケットのカプセル化されたコピーの破棄を開始し、DRが不必要にパケットをカプセル化しないように、Register-StopメッセージをSのDRに送り返します。
At the end of phase two, traffic will be flowing natively from S along a source-specific tree to the RP, and from there along the shared tree to the receivers. Where the two trees intersect, traffic may transfer from the source-specific tree to the RP tree and thus avoid taking a long detour via the RP.
フェーズ2の終わりに、トラフィックはSから送信元固有のツリーに沿ってネイティブに流れ、そこから共有ツリーに沿ってレシーバーに流れます。 2つのツリーが交差している場合、トラフィックは送信元固有のツリーからRPツリーに転送される可能性があるため、RPを経由して長い迂回が行われるのを回避できます。
Note that a sender may start sending before or after a receiver joins the group, and thus phase two may happen before the shared tree to the receiver is built.
送信者は受信者がグループに参加する前または後に送信を開始する可能性があるため、受信者への共有ツリーが構築される前にフェーズ2が発生する可能性があることに注意してください。
Although having the RP join back towards the source removes the encapsulation overhead, it does not completely optimize the forwarding paths. For many receivers, the route via the RP may involve a significant detour when compared with the shortest path from the source to the receiver.
RPをソースに向けて結合させると、カプセル化のオーバーヘッドはなくなりますが、転送パスが完全に最適化されるわけではありません。多くのレシーバーの場合、RP経由のルートは、ソースからレシーバーへの最短パスと比較すると、かなりの迂回を伴う場合があります。
To obtain lower latencies or more efficient bandwidth utilization, a router on the receiver's LAN, typically the DR, may optionally initiate a transfer from the shared tree to a source-specific shortest-path tree (SPT). To do this, it issues an (S,G) Join towards S. This instantiates state in the routers along the path to S. Eventually, this join either reaches S's subnet or reaches a router that already has (S,G) state. When this happens, data packets from S start to flow following the (S,G) state until they reach the receiver.
より低いレイテンシまたはより効率的な帯域幅使用率を取得するために、レシーバーのLAN上のルーター（通常はDR）は、オプションで共有ツリーからソース固有の最短パスツリー（SPT）への転送を開始できます。これを行うには、Sに向けて（S、G）結合を発行します。これにより、Sへのパスに沿ってルーターの状態がインスタンス化されます。最終的に、この結合はSのサブネットに到達するか、既に（S、G）状態のルーターに到達します。これが発生すると、Sからのデータパケットは、（S、G）ステートに従ってフローし始め、レシーバーに到達します。
At this point, the receiver (or a router upstream of the receiver) will be receiving two copies of the data: one from the SPT and one from the RPT. When the first traffic starts to arrive from the SPT, the DR or upstream router starts to drop the packets for G from S that arrive via the RP tree. In addition, it sends an (S,G) Prune message towards the RP. This is known as an (S,G,rpt) Prune. The Prune message travels hop-by-hop, instantiating state along the path towards the RP indicating that traffic from S for G should NOT be forwarded in this direction. The prune is propagated until it reaches the RP or a router that still needs the traffic from S for other receivers.
この時点で、レシーバー（またはレシーバーの上流のルーター）はデータの2つのコピーを受信します。1つはSPTから、もう1つはRPTからです。最初のトラフィックがSPTから到着し始めると、DRまたは上流ルーターは、RPツリーを介して到着するSからのGのパケットのドロップを開始します。さらに、RPに向けて（S、G）Pruneメッセージを送信します。これは（S、G、rpt）プルーンとして知られています。 Pruneメッセージはホップバイホップで移動し、パスに沿って状態をインスタンス化してRPに向かい、SからGへのトラフィックがこの方向に転送されないことを示します。プルーンは、RPに到達するか、他のレシーバーのSからのトラフィックを必要とするルータに到達するまで伝播されます。
By now, the receiver will be receiving traffic from S along the shortest-path tree between the receiver and S. In addition, the RP is receiving the traffic from S, but this traffic is no longer reaching the receiver along the RP tree. As far as the receiver is concerned, this is the final distribution tree.
これで、レシーバーはSからのトラフィックを、レシーバーとSの間の最短パスツリーに沿って受信します。さらに、RPはSからトラフィックを受信していますが、このトラフィックはRPツリーに沿ってレシーバーに到達していません。受信者に関する限り、これは最終的な配布ツリーです。
IGMPv3 permits a receiver to join a group and specify that it only wants to receive traffic for a group if that traffic comes from a particular source. If a receiver does this, and no other receiver on the LAN requires all the traffic for the group, then the DR may omit performing a (*,G) join to set up the shared tree, and instead issue a source-specific (S,G) join only.
IGMPv3は、受信者がグループに参加することを許可し、そのトラフィックが特定のソースからのものである場合にのみ、グループのトラフィックを受信することを指定します。レシーバーがこれを行い、LAN上の他のレシーバーがグループのすべてのトラフィックを必要としない場合、DRは（*、G）結合の実行を省略して共有ツリーを設定し、代わりにソース固有の（S 、G）参加のみ。
The range of multicast addresses from 232.0.0.0 to 232.255.255.255 is currently set aside for source-specific multicast in IPv4. For groups in this range, receivers should only issue source-specific IGMPv3 joins. If a PIM router receives a non-source-specific join for a group in this range, it should ignore it.
232.0.0.0から232.255.255.255までのマルチキャストアドレスの範囲は、現在IPv4のソース固有のマルチキャスト用に確保されています。この範囲のグループの場合、受信者はソース固有のIGMPv3結合のみを発行する必要があります。 PIMルーターがこの範囲のグループのソース固有でない結合を受信した場合、それは無視する必要があります。
IGMPv3 also permits a receiver to join a group and to specify that it only wants to receive traffic for a group if that traffic does not come from a specific source or sources. In this case, the DR will perform a (*,G) join as normal, but may combine this with an (S,G,rpt) prune for each of the sources the receiver does not wish to receive.
IGMPv3では、受信者がグループに参加し、特定の1つまたは複数の送信元からのトラフィックでない場合にのみ、グループのトラフィックを受信することを指定することもできます。この場合、DRは通常どおり（*、G）結合を実行しますが、これを（S、G、rpt）プルーンと組み合わせて、受信側が受信したくないソースごとに削除することができます。
The overview so far has concerned itself with point-to-point transit links. However, using multi-access LANs such as Ethernet for transit is not uncommon. This can cause complications for three reasons:
これまでの概要は、ポイントツーポイントのトランジットリンクに関係しています。ただし、トランジットにイーサネットなどのマルチアクセスLANを使用することは珍しくありません。これは3つの理由で複雑化を引き起こす可能性があります。
o Two or more routers on the LAN may issue (*,G) Joins to different upstream routers on the LAN because they have inconsistent MRIB entries regarding how to reach the RP. Both paths on the RP tree will be set up, causing two copies of all the shared tree traffic to appear on the LAN.
o LAN上の2つ以上のルーターは、RPへの到達方法に関して一貫性のないMRIBエントリを持っているため、LAN上の異なる上流ルーターへの（*、G）結合を発行する場合があります。 RPツリーの両方のパスが設定され、すべての共有ツリートラフィックの2つのコピーがLANに表示されます。
o Two or more routers on the LAN may issue (S,G) Joins to different upstream routers on the LAN because they have inconsistent MRIB entries regarding how to reach source S. Both paths on the source-specific tree will be set up, causing two copies of all the traffic from S to appear on the LAN.
o LAN上の2つ以上のルーターが、ソースSに到達する方法に関して一貫性のないMRIBエントリを持っているため、LAN上の異なるアップストリームルーターへの（S、G）Joinを発行する場合があります。ソース固有のツリーに両方のパスが設定され、2つのSからのすべてのトラフィックのコピーがLANに表示されます。
o A router on the LAN may issue a (*,G) Join to one upstream router on the LAN, and another router on the LAN may issue an (S,G) Join to a different upstream router on the same LAN. Traffic from S may reach the LAN over both the RPT and the SPT. If the receiver behind the downstream (*,G) router doesn't issue an (S,G,rpt) prune, then this condition would persist.
o LAN上のルーターは、LAN上の1つの上流ルーターに（*、G）Joinを発行し、LAN上の別のルーターは、同じLAN上の別の上流ルーターに（S、G）Joinを発行する場合があります。 Sからのトラフィックは、RPTとSPTの両方を介してLANに到達します。ダウンストリーム（*、G）ルーターの背後にあるレシーバーが（S、G、rpt）プルーンを発行しない場合、この状態が持続します。
All of these problems are caused by there being more than one upstream router with join state for the group or source-group pair. PIM does not prevent such duplicate joins from occurring; instead, when duplicate data packets appear on the LAN from different routers, these routers notice this and then elect a single forwarder. This election is performed using PIM Assert messages, which resolve the problem in favor of the upstream router that has (S,G) state; or, if neither router or both routers have (S,G) state, then the problem is resolved in favor of the router with the best metric to the RP for RP trees, or the best metric to the source for source-specific trees.
これらの問題はすべて、グループまたはソースグループペアの参加状態を持つアップストリームルータが複数あることが原因です。 PIMは、このような重複した結合の発生を防止しません。代わりに、異なるルーターからLANに重複したデータパケットが現れると、これらのルーターはこれに気づき、単一のフォワーダーを選びます。この選択は、PIMアサートメッセージを使用して実行されます。これにより、（S、G）状態のアップストリームルータを優先して問題が解決されます。または、どちらのルーターも両方のルーターが（S、G）状態でない場合は、RPツリーのRPに最適なメトリック、またはソース固有のツリーのソースに最適なメトリックを持つルーターを優先することで問題が解決されます。
These Assert messages are also received by the downstream routers on the LAN, and these cause subsequent Join messages to be sent to the upstream router that won the Assert.
これらのAssertメッセージは、LAN上のダウンストリームルーターでも受信されます。これにより、後続のJoinメッセージが、Assertを獲得したアップストリームルーターに送信されます。
PIM-SM routers need to know the address of the RP for each group for which they have (*,G) state. This address is obtained automatically (e.g., embedded-RP), through a bootstrap mechanism, or through static configuration.
PIM-SMルーターは、（*、G）状態の各グループのRPのアドレスを知る必要があります。このアドレスは、ブートストラップメカニズムを通じて、または静的構成を通じて、自動的に（たとえば、組み込みRP）取得されます。
One dynamic way to do this is to use the Bootstrap Router (BSR) mechanism [11]. One router in each PIM domain is elected the BSR through a simple election process. All the routers in the domain that are configured to be candidates to be RPs periodically unicast their candidacy to the BSR. From the candidates, the BSR picks an RP-set, and periodically announces this set in a Bootstrap message. Bootstrap messages are flooded hop-by-hop throughout the domain until all routers in the domain know the RP-Set.
これを行う1つの動的な方法は、ブートストラップルーター（BSR）メカニズムを使用することです[11]。各PIMドメイン内の1つのルーターは、単純な選定プロセスによりBSRに選定されます。 RPの候補になるように構成されたドメイン内のすべてのルーターは、その候補をBSRに定期的にユニキャストします。 BSRは候補からRPセットを選択し、このセットを定期的にブートストラップメッセージで通知します。ドメイン内のすべてのルーターがRP-Setを認識するまで、ブートストラップメッセージはドメイン全体にホップバイホップでフラッディングされます。
To map a group to an RP, a router hashes the group address into the RP-set using an order-preserving hash function (one that minimizes changes if the RP-Set changes). The resulting RP is the one that it uses as the RP for that group.
グループをRPにマッピングするために、ルーターは順序を維持するハッシュ関数（RP-Setが変更された場合の変更を最小限に抑える関数）を使用して、グループアドレスをRP-setにハッシュします。結果のRPは、そのグループのRPとして使用するものです。
The specification of PIM-SM is broken into several parts:
PIM-SMの仕様は、いくつかの部分に分かれています。
o Section 4.1 details the protocol state stored.
o セクション4.1では、保存されているプロトコルの状態について詳しく説明しています。
o Section 4.2 specifies the data packet forwarding rules.
o セクション4.2は、データパケット転送ルールを指定します。
o Section 4.3 specifies Designated Router (DR) election and the rules for sending and processing Hello messages.
o セクション4.3は、指定ルーター（DR）の選択と、Helloメッセージの送信および処理のルールを指定しています。
o Section 4.4 specifies the PIM Register generation and processing rules.
o セクション4.4は、PIMレジスタの生成および処理規則を指定します。
o Section 4.5 specifies the PIM Join/Prune generation and processing rules.
o セクション4.5は、PIMのJoin / Pruneの生成と処理のルールを規定しています。
o Section 4.6 specifies the PIM Assert generation and processing rules.
o セクション4.6は、PIMアサートの生成および処理ルールを指定します。
o Section 4.7 specifies the RP discovery mechanisms.
o セクション4.7では、RP検出メカニズムを指定しています。
o Section 4.8 describes PIM-SSM, the subset of PIM required to support Source-Specific Multicast.
o セクション4.8では、ソース固有のマルチキャストをサポートするために必要なPIMのサブセットであるPIM-SSMについて説明します。
o Section 4.9 specifies the PIM packet formats.
o セクション4.9では、PIMパケット形式を指定しています。
o Section 4.10 provides a summary of PIM-SM timers, and Section 4.11 provides their default values.
o セクション4.10はPIM-SMタイマーの要約を提供し、セクション4.11はそれらのデフォルト値を提供します。
This section specifies all the protocol state that a PIM implementation should maintain in order to function correctly. We term this state the Tree Information Base (TIB), as it holds the state of all the multicast distribution trees at this router. In this specification, we define PIM mechanisms in terms of the TIB. However, only a very simple implementation would actually implement packet forwarding operations in terms of this state. Most implementations will use this state to build a multicast forwarding table, which would then be updated when the relevant state in the TIB changes.
このセクションでは、PIM実装が正しく機能するために維持する必要があるすべてのプロトコル状態を指定します。このルータでのすべてのマルチキャスト配信ツリーの状態を保持するため、これをツリー情報ベース（TIB）と呼びます。この仕様では、TIBの観点からPIMメカニズムを定義します。ただし、非常に単純な実装のみが、この状態に関してパケット転送操作を実際に実装します。ほとんどの実装では、この状態を使用してマルチキャスト転送テーブルを作成します。このテーブルは、TIBの関連する状態が変化すると更新されます。
Although we specify precisely the state to be kept, this does not mean that an implementation of PIM-SM needs to hold the state in this form. This is actually an abstract state definition, which is needed in order to specify the router's behavior. A PIM-SM implementation is free to hold whatever internal state it requires and will still be conformant with this specification so long as it results in the same externally visible protocol behavior as an abstract router that holds the following state.
保持する状態を正確に指定しますが、これは、PIM-SMの実装がこの形式で状態を保持する必要があることを意味しません。これは実際には抽象的な状態定義であり、ルーターの動作を指定するために必要です。 PIM-SM実装は、必要な内部状態を自由に保持でき、次の状態を保持する抽象ルーターと同じ外部から見えるプロトコル動作が発生する限り、この仕様に準拠します。
We divide TIB state into three sections:
TIB状態を3つのセクションに分割します。
(*,G) state State that maintains the RP tree for G.
（*、G）状態GのRPツリーを維持する状態。
(S,G) state State that maintains a source-specific tree for source S and group G.
（S、G）状態ソースSおよびグループGのソース固有のツリーを維持する状態。
(S,G,rpt) state State that maintains source-specific information about source S on the RP tree for G. For example, if a source is being received on the source-specific tree, it will normally have been pruned off the RP tree. This prune state is (S,G,rpt) state.
（S、G、rpt）状態GのRPツリーでソースSに関するソース固有の情報を保持する状態。たとえば、ソースがソース固有のツリーで受信されている場合、通常はRPから削除されます。木。このプルーン状態は（S、G、rpt）状態です。
The state that should be kept is described below. Of course, implementations will only maintain state when it is relevant to forwarding operations; for example, the "NoInfo" state might be assumed from the lack of other state information rather than being held explicitly.
保持すべき状態を以下に示します。もちろん、実装は転送操作に関連する場合にのみ状態を維持します。たとえば、 "NoInfo"状態は、明示的に保持されるのではなく、他の状態情報がないためと想定される場合があります。
A router holds the following non-group-specific state:
ルータは、次の非グループ固有の状態を保持しています。
For each interface:
各インターフェースについて：
o Effective Override Interval
o 有効なオーバーライド間隔
o Effective Propagation Delay
o 効果的な伝播遅延
o Suppression state: One of {"Enable", "Disable"}
o 抑制状態：{"有効"、 "無効"}のいずれか
Neighbor State:
ネイバーステート：
For each neighbor:
各ネイバーについて：
o Information from neighbor's Hello
o 隣人のハローからの情報
o Neighbor's GenID.
o ネイバーのGenID。
o Neighbor Liveness Timer (NLT)
o ネイバー活性タイマー（NLT）
Designated Router (DR) State:
指定ルーター（DR）の状態：
o Designated Router's IP Address
o 指定ルーターのIPアドレス
o DR's DR Priority
o DRのDR優先度
The Effective Override Interval, the Effective Propagation Delay, and the Interface suppression state are described in Section 4.3.3. Designated Router state is described in Section 4.3.
有効オーバーライド間隔、有効伝播遅延、およびインターフェース抑制状態については、セクション4.3.3で説明します。指定ルーターの状態については、セクション4.3で説明します。
For every group G, a router keeps the following state:
すべてのグループGについて、ルーターは次の状態を維持します。
(*,G) state: For each interface:
（*、G）状態：各インターフェースについて：
Local Membership:
State: One of {"NoInfo", "Include"}
PIM (*,G) Join/Prune State:
PIM（*、G）結合/プルーニング状態：
o State: One of {"NoInfo" (NI), "Join" (J), "Prune-Pending" (PP)}
o 状態：{"NoInfo"（NI）、 "Join"（J）、 "Prune-Pending"（PP）}のいずれか
o Prune-Pending Timer (PPT)
o プルーンペンディングタイマー（PPT）
o Join/Prune Expiry Timer (ET)
o 加入/プルーニング有効期限タイマー（ET）
(*,G) Assert Winner State
（*、G）勝者の状態をアサート
o State: One of {"NoInfo" (NI), "I lost Assert" (L), "I won Assert" (W)}
o 状態：{"NoInfo"（NI）、 "I lost Assert"（L）、 "I won Assert"（W）}のいずれか
o Assert Timer (AT)
o アサートタイマー（AT）
o Assert winner's IP Address (AssertWinner)
o 勝者のIPアドレスをアサートする（AssertWinner）
o Assert winner's Assert Metric (AssertWinnerMetric)
o 勝者のアサートメトリックのアサート（AssertWinnerMetric）
Not interface specific:
インターフェース固有ではありません：
Upstream (*,G) Join/Prune State:
アップストリーム（*、G）結合/プルーニング状態：
o State: One of {"NotJoined(*,G)", "Joined(*,G)"}
o 状態：{"NotJoined（*、G）"、 "Joined（*、G）"}のいずれか
o Upstream Join/Prune Timer (JT)
o アップストリームジョイン/プルーンタイマー（JT）
o Last RP Used
o 最後に使用されたRP
o Last RPF Neighbor towards RP that was used
o 使用されたRPに対する最後のRPFネイバー
Local membership is the result of the local membership mechanism (such as IGMP or MLD) running on that interface. It need not be kept if this router is not the DR on that interface unless this router won a (*,G) assert on this interface for this group, although implementations may optionally keep this state in case they become the DR or assert winner. It is RECOMMENDED to store this information if possible, as it reduces latency converging to stable operating conditions after a failure causing a change of DR. This information is used by the pim_include(*,G) macro described in Section 4.1.5.
ローカルメンバーシップは、そのインターフェイスで実行されているローカルメンバーシップメカニズム（IGMPやMLDなど）の結果です。このルーターがこのグループのこのインターフェイスで（*、G）アサートを獲得しない限り、このルーターがそのインターフェイスのDRでない場合は、維持する必要はありませんが、実装がDRまたはアサートの勝者になる場合に備えて、この状態を維持することができます。障害がDRの変更を引き起こした後、安定した動作条件に収束するまでの待ち時間が短縮されるため、可能であればこの情報を保存することをお勧めします。この情報は、セクション4.1.5で説明されているpim_include（*、G）マクロによって使用されます。
PIM (*,G) Join/Prune state is the result of receiving PIM (*,G) Join/Prune messages on this interface and is specified in Section 4.5.1. The state is used by the macros that calculate the outgoing interface list in Section 4.1.5, and in the JoinDesired(*,G) macro (defined in Section 4.5.4) that is used in deciding whether a Join(*,G) should be sent upstream.
PIM（*、G）Join / Prune状態は、このインターフェースでPIM（*、G）Join / Pruneメッセージを受信した結果であり、セクション4.5.1で指定されています。状態は、セクション4.1.5の発信インターフェースリストを計算するマクロと、Join（*、G）かどうかの決定に使用されるJoinDesired（*、G）マクロ（セクション4.5.4で定義）で使用されます。アップストリームに送信する必要があります。
(*,G) Assert Winner state is the result of sending or receiving (*,G) Assert messages on this interface. It is specified in Section 4.6.2.
（*、G）アサート勝者の状態は、このインターフェースで（*、G）アサートメッセージを送信または受信した結果です。セクション4.6.2で指定されています。
The upstream (*,G) Join/Prune State reflects the state of the upstream (*,G) state machine described in Section 4.5.4.
アップストリーム（*、G）のJoin / Prune状態は、セクション4.5.4で説明されているアップストリーム（*、G）の状態マシンの状態を反映しています。
The upstream (*,G) Join/Prune Timer is used to send out periodic Join(*,G) messages, and to override Prune(*,G) messages from peers on an upstream LAN interface.
アップストリーム（*、G）のJoin / Pruneタイマーは、定期的なJoin（*、G）メッセージを送信し、アップストリームLANインターフェイス上のピアからのPrune（*、G）メッセージを上書きするために使用されます。
The last RP used must be stored because if the RP changes, then state must be torn down and rebuilt for groups whose RP changes.
RPが変更された場合は、RPが変更されたグループ用に状態を破棄して再構築する必要があるため、最後に使用されたRPを保存する必要があります。
The last RPF neighbor towards the RP is stored because if the MRIB changes, then the RPF neighbor towards the RP may change. If it does so, then we need to trigger a new Join(*,G) to the new upstream neighbor and a Prune(*,G) to the old upstream neighbor. Similarly, if a router detects through a changed GenID in a Hello message that the upstream neighbor towards the RP has rebooted, then it SHOULD re-instantiate state by sending a Join(*,G). These mechanisms are specified in Section 4.5.4.
RPへの最後のRPFネイバーは保存されます。これは、MRIBが変更されると、RPへのRPFネイバーが変更される可能性があるためです。その場合は、新しい上流のネイバーに新しいJoin（*、G）をトリガーし、古い上流のネイバーにPrune（*、G）をトリガーする必要があります。同様に、ルーターがHelloメッセージの変更されたGenIDを介して、RPへの上流のネイバーがリブートしたことを検出した場合、Join（*、G）を送信して状態を再インスタンス化する必要があります（SHOULD）。これらのメカニズムは、セクション4.5.4で指定されています。
For every source/group pair (S,G), a router keeps the following state:
すべてのソース/グループペア（S、G）について、ルーターは次の状態を維持します。
(S,G) state:
（S、G）状態：
For each interface:
各インターフェースについて：
Local Membership:
State: One of {"NoInfo", "Include"}
PIM (S,G) Join/Prune State:
PIM（S、G）加入/プルーニング状態：
o State: One of {"NoInfo" (NI), "Join" (J), "Prune-Pending" (PP)}
o 状態：{"NoInfo"（NI）、 "Join"（J）、 "Prune-Pending"（PP）}のいずれか
o Prune-Pending Timer (PPT)
o プルーンペンディングタイマー（PPT）
o Join/Prune Expiry Timer (ET)
o 加入/プルーニング有効期限タイマー（ET）
(S,G) Assert Winner State
（S、G）勝者の状態をアサート
o State: One of {"NoInfo" (NI), "I lost Assert" (L), "I won Assert" (W)}
o 状態：{"NoInfo"（NI）、 "I lost Assert"（L）、 "I won Assert"（W）}のいずれか
o Assert Timer (AT)
o アサートタイマー（AT）
o Assert winner's IP Address (AssertWinner)
o 勝者のIPアドレスをアサートする（AssertWinner）
o Assert winner's Assert Metric (AssertWinnerMetric)
o 勝者のアサートメトリックのアサート（AssertWinnerMetric）
Not interface specific:
インターフェース固有ではありません：
Upstream (S,G) Join/Prune State:
アップストリーム（S、G）結合/プルーニング状態：
o State: One of {"NotJoined(S,G)", "Joined(S,G)"}
o 状態：{"NotJoined（S、G）"、 "Joined（S、G）"}のいずれか
o Upstream (S,G) Join/Prune Timer (JT)
o アップストリーム（S、G）結合/プルーニングタイマー（JT）
o Last RPF Neighbor towards S that was used
o 使用されたSへの最後のRPFネイバー
o SPTbit (indicates (S,G) state is active)
o SPTbit（（S、G）状態がアクティブであることを示します）
o (S,G) Keepalive Timer (KAT) Additional (S,G) state at the DR:
o（S、G）DRでのキープアライブタイマー（KAT）追加（S、G）状態：
o Register state: One of {"Join" (J), "Prune" (P), "Join-Pending" (JP), "NoInfo" (NI)}
o 登録状態：{"Join"（J）、 "Prune"（P）、 "Join-Pending"（JP）、 "NoInfo"（NI）}のいずれか
o Register-Stop Timer (RST)
o レジスターストップタイマー（RST）
Local membership is the result of the local source-specific membership mechanism (such as IGMP Version 3) running on that interface and specifying that this particular source should be included. As stored here, this state is the resulting state after any IGMPv3 inconsistencies have been resolved. It need not be kept if this router is not the DR on that interface unless this router won an (S,G) assert on this interface for this group. However, it is RECOMMENDED to store this information if possible, as it reduces latency converging to stable operating conditions after a failure causing a change of DR. This information is used by the pim_include(S,G) macro described in Section 4.1.5.
ローカルメンバーシップは、そのインターフェイスで実行され、この特定のソースを含める必要があることを指定する、ローカルソース固有のメンバーシップメカニズム（IGMPバージョン3など）の結果です。ここに格納されているように、この状態は、IGMPv3の不整合が解決された後の結果の状態です。このルーターがこのグループのこのインターフェースで（S、G）アサートを獲得しない限り、このルーターがそのインターフェースのDRでない場合は保持する必要はありません。ただし、DRの変更を引き起こした障害の後で安定した動作条件に収束するまでの待ち時間が短縮されるため、可能であればこの情報を保存することをお勧めします。この情報は、セクション4.1.5で説明されているpim_include（S、G）マクロによって使用されます。
PIM (S,G) Join/Prune state is the result of receiving PIM (S,G) Join/Prune messages on this interface and is specified in Section 4.5.2. The state is used by the macros that calculate the outgoing interface list in Section 4.1.5, and in the JoinDesired(S,G) macro (defined in Section 4.5.5) that is used in deciding whether a Join(S,G) should be sent upstream.
PIM（S、G）Join / Prune状態は、このインターフェースでPIM（S、G）Join / Pruneメッセージを受信した結果であり、セクション4.5.2で指定されています。状態は、セクション4.1.5の発信インターフェースリストを計算するマクロと、Join（S、G）かどうかの決定に使用されるJoinDesired（S、G）マクロ（セクション4.5.5で定義）で使用されます。アップストリームに送信する必要があります。
(S,G) Assert Winner state is the result of sending or receiving (S,G) Assert messages on this interface. It is specified in Section 4.6.1.
（S、G）アサート勝者の状態は、このインターフェースで（S、G）アサートメッセージを送信または受信した結果です。セクション4.6.1で指定されています。
The upstream (S,G) Join/Prune State reflects the state of the upstream (S,G) state machine described in Section 4.5.5.
アップストリーム（S、G）のJoin / Prune Stateは、セクション4.5.5で説明されているアップストリーム（S、G）ステートマシンの状態を反映しています。
The upstream (S,G) Join/Prune Timer is used to send out periodic Join(S,G) messages, and to override Prune(S,G) messages from peers on an upstream LAN interface.
アップストリーム（S、G）のJoin / Pruneタイマーは、定期的なJoin（S、G）メッセージを送信し、アップストリームLANインターフェイス上のピアからのPrune（S、G）メッセージを上書きするために使用されます。
The last RPF neighbor towards S is stored because if the MRIB changes, then the RPF neighbor towards S may change. If it does so, then we need to trigger a new Join(S,G) to the new upstream neighbor and a Prune(S,G) to the old upstream neighbor. Similarly, if the router detects through a changed GenID in a Hello message that the upstream neighbor towards S has rebooted, then it SHOULD re-instantiate state by sending a Join(S,G). These mechanisms are specified in Section 4.5.5.
Sへの最後のRPFネイバーは保存されます。これは、MRIBが変更されると、SへのRPFネイバーが変更される可能性があるためです。その場合は、新しいアップストリームネイバーに新しいJoin（S、G）をトリガーし、古いアップストリームネイバーにPrune（S、G）をトリガーする必要があります。同様に、ルータがHelloメッセージ内の変更されたGenIDを介して、Sへのアップストリームネイバーがリブートしたことを検出した場合、Join（S、G）を送信して状態を再インスタンス化する必要があります（SHOULD）。これらのメカニズムは、セクション4.5.5で指定されています。
The SPTbit is used to indicate whether forwarding is taking place on the (S,G) Shortest Path Tree (SPT) or on the (*,G) tree. A router can have (S,G) state and still be forwarding on (*,G) state during the interval when the source-specific tree is being constructed. When SPTbit is FALSE, only (*,G) forwarding state is used to forward packets from S to G. When SPTbit is TRUE, both (*,G) and (S,G) forwarding state are used.
SPTbitは、転送が（S、G）最短パスツリー（SPT）または（*、G）ツリーのどちらで行われているかを示すために使用されます。ルーターは（S、G）状態を保持できますが、送信元固有のツリーが構築されている間、（*、G）状態で転送を継続できます。 SPTbitがFALSEの場合、（*、G）転送状態のみがSからGへのパケットの転送に使用されます。SPTbitがTRUEの場合、（*、G）および（S、G）転送状態の両方が使用されます。
The (S,G) Keepalive Timer is updated by data being forwarded using this (S,G) forwarding state. It is used to keep (S,G) state alive in the absence of explicit (S,G) Joins. Amongst other things, this is necessary for the so-called "turnaround rules" -- when the RP uses (S,G) joins to stop encapsulation, and then (S,G) prunes to prevent traffic from unnecessarily reaching the RP.
（S、G）キープアライブタイマーは、この（S、G）転送状態を使用して転送されるデータによって更新されます。これは、明示的な（S、G）結合がない場合に（S、G）状態を維持するために使用されます。とりわけ、これは、いわゆる「ターンアラウンドルール」に必要です。RPが（S、G）結合を使用してカプセル化を停止し、（S、G）がプルーニングして、トラフィックが不必要にRPに到達しないようにします。
On a DR, the (S,G) Register State is used to keep track of whether to encapsulate data to the RP on the Register Tunnel; the (S,G) Register-Stop Timer tracks how long before encapsulation begins again for a given (S,G).
DRでは、（S、G）レジスタステートを使用して、データをレジスタトンネル上のRPにカプセル化するかどうかを追跡します。 （S、G）レジスターストップタイマーは、特定の（S、G）のカプセル化が再開されるまでの時間を追跡します。
For every source/group pair (S,G) for which a router also has (*,G) state, it also keeps the following state:
ルーターも（*、G）状態を持つすべてのソース/グループペア（S、G）について、次の状態も保持します。
(S,G,rpt) state:
（S、G、rpt）状態：
For each interface:
各インターフェースについて：
Local Membership:
State: One of {"NoInfo", "Exclude"}
PIM (S,G,rpt) Join/Prune State:
PIM（S、G、rpt）加入/プルーニング状態：
o State: One of {"NoInfo", "Pruned", "Prune-Pending"}
o 状態：{"NoInfo"、 "Pruned"、 "Prune-Pending"}のいずれか
o Prune-Pending Timer (PPT)
o プルーンペンディングタイマー（PPT）
o Join/Prune Expiry Timer (ET)
o 加入/プルーニング有効期限タイマー（ET）
Not interface specific:
インターフェース固有ではありません：
Upstream (S,G,rpt) Join/Prune State:
アップストリーム（S、G、rpt）結合/プルーニング状態：
o State: One of {"RPTNotJoined(G)", "NotPruned(S,G,rpt)", "Pruned(S,G,rpt)"}
o 状態：{"RPTNotJoined（G）"、 "NotPruned（S、G、rpt）"、 "Pruned（S、G、rpt）"}のいずれか
o Override Timer (OT)
o オーバーライドタイマー（OT）
Local membership is the result of the local source-specific membership mechanism (such as IGMPv3) running on that interface and specifying that although there is (*,G) Include state, this particular source should be excluded. As stored here, this state is the resulting state after any IGMPv3 inconsistencies between LAN members have been resolved. It need not be kept if this router is not the DR on that interface unless this router won a (*,G) assert on this interface for this group. However, we RECOMMEND storing this information if possible, as it reduces latency converging to stable operating conditions after a failure causing a change of DR. This information is used by the pim_exclude(S,G) macro described in Section 4.1.5.
ローカルメンバーシップは、そのインターフェイスで実行されているローカルソース固有のメンバーシップメカニズム（IGMPv3など）の結果であり、（*、G）インクルード状態はあるが、この特定のソースは除外する必要があることを指定します。ここに保存されているように、この状態は、LANメンバー間のIGMPv3の不整合が解決された後の結果の状態です。このルーターがこのグループのこのインターフェースで（*、G）アサートを獲得しない限り、このルーターがそのインターフェースのDRでない場合は保持する必要はありません。ただし、障害がDRの変更を引き起こした後、安定した動作条件に収束するまでの待ち時間が短縮されるため、可能であればこの情報を保存することをお勧めします。この情報は、セクション4.1.5で説明されているpim_exclude（S、G）マクロによって使用されます。
PIM (S,G,rpt) Join/Prune state is the result of receiving PIM (S,G,rpt) Join/Prune messages on this interface and is specified in Section 4.5.3. The state is used by the macros that calculate the outgoing interface list in Section 4.1.5, and in the rules for adding Prune(S,G,rpt) messages to Join(*,G) messages specified in Section 4.5.6.
PIM（S、G、rpt）Join / Prune状態は、このインターフェースでPIM（S、G、rpt）Join / Pruneメッセージを受信した結果であり、セクション4.5.3で指定されています。この状態は、セクション4.1.5の発信インターフェースリストを計算するマクロと、セクション4.5.6で指定されたJoin（*、G）メッセージにPrune（S、G、rpt）メッセージを追加するためのルールで使用されます。
The upstream (S,G,rpt) Join/Prune state is used along with the Override Timer to send the correct override messages in response to Join/Prune messages sent by upstream peers on a LAN. This state and behavior are specified in Section 4.5.7.
アップストリーム（S、G、rpt）のJoin / Prune状態は、Override Timerと共に使用され、LAN上のアップストリームピアによって送信されたJoin / Pruneメッセージに応答して正しいオーバーライドメッセージを送信します。この状態と動作は、セクション4.5.7で指定されています。
Using this state, we define the following "macro" definitions, which we will use in the descriptions of the state machines and pseudocode in the following sections.
この状態を使用して、次の「マクロ」定義を定義します。これは、次のセクションの状態マシンと疑似コードの説明で使用します。
The most important macros are those that define the outgoing interface list (or "olist") for the relevant state. An olist can be "immediate" if it is built directly from the state of the relevant type. For example, the immediate_olist(S,G) is the olist that would be built if the router only had (S,G) state and no (*,G) or (S,G,rpt) state. In contrast, the "inherited" olist inherits state from other types. For example, the inherited_olist(S,G) is the olist that is relevant for forwarding a packet from S to G using both source-specific and group-specific state.
最も重要なマクロは、関連する状態の発信インターフェイスリスト（または「olist」）を定義するマクロです。 olistは、関連する型の状態から直接構築されている場合、「即時」である可能性があります。たとえば、immediate_olist（S、G）は、ルーターに（S、G）状態のみがあり、（*、G）または（S、G、rpt）状態がない場合に作成されるolistです。対照的に、「継承された」olistは、他のタイプから状態を継承します。たとえば、inherited_olist（S、G）は、ソース固有の状態とグループ固有の状態の両方を使用してSからGにパケットを転送するのに関連するolistです。
There is no immediate_olist(S,G,rpt), as (S,G,rpt) state is negative state; it removes interfaces in the (*,G) olist from the olist that is actually used to forward traffic. The inherited_olist(S,G,rpt) is therefore the olist that would be used for a packet from S to G forwarding on the RP tree. It is a strict subset of immediate_olist(*,G).
（S、G、rpt）状態は負の状態であるため、immediate_olist（S、G、rpt）はありません。 （*、G）olistのインターフェースを、トラフィックの転送に実際に使用されているolistから削除します。 inherited_olist（S、G、rpt）は、RPツリーでSからGへの転送に使用されるolistです。これはimmediate_olist（*、G）の厳密なサブセットです。
Generally speaking, the inherited_olists are used for forwarding, and the immediate_olists are used to make decisions about state maintenance.
一般的に、inherited_olistsは転送に使用され、immediate_olistsは状態の維持に関する決定を行うために使用されます。
immediate_olist(*,G) =
joins(*,G) (+) pim_include(*,G) (-) lost_assert(*,G)
immediate_olist(S,G) =
joins(S,G) (+) pim_include(S,G) (-) lost_assert(S,G)
inherited_olist(S,G,rpt) =
( joins(*,G) (-) prunes(S,G,rpt) )
(+) ( pim_include(*,G) (-) pim_exclude(S,G))
(-) ( lost_assert(*,G) (+) lost_assert(S,G,rpt) )
inherited_olist(S,G) =
inherited_olist(S,G,rpt) (+)
joins(S,G) (+) pim_include(S,G) (-) lost_assert(S,G)
The macros pim_include(*,G) and pim_include(S,G) indicate the interfaces to which traffic might be forwarded because of hosts that are local members on that interface. Note that normally only the DR cares about local membership, but when an assert happens, the assert winner takes over responsibility for forwarding traffic to local members that have requested traffic on a group or source/group pair.
マクロpim_include（*、G）およびpim_include（S、G）は、そのインターフェースのローカルメンバーであるホストが原因でトラフィックが転送される可能性があるインターフェースを示します。通常、DRのみがローカルメンバーシップを考慮しますが、アサートが発生すると、アサートの勝者が、グループまたはソース/グループのペアでトラフィックを要求したローカルメンバーにトラフィックを転送する責任を引き継ぎます。
pim_include(*,G) =
{ all interfaces I such that:
( ( I_am_DR( I ) AND lost_assert(*,G,I) == FALSE )
OR AssertWinner(*,G,I) == me )
AND local_receiver_include(*,G,I) }
pim_include(S,G) =
{ all interfaces I such that:
( (I_am_DR( I ) AND lost_assert(S,G,I) == FALSE )
OR AssertWinner(S,G,I) == me )
AND local_receiver_include(S,G,I) }
pim_exclude(S,G) =
{ all interfaces I such that:
( (I_am_DR( I ) AND lost_assert(*,G,I) == FALSE )
OR AssertWinner(*,G,I) == me )
AND local_receiver_exclude(S,G,I) }
The clause "local_receiver_include(S,G,I)" is true if the IGMP/MLD module or other local membership mechanism has determined that local members on interface I desire to receive traffic sent specifically by S to G. "local_receiver_include(*,G,I)" is true if the IGMP/MLD module or other local membership mechanism has determined that local members on interface I desire to receive all traffic sent to G (possibly excluding traffic from a specific set of sources). "local_receiver_exclude(S,G,I)" is true if "local_receiver_include(*,G,I)" is true but none of the local members desire to receive traffic from S.
「local_receiver_include（S、G、I）」という句は、IGMP / MLDモジュールまたはその他のローカルメンバーシップメカニズムが、SからGに具体的に送信されたトラフィックを受信したいインターフェイスのローカルメンバーを決定した場合にtrueになります。「local_receiver_include（*、G 、I） "は、IGMP / MLDモジュールまたは他のローカルメンバーシップメカニズムが、Gに送信されたすべてのトラフィックを受信することを希望するインターフェイスのローカルメンバーを特定した場合に該当します（特定のソースセットからのトラフィックを除外する可能性があります）。 「local_receiver_exclude（S、G、I）」は、「local_receiver_include（*、G、I）」がtrueの場合はtrueですが、ローカルメンバーのいずれもSからのトラフィックの受信を望んでいません。
The set "joins(*,G)" is the set of all interfaces on which the router has received (*,G) Joins:
"joins（*、G）"のセットは、ルーターが（*、G）Joinsを受信したすべてのインターフェースのセットです。
joins(*,G) =
{ all interfaces I such that
DownstreamJPState(*,G,I) is either Join or Prune-Pending }
DownstreamJPState(*,G,I) is the state of the finite state machine in Section 4.5.1.
DownstreamJPState（*、G、I）は、セクション4.5.1の有限状態マシンの状態です。
The set "joins(S,G)" is the set of all interfaces on which the router has received (S,G) Joins:
"joins（S、G）"のセットは、ルーターが（S、G）Joinsを受信したすべてのインターフェースのセットです。
joins(S,G) =
{ all interfaces I such that
DownstreamJPState(S,G,I) is either Join or Prune-Pending }
DownstreamJPState(S,G,I) is the state of the finite state machine in Section 4.5.2.
DownstreamJPState（S、G、I）は、セクション4.5.2の有限状態マシンの状態です。
The set "prunes(S,G,rpt)" is the set of all interfaces on which the router has received (*,G) joins and (S,G,rpt) prunes:
セット「prunes（S、G、rpt）」は、ルーターが（*、G）加入と（S、G、rpt）プルーニングを受信したすべてのインターフェースのセットです。
prunes(S,G,rpt) =
{ all interfaces I such that
DownstreamJPState(S,G,rpt,I) is Prune or PruneTmp }
DownstreamJPState(S,G,rpt,I) is the state of the finite state machine in Section 4.5.3.
DownstreamJPState（S、G、rpt、I）は、セクション4.5.3の有限状態マシンの状態です。
The set "lost_assert(*,G)" is the set of all interfaces on which the router has received (*,G) joins but has lost a (*,G) assert. The macro lost_assert(*,G,I) is defined in Section 4.6.5.
セット "lost_assert（*、G）"は、ルーターが（*、G）加入を受信したが（*、G）アサートを失ったすべてのインターフェースのセットです。マクロlost_assert（*、G、I）はセクション4.6.5で定義されています。
lost_assert(*,G) =
{ all interfaces I such that
lost_assert(*,G,I) == TRUE }
The set "lost_assert(S,G,rpt)" is the set of all interfaces on which the router has received (*,G) joins but has lost an (S,G) assert. The macro lost_assert(S,G,rpt,I) is defined in Section 4.6.5.
セット「lost_assert（S、G、rpt）」は、ルーターが（*、G）加入を受信したが（S、G）アサートを失ったすべてのインターフェースのセットです。マクロlost_assert（S、G、rpt、I）はセクション4.6.5で定義されています。
lost_assert(S,G,rpt) =
{ all interfaces I such that
lost_assert(S,G,rpt,I) == TRUE }
The set "lost_assert(S,G)" is the set of all interfaces on which the router has received (S,G) joins but has lost an (S,G) assert. The macro lost_assert(S,G,I) is defined in Section 4.6.5.
セット「lost_assert（S、G）」は、ルーターが（S、G）加入を受信したが（S、G）アサートを失ったすべてのインターフェースのセットです。マクロlost_assert（S、G、I）はセクション4.6.5で定義されています。
lost_assert(S,G) =
{ all interfaces I such that
lost_assert(S,G,I) == TRUE }
The following pseudocode macro definitions are also used in many places in the specification. Basically, RPF' is the RPF neighbor towards an RP or source unless a PIM-Assert has overridden the normal choice of neighbor.
次の疑似コードマクロ定義も、仕様の多くの場所で使用されています。基本的に、RPF 'は、PIM-Assertが通常のネイバーの選択を上書きしていない限り、RPまたはソースに対するRPFネイバーです。
neighbor RPF'(*,G) {
if ( I_Am_Assert_Loser(*, G, RPF_interface(RP(G))) ) {
return AssertWinner(*, G, RPF_interface(RP(G)) )
} else {
return NBR( RPF_interface(RP(G)), MRIB.next_hop( RP(G) ) )
}
}
neighbor RPF'(S,G,rpt) {
if( I_Am_Assert_Loser(S, G, RPF_interface(RP(G)) ) ) {
return AssertWinner(S, G, RPF_interface(RP(G)) )
} else {
return RPF'(*,G)
}
}
neighbor RPF'(S,G) {
if ( I_Am_Assert_Loser(S, G, RPF_interface(S) )) {
return AssertWinner(S, G, RPF_interface(S) )
} else {
return NBR( RPF_interface(S), MRIB.next_hop( S ) )
}
}
RPF'(*,G) and RPF'(S,G) indicate the neighbor from which data packets should be coming and to which joins should be sent on the RP tree and SPT, respectively.
RPF '（*、G）およびRPF'（S、G）は、RPツリーおよびSPTで、それぞれデータパケットの送信元および結合先の送信先を示します。
RPF'(S,G,rpt) is basically RPF'(*,G) modified by the result of an Assert(S,G) on RPF_interface(RP(G)). In such a case, packets from S will be originating from a different router than RPF'(*,G). If we only have active (*,G) Join state, we need to accept packets from RPF'(S,G,rpt) and add a Prune(S,G,rpt) to the periodic Join(*,G) messages that we send to RPF'(*,G) (see Section 4.5.6).
RPF '（S、G、rpt）は、基本的にRPF_interface（RP（G））のAssert（S、G）の結果によって変更されたRPF'（*、G）です。そのような場合、SからのパケットはRPF '（*、G）とは異なるルーターから発信されます。アクティブ（*、G）の結合状態しかない場合、RPF '（S、G、rpt）からのパケットを受け入れ、Prune（S、G、rpt）を定期的なJoin（*、G）メッセージに追加する必要があります。 RPF '（*、G）に送信します（セクション4.5.6を参照）。
The function MRIB.next_hop( S ) returns an address of the next-hop PIM neighbor toward the host S, as indicated by the current MRIB. If S is directly adjacent, then MRIB.next_hop( S ) returns NULL. At the RP for G, MRIB.next_hop( RP(G)) returns NULL.
関数MRIB.next_hop（S）は、現在のMRIBで示されているように、ホストSに向かうネクストホップPIMネイバーのアドレスを返します。 Sが直接隣接している場合、MRIB.next_hop（S）はNULLを返します。 GのRPでは、MRIB.next_hop（RP（G））はNULLを返します。
The function NBR( I, A ) uses information gathered through PIM Hello messages to map the IP address A of a directly connected PIM neighbor router on interface I to the primary IP address of the same router (Section 4.3.4). The primary IP address of a neighbor is the address that it uses as the source of its PIM Hello messages. Note that a neighbor's IP address may be non-unique within the PIM neighbor database due to scope issues. The address must, however, be unique amongst the addresses of all the PIM neighbors on a specific interface.
関数NBR（I、A）は、PIM Helloメッセージを通じて収集された情報を使用して、インターフェースIに直接接続されたPIM隣接ルーターのIPアドレスAを同じルーターのプライマリIPアドレスにマップします（セクション4.3.4）。ネイバーのプライマリIPアドレスは、PIM Helloメッセージの送信元として使用するアドレスです。スコープの問題により、PIMネイバーデータベース内でネイバーのIPアドレスが一意でない場合があることに注意してください。ただし、アドレスは、特定のインターフェイス上のすべてのPIMネイバーのアドレス間で一意である必要があります。
I_Am_Assert_Loser(S, G, I) is true if the Assert state machine (in Section 4.6.1) for (S,G) on Interface I is in "I am Assert Loser" state.
I_Am_Assert_Loser（S、G、I）は、インターフェイスIの（S、G）のアサートステートマシン（セクション4.6.1）が「I am Assert Loser」状態の場合にtrueになります。
I_Am_Assert_Loser(*, G, I) is true if the Assert state machine (in Section 4.6.2) for (*,G) on Interface I is in "I am Assert Loser" state.
I_Am_Assert_Loser（*、G、I）は、インターフェイスIの（*、G）のアサートステートマシン（セクション4.6.2）が「I am Assert Loser」状態の場合にtrueになります。
The PIM-SM packet forwarding rules are defined below in pseudocode.
PIM-SMパケット転送ルールは、以下の疑似コードで定義されています。
iif is the incoming interface of the packet.
iifは、パケットの着信インターフェースです。
S is the source address of the packet.
Sはパケットの送信元アドレスです。
G is the destination address of the packet (group address).
Gは、パケットの宛先アドレス（グループアドレス）です。
RP is the address of the Rendezvous Point for this group.
RPは、このグループのランデブーポイントのアドレスです。
RPF_interface(S) is the interface the MRIB indicates would be used to route packets to S.
RPF_interface（S）は、MRIBがパケットをSにルーティングするために使用されることを示すインターフェイスです。
RPF_interface(RP) is the interface the MRIB indicates would be used to route packets to the RP, except at the RP when it is the decapsulation interface (the "virtual" interface on which Register packets are received).
RPF_interface（RP）は、カプセル化解除インターフェイス（レジスタパケットが受信される「仮想」インターフェイス）であるRPを除いて、MRIBがパケットをRPにルーティングするために使用されることを示すインターフェイスです。
First, we restart (or start) the Keepalive Timer if the source is on a directly connected subnet.
まず、ソースが直接接続されたサブネット上にある場合、キープアライブタイマーを再起動（または開始）します。
Second, we check to see if the SPTbit should be set because we've now switched from the RP tree to the SPT.
次に、RPツリーからSPTに切り替えたため、SPTbitを設定する必要があるかどうかを確認します。
Next, we check to see whether the packet should be accepted based on TIB state and the interface that the packet arrived on.
次に、TIBの状態とパケットが到着したインターフェイスに基づいて、パケットを受け入れる必要があるかどうかを確認します。
If the packet should be forwarded using (S,G) state, we then build an outgoing interface list for the packet. If this list is not empty, then we restart the (S,G) state Keepalive Timer.
（S、G）状態を使用してパケットを転送する必要がある場合は、パケットの送信インターフェイスリストを作成します。このリストが空でない場合、（S、G）状態のキープアライブタイマーを再起動します。
If the packet should be forwarded using (*,G) state, then we just build an outgoing interface list for the packet. We also check if we should initiate a switch to start receiving this source on a shortest path tree.
（*、G）状態を使用してパケットを転送する必要がある場合は、パケットの送信インターフェイスリストを作成するだけです。また、最短パスツリーでこのソースの受信を開始するための切り替えを開始する必要があるかどうかも確認します。
Finally, we remove the incoming interface from the outgoing interface list we've created, and if the resulting outgoing interface list is not empty, we forward the packet out of those interfaces.
最後に、作成した発信インターフェイスリストから着信インターフェイスを削除し、結果の発信インターフェイスリストが空でない場合は、それらのインターフェイスからパケットを転送します。
On receipt of data from S to G on interface iif:
if( DirectlyConnected(S) == TRUE AND iif == RPF_interface(S) ) {
set KeepaliveTimer(S,G) to Keepalive_Period
# Note: A register state transition or UpstreamJPState(S,G)
# transition may happen as a result of restarting
# KeepaliveTimer, and must be dealt with here.
}
if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined AND
inherited_olist(S,G) != NULL ) {
set KeepaliveTimer(S,G) to Keepalive_Period
}
Update_SPTbit(S,G,iif)
oiflist = NULL
if( iif == RPF_interface(S) AND SPTbit(S,G) == TRUE ) {
oiflist = inherited_olist(S,G)
} else if( iif == RPF_interface(RP(G)) AND SPTbit(S,G) == FALSE ) {
oiflist = inherited_olist(S,G,rpt)
CheckSwitchToSpt(S,G)
} else {
# Note: RPF check failed.
# A transition in an Assert finite state machine may cause an
# Assert(S,G) or Assert(*,G) message to be sent out interface iif.
# See Section 4.6 for details.
if ( SPTbit(S,G) == TRUE AND iif is in inherited_olist(S,G) ) {
send Assert(S,G) on iif
} else if ( SPTbit(S,G) == FALSE AND
iif is in inherited_olist(S,G,rpt) ) {
send Assert(*,G) on iif
}
}
oiflist = oiflist (-) iif forward packet on all interfaces in oiflist
oiflist = oiflist（-）oiflistのすべてのインターフェースでiif転送パケット
This pseudocode employs several "macro" definitions:
この疑似コードは、いくつかの「マクロ」定義を採用しています。
DirectlyConnected(S) is TRUE if the source S is on any subnet that is directly connected to this router (or for packets originating on this router).
ソースSがこのルーターに直接接続されているサブネット上にある場合（またはこのルーターから発信されたパケットの場合）、DirectlyConnected（S）はTRUEです。
inherited_olist(S,G) and inherited_olist(S,G,rpt) are defined in Section 4.1.
inherited_olist（S、G）およびinherited_olist（S、G、rpt）は、セクション4.1で定義されています。
Basically, inherited_olist(S,G) is the outgoing interface list for packets forwarded on (S,G) state, taking into account (*,G) state, asserts, etc.
基本的に、inherited_olist（S、G）は、（S、G）状態で転送されたパケットの発信インターフェイスリストであり、（*、G）状態やアサートなどを考慮しています。
inherited_olist(S,G,rpt) is the outgoing interface list for packets forwarded on (*,G) state, taking into account (S,G,rpt) prune state, asserts, etc.
inherited_olist（S、G、rpt）は、（S、G、rpt）プルーン状態やアサートなどを考慮して、（*、G）状態で転送されたパケットの発信インターフェイスリストです。
Update_SPTbit(S,G,iif) is defined in Section 4.2.2.
Update_SPTbit（S、G、iif）はセクション4.2.2で定義されています。
CheckSwitchToSpt(S,G) is defined in Section 4.2.1.
CheckSwitchToSpt（S、G）はセクション4.2.1で定義されています。
UpstreamJPState(S,G) is the state of the finite state machine in Section 4.5.5.
UpstreamJPState（S、G）は、セクション4.5.5の有限状態マシンの状態です。
Keepalive_Period is defined in Section 4.11.
Keepalive_Periodはセクション4.11で定義されています。
Data-triggered PIM-Assert messages sent from the above forwarding code SHOULD be rate-limited in an implementation-dependent manner.
上記の転送コードから送信されたデータトリガーPIM-Assertメッセージは、実装依存の方法でレート制限する必要があります（SHOULD）。
In Sparse-Mode PIM, last-hop routers join the shared tree towards the RP. Once traffic from sources to joined groups arrives at a last-hop router, it has the option of switching to receive the traffic on a shortest path tree (SPT).
スパースモードPIMでは、ラストホップルータはRPに向けて共有ツリーに参加します。ソースから参加グループへのトラフィックがラストホップルータに到着すると、最短パスツリー（SPT）でトラフィックを受信するように切り替えるオプションがあります。
The decision for a router to switch to the SPT is controlled as follows:
ルータがSPTに切り替える決定は、次のように制御されます。
void
CheckSwitchToSpt(S,G) {
if ( ( pim_include(*,G) (-) pim_exclude(S,G)
(+) pim_include(S,G) != NULL )
AND SwitchToSptDesired(S,G) ) {
# Note: Restarting the KAT will result in the SPT switch.
set KeepaliveTimer(S,G) to Keepalive_Period
}
}
SwitchToSptDesired(S,G) is a policy function that is implementation defined. An "infinite threshold" policy can be implemented by making SwitchToSptDesired(S,G) return false all the time. A "switch on first packet" policy can be implemented by making SwitchToSptDesired(S,G) return true once a single packet has been received for the source and group.
SwitchToSptDesired（S、G）は、実装で定義されるポリシー関数です。 「無限しきい値」ポリシーは、SwitchToSptDesired（S、G）が常にfalseを返すようにすることで実装できます。 「最初のパケットのスイッチ」ポリシーは、ソースとグループの単一のパケットが受信されると、SwitchToSptDesired（S、G）がtrueを返すようにすることで実装できます。
The (S,G) SPTbit is used to distinguish whether to forward on (*,G) or on (S,G) state. When switching from the RP tree to the source tree, there is a transition period when data is arriving due to upstream (*,G) state while upstream (S,G) state is being established, during which time a router should continue to forward only on (*,G) state. This prevents temporary black holes that would be caused by sending a Prune(S,G,rpt) before the upstream (S,G) state has finished being established.
（S、G）SPTbitは、（*、G）状態で転送するか、（S、G）状態で転送するかを区別するために使用されます。 RPツリーからソースツリーに切り替えるとき、アップストリーム（S、G）状態が確立されている間に、アップストリーム（*、G）状態が原因でデータが到着する遷移期間があり、その間、ルーターは転送を継続する必要があります。 （*、G）状態のみ。これにより、アップストリーム（S、G）状態の確立が完了する前にPrune（S、G、rpt）を送信することによって発生する一時的なブラックホールが防止されます。
Thus, when a packet arrives, the (S,G) SPTbit is updated as follows:
したがって、パケットが到着すると、（S、G）SPTbitは次のように更新されます。
void
Update_SPTbit(S,G,iif) {
if ( iif == RPF_interface(S)
AND JoinDesired(S,G) == TRUE
AND ( DirectlyConnected(S) == TRUE
OR RPF_interface(S) != RPF_interface(RP(G))
OR inherited_olist(S,G,rpt) == NULL
OR ( ( RPF'(S,G) == RPF'(*,G) ) AND
( RPF'(S,G) != NULL ) )
OR ( I_Am_Assert_Loser(S,G,iif) ) ) ) {
Set SPTbit(S,G) to TRUE
}
}
Additionally, a router can set SPTbit(S,G) to TRUE in other cases, such as when it receives an Assert(S,G) on RPF_interface(S) (see Section 4.6.1).
さらに、ルータは、RPF_interface（S）でAssert（S、G）を受信する場合など、他の場合にSPTbit（S、G）をTRUEに設定できます（セクション4.6.1を参照）。
JoinDesired(S,G) is defined in Section 4.5.5 and indicates whether we have the appropriate (S,G) Join state to wish to send a Join(S,G) upstream.
JoinDesired（S、G）はセクション4.5.5で定義されており、Join（S、G）をアップストリームに送信するための適切な（S、G）結合状態があるかどうかを示します。
Basically, Update_SPTbit(S,G,iif) will set the SPTbit if we have the appropriate (S,G) join state, and if the packet arrived on the correct upstream interface for S, and if one or more of the following conditions apply:
基本的に、Update_SPTbit（S、G、iif）は、適切な（S、G）結合状態があり、パケットがSの正しいアップストリームインターフェイスに到着し、次の条件の1つ以上が当てはまる場合、SPTbitを設定します：
1. The source is directly connected, in which case the switch to the SPT is a no-op.
1. ソースが直接接続されている場合、SPTへのスイッチは何もしません。
2. The RPF interface to S is different from the RPF interface to the RP. The packet arrived on RPF_interface(S), and so the SPT must have been completed.
2. SへのRPFインターフェイスは、RPへのRPFインターフェイスとは異なります。パケットはRPF_interface（S）に到着したため、SPTは完了している必要があります。
3. No one wants the packet on the RP tree.
3. 誰もRPツリーのパケットを必要としません。
4. RPF'(S,G) == RPF'(*,G). In this case, the router will never be able to tell if the SPT has been completed, so it should just switch immediately. The RPF'(S,G) != NULL check ensures that the SPTbit is set only if the RPF neighbor towards S is valid.
4. RPF '（S、G）== RPF'（*、G）。この場合、ルータはSPTが完了したかどうかを知ることができないため、ただちに切り替える必要があります。 RPF '（S、G）！= NULLチェックは、SへのRPFネイバーが有効な場合にのみSPTbitが設定されることを保証します。
In the case where the RPF interface is the same for the RP and for S, but RPF'(S,G) and RPF'(*,G) differ, we wait for an Assert(S,G), which indicates that the upstream router with (S,G) state believes the SPT has been completed. However, item (3) above is needed because there may not be any (*,G) state to trigger an Assert(S,G) to happen.
RPFインターフェイスがRPとSで同じであるが、RPF '（S、G）とRPF'（*、G）が異なる場合、Assert（S、G）を待ちます。これは、 （S、G）状態の上流ルーターは、SPTが完了したと信じています。ただし、Assert（S、G）をトリガーする（*、G）状態がない可能性があるため、上記の項目（3）が必要です。
The SPTbit is cleared in the (S,G) upstream state machine (see Section 4.5.5) when JoinDesired(S,G) becomes FALSE.
JoinDesired（S、G）がFALSEになると、（S、G）アップストリームステートマシン（セクション4.5.5を参照）でSPTbitがクリアされます。
A shared-media LAN like Ethernet may have multiple PIM-SM routers connected to it. A single one of these routers, the DR, will act on behalf of directly connected hosts with respect to the PIM-SM protocol. Because the distinction between LANs and point-to-point interfaces can sometimes be blurred, and because routers may also have multicast host functionality, the PIM-SM specification makes no distinction between the two. Thus, DR election will happen on all interfaces, LAN or otherwise.
イーサネットなどの共有メディアLANには、複数のPIM-SMルーターが接続されている場合があります。これらのルーターの1つであるDRは、PIM-SMプロトコルに関して、直接接続されたホストに代わって動作します。 LANとポイントツーポイントインターフェイスの区別が不明瞭になる場合があること、およびルーターがマルチキャストホスト機能を備えている場合があるため、PIM-SM仕様では2つを区別しません。したがって、DR選出は、LANまたはその他のすべてのインターフェイスで行われます。
DR election is performed using Hello messages. Hello messages are also the way that option negotiation takes place in PIM, so that additional functionality can be enabled, or parameters tuned.
DR選出は、Helloメッセージを使用して実行されます。 Helloメッセージは、PIMでオプションネゴシエーションが行われる方法でもあるため、追加機能を有効にしたり、パラメーターを調整したりできます。
PIM Hello messages are sent periodically on each PIM-enabled interface. They allow a router to learn about the neighboring PIM routers on each interface. Hello messages are also the mechanism used to elect a DR, and to negotiate additional capabilities. A router must record the Hello information received from each PIM neighbor.
PIM Helloメッセージは、各PIM対応インターフェイスで定期的に送信されます。それらはルータが各インターフェイスの隣接PIMルータについて学ぶことを可能にします。 Helloメッセージは、DRを選出し、追加機能をネゴシエートするために使用されるメカニズムでもあります。ルータは、各PIMネイバーから受信したHello情報を記録する必要があります。
Hello messages MUST be sent on all active interfaces, including physical point-to-point links, and are multicast to the 'ALL-PIM-ROUTERS' group address ('224.0.0.13' for IPv4 and 'ff02::d' for IPv6).
Helloメッセージは、物理的なポイントツーポイントリンクを含むすべてのアクティブなインターフェイスで送信する必要があり、「ALL-PIM-ROUTERS」グループアドレス（IPv4の場合は「224.0.0.13」、IPv6の場合は「ff02 :: d」にマルチキャストされます。 ）。
We note that some implementations do not send Hello messages on point-to-point interfaces. This is non-compliant behavior. A compliant PIM router MUST send Hello messages, even on point-to-point interfaces.
一部の実装では、ポイントツーポイントインターフェイスでHelloメッセージを送信しないことに注意してください。これは非準拠の動作です。準拠PIMルーターは、ポイントツーポイントインターフェイスであっても、Helloメッセージを送信する必要があります。
A per-interface Hello Timer (HT(I)) is used to trigger sending Hello messages on each active interface. When PIM is enabled on an interface or a router first starts, the Hello Timer of that interface is set to a random value between 0 and Triggered_Hello_Delay. This prevents synchronization of Hello messages if multiple routers are powered on simultaneously. After the initial randomized interval, Hello messages MUST be sent every Hello_Period seconds. The Hello Timer SHOULD NOT be reset except when it expires.
インターフェイスごとのHelloタイマー（HT（I））は、アクティブな各インターフェイスでHelloメッセージの送信をトリガーするために使用されます。インターフェイスまたはルータでPIMが最初に有効になると、そのインターフェイスのHelloタイマーが0〜Triggered_Hello_Delayのランダムな値に設定されます。これにより、複数のルーターの電源が同時に投入された場合に、Helloメッセージが同期されなくなります。最初のランダム化された間隔の後、HelloメッセージはHello_Period秒ごとに送信される必要があります。 Helloタイマーは、有効期限が切れた場合を除き、リセットしないでください。
Note that neighbors will not accept Join/Prune or Assert messages from a router unless they have first heard a Hello message from that router. Thus, if a router needs to send a Join/Prune or Assert message on an interface on which it has not yet sent a Hello message with the currently configured IP address, then it MUST immediately send the relevant Hello message without waiting for the Hello Timer to expire, followed by the Join/Prune or Assert message.
ネイバーは、ルータからのHelloメッセージを最初に聞いていない限り、ルータからのJoin / PruneまたはAssertメッセージを受け入れないことに注意してください。したがって、ルーターが、現在構成されているIPアドレスでHelloメッセージをまだ送信していないインターフェイスでJoin / PruneまたはAssertメッセージを送信する必要がある場合、Helloタイマーを待たずに、関連するHelloメッセージをすぐに送信する必要があります。期限切れになり、その後にJoin / PruneまたはAssertメッセージが続きます。
The DR Priority option allows a network administrator to give preference to a particular router in the DR election process by giving it a numerically larger DR Priority. The DR Priority option SHOULD be included in every Hello message, even if no DR Priority is explicitly configured on that interface. This is necessary because priority-based DR election is only enabled when all neighbors on an interface advertise that they are capable of using the DR Priority option. The default priority is 1.
DR優先度オプションを使用すると、ネットワーク管理者は、DR選択プロセスで特定のルーターを数値的に大きなDR優先度に設定することにより、ルーターを優先することができます。 DR優先度オプションは、そのインターフェイスで明示的にDR優先度が構成されていない場合でも、すべてのHelloメッセージに含める必要があります（SHOULD）。優先度ベースのDR選出は、インターフェイス上のすべてのネイバーがDR優先度オプションを使用できることを通知している場合にのみ有効になるため、これが必要です。デフォルトの優先順位は1です。
The Generation Identifier (GenID) option SHOULD be included in all Hello messages. The GenID option contains a randomly generated 32-bit value that is regenerated each time PIM forwarding is started or restarted on the interface, including when the router itself restarts. When a Hello message with a new GenID is received from a neighbor, any old Hello information about that neighbor SHOULD be discarded and superseded by the information from the new Hello message. This may cause a new DR to be chosen on that interface.
Generation Identifier（GenID）オプションは、すべてのHelloメッセージに含める必要があります（SHOULD）。 GenIDオプションには、ランダムに生成された32ビット値が含まれており、ルーター自体の再起動時を含め、PIM転送がインターフェイスで開始または再起動されるたびに再生成されます。新しいGenIDのHelloメッセージをネイバーから受信すると、そのネイバーに関する古いHello情報は破棄され、新しいHelloメッセージからの情報に置き換えられる必要があります（SHOULD）。これにより、そのインターフェイスで新しいDRが選択される場合があります。
The LAN Prune Delay option SHOULD be included in all Hello messages sent on multi-access LANs. This option advertises a router's capability to use values other than the defaults for the Propagation_Delay and Override_Interval, which affect the setting of the Prune-Pending, Upstream Join, and Override Timers (defined in Section 4.10).
LAN Prune Delayオプションは、マルチアクセスLANで送信されるすべてのHelloメッセージに含める必要があります（SHOULD）。このオプションは、Propagation_DelayおよびOverride_Intervalのデフォルト以外の値を使用するルーターの機能を通知します。これは、プルーニング保留、アップストリーム結合、およびオーバーライドタイマーの設定に影響します（セクション4.10で定義）。
The Address List option advertises all the secondary addresses associated with the source interface of the router originating the message. The option MUST be included in all Hello messages if there are secondary addresses associated with the source interface and MAY be omitted if no secondary addresses exist.
[アドレス一覧]オプションは、メッセージを発信するルーターの送信元インターフェイスに関連付けられているすべてのセカンダリアドレスをアドバタイズします。ソースインターフェイスに関連付けられたセカンダリアドレスがある場合、このオプションはすべてのHelloメッセージに含める必要があり、セカンダリアドレスが存在しない場合は省略できます。
To allow new or rebooting routers to learn of PIM neighbors quickly, when a Hello message is received from a new neighbor, or a Hello message with a new GenID is received from an existing neighbor, a new Hello message SHOULD be sent on this interface after a randomized delay between 0 and Triggered_Hello_Delay. This triggered message need not change the timing of the scheduled periodic message. If a router needs to send a Join/Prune to the new neighbor or send an Assert message in response to an Assert message from the new neighbor before this randomized delay has expired, then it MUST immediately send the relevant Hello message without waiting for the Hello Timer to expire, followed by the Join/Prune or Assert message. If it does not do this, then the new neighbor will discard the Join/Prune or Assert message.
新しいルーターまたは再起動中のルーターがPIMネイバーをすばやく認識できるようにするには、新しいネイバーからHelloメッセージを受信したとき、または既存のネイバーから新しいGenIDのHelloメッセージを受信したときに、このインターフェイスで新しいHelloメッセージを送信する必要があります（SHOULD） 0とTriggered_Hello_Delayの間のランダムな遅延。このトリガーされたメッセージは、スケジュールされた定期的なメッセージのタイミングを変更する必要はありません。このランダム化された遅延が期限切れになる前に、ルーターが新しいネイバーにJoin / Pruneを送信するか、新しいネイバーからのAssertメッセージに応答してAssertメッセージを送信する必要がある場合、Helloを待たずに、関連するHelloメッセージをすぐに送信する必要があります。タイマーが期限切れになり、その後にJoin / PruneまたはAssertメッセージが続きます。これを行わない場合、新しいネイバーはJoin / PruneまたはAssertメッセージを破棄します。
Before an interface goes down or changes primary IP address, a Hello message with a zero HoldTime SHOULD be sent immediately (with the old IP address if the IP address changed). This will cause PIM neighbors to remove this neighbor (or its old IP address) immediately. After an interface has changed its IP address, it MUST send a Hello message with its new IP address. If an interface changes one of its secondary IP addresses, a Hello message with an updated Address List option and a non-zero HoldTime SHOULD be sent immediately. This will cause PIM neighbors to update this neighbor's list of secondary addresses immediately.
インターフェイスがダウンするか、プライマリIPアドレスを変更する前に、HoldTimeがゼロのHelloメッセージをすぐに送信する必要があります（IPアドレスが変更された場合は古いIPアドレスを使用）。これにより、PIMネイバーはこのネイバー（またはその古いIPアドレス）をすぐに削除します。インターフェイスがIPアドレスを変更した後、新しいIPアドレスでHelloメッセージを送信する必要があります。インターフェイスがセカンダリIPアドレスの1つを変更した場合、アドレスリストオプションが更新されたHelloメッセージとゼロ以外のHoldTimeがすぐに送信される必要があります。これにより、PIMネイバーはこのネイバーのセカンダリアドレスのリストをすぐに更新します。
When a PIM Hello message is received on interface I, the following information about the sending neighbor is recorded:
PIM HelloメッセージがインターフェイスIで受信されると、送信ネイバーに関する次の情報が記録されます。
neighbor.interface The interface on which the Hello message arrived.
neighbor.interface Helloメッセージが到着したインターフェース。
neighbor.primary_ip_address The IP address that the PIM neighbor used as the source address of the Hello message.
neighbor.primary_ip_address PIMネイバーがHelloメッセージの送信元アドレスとして使用したIPアドレス。
neighbor.genid The Generation ID of the PIM neighbor.
neighbor.genid PIMネイバーの世代ID。
neighbor.dr_priority The DR Priority field of the PIM neighbor, if it is present in the Hello message.
neighbor.dr_priority Helloメッセージに存在する場合、PIMネイバーのDR Priorityフィールド。
neighbor.dr_priority_present A flag indicating if the DR Priority field was present in the Hello message.
neighbor.dr_priority_present HelloメッセージにDR Priorityフィールドが存在したかどうかを示すフラグ。
neighbor.timeout A timer value to time out the neighbor state when it becomes stale, also known as the Neighbor Liveness Timer.
neighbor.timeoutネイバー状態が古くなったときにタイムアウトするタイマー値。ネイバーライブネスタイマーとも呼ばれます。
The Neighbor Liveness Timer (NLT(N,I)) is reset to Hello_Holdtime (from the Hello Holdtime option) whenever a Hello message is received containing a Holdtime option, or to Default_Hello_Holdtime if the Hello message does not contain the Holdtime option.
ネイバーライブネスタイマー（NLT（N、I））は、Holdtimeオプションを含むHelloメッセージを受信すると、Hello_Holdtime（Hello Holdtimeオプションから）にリセットされます。HelloメッセージにHoldtimeオプションが含まれていない場合は、Default_Hello_Holdtimeにリセットされます。
Neighbor state is deleted when the neighbor timeout expires.
ネイバータイムアウトの期限が切れると、ネイバー状態が削除されます。
The function for computing the DR on interface I is:
インターフェイスIでDRを計算する関数は次のとおりです。
host
DR(I) {
dr = me
for each neighbor on interface I {
if ( dr_is_better( neighbor, dr, I ) == TRUE ) {
dr = neighbor
}
}
return dr
}
The function used for comparing DR "metrics" on interface I is:
インターフェイスIでDR「メトリック」を比較するために使用される関数は次のとおりです。
bool
dr_is_better(a,b,I) {
if( there is a neighbor n on I for which n.dr_priority_present
is false ) {
return a.primary_ip_address > b.primary_ip_address
} else {
return ( a.dr_priority > b.dr_priority ) OR
( a.dr_priority == b.dr_priority AND
a.primary_ip_address > b.primary_ip_address )
}
}
The trivial function I_am_DR(I) is defined to aid readability:
簡単な関数I_am_DR（I）は、読みやすくするために定義されています。
bool
I_am_DR(I) {
return DR(I) == me
}
The DR Priority is a 32-bit unsigned number, and the numerically larger priority is always preferred. A router's idea of the current DR on an interface can change when a PIM Hello message is received, when a neighbor times out, or when a router's own DR Priority changes. If the router becomes the DR or ceases to be the DR, this will normally cause the DR Register state machine to change state. Subsequent actions are determined by that state machine.
DR優先度は32ビットの符号なし数値であり、数値的に大きい優先度が常に優先されます。インターフェイス上の現在のDRに関するルーターの考えは、PIM Helloメッセージが受信されたとき、ネイバーがタイムアウトしたとき、またはルーター自身のDR優先度が変更されたときに変更される可能性があります。ルータがDRになるか、DRでなくなると、通常、これによりDRレジスタステートマシンの状態が変化します。以降のアクションは、そのステートマシンによって決定されます。
We note that some PIM implementations do not send Hello messages on point-to-point interfaces and thus cannot perform DR election on such interfaces. This is non-compliant behavior. DR election MUST be performed on ALL active PIM-SM interfaces.
一部のPIM実装では、ポイントツーポイントインターフェイスでHelloメッセージを送信しないため、そのようなインターフェイスでDR選出を実行できないことに注意してください。これは非準拠の動作です。すべてのアクティブなPIM-SMインターフェイスでDR選出を実行する必要があります。
In addition to the information recorded for the DR Election, the following per-neighbor information is obtained from the LAN Prune Delay Hello option:
DR Electionのために記録された情報に加えて、次のネイバーごとの情報がLAN Prune Delay Helloオプションから取得されます。
neighbor.lan_prune_delay_present A flag indicating if the LAN Prune Delay option was present in the Hello message.
neighbor.lan_prune_delay_present HelloメッセージにLAN Prune Delayオプションが存在したかどうかを示すフラグ。
neighbor.tracking_support A flag storing the value of the T bit in the LAN Prune Delay option if it is present in the Hello message. This indicates the neighbor's capability to disable Join message suppression.
neighbor.tracking_support Helloメッセージに存在する場合、LANプルーニング遅延オプションのTビットの値を格納するフラグ。これは、Joinメッセージの抑制を無効にするネイバーの機能を示しています。
neighbor.propagation_delay The Propagation Delay field of the LAN Prune Delay option (if present) in the Hello message.
neighbor.propagation_delay HelloメッセージのLAN Prune Delayオプション（存在する場合）のPropagation Delayフィールド。
neighbor.override_interval The Override_Interval field of the LAN Prune Delay option (if present) in the Hello message.
neighbor.override_interval HelloメッセージのLAN Prune Delayオプション（存在する場合）のOverride_Intervalフィールド。
The additional state described above is deleted along with the DR neighbor state when the neighbor timeout expires.
上記の追加の状態は、ネイバータイムアウトの期限が切れると、DRネイバーの状態とともに削除されます。
Just like the DR Priority option, the information provided in the LAN Prune Delay option is not used unless all neighbors on a link advertise the option. The function below computes this state:
DR優先度オプションと同様に、リンク上のすべてのネイバーがオプションを通知しない限り、LANプルーニング遅延オプションで提供される情報は使用されません。以下の関数はこの状態を計算します：
bool
lan_delay_enabled(I) {
for each neighbor on interface I {
if ( neighbor.lan_prune_delay_present == false ) {
return false
}
}
return true
}
The Propagation Delay inserted by a router in the LAN Prune Delay option expresses the expected message propagation delay on the link and SHOULD be configurable by the system administrator. It is used by upstream routers to figure out how long they should wait for a Join override message before pruning an interface.
ルーターによってLANプルーン遅延オプションに挿入された伝搬遅延は、リンク上で予想されるメッセージ伝搬遅延を表し、システム管理者が構成可能である必要があります（SHOULD）。上流のルーターは、インターフェイスをプルーニングする前に、Joinオーバーライドメッセージを待つ時間を把握するために使用されます。
PIM implementers SHOULD enforce a lower bound on the permitted values for this delay to allow for scheduling and processing delays within their router. Such delays may cause received messages to be processed later as well as triggered messages to be sent later than intended. Setting this Propagation Delay to too low a value may result in temporary forwarding outages because a downstream router will not be able to override a neighbor's Prune message before the upstream neighbor stops forwarding.
PIMインプリメンターは、ルーター内での遅延のスケジューリングと処理を可能にするために、この遅延の許容値に下限を適用する必要があります（SHOULD）。このような遅延により、受信したメッセージが後で処理されたり、トリガーされたメッセージが意図したよりも後で送信されたりする場合があります。この伝播遅延の設定値が小さすぎると、ダウンストリームルータがアップストリームネイバーが転送を停止する前にネイバーのプルーンメッセージを上書きできないため、一時的な転送停止が発生する可能性があります。
When all routers on a link are in a position to negotiate a Propagation Delay different from the default, the largest value from those advertised by each neighbor is chosen. The function for computing the Effective Propagation Delay of interface I is:
リンク上のすべてのルータがデフォルトとは異なる伝播遅延をネゴシエートする位置にある場合、各ネイバーによってアドバタイズされたルータから最大の値が選択されます。インターフェイスIの有効伝播遅延を計算する関数は次のとおりです。
time_interval
Effective_Propagation_Delay(I) {
if ( lan_delay_enabled(I) == false ) {
return Propagation_delay_default
}
delay = Propagation_Delay(I)
for each neighbor on interface I {
if ( neighbor.propagation_delay > delay ) {
delay = neighbor.propagation_delay
}
}
return delay
}
To avoid synchronization of override messages when multiple downstream routers share a multi-access link, the sending of such messages is delayed by a small random amount of time. The period of randomization should represent the size of the PIM router population on the link. Each router expresses its view of the amount of randomization necessary in the Override Interval field of the LAN Prune Delay option.
複数のダウンストリームルーターがマルチアクセスリンクを共有しているときにオーバーライドメッセージの同期を回避するために、そのようなメッセージの送信は、ランダムな短い時間だけ遅延されます。ランダム化の期間は、リンク上のPIMルーター集団のサイズを表す必要があります。各ルーターは、LANプルーニング遅延オプションの[オーバーライド間隔]フィールドで必要なランダム化の量についての見方を表現しています。
When all routers on a link are in a position to negotiate an Override Interval different from the default, the largest value from those advertised by each neighbor is chosen. The function for computing the Effective Override Interval of interface I is:
リンク上のすべてのルーターがデフォルトとは異なるオーバーライド間隔をネゴシエートできる位置にある場合、各ネイバーによってアドバタイズされたルーターから最大の値が選択されます。インターフェースIの有効オーバーライド間隔を計算する関数は次のとおりです。
time_interval
Effective_Override_Interval(I) {
if ( lan_delay_enabled(I) == false ) {
return t_override_default
}
delay = Override_Interval(I)
for each neighbor on interface I {
if ( neighbor.override_interval > delay ) {
delay = neighbor.override_interval
}
}
return delay
}
Although the mechanisms are not specified in this document, it is possible for upstream routers to explicitly track the join membership of individual downstream routers if Join suppression is disabled. A router can advertise its willingness to disable Join suppression by using the T bit in the LAN Prune Delay Hello option. Unless all PIM routers on a link negotiate this capability, explicit tracking and the disabling of the Join suppression mechanism are not possible. The function for computing the state of Suppression on interface I is:
メカニズムはこのドキュメントでは指定されていませんが、結合抑制が無効になっている場合、上流ルーターが個々の下流ルーターの結合メンバーシップを明示的に追跡することが可能です。ルーターは、LAN Prune Delay HelloオプションのTビットを使用して、参加抑制を無効にする意欲をアドバタイズできます。リンク上のすべてのPIMルーターがこの機能をネゴシエートしない限り、明示的な追跡と参加抑制メカニズムの無効化は不可能です。インターフェースIの抑制状態を計算する関数は次のとおりです。
bool
Suppression_Enabled(I) {
if ( lan_delay_enabled(I) == false ) {
return true
}
for each neighbor on interface I {
if ( neighbor.tracking_support == false ) {
return true
}
}
return false
}
Note that the setting of Suppression_Enabled(I) affects the value of t_suppressed (see Section 4.11).
Suppression_Enabled（I）の設定はt_suppressedの値に影響することに注意してください（セクション4.11を参照）。
Communication of a router's interface secondary addresses to its PIM neighbors is necessary to provide the neighbors with a mechanism for mapping next_hop information obtained through their MRIB to a primary address that can be used as a destination for Join/Prune messages. The mapping is performed through the NBR macro. The primary address of a PIM neighbor is obtained from the source IP address used in its PIM Hello messages. Secondary addresses are carried within the Hello message in an Address List Hello option. The primary address of the source interface of the router MUST NOT be listed within the Address List Hello option.
ルータのインターフェイスのセカンダリアドレスとそのPIMネイバーとの通信は、MRIBを通じて取得したnext_hop情報を、Join / Pruneメッセージの宛先として使用できるプライマリアドレスにマッピングするメカニズムをネイバーに提供するために必要です。マッピングはNBRマクロを通じて実行されます。 PIMネイバーのプライマリアドレスは、PIM Helloメッセージで使用される送信元IPアドレスから取得されます。セカンダリアドレスは、アドレスリストのHelloオプションのHelloメッセージ内で伝達されます。ルーターのソースインターフェイスのプライマリアドレスは、アドレスリストのHelloオプション内にリストされてはいけません。
In addition to the information recorded for the DR Election, the following per-neighbor information is obtained from the Address List Hello option:
DR選挙のために記録された情報に加えて、次のネイバーごとの情報がアドレスリストのHelloオプションから取得されます。
neighbor.secondary_address_list The list of secondary addresses used by the PIM neighbor on the interface through which the Hello message was transmitted.
neighbor.secondary_address_list Helloメッセージが送信されたインターフェイス上のPIMネイバーが使用するセカンダリアドレスのリスト。
When processing a received PIM Hello message containing an Address List Hello option, the list of secondary addresses in the message completely replaces any previously associated secondary addresses for that neighbor. If a received PIM Hello message does not contain an Address List Hello option, then all secondary addresses associated with the neighbor MUST be deleted. If a received PIM Hello message contains an Address List Hello option that includes the primary address of the sending router in the list of secondary addresses (although this is not expected), then the addresses listed in the message, excluding the primary address, are used to update the associated secondary addresses for that neighbor.
アドレスリストのHelloオプションを含む受信したPIM Helloメッセージを処理する場合、メッセージ内のセカンダリアドレスのリストは、そのネイバーに以前関連付けられていたセカンダリアドレスを完全に置き換えます。受信したPIM HelloメッセージにアドレスリストのHelloオプションが含まれていない場合は、ネイバーに関連付けられているすべてのセカンダリアドレスを削除する必要があります。受信したPIM Helloメッセージに、送信元ルーターのプライマリアドレスがセカンダリアドレスのリストに含まれているアドレスリストのHelloオプションが含まれている場合（これは予期されていません）、メッセージにリストされているアドレス（プライマリアドレスを除く）が使用されますそのネイバーの関連付けられたセカンダリアドレスを更新します。
All the advertised secondary addresses in received Hello messages must be checked against those previously advertised by all other PIM neighbors on that interface. If there is a conflict and the same secondary address was previously advertised by another neighbor, then only the most recently received mapping MUST be maintained, and an error message SHOULD be logged to the administrator in a rate-limited manner.
受信したHelloメッセージでアドバタイズされたすべてのセカンダリアドレスは、そのインターフェイス上の他のすべてのPIMネイバーによって以前にアドバタイズされたアドレスと照合する必要があります。競合があり、同じセカンダリアドレスが別のネイバーによって以前にアドバタイズされた場合、最後に受信したマッピングのみを維持する必要があり、レート制限された方法でエラーメッセージを管理者に記録する必要があります。
Within one Address List Hello option, all the addresses MUST be of the same address family. It is not permitted to mix IPv4 and IPv6 addresses within the same message. In addition, the address family of the fields in the message SHOULD be the same as the IP source and destination addresses of the packet header.
1つのアドレスリストのHelloオプション内では、すべてのアドレスが同じアドレスファミリである必要があります。同じメッセージ内でIPv4アドレスとIPv6アドレスを混在させることはできません。さらに、メッセージ内のフィールドのアドレスファミリは、パケットヘッダーのIP送信元および宛先アドレスと同じである必要があります（SHOULD）。
The Designated Router (DR) on a LAN or point-to-point link encapsulates multicast packets from local sources to the RP for the relevant group unless it recently received a Register-Stop message for that (S,G) or (*,G) from the RP. When the DR receives a Register-Stop message from the RP, it starts a Register-Stop Timer to maintain this state. Just before the Register-Stop Timer expires, the DR sends a Null-Register message to the RP to allow the RP to refresh the Register-Stop information at the DR. If the Register-Stop Timer actually expires, the DR will resume encapsulating packets from the source to the RP.
LANまたはポイントツーポイントリンク上の指定ルーター（DR）は、その（S、G）または（*、G）のRegister-Stopメッセージを最近受信していない限り、ローカルソースから関連グループのRPへのマルチキャストパケットをカプセル化します。 ）RPから。 DRはRPからRegister-Stopメッセージを受信すると、この状態を維持するためにRegister-Stopタイマーを開始します。 Register-Stopタイマーが期限切れになる直前に、DRはNull-RegisterメッセージをRPに送信して、RPがDRでRegister-Stop情報を更新できるようにします。 Register-Stopタイマーが実際に期限切れになると、DRは送信元からRPへのパケットのカプセル化を再開します。
Every PIM-SM router has the capability to be a DR. The state machine below is used to implement Register functionality. For the purposes of specification, we represent the mechanism to encapsulate packets to the RP as a Register-Tunnel interface, which is added to or removed from the (S,G) olist. The tunnel interface then takes part in the normal packet forwarding rules as specified in Section 4.2.
すべてのPIM-SMルーターには、DRになる機能があります。以下のステートマシンは、レジスタ機能を実装するために使用されます。仕様上、RPへのパケットをカプセル化するメカニズムは、（S、G）olistに追加または削除されるRegister-Tunnelインターフェイスとして表します。次に、トンネルインターフェースは、セクション4.2で指定されている通常のパケット転送ルールに参加します。
If register state is maintained, it is maintained only for directly connected sources and is per-(S,G). There are four states in the DR's per-(S,G) Register state machine:
レジスター状態が維持される場合、それは直接接続されたソースに対してのみ維持され、（S、G）ごとになります。 DRの（S、G）レジスタステートマシンには4つの状態があります。
Join (J) The register tunnel is "joined" (the join is actually implicit, but the DR acts as if the RP has joined the DR on the tunnel interface).
結合（J）レジスタトンネルは「結合」されます（結合は実際には暗黙的ですが、DRは、RPがトンネルインターフェイス上のDRに結合したかのように動作します）。
Prune (P) The register tunnel is "pruned" (this occurs when a Register-Stop is received).
Prune（P）レジスタトンネルは「プルーニング」されます（これは、Register-Stopが受信されたときに発生します）。
Join-Pending (JP) The register tunnel is pruned but the DR is contemplating adding it back.
Join-Pending（JP）登録トンネルはプルーニングされましたが、DRはそれを再び追加することを検討しています。
NoInfo (NI) No information. This is the initial state, and the state when the router is not the DR.
NoInfo（NI）情報はありません。これは初期状態であり、ルーターがDRでない場合の状態です。
In addition, a Register-Stop Timer (RST) is kept if the state machine is not in the NoInfo state.
さらに、ステートマシンがNoInfo状態でない場合、Register-Stop Timer（RST）が保持されます。
Figure 1: Per-(S,G) Register State Machine at a DR
図1：DRでの（S、G）ごとのレジスタステートマシン
+----------++----------------------------------------------------------+
| || Event |
| ++----------+-----------+-----------+-----------+-----------+
|Prev State||Register- | Could | Could | Register- | RP changed|
| ||Stop Timer| Register | Register | Stop | |
| ||expires | ->True | ->False | received | |
+----------++----------+-----------+-----------+-----------+-----------+
|NoInfo ||- | -> J state| - | - | - |
|(NI) || | add reg | | | |
| || | tunnel | | | |
+----------++----------+-----------+-----------+-----------+-----------+
| ||- | - | -> NI | -> P state| -> J state|
| || | | state | | |
| || | | remove reg| remove reg| update reg|
|Join (J) || | | tunnel | tunnel; | tunnel |
| || | | | set | |
| || | | | Register- | |
| || | | | Stop | |
| || | | | Timer(*) | |
+----------++----------+-----------+-----------+-----------+-----------+
| ||-> J state| - | -> NI | -> P state| -> J state|
| || | | state | | |
|Join- ||add reg | | | set | add reg |
|Pending ||tunnel | | | Register- | tunnel; |
|(JP) || | | | Stop | cancel |
| || | | | Timer(*) | Register- |
| || | | | | Stop Timer|
+----------++----------+-----------+-----------+-----------+-----------+
| ||-> JP | - | -> NI | - | -> J state|
| ||state | | state | | |
| ||set | | | | add reg |
|Prune (P) ||Register- | | | | tunnel; |
| ||Stop | | | | cancel |
| ||Timer(**);| | | | Register- |
| ||send Null-| | | | Stop Timer|
| ||Register | | | | |
+----------++----------+-----------+-----------+-----------+-----------+
Notes:
ノート：
(*) The Register-Stop Timer is set to a random value chosen uniformly from the interval ( 0.5 * Register_Suppression_Time, 1.5 * Register_Suppression_Time) minus Register_Probe_Time.
（*）Register-Stop Timerは、間隔（0.5 * Register_Suppression_Time、1.5 * Register_Suppression_Time）からRegister_Probe_Timeを引いた値から一様に選択されたランダムな値に設定されます。
Subtracting off Register_Probe_Time is a bit unnecessary because it is really small compared to Register_Suppression_Time, but this was in the old specification and is kept for compatibility.
Register_Suppression_Timeと比較して本当に小さいため、Register_Probe_Timeを減算することは少し不要ですが、これは古い仕様にあり、互換性のために保持されています。
(**) The Register-Stop Timer is set to Register_Probe_Time.
（**）Register-Stop TimerはRegister_Probe_Timeに設定されます。
The following three actions are defined:
次の3つのアクションが定義されています。
Add Register Tunnel
登録トンネルを追加
A Register-Tunnel virtual interface, VI, is created (if it doesn't already exist) with its encapsulation target being RP(G). DownstreamJPState(S,G,VI) is set to Join state, causing the tunnel interface to be added to immediate_olist(S,G) and inherited_olist(S,G).
Register-Tunnel仮想インターフェイスVIが作成され（まだ存在しない場合）、カプセル化ターゲットはRP（G）です。 DownstreamJPState（S、G、VI）がJoin状態に設定され、トンネルインターフェースがimmediate_olist（S、G）およびinherited_olist（S、G）に追加されます。
Remove Register Tunnel
登録トンネルを削除
VI is the Register-Tunnel virtual interface with encapsulation target of RP(G). DownstreamJPState(S,G,VI) is set to NoInfo state, causing the tunnel interface to be removed from immediate_olist(S,G) and inherited_olist(S,G). If DownstreamJPState(S,G,VI) is NoInfo for all (S,G), then VI can be deleted.
VIは、RP（G）のカプセル化ターゲットを持つRegister-Tunnel仮想インターフェイスです。 DownstreamJPState（S、G、VI）はNoInfo状態に設定され、トンネルインターフェースがimmediate_olist（S、G）およびinherited_olist（S、G）から削除されます。 DownstreamJPState（S、G、VI）がすべて（S、G）のNoInfoである場合、VIを削除できます。
Update Register Tunnel
登録トンネルの更新
This action occurs when RP(G) changes.
このアクションは、RP（G）が変更されたときに発生します。
VI_old is the Register-Tunnel virtual interface with encapsulation target old_RP(G). A Register-Tunnel virtual interface, VI_new, is created (if it doesn't already exist) with its encapsulation target being new_RP(G). DownstreamJPState(S,G,VI_old) is set to NoInfo state, and DownstreamJPState(S,G,VI_new) is set to Join state. If DownstreamJPState(S,G,VI_old) is NoInfo for all (S,G), then VI_old can be deleted.
VI_oldは、カプセル化ターゲットold_RP（G）を持つRegister-Tunnel仮想インターフェイスです。 Register-Tunnel仮想インターフェイスVI_newが作成され（まだ存在しない場合）、カプセル化ターゲットはnew_RP（G）です。 DownstreamJPState（S、G、VI_old）はNoInfo状態に設定され、DownstreamJPState（S、G、VI_new）は結合状態に設定されます。 DownstreamJPState（S、G、VI_old）がすべて（S、G）のNoInfoである場合、VI_oldを削除できます。
Note that we cannot simply change the encapsulation target of VI_old because not all groups using that encapsulation tunnel will have moved to the same new RP.
そのカプセル化トンネルを使用するすべてのグループが同じ新しいRPに移動するわけではないため、VI_oldのカプセル化ターゲットを単に変更することはできないことに注意してください。
CouldRegister(S,G)
CouldRegister（S、G）
The macro "CouldRegister" in the state machine is defined as:
ステートマシンのマクロ「CouldRegister」は、次のように定義されます。
bool CouldRegister(S,G) {
return ( I_am_DR( RPF_interface(S) ) AND
KeepaliveTimer(S,G) is running AND
DirectlyConnected(S) == TRUE )
}
Note that on reception of a packet at the DR from a directly connected source, KeepaliveTimer(S,G) needs to be set by the packet forwarding rules before computing CouldRegister(S,G) in the register state machine, or the first packet from a source won't be registered.
直接接続されたソースからDRでパケットを受信すると、レジスタステートマシンでCouldRegister（S、G）を計算する前に、キープアライブタイマー（S、G）をパケット転送ルールで設定する必要があることに注意してください。ソースは登録されません。
Encapsulating Data Packets in the Register Tunnel
レジスタトンネルでのデータパケットのカプセル化
Conceptually, the Register Tunnel is an interface with a smaller MTU than the underlying IP interface towards the RP. IP fragmentation on packets forwarded on the Register Tunnel is performed based upon this smaller MTU. The encapsulating DR may perform Path MTU Discovery to the RP to determine the effective MTU of the tunnel. Fragmentation for the smaller MTU should take both the outer IP header and the PIM register header overhead into account. If a multicast packet is fragmented on the way into the Register Tunnel, each fragment is encapsulated individually so it contains IP, PIM, and inner IP headers.
概念的には、Register Tunnelは、RPへの基になるIPインターフェイスよりもMTUが小さいインターフェイスです。レジスタトンネルで転送されるパケットのIPフラグメンテーションは、この小さいMTUに基づいて実行されます。カプセル化DRは、RPへのパスMTUディスカバリを実行して、トンネルの有効MTUを決定します。小さいMTUのフラグメンテーションでは、外部IPヘッダーとPIMレジスタヘッダーのオーバーヘッドの両方を考慮する必要があります。マルチキャストパケットがレジスタトンネルへの途中でフラグメント化される場合、各フラグメントは個別にカプセル化されるため、IP、PIM、および内部IPヘッダーが含まれます。
In IPv6, the DR MUST perform Path MTU Discovery, and an ICMP Packet Too Big message MUST be sent by the encapsulating DR if it receives a packet that will not fit in the effective MTU of the tunnel. If the MTU between the DR and the RP results in the effective tunnel MTU being smaller than 1280 (the IPv6 minimum MTU), the DR MUST send Fragmentation Required messages with an MTU value of 1280 and MUST fragment its PIM register messages as required, using an IPv6 fragmentation header between the outer IPv6 header and the PIM Register header.
IPv6では、DRはパスMTUディスカバリーを実行する必要があり、トンネルの有効なMTUに適合しないパケットを受信した場合、カプセル化DRによってICMPパケットが大きすぎるメッセージを送信する必要があります。 DRとRP間のMTUの結果、有効なトンネルMTUが1280（IPv6最小MTU）未満になる場合、DRは、MTU値が1280のフラグメンテーション要求メッセージを送信し、必要に応じて、PIMレジスタメッセージをフラグメント化する必要があります。外部IPv6ヘッダーとPIM Registerヘッダーの間のIPv6フラグメンテーションヘッダー。
The TTL of a forwarded data packet is decremented before it is encapsulated in the Register Tunnel. The encapsulating packet uses the normal TTL that the router would use for any locally generated IP packet.
転送されたデータパケットのTTLは、レジスタトンネルでカプセル化される前にデクリメントされます。カプセル化パケットは、ルーターがローカルで生成したIPパケットに使用する通常のTTLを使用します。
The IP Explicit Congestion Notification (ECN) bits should be copied from the original packet to the IP header of the encapsulating packet. They SHOULD NOT be set independently by the encapsulating router.
IP明示的輻輳通知（ECN）ビットは、元のパケットからカプセル化パケットのIPヘッダーにコピーする必要があります。それらは、カプセル化ルーターによって独立して設定されるべきではありません。
The Diffserv Code Point (DSCP) should be copied from the original packet to the IP header of the encapsulating packet. It MAY be set independently by the encapsulating router, based upon static configuration or traffic classification. See [12] for more discussion on setting the DSCP on tunnels.
Diffservコードポイント（DSCP）は、元のパケットからカプセル化パケットのIPヘッダーにコピーする必要があります。静的構成またはトラフィック分類に基づいて、カプセル化ルーターによって個別に設定される場合があります。トンネルでのDSCPの設定についての詳細は、[12]を参照してください。
Handling Register-Stop(*,G) Messages at the DR
DRでのRegister-Stop（*、G）メッセージの処理
An old RP might send a Register-Stop message with the source address set to all zeros. This was the normal course of action in RFC 2362 when the Register message matched against (*,G) state at the RP, and it was defined as meaning "stop encapsulating all sources for this group". However, the behavior of such a Register-Stop(*,G) is ambiguous or incorrect in some circumstances.
古いRPは、送信元アドレスがすべてゼロに設定されたRegister-Stopメッセージを送信する場合があります。これは、登録メッセージがRPの（*、G）状態と一致したときのRFC 2362の通常の行動方針であり、「このグループのすべてのソースのカプセル化を停止する」という意味として定義されていました。ただし、状況によっては、このようなRegister-Stop（*、G）の動作があいまいまたは正しくありません。
We specify that an RP should not send Register-Stop(*,G) messages, but for compatibility, a DR should be able to accept one if it is received.
RPがRegister-Stop（*、G）メッセージを送信しないように指定していますが、互換性のために、DRはそれを受信した場合にそれを受け入れることができる必要があります。
A Register-Stop(*,G) should be treated as a Register-Stop(S,G) for all (S,G) Register state machines that are not in the NoInfo state. A router should not apply a Register-Stop(*,G) to sources that become active after the Register-Stop(*,G) was received.
Register-Stop（*、G）は、NoInfo状態にないすべての（S、G）レジスタステートマシンのRegister-Stop（S、G）として扱う必要があります。ルーターは、Register-Stop（*、G）の受信後にアクティブになるソースにRegister-Stop（*、G）を適用しないでください。
When an RP receives a Register message, the course of action is decided according to the following pseudocode:
RPが登録メッセージを受信すると、次の疑似コードに従って一連のアクションが決定されます。
packet_arrives_on_rp_tunnel( pkt ) {
if( outer.dst is not one of my addresses ) {
drop the packet silently.
# Note: This may be a spoofing attempt.
}
if( I_am_RP(G) AND outer.dst == RP(G) ) {
sentRegisterStop = FALSE;
if ( SPTbit(S,G) OR
( SwitchToSptDesired(S,G) AND
( inherited_olist(S,G) == NULL ))) {
send Register-Stop(S,G) to outer.src
sentRegisterStop = TRUE;
}
if ( SPTbit(S,G) OR SwitchToSptDesired(S,G) ) {
if ( sentRegisterStop == TRUE ) {
set KeepaliveTimer(S,G) to RP_Keepalive_Period;
} else {
set KeepaliveTimer(S,G) to Keepalive_Period;
}
}
if( !SPTbit(S,G) AND ! pkt.NullRegisterBit ) {
decapsulate and forward the inner packet to
inherited_olist(S,G,rpt) # Note (+)
}
} else {
send Register-Stop(S,G) to outer.src
# Note (*)
}
}
outer.dst is the IP destination address of the encapsulating header.
outer.dstは、カプセル化ヘッダーのIP宛先アドレスです。
outer.src is the IP source address of the encapsulating header, i.e., the DR's address.
outer.srcは、カプセル化ヘッダーのIP送信元アドレス、つまりDRのアドレスです。
I_am_RP(G) is true if the group-to-RP mapping indicates that this router is the RP for the group.
グループからRPへのマッピングが、このルーターがグループのRPであることを示している場合、I_am_RP（G）はtrueです。
Note (*): This may block traffic from S for Register_Suppression_Time if the DR learned about a new group-to-RP mapping before the RP did. However, this doesn't matter unless we figure out some way for the RP also to accept (*,G) joins when it doesn't yet realize that it is about to become the RP for G. This will all get sorted out once the RP learns the new group-to-RP mapping. We decided to do nothing about this and just accept the fact that PIM may suffer interrupted (*,G) connectivity following an RP change.
注（*）：DRがRPが行う前に新しいグループからRPへのマッピングについて学習した場合、Register_Suppression_TimeのSからのトラフィックをブロックする可能性があります。ただし、RPが（*、G）結合を受け入れる何らかの方法を理解していない限り、これは問題になりません。GのRPになろうとしていることをまだ認識していないためです。これはすべて一度ソートされます。 RPは新しいグループからRPへのマッピングを学習します。これについては何もしないことを決定し、RPの変更後にPIMが（*、G）接続が中断する可能性があるという事実を受け入れるだけです。
Note (+): Implementations SHOULD NOT make this a special case, but SHOULD arrange that this path rejoin the normal packet forwarding path. All of the appropriate actions from the "On receipt of data from S to G on interface iif" pseudocode in Section 4.2 should be performed.
注（+）：実装では、これを特別なケースにするべきではありませんが、このパスが通常のパケット転送パスに再結合するように手配する必要があります（SHOULD）。セクション4.2の「インターフェイスiifでSからGへのデータの受信時」疑似コードからの適切なアクションはすべて実行する必要があります。
KeepaliveTimer(S,G) is restarted at the RP when packets arrive on the proper tunnel interface and the RP desires to switch to the SPT or the SPTbit is already set. This may cause the upstream (S,G) state machine to trigger a join if the inherited_olist(S,G) is not NULL.
キープアライブタイマー（S、G）は、パケットが適切なトンネルインターフェイスに到着し、RPがSPTへの切り替えを希望するか、SPTビットがすでに設定されている場合、RPで再起動されます。これにより、inherited_olist（S、G）がNULLでない場合、上流（S、G）の状態マシンが結合をトリガーする可能性があります。
An RP should preserve (S,G) state that was created in response to a Register message for at least ( 3 * Register_Suppression_Time ); otherwise, the RP may stop joining (S,G) before the DR for S has restarted sending registers. Traffic would then be interrupted until the Register-Stop Timer expires at the DR.
RPは、少なくとも（3 * Register_Suppression_Time）の間、Registerメッセージに応答して作成された（S、G）状態を保持する必要があります。そうしないと、SのDRがレジスターの送信を再開する前に、RPが（S、G）に参加しなくなる場合があります。その後、DRでレジスタ停止タイマーが期限切れになるまで、トラフィックが中断されます。
Thus, at the RP, KeepaliveTimer(S,G) should be restarted to ( 3 * Register_Suppression_Time + Register_Probe_Time ).
したがって、RPでは、KeepaliveTimer（S、G）を（3 * Register_Suppression_Time + Register_Probe_Time）に再開する必要があります。
When forwarding a packet from the Register Tunnel, the TTL of the original data packet is decremented after it is decapsulated.
レジスタトンネルからパケットを転送する場合、元のデータパケットのTTLは、カプセル化が解除された後に減分されます。
The IP ECN bits should be copied from the IP header of the Register packet to the decapsulated packet.
IP ECNビットは、RegisterパケットのIPヘッダーからカプセル化解除されたパケットにコピーする必要があります。
The DSCP should be copied from the IP header of the Register packet to the decapsulated packet. The RP MAY retain the DSCP of the inner packet or re-classify the packet and apply a different DSCP. Scenarios where each of these might be useful are discussed in [12].
DSCPは、RegisterパケットのIPヘッダーからカプセル化解除されたパケットにコピーする必要があります。 RPは内部パケットのDSCPを保持するか、パケットを再分類して別のDSCPを適用できます。これらのそれぞれが役立つかもしれないシナリオは[12]で議論されます。
A PIM Join/Prune message consists of a list of groups and a list of Joined and Pruned sources for each group. When processing a received Join/Prune message, each Joined or Pruned source for a group is effectively considered individually, and applies to one or more of the following state machines. When considering a Join/Prune message whose Upstream Neighbor Address field addresses this router, (*,G) Joins and Prunes can affect both the (*,G) and (S,G,rpt) downstream state machines, while (S,G), and (S,G,rpt) Joins and Prunes can only affect their respective downstream state machines. When considering a Join/Prune message whose Upstream Neighbor Address field addresses another router, most Join or Prune messages could affect each upstream state machine.
PIM Join / Pruneメッセージは、グループのリストと、各グループのJoinedおよびPrunedソースのリストで構成されています。受信したJoin / Pruneメッセージを処理するとき、グループのJoinまたはPrunedの各ソースは効果的に個別に考慮され、次の1つ以上のステートマシンに適用されます。アップストリームネイバーアドレスフィールドがこのルーターをアドレス指定するJoin / Pruneメッセージを検討する場合、（*、G）のJoinとPrunesは、（S、G）と（S、G、rpt）の両方のダウンストリームステートマシンに影響を与える可能性があります。 ）、および（S、G、rpt）の結合とプルーンは、それぞれのダウンストリーム状態マシンにのみ影響を与えることができます。アップストリームネイバーアドレスフィールドが別のルーターをアドレス指定するJoin / Pruneメッセージを検討する場合、ほとんどのJoinまたはPruneメッセージが各アップストリームステートマシンに影響を与える可能性があります。
In general, a PIM Join/Prune message should only be accepted for processing if it comes from a known PIM neighbor. A PIM router hears about PIM neighbors through PIM Hello messages. If a router receives a Join/Prune message from a particular IP source address and it has not seen a PIM Hello message from that source address, then the Join/Prune message SHOULD be discarded without further processing. In addition, if the Hello message from a neighbor was authenticated (see Section 6.3), then all Join/Prune messages from that neighbor MUST also be authenticated.
一般に、PIM Join / Pruneメッセージは、既知のPIMネイバーから送信された場合にのみ、処理のために受け入れられる必要があります。 PIMルーターは、PIM Helloメッセージを通じてPIMネイバーを認識します。ルータが特定のIP送信元アドレスからJoin / Pruneメッセージを受信し、その送信元アドレスからのPIM Helloメッセージを受信していない場合、Join / Pruneメッセージは、それ以上の処理なしで破棄する必要があります（SHOULD）。さらに、ネイバーからのHelloメッセージが認証された場合（セクション6.3を参照）、そのネイバーからのすべてのJoin / Pruneメッセージも認証される必要があります。
We note that some older PIM implementations incorrectly fail to send Hello messages on point-to-point interfaces, so we also RECOMMEND that a configuration option be provided to allow interoperation with such older routers, but that this configuration option SHOULD NOT be enabled by default.
古いPIM実装の中には、ポイントツーポイントインターフェイスでのHelloメッセージの送信に失敗するものがあることに注意してください。そのため、このような古いルーターとの相互運用を可能にする構成オプションを提供することをお勧めしますが、この構成オプションはデフォルトで有効にすべきではありません（SHOULD NOT） 。
When a router receives a Join(*,G), it must first check to see whether the RP in the message matches RP(G) (the router's idea of who the RP is). If the RP in the message does not match RP(G), the Join(*,G) should be silently dropped. (Note that other source list entries, such as (S,G,rpt) or (S,G), in the same Group-Specific Set should still be processed.) If a router has no RP information (e.g., has not recently received a BSR message), then it may choose to accept Join(*,G) and treat the RP in the message as RP(G). Received Prune(*,G) messages are processed even if the RP in the message does not match RP(G).
ルーターは、Join（*、G）を受信すると、まずメッセージ内のRPがRP（G）（ルーターがRPであるという概念）と一致するかどうかを確認する必要があります。メッセージ内のRPがRP（G）と一致しない場合、Join（*、G）は警告なしにドロップされます。 （同じグループ固有セット内の（S、G、rpt）や（S、G）などの他のソースリストエントリは引き続き処理する必要があることに注意してください。）ルーターにRP情報がない場合（たとえば、最近BSRメッセージを受信した場合）、Join（*、G）を受け入れ、メッセージ内のRPをRP（G）として扱うことを選択できます。受信したPrune（*、G）メッセージは、メッセージ内のRPがRP（G）と一致しない場合でも処理されます。
The per-interface state machine for receiving (*,G) Join/Prune messages is given below. There are three states:
（*、G）Join / Pruneメッセージを受信するためのインターフェイスごとのステートマシンを以下に示します。 3つの状態があります。
NoInfo (NI) The interface has no (*,G) Join state and no timers running.
NoInfo（NI）インターフェースには（*、G）結合状態がなく、タイマーは実行されていません。
Join (J) The interface has (*,G) Join state, which will cause the router to forward packets destined for G from this interface except if there is also (S,G,rpt) prune information (see Section 4.5.3) or the router lost an assert on this interface.
参加（J）インターフェイスには（*、G）参加状態があります。これにより、ルーターは、このインターフェイスからG宛てのパケットを転送します（ただし、（S、G、rpt）のプルーン情報がある場合を除きます（4.5.3項を参照））。または、ルーターがこのインターフェースのアサートを失いました。
Prune-Pending (PP) The router has received a Prune(*,G) on this interface from a downstream neighbor and is waiting to see whether the prune will be overridden by another downstream router. For forwarding purposes, the Prune-Pending state functions exactly like the Join state.
Prune-Pending（PP）ルーターは、このインターフェース上でダウンストリームネイバーからPrune（*、G）を受信し、プルーンが別のダウンストリームルーターによってオーバーライドされるかどうかを確認するために待機しています。転送の目的で、Prune-Pending状態はJoin状態とまったく同じように機能します。
In addition, the state machine uses two timers:
さらに、ステートマシンは2つのタイマーを使用します。
Expiry Timer (ET) This timer is restarted when a valid Join(*,G) is received. Expiry of the Expiry Timer causes the interface state to revert to NoInfo for this group.
有効期限タイマー（ET）このタイマーは、有効なJoin（*、G）が受信されると再開されます。 Expiry of the Expiry Timerは、インターフェイスの状態をこのグループのNoInfoに戻します。
Prune-Pending Timer (PPT) This timer is set when a valid Prune(*,G) is received. Expiry of the Prune-Pending Timer causes the interface state to revert to NoInfo for this group.
Prune-Pending Timer（PPT）このタイマーは、有効なPrune（*、G）が受信されたときに設定されます。 Prune-Pending Timerが期限切れになると、インターフェイスの状態がこのグループのNoInfoに戻ります。
Figure 2: Downstream Per-Interface (*,G) State Machine
図2：ダウンストリームのインターフェイスごとの（*、G）ステートマシン
+------------++--------------------------------------------------------+
| || Event |
| ++-------------+--------------+-------------+-------------+
|Prev State ||Receive | Receive | Prune- | Expiry Timer|
| ||Join(*,G) | Prune(*,G) | Pending | Expires |
| || | | Timer | |
| || | | Expires | |
+------------++-------------+--------------+-------------+-------------+
| ||-> J state | -> NI state | - | - |
|NoInfo (NI) ||start Expiry | | | |
| ||Timer | | | |
+------------++-------------+--------------+-------------+-------------+
| ||-> J state | -> PP state | - | -> NI state |
|Join (J) ||restart | start Prune- | | |
| ||Expiry Timer | Pending | | |
| || | Timer | | |
+------------++-------------+--------------+-------------+-------------+
|Prune- ||-> J state | -> PP state | -> NI state | -> NI state |
|Pending (PP)||restart | | Send Prune- | |
| ||Expiry Timer | | Echo(*,G) | |
+------------++-------------+--------------+-------------+-------------+
The transition events "Receive Join(*,G)" and "Receive Prune(*,G)" imply receiving a Join or Prune targeted to this router's primary IP address on the received interface. If the upstream neighbor address field is not correct, these state transitions in this state machine MUST NOT occur, although seeing such a packet may cause state transitions in other state machines.
遷移イベント「Receive Join（*、G）」および「Receive Prune（*、G）」は、受信したインターフェースでこのルーターのプライマリIPアドレスをターゲットとするJoinまたはPruneを受信することを意味します。アップストリームネイバーアドレスフィールドが正しくない場合、この状態マシンでこれらの状態遷移が発生してはなりません（MUST NOT）。ただし、このようなパケットを確認すると、他の状態マシンで状態遷移が発生する可能性があります。
On unnumbered interfaces on point-to-point links, the router's address should be the same as the source address it chose for the Hello message it sent over that interface. However, on point-to-point links it is RECOMMENDED that for backwards compatibility PIM Join/Prune messages with an upstream neighbor address field of all zeros also be accepted.
ポイントツーポイントリンク上の番号付けされていないインターフェイスでは、ルーターのアドレスは、そのインターフェイスを介して送信したHelloメッセージ用に選択したソースアドレスと同じである必要があります。ただし、ポイントツーポイントリンクでは、下位互換性のために、すべて0のアップストリームネイバーアドレスフィールドを持つPIM Join / Pruneメッセージも受け入れることをお勧めします。
Transitions from NoInfo State
NoInfo状態からの遷移
When in NoInfo state, the following event may trigger a transition:
NoInfo状態の場合、次のイベントが遷移をトリガーする可能性があります。
Receive Join(*,G) A Join(*,G) is received on interface I with its Upstream Neighbor Address set to the router's primary IP address on I.
Join（*、G）の受信Join（*、G）は、IのルーターのプライマリIPアドレスに設定されたアップストリームネイバーアドレスを持つインターフェイスIで受信されます。
The (*,G) downstream state machine on interface I transitions to the Join state. The Expiry Timer (ET) is started and set to the HoldTime from the triggering Join/Prune message.
インターフェイスIの（*、G）ダウンストリームステートマシンは、Join状態に移行します。 Expiry Timer（ET）が開始され、トリガーとなるJoin / PruneメッセージからHoldTimeに設定されます。
Transitions from Join State
結合状態からの遷移
When in Join state, the following events may trigger a transition:
結合状態の場合、次のイベントが遷移をトリガーする可能性があります。
Receive Join(*,G) A Join(*,G) is received on interface I with its Upstream Neighbor Address set to the router's primary IP address on I.
Join（*、G）の受信Join（*、G）は、IのルーターのプライマリIPアドレスに設定されたアップストリームネイバーアドレスを持つインターフェイスIで受信されます。
The (*,G) downstream state machine on interface I remains in Join state, and the Expiry Timer (ET) is restarted. The ET is set to the maximum of its current value and the HoldTime from the triggering Join/Prune message.
インターフェイスIの（*、G）ダウンストリームステートマシンはJoin状態のままで、有効期限タイマー（ET）が再起動されます。 ETは、現在の値と、トリガーとなるJoin / PruneメッセージからのHoldTimeの最大値に設定されます。
Receive Prune(*,G) A Prune(*,G) is received on interface I with its Upstream Neighbor Address set to the router's primary IP address on I.
受信Prune（*、G）Prune（*、G）は、IのアップストリームネイバーアドレスがルータのプライマリIPアドレスに設定されたインターフェイスIで受信されます。
The (*,G) downstream state machine on interface I transitions to the Prune-Pending state. The Prune-Pending Timer is started. It is set to the J/P_Override_Interval(I) if the router has more than one neighbor on that interface; otherwise, it is set to zero, causing it to expire immediately.
インターフェイスIの（*、G）ダウンストリームステートマシンは、Prune-Pending状態に移行します。 Prune-Pending Timerが開始されます。ルータのインターフェイスに複数のネイバーがある場合は、J / P_Override_Interval（I）に設定されます。それ以外の場合はゼロに設定され、すぐに期限切れになります。
Expiry Timer Expires The Expiry Timer for the (*,G) downstream state machine on interface I expires.
Expiry Timer ExpiresインターフェイスIの（*、G）ダウンストリームステートマシンのExpiry Timerが期限切れになります。
The (*,G) downstream state machine on interface I transitions to the NoInfo state.
インターフェイスIの（*、G）ダウンストリームステートマシンは、NoInfo状態に遷移します。
Transitions from Prune-Pending State
プルーンペンディング状態からの移行
When in Prune-Pending state, the following events may trigger a transition:
Prune-Pending状態の場合、次のイベントが遷移をトリガーする可能性があります。
Receive Join(*,G) A Join(*,G) is received on interface I with its Upstream Neighbor Address set to the router's primary IP address on I.
Join（*、G）の受信Join（*、G）は、IのルーターのプライマリIPアドレスに設定されたアップストリームネイバーアドレスを持つインターフェイスIで受信されます。
The (*,G) downstream state machine on interface I transitions to the Join state. The Prune-Pending Timer is canceled (without triggering an expiry event). The Expiry Timer (ET) is restarted and is then set to the maximum of its current value and the HoldTime from the triggering Join/Prune message.
インターフェイスIの（*、G）ダウンストリームステートマシンは、Join状態に移行します。 Prune-Pending Timerはキャンセルされます（期限切れイベントをトリガーすることなく）。有効期限タイマー（ET）が再起動され、現在の値とトリガー/参加/プルーンメッセージからのHoldTimeの最大値に設定されます。
Expiry Timer Expires The Expiry Timer for the (*,G) downstream state machine on interface I expires.
Expiry Timer ExpiresインターフェイスIの（*、G）ダウンストリームステートマシンのExpiry Timerが期限切れになります。
The (*,G) downstream state machine on interface I transitions to the NoInfo state.
インターフェイスIの（*、G）ダウンストリームステートマシンは、NoInfo状態に遷移します。
Prune-Pending Timer Expires The Prune-Pending Timer for the (*,G) downstream state machine on interface I expires.
Prune-Pending Timer ExpiresインターフェースIの（*、G）ダウンストリームステートマシンのPrune-Pending Timerが期限切れになります。
The (*,G) downstream state machine on interface I transitions to the NoInfo state. A PruneEcho(*,G) is sent onto the subnet connected to interface I.
インターフェイスIの（*、G）ダウンストリームステートマシンは、NoInfo状態に遷移します。 PruneEcho（*、G）は、インターフェースIに接続されたサブネットに送信されます。
The action "Send PruneEcho(*,G)" is triggered when the router stops forwarding on an interface as a result of a prune. A PruneEcho(*,G) is simply a Prune(*,G) message sent by the upstream router on a LAN with its own address in the Upstream Neighbor Address field. Its purpose is to add additional reliability so that if a Prune that should have been overridden by another router is lost locally on the LAN, then the PruneEcho may be received and cause the override to happen. A PruneEcho(*,G) need not be sent on an interface that contains only a single PIM neighbor during the time this state machine was in Prune-Pending state.
アクション「Srun PruneEcho（*、G）」は、プルーンの結果としてルータがインターフェイスでの転送を停止したときにトリガーされます。 PruneEcho（*、G）は、LANのアップストリームルータによって送信されたPrune（*、G）メッセージであり、アップストリームネイバーアドレスフィールドに独自のアドレスが含まれています。その目的は、別のルーターによってオーバーライドされるべきであったプルーンがLANでローカルに失われた場合にPruneEchoを受信してオーバーライドが発生するように、信頼性を追加することです。 PruneEcho（*、G）は、このステートマシンがPrune-Pending状態である間、単一のPIMネイバーのみを含むインターフェイスで送信する必要はありません。
The per-interface state machine for receiving (S,G) Join/Prune messages is given below and is almost identical to that for (*,G) messages. There are three states:
（S、G）Join / Pruneメッセージを受信するためのインターフェイスごとのステートマシンを以下に示します。これは（*、G）メッセージの場合とほぼ同じです。 3つの状態があります。
NoInfo (NI) The interface has no (S,G) Join state and no (S,G) timers running.
NoInfo（NI）インターフェースには（S、G）結合状態がなく、実行中の（S、G）タイマーもありません。
Join (J) The interface has (S,G) Join state, which will cause the router to forward packets from S destined for G from this interface if the (S,G) state is active (the SPTbit is set) except if the router lost an assert on this interface.
参加（J）インターフェースには（S、G）参加状態があります。これにより、（S、G）状態がアクティブ（SPTbitが設定されている）の場合を除いて、ルーターはSからG宛てのパケットをこのインターフェースから転送します。ルータはこのインターフェイスのアサートを失いました。
Prune-Pending (PP) The router has received a Prune(S,G) on this interface from a downstream neighbor and is waiting to see whether the prune will be overridden by another downstream router. For forwarding purposes, the Prune-Pending state functions exactly like the Join state.
Prune-Pending（PP）ルーターは、このインターフェースで下流の隣接ルーターからPrune（S、G）を受信し、別の下流のルーターによって除去が上書きされるかどうかを確認するために待機しています。転送の目的で、Prune-Pending状態はJoin状態とまったく同じように機能します。
In addition, there are two timers:
さらに、2つのタイマーがあります。
Expiry Timer (ET) This timer is set when a valid Join(S,G) is received. Expiry of the Expiry Timer causes this state machine to revert to NoInfo state.
有効期限タイマー（ET）このタイマーは、有効なJoin（S、G）が受信されたときに設定されます。 Expiry of the Expiry Timerにより、このステートマシンはNoInfo状態に戻ります。
Prune-Pending Timer (PPT) This timer is set when a valid Prune(S,G) is received. Expiry of the Prune-Pending Timer causes this state machine to revert to NoInfo state.
Prune-Pending Timer（PPT）このタイマーは、有効なPrune（S、G）が受信されたときに設定されます。 Prune-Pending Timerが期限切れになると、このステートマシンはNoInfo状態に戻ります。
Figure 3: Downstream Per-Interface (S,G) State Machine
図3：ダウンストリームPer-Interface（S、G）ステートマシン
+------------++--------------------------------------------------------+
| || Event |
| ++-------------+--------------+-------------+-------------+
|Prev State ||Receive | Receive | Prune- | Expiry Timer|
| ||Join(S,G) | Prune(S,G) | Pending | Expires |
| || | | Timer | |
| || | | Expires | |
+------------++-------------+--------------+-------------+-------------+
| ||-> J state | -> NI state | - | - |
|NoInfo (NI) ||start Expiry | | | |
| ||Timer | | | |
+------------++-------------+--------------+-------------+-------------+
| ||-> J state | -> PP state | - | -> NI state |
|Join (J) ||restart | start Prune- | | |
| ||Expiry Timer | Pending | | |
| || | Timer | | |
+------------++-------------+--------------+-------------+-------------+
|Prune- ||-> J state | -> PP state | -> NI state | -> NI state |
|Pending (PP)||restart | | Send Prune- | |
| ||Expiry Timer | | Echo(S,G) | |
+------------++-------------+--------------+-------------+-------------+
The transition events "Receive Join(S,G)" and "Receive Prune(S,G)" imply receiving a Join or Prune targeted to this router's primary IP address on the received interface. If the upstream neighbor address field is not correct, these state transitions in this state machine MUST NOT occur, although seeing such a packet may cause state transitions in other state machines.
遷移イベント「Receive Join（S、G）」および「Receive Prune（S、G）」は、受信したインターフェースでこのルーターのプライマリIPアドレスをターゲットとするJoinまたはPruneを受信することを意味します。アップストリームネイバーアドレスフィールドが正しくない場合、この状態マシンでこれらの状態遷移が発生してはなりません（MUST NOT）。ただし、このようなパケットを確認すると、他の状態マシンで状態遷移が発生する可能性があります。
On unnumbered interfaces on point-to-point links, the router's address SHOULD be the same as the source address it chose for the Hello message it sent over that interface. However, on point-to-point links it is RECOMMENDED that for backwards compatibility PIM Join/Prune messages with an upstream neighbor address field of all zeros also be accepted.
ポイントツーポイントリンクの番号なしインターフェースでは、ルーターのアドレスは、そのインターフェースを介して送信したHelloメッセージ用に選択した送信元アドレスと同じである必要があります（SHOULD）。ただし、ポイントツーポイントリンクでは、下位互換性のために、すべて0のアップストリームネイバーアドレスフィールドを持つPIM Join / Pruneメッセージも受け入れることをお勧めします。
Transitions from NoInfo State
NoInfo状態からの遷移
When in NoInfo state, the following event may trigger a transition:
NoInfo状態の場合、次のイベントが遷移をトリガーする可能性があります。
Receive Join(S,G) A Join(S,G) is received on interface I with its Upstream Neighbor Address set to the router's primary IP address on I.
Join（S、G）の受信Join（S、G）は、IのルーターのプライマリIPアドレスに設定されたアップストリームネイバーアドレスを持つインターフェイスIで受信されます。
The (S,G) downstream state machine on interface I transitions to the Join state. The Expiry Timer (ET) is started and set to the HoldTime from the triggering Join/Prune message.
インターフェイスIの（S、G）ダウンストリームステートマシンは、Join状態に移行します。 Expiry Timer（ET）が開始され、トリガーとなるJoin / PruneメッセージからHoldTimeに設定されます。
Transitions from Join State
結合状態からの遷移
When in Join state, the following events may trigger a transition:
結合状態の場合、次のイベントが遷移をトリガーする可能性があります。
Receive Join(S,G) A Join(S,G) is received on interface I with its Upstream Neighbor Address set to the router's primary IP address on I.
Join（S、G）の受信Join（S、G）は、IのルーターのプライマリIPアドレスに設定されたアップストリームネイバーアドレスを持つインターフェイスIで受信されます。
The (S,G) downstream state machine on interface I remains in Join state. The Expiry Timer (ET) is restarted and is then set to the maximum of its current value and the HoldTime from the triggering Join/Prune message.
インターフェイスIの（S、G）ダウンストリームステートマシンは、Join状態のままです。有効期限タイマー（ET）が再起動され、現在の値とトリガー/参加/プルーンメッセージからのHoldTimeの最大値に設定されます。
Receive Prune(S,G) A Prune(S,G) is received on interface I with its Upstream Neighbor Address set to the router's primary IP address on I.
受信Prune（S、G）Prune（S、G）は、IのアップストリームネイバーアドレスがルータのプライマリIPアドレスに設定されたインターフェイスIで受信されます。
The (S,G) downstream state machine on interface I transitions to the Prune-Pending state. The Prune-Pending Timer is started. It is set to the J/P_Override_Interval(I) if the router has more than one neighbor on that interface; otherwise, it is set to zero, causing it to expire immediately.
インターフェイスIの（S、G）ダウンストリームステートマシンは、プルーンペンディングステートに移行します。 Prune-Pending Timerが開始されます。ルータのインターフェイスに複数のネイバーがある場合は、J / P_Override_Interval（I）に設定されます。それ以外の場合はゼロに設定され、すぐに期限切れになります。
Expiry Timer Expires The Expiry Timer for the (S,G) downstream state machine on interface I expires.
Expiry Timer Expiresインターフェイス上の（S、G）ダウンストリームステートマシンのExpiry Timerが期限切れになります。
The (S,G) downstream state machine on interface I transitions to the NoInfo state.
インターフェイスIの（S、G）ダウンストリームステートマシンは、NoInfo状態に遷移します。
Transitions from Prune-Pending State
プルーンペンディング状態からの移行
When in Prune-Pending state, the following events may trigger a transition:
Prune-Pending状態の場合、次のイベントが遷移をトリガーする可能性があります。
Receive Join(S,G) A Join(S,G) is received on interface I with its Upstream Neighbor Address set to the router's primary IP address on I.
Join（S、G）の受信Join（S、G）は、IのルーターのプライマリIPアドレスに設定されたアップストリームネイバーアドレスを持つインターフェイスIで受信されます。
The (S,G) downstream state machine on interface I transitions to the Join state. The Prune-Pending Timer is canceled (without triggering an expiry event). The Expiry Timer (ET) is restarted and is then set to the maximum of its current value and the HoldTime from the triggering Join/Prune message.
インターフェイスIの（S、G）ダウンストリームステートマシンは、Join状態に移行します。 Prune-Pending Timerはキャンセルされます（期限切れイベントをトリガーすることなく）。有効期限タイマー（ET）が再起動され、現在の値とトリガー/参加/プルーンメッセージからのHoldTimeの最大値に設定されます。
Expiry Timer Expires The Expiry Timer for the (S,G) downstream state machine on interface I expires.
Expiry Timer Expiresインターフェイス上の（S、G）ダウンストリームステートマシンのExpiry Timerが期限切れになります。
The (S,G) downstream state machine on interface I transitions to the NoInfo state.
インターフェイスIの（S、G）ダウンストリームステートマシンは、NoInfo状態に遷移します。
Prune-Pending Timer Expires The Prune-Pending Timer for the (S,G) downstream state machine on interface I expires.
Prune-Pending Timer ExpiresインターフェースIの（S、G）ダウンストリームステートマシンのPrune-Pending Timerが期限切れになります。
The (S,G) downstream state machine on interface I transitions to the NoInfo state. A PruneEcho(S,G) is sent onto the subnet connected to interface I.
インターフェイスIの（S、G）ダウンストリームステートマシンは、NoInfo状態に遷移します。 PruneEcho（S、G）は、インターフェースIに接続されたサブネットに送信されます。
The action "Send PruneEcho(S,G)" is triggered when the router stops forwarding on an interface as a result of a prune. A PruneEcho(S,G) is simply a Prune(S,G) message sent by the upstream router on a LAN with its own address in the Upstream Neighbor Address field. Its purpose is to add additional reliability so that if a Prune that should have been overridden by another router is lost locally on the LAN, then the PruneEcho may be received and cause the override to happen. A PruneEcho(S,G) need not be sent on an interface that contains only a single PIM neighbor during the time this state machine was in Prune-Pending state.
アクション「Srun PruneEcho（S、G）」は、プルーニングの結果としてルータがインターフェイスでの転送を停止したときにトリガーされます。 PruneEcho（S、G）は、LANのアップストリームルータによって送信されたPrune（S、G）メッセージであり、アップストリームネイバーアドレスフィールドに独自のアドレスが含まれています。その目的は、別のルーターによってオーバーライドされるべきであったプルーンがLANでローカルに失われた場合にPruneEchoを受信してオーバーライドが発生するように、信頼性を追加することです。この状態マシンがPrune-Pending状態にある間、PruneEcho（S、G）は、単一のPIMネイバーのみを含むインターフェイスで送信する必要はありません。
The per-interface state machine for receiving (S,G,rpt) Join/Prune messages is given below. There are five states:
（S、G、rpt）Join / Pruneメッセージを受信するためのインターフェイスごとのステートマシンを以下に示します。 5つの状態があります。
NoInfo (NI) The interface has no (S,G,rpt) Prune state and no (S,G,rpt) timers running.
NoInfo（NI）インターフェースには（S、G、rpt）プルーン状態がなく、実行中の（S、G、rpt）タイマーもありません。
Prune (P) The interface has (S,G,rpt) Prune state, which will cause the router not to forward packets from S destined for G from this interface even though the interface has active (*,G) Join state.
Prune（P）インターフェースには（S、G、rpt）Prune状態があります。これにより、インターフェースにアクティブ（*、G）加入状態があっても、ルーターはSからG宛てのパケットをこのインターフェースから転送しません。
Prune-Pending (PP) The router has received a Prune(S,G,rpt) on this interface from a downstream neighbor and is waiting to see whether the prune will be overridden by another downstream router. For forwarding purposes, the Prune-Pending state functions exactly like the NoInfo state.
Prune-Pending（PP）ルーターは、下流の隣接ノードからこのインターフェースでPrune（S、G、rpt）を受信し、別の下流のルーターによって除去が上書きされるかどうかを確認するために待機しています。転送の目的で、Prune-Pending状態はNoInfo状態とまったく同じように機能します。
PruneTmp (P') This state is a transient state that for forwarding purposes behaves exactly like the Prune state. A (*,G) Join has been received (which may cancel the (S,G,rpt) Prune). As we parse the Join/Prune message from top to bottom, we first enter this state if the message contains a (*,G) Join. Later in the message, we will normally encounter an (S,G,rpt) prune to reinstate the Prune state. However, if we reach the end of the message without encountering such an (S,G,rpt) prune, then we will revert to NoInfo state in this state machine.
PruneTmp（P '）この状態は一時的な状態で、転送の目的でPrune状態とまったく同じように動作します。 （*、G）結合が受信されました（（S、G、rpt）プルーンがキャンセルされる場合があります）。 Join / Pruneメッセージを上から下に解析するとき、メッセージに（*、G）Joinが含まれている場合、最初にこの状態に入ります。メッセージの後半では、通常、（S、G、rpt）プルーンが発生してプルーン状態を復元します。ただし、このような（S、G、rpt）プルーンに出会わずにメッセージの最後に到達すると、この状態マシンのNoInfo状態に戻ります。
As no time is spent in this state, no timers can expire.
この状態では時間が消費されないため、タイマーが期限切れになることはありません。
Prune-Pending-Tmp (PP') This state is a transient state that is identical to P' except that it is associated with the PP state rather than the P state. For forwarding purposes, PP' behaves exactly like the PP state.
Prune-Pending-Tmp（PP '）この状態は、P状態ではなくPP状態に関連付けられていることを除いて、P'と同じ一時的な状態です。転送の目的で、PP 'はPP状態とまったく同じように動作します。
In addition, there are two timers:
さらに、2つのタイマーがあります。
Expiry Timer (ET) This timer is set when a valid Prune(S,G,rpt) is received. Expiry of the Expiry Timer causes this state machine to revert to NoInfo state.
有効期限タイマー（ET）このタイマーは、有効なPrune（S、G、rpt）が受信されたときに設定されます。 Expiry of the Expiry Timerにより、このステートマシンはNoInfo状態に戻ります。
Prune-Pending Timer (PPT) This timer is set when a valid Prune(S,G,rpt) is received. Expiry of the Prune-Pending Timer causes this state machine to move on to Prune state.
Prune-Pending Timer（PPT）このタイマーは、有効なPrune（S、G、rpt）が受信されたときに設定されます。 Prune-Pending Timerが期限切れになると、このステートマシンはPrune状態に移行します。
Figure 4: Downstream Per-Interface (S,G,rpt) State Machine
図4：ダウンストリームPer-Interface（S、G、rpt）ステートマシン
+----------++----------------------------------------------------------+
| || Event |
| ++---------+----------+----------+--------+--------+--------+
|Prev ||Receive | Receive | Receive | End of | Prune- | Expiry |
|State ||Join(*,G)| Join | Prune | Message| Pending| Timer |
| || | (S,G,rpt)| (S,G,rpt)| | Timer | Expires|
| || | | | | Expires| |
+----------++---------+----------+----------+--------+--------+--------+
| ||- | - | -> PP | - | - | - |
| || | | state | | | |
| || | | start | | | |
|NoInfo || | | Prune- | | | |
|(NI) || | | Pending | | | |
| || | | Timer; | | | |
| || | | start | | | |
| || | | Expiry | | | |
| || | | Timer | | | |
+----------++---------+----------+----------+--------+--------+--------+
| ||-> P' | -> NI | -> P | - | - | -> NI |
| ||state | state | state | | | state |
|Prune (P) || | | restart | | | |
| || | | Expiry | | | |
| || | | Timer | | | |
+----------++---------+----------+----------+--------+--------+--------+
|Prune- ||-> PP' | -> NI | - | - | -> P | - |
|Pending ||state | state | | | state | |
|(PP) || | | | | | |
+----------++---------+----------+----------+--------+--------+--------+
| ||- | - | -> P | -> NI | - | - |
|PruneTmp || | | state | state | | |
|(P') || | | restart | | | |
| || | | Expiry | | | |
| || | | Timer | | | |
+----------++---------+----------+----------+--------+--------+--------+
| ||- | - | -> PP | -> NI | - | - |
|Prune- || | | state | state | | |
|Pending- || | | restart | | | |
|Tmp (PP') || | | Expiry | | | |
| || | | Timer | | | |
+----------++---------+----------+----------+--------+--------+--------+
The transition events "Receive Join(S,G,rpt)", "Receive Prune(S,G,rpt)", and "Receive Join(*,G)" imply receiving a Join or Prune targeted to this router's primary IP address on the received interface. If the upstream neighbor address field is not correct, these state transitions in this state machine MUST NOT occur, although seeing such a packet may cause state transitions in other state machines.
遷移イベント「Receive Join（S、G、rpt）」、「Receive Prune（S、G、rpt）」、および「Receive Join（*、G）」は、このルーターのプライマリIPアドレスをターゲットとするJoinまたはPruneの受信を意味します受信したインターフェイス。アップストリームネイバーアドレスフィールドが正しくない場合、この状態マシンでこれらの状態遷移が発生してはなりません（MUST NOT）。ただし、このようなパケットを確認すると、他の状態マシンで状態遷移が発生する可能性があります。
On unnumbered interfaces on point-to-point links, the router's address should be the same as the source address it chose for the Hello message it sent over that interface. However, on point-to-point links it is RECOMMENDED that PIM Join/Prune messages with an upstream neighbor address field of all zeros also be accepted.
ポイントツーポイントリンク上の番号付けされていないインターフェイスでは、ルーターのアドレスは、そのインターフェイスを介して送信したHelloメッセージ用に選択したソースアドレスと同じである必要があります。ただし、ポイントツーポイントリンクでは、アップストリームのネイバーアドレスフィールドがすべてゼロのPIM加入/プルーニングメッセージも受け入れることをお勧めします。
Transitions from NoInfo State
NoInfo状態からの遷移
When in NoInfo (NI) state, the following event may trigger a transition:
NoInfo（NI）状態の場合、次のイベントが遷移をトリガーすることがあります。
Receive Prune(S,G,rpt) A Prune(S,G,rpt) is received on interface I with its Upstream Neighbor Address set to the router's primary IP address on I.
受信Prune（S、G、rpt）Prune（S、G、rpt）は、IのアップストリームネイバーアドレスをルーターのプライマリIPアドレスに設定して、インターフェイスIで受信されます。
The (S,G,rpt) downstream state machine on interface I transitions to the Prune-Pending state. The Expiry Timer (ET) is started and set to the HoldTime from the triggering Join/Prune message. The Prune-Pending Timer is started. It is set to the J/P_Override_Interval(I) if the router has more than one neighbor on that interface; otherwise, it is set to zero, causing it to expire immediately.
インターフェイスIの（S、G、rpt）ダウンストリームステートマシンは、プルーンペンディングステートに移行します。 Expiry Timer（ET）が開始され、トリガーとなるJoin / PruneメッセージからHoldTimeに設定されます。 Prune-Pending Timerが開始されます。ルータのインターフェイスに複数のネイバーがある場合は、J / P_Override_Interval（I）に設定されます。それ以外の場合はゼロに設定され、すぐに期限切れになります。
Transitions from Prune-Pending State
プルーンペンディング状態からの移行
When in Prune-Pending (PP) state, the following events may trigger a transition:
Prune-Pending（PP）状態の場合、次のイベントが遷移をトリガーする可能性があります。
Receive Join(*,G) A Join(*,G) is received on interface I with its Upstream Neighbor Address set to the router's primary IP address on I.
Join（*、G）の受信Join（*、G）は、IのルーターのプライマリIPアドレスに設定されたアップストリームネイバーアドレスを持つインターフェイスIで受信されます。
The (S,G,rpt) downstream state machine on interface I transitions to the Prune-Pending-Tmp state whilst the remainder of the compound Join/Prune message containing the Join(*,G) is processed.
インターフェースIの（S、G、rpt）ダウンストリームステートマシンは、Prune-Pending-Tmp状態に移行しますが、Join（*、G）を含む複合Join / Pruneメッセージの残りは処理されます。
Receive Join(S,G,rpt) A Join(S,G,rpt) is received on interface I with its Upstream Neighbor Address set to the router's primary IP address on I.
Join（S、G、rpt）の受信Join（S、G、rpt）は、IのアップストリームネイバーアドレスがルーターのプライマリIPアドレスに設定されたインターフェイスIで受信されます。
The (S,G,rpt) downstream state machine on interface I transitions to the NoInfo state. The ET and PPT are canceled.
インターフェイスIの（S、G、rpt）ダウンストリームステートマシンは、NoInfo状態に遷移します。 ETとPPTはキャンセルされます。
Prune-Pending Timer Expires The Prune-Pending Timer for the (S,G,rpt) downstream state machine on interface I expires.
Prune-Pending Timer ExpiresインターフェースIの（S、G、rpt）ダウンストリームステートマシンのPrune-Pending Timerが期限切れになります。
The (S,G,rpt) downstream state machine on interface I transitions to the Prune state.
インターフェイスIの（S、G、rpt）ダウンストリームステートマシンはプルーン状態に移行します。
Transitions from Prune State
プルーン州からの移行
When in Prune (P) state, the following events may trigger a transition:
プルーン（P）状態の場合、次のイベントが遷移をトリガーすることがあります。
Receive Join(*,G) A Join(*,G) is received on interface I with its Upstream Neighbor Address set to the router's primary IP address on I.
Join（*、G）の受信Join（*、G）は、IのルーターのプライマリIPアドレスに設定されたアップストリームネイバーアドレスを持つインターフェイスIで受信されます。
The (S,G,rpt) downstream state machine on interface I transitions to the PruneTmp state whilst the remainder of the compound Join/Prune message containing the Join(*,G) is processed.
インターフェースIの（S、G、rpt）ダウンストリームステートマシンは、PruneTmp状態に移行しますが、Join（*、G）を含む複合Join / Pruneメッセージの残りは処理されます。
Receive Join(S,G,rpt) A Join(S,G,rpt) is received on interface I with its Upstream Neighbor Address set to the router's primary IP address on I.
Join（S、G、rpt）の受信Join（S、G、rpt）は、IのアップストリームネイバーアドレスがルーターのプライマリIPアドレスに設定されたインターフェイスIで受信されます。
The (S,G,rpt) downstream state machine on interface I transitions to the NoInfo state. The ET and PPT are canceled.
インターフェイスIの（S、G、rpt）ダウンストリームステートマシンは、NoInfo状態に遷移します。 ETとPPTはキャンセルされます。
Receive Prune(S,G,rpt) A Prune(S,G,rpt) is received on interface I with its Upstream Neighbor Address set to the router's primary IP address on I.
受信Prune（S、G、rpt）Prune（S、G、rpt）は、IのアップストリームネイバーアドレスをルーターのプライマリIPアドレスに設定して、インターフェイスIで受信されます。
The (S,G,rpt) downstream state machine on interface I remains in Prune state. The Expiry Timer (ET) is restarted and is then set to the maximum of its current value and the HoldTime from the triggering Join/Prune message.
インターフェイスIの（S、G、rpt）ダウンストリームステートマシンはプルーン状態のままです。有効期限タイマー（ET）が再起動され、現在の値とトリガー/参加/プルーンメッセージからのHoldTimeの最大値に設定されます。
Expiry Timer Expires The Expiry Timer for the (S,G,rpt) downstream state machine on interface I expires.
Expiry Timer Expiresインターフェイス上の（S、G、rpt）ダウンストリームステートマシンのExpiry Timerが期限切れになります。
The (S,G,rpt) downstream state machine on interface I transitions to the NoInfo state.
インターフェイスIの（S、G、rpt）ダウンストリームステートマシンは、NoInfo状態に遷移します。
Transitions from Prune-Pending-Tmp State
Prune-Pending-Tmp状態からの遷移
When in Prune-Pending-Tmp (PP') state and processing a compound Join/Prune message, the following events may trigger a transition:
Prune-Pending-Tmp（PP '）状態で、複合Join / Pruneメッセージを処理している場合、次のイベントが遷移をトリガーすることがあります。
Receive Prune(S,G,rpt) The compound Join/Prune message contains a Prune(S,G,rpt) that is received on interface I with its Upstream Neighbor Address set to the router's primary IP address on I.
受信Prune（S、G、rpt）複合Join / Pruneメッセージには、インターフェイスIで受信されたPrune（S、G、rpt）が含まれており、そのアップストリームネイバーアドレスがIのルーターのプライマリIPアドレスに設定されています。
The (S,G,rpt) downstream state machine on interface I transitions back to the Prune-Pending state. The Expiry Timer (ET) is restarted and is then set to the maximum of its current value and the HoldTime from the triggering Join/Prune message.
インターフェイスIの（S、G、rpt）ダウンストリームステートマシンは、プルーンペンディングステートに戻ります。有効期限タイマー（ET）が再起動され、現在の値とトリガー/参加/プルーンメッセージからのHoldTimeの最大値に設定されます。
End of Message The end of the compound Join/Prune message is reached.
メッセージの終わり複合Join / Pruneメッセージの終わりに達しました。
The (S,G,rpt) downstream state machine on interface I transitions to the NoInfo state. The ET and PPT are canceled.
インターフェイスIの（S、G、rpt）ダウンストリームステートマシンは、NoInfo状態に遷移します。 ETとPPTはキャンセルされます。
Transitions from PruneTmp State
PruneTmp状態からの遷移
When in PruneTmp (P') state and processing a compound Join/Prune message, the following events may trigger a transition:
PruneTmp（P '）状態で、複合Join / Pruneメッセージを処理しているときに、次のイベントが遷移をトリガーする場合があります。
Receive Prune(S,G,rpt) The compound Join/Prune message contains a Prune(S,G,rpt).
受信Prune（S、G、rpt）複合Join / Pruneメッセージには、Prune（S、G、rpt）が含まれています。
The (S,G,rpt) downstream state machine on interface I transitions back to the Prune state. The Expiry Timer (ET) is restarted and is then set to the maximum of its current value and the HoldTime from the triggering Join/Prune message.
インターフェイスIの（S、G、rpt）ダウンストリームステートマシンは、プルーンステートに戻ります。有効期限タイマー（ET）が再起動され、現在の値とトリガー/参加/プルーンメッセージからのHoldTimeの最大値に設定されます。
End of Message The end of the compound Join/Prune message is reached.
メッセージの終わり複合Join / Pruneメッセージの終わりに達しました。
The (S,G,rpt) downstream state machine on interface I transitions to the NoInfo state. ET is canceled.
インターフェイスIの（S、G、rpt）ダウンストリームステートマシンは、NoInfo状態に遷移します。 ETはキャンセルされます。
Note: Receiving a Prune(*,G) does not affect the (S,G,rpt) downstream state machine.
注：Prune（*、G）を受信しても、（S、G、rpt）ダウンストリーム状態マシンには影響しません。
The per-interface state machines for (*,G) hold join state from downstream PIM routers. This state then determines whether a router needs to propagate a Join(*,G) upstream towards the RP.
（*、G）のインターフェイスごとの状態マシンは、ダウンストリームPIMルーターからの参加状態を保持します。次に、この状態は、ルーターがJoin（*、G）アップストリームをRPに向かって伝播する必要があるかどうかを決定します。
If a router wishes to propagate a Join(*,G) upstream, it must also watch for messages on its upstream interface from other routers on that subnet, and these may modify its behavior. If it sees a Join(*,G) to the correct upstream neighbor, it should suppress its own Join(*,G). If it sees a Prune(*,G) to the correct upstream neighbor, it should be prepared to override that prune by sending a Join(*,G) almost immediately. Finally, if it sees the Generation ID (see Section 4.3) of the correct upstream neighbor change, it knows that the upstream neighbor has lost state, and it should be prepared to refresh the state by sending a Join(*,G) almost immediately.
ルータがJoin（*、G）アップストリームを伝播したい場合は、そのサブネット上の他のルータからのアップストリームインターフェイスのメッセージも監視する必要があり、これらはその動作を変更する可能性があります。正しいアップストリームネイバーへのJoin（*、G）が検出された場合、自身のJoin（*、G）を抑制する必要があります。正しい上流のネイバーへのPrune（*、G）を検出した場合、Join（*、G）をほとんどすぐに送信して、そのプルーンをオーバーライドする準備をする必要があります。最後に、正しい上流ネイバーの変更の世代ID（セクション4.3を参照）が見つかれば、上流ネイバーの状態が失われていることがわかり、Join（*、G）をすぐに送信して状態を更新する準備をする必要があります。 。
If a (*,G) Assert occurs on the upstream interface, and this changes this router's idea of the upstream neighbor, it should be prepared to ensure that the Assert winner is aware of downstream routers by sending a Join(*,G) almost immediately.
（*、G）アサートがアップストリームインターフェイスで発生し、これがこのルーターのアップストリームネイバーの概念を変更する場合、アサートの勝者がJoin（*、G）をほぼ送信することによってダウンストリームのルーターを認識できるように準備する必要がありますすぐに。
In addition, if the MRIB changes to indicate that the next hop towards the RP has changed, and either the upstream interface changes or there is no Assert winner on the upstream interface, the router should prune off from the old next hop and join towards the new next hop.
さらに、MRIBが変更されてRPへのネクストホップが変更され、アップストリームインターフェイスが変更されるか、アップストリームインターフェイスにアサート勝者がない場合、ルータは古いネクストホップからプルーニングして、新しいネクストホップ。
The upstream (*,G) state machine only contains two states:
アップストリーム（*、G）状態マシンには、2つの状態のみが含まれます。
Not Joined The downstream state machines indicate that the router does not need to join the RP tree for this group.
参加していないダウンストリームステートマシンは、ルーターがこのグループのRPツリーに参加する必要がないことを示しています。
Joined The downstream state machines indicate that the router should join the RP tree for this group.
参加ダウンストリームステートマシンは、ルータがこのグループのRPツリーに参加する必要があることを示しています。
In addition, one timer JT(*,G) is kept that is used to trigger the sending of a Join(*,G) to the upstream next hop towards the RP, RPF'(*,G).
さらに、RPへのアップストリームネクストホップであるRPF '（*、G）へのJoin（*、G）の送信をトリガーするために使用される1つのタイマーJT（*、G）が保持されます。
Figure 5: Upstream (*,G) State Machine
図5：アップストリーム（*、G）ステートマシン
+-------------------++-------------------------------------------------+
| || Event |
| Prev State ++------------------------+------------------------+
| || JoinDesired(*,G) | JoinDesired(*,G) |
| || ->True | ->False |
+-------------------++------------------------+------------------------+
| || -> J state | - |
| NotJoined (NJ) || Send Join(*,G); | |
| || set Join Timer to | |
| || t_periodic | |
+-------------------++------------------------+------------------------+
| Joined (J) || - | -> NJ state |
| || | Send Prune(*,G); |
| || | cancel Join Timer |
+-------------------++------------------------+------------------------+
In addition, we have the following transitions, which occur within the Joined state:
さらに、Joined状態内で発生する次の遷移があります。
+----------------------------------------------------------------------+
| In Joined (J) State |
+----------------+-----------------+-----------------+-----------------+
|Timer Expires | See Join(*,G) | See Prune(*,G) | RPF'(*,G) |
| | to RPF'(*,G) | to RPF'(*,G) | changes due to |
| | | | an Assert |
+----------------+-----------------+-----------------+-----------------+
|Send | Increase Join | Decrease Join | Decrease Join |
|Join(*,G); set | Timer to | Timer to | Timer to |
|Join Timer to | t_joinsuppress | t_override | t_override |
|t_periodic | | | |
+----------------+-----------------+-----------------+-----------------+
+----------------------------------------------------------------------+
| In Joined (J) State |
+----------------------------------+-----------------------------------+
| RPF'(*,G) changes not | RPF'(*,G) GenID changes |
| due to an Assert | |
+----------------------------------+-----------------------------------+
| Send Join(*,G) to new | Decrease Join Timer to |
| next hop; send | t_override |
| Prune(*,G) to old next | |
| hop; set Join Timer to | |
| t_periodic | |
+----------------------------------+-----------------------------------+
This state machine uses the following macro:
このステートマシンは次のマクロを使用します。
bool JoinDesired(*,G) {
if (immediate_olist(*,G) != NULL)
return TRUE
else
return FALSE
}
JoinDesired(*,G) is true when the router has forwarding state that would cause it to forward traffic for G using shared tree state. Note that although JoinDesired is true, the router's sending of a Join(*,G) message may be suppressed by another router sending a Join(*,G) onto the upstream interface.
JoinDesired（*、G）は、ルーターに転送状態があり、共有ツリー状態を使用してGのトラフィックを転送する場合にtrueになります。 JoinDesiredはtrueですが、Join（*、G）メッセージを送信するルーターは、Join（*、G）をアップストリームインターフェイスに送信する別のルーターによって抑制される場合があります。
Transitions from NotJoined State
NotJoined状態からの遷移
When the upstream (*,G) state machine is in NotJoined state, the following event may trigger a state transition:
アップストリーム（*、G）ステートマシンがNotJoined状態の場合、次のイベントが状態遷移をトリガーする可能性があります。
JoinDesired(*,G) becomes True The macro JoinDesired(*,G) becomes True, e.g., because the downstream state for (*,G) has changed so that at least one interface is in immediate_olist(*,G).
JoinDesired（*、G）がTrueになるマクロJoinDesired（*、G）がTrueになるのは、たとえば、（*、G）のダウンストリーム状態が変更され、少なくとも1つのインターフェイスがimmediate_olist（*、G）になるためです。
The upstream (*,G) state machine transitions to the Joined state. Send Join(*,G) to the appropriate upstream neighbor, which is RPF'(*,G). Set the Join Timer (JT) to expire after t_periodic seconds.
アップストリーム（*、G）ステートマシンは、Joined状態に遷移します。 Join（*、G）をRPF '（*、G）である適切な上流ネイバーに送信します。結合タイマー（JT）をt_periodic秒後に期限切れになるように設定します。
Transitions from Joined State
参加国からの移行
When the upstream (*,G) state machine is in Joined state, the following events may trigger state transitions:
アップストリーム（*、G）状態マシンが結合状態にある場合、次のイベントが状態遷移をトリガーする可能性があります。
JoinDesired(*,G) becomes False The macro JoinDesired(*,G) becomes False, e.g., because the downstream state for (*,G) has changed so no interface is in immediate_olist(*,G).
JoinDesired（*、G）がFalseになるマクロJoinDesired（*、G）がFalseになるのは、たとえば、（*、G）のダウンストリーム状態が変更されたため、immediate_olist（*、G）にインターフェイスがないためです。
The upstream (*,G) state machine transitions to the NotJoined state. Send Prune(*,G) to the appropriate upstream neighbor, which is RPF'(*,G). Cancel the Join Timer (JT).
アップストリーム（*、G）の状態マシンは、NotJoined状態に遷移します。 Prune（*、G）をRPF '（*、G）である適切な上流ネイバーに送信します。参加タイマー（JT）をキャンセルします。
Join Timer Expires The Join Timer (JT) expires, indicating time to send a Join(*,G).
結合タイマーの期限切れ結合タイマー（JT）が期限切れになり、Join（*、G）を送信する時間を示します。
Send Join(*,G) to the appropriate upstream neighbor, which is RPF'(*,G). Restart the Join Timer (JT) to expire after t_periodic seconds.
Join（*、G）をRPF '（*、G）である適切な上流ネイバーに送信します。結合タイマー（JT）を再起動して、t_periodic秒後に期限切れにします。
See Join(*,G) to RPF'(*,G) This event is only relevant if RPF_interface(RP(G)) is a shared medium. This router sees another router on RPF_interface(RP(G)) send a Join(*,G) to RPF'(*,G). This causes this router to suppress its own Join.
Join（*、G）to RPF '（*、G）を参照してください。このイベントは、RPF_interface（RP（G））が共有メディアである場合にのみ関連します。このルーターは、RPF_interface（RP（G））上の別のルーターを認識して、Join（*、G）をRPF '（*、G）に送信します。これにより、このルーターは独自の参加を抑制します。
The upstream (*,G) state machine remains in Joined state.
アップストリーム（*、G）の状態マシンは、Joined状態のままです。
Let t_joinsuppress be the minimum of t_suppressed and the HoldTime from the Join/Prune message triggering this event. If the Join Timer is set to expire in less than t_joinsuppress seconds, reset it so that it expires after t_joinsuppress seconds. If the Join Timer is set to expire in more than t_joinsuppress seconds, leave it unchanged.
t_joinsuppressをt_suppressedの最小値とし、このイベントをトリガーするJoin / PruneメッセージからのHoldTimeとします。結合タイマーがt_joinsuppress秒未満で期限切れになるように設定されている場合は、タイマーをリセットしてt_joinsuppress秒後に期限切れになるようにします。結合タイマーがt_joinsuppress秒を超えて期限切れになるように設定されている場合は、変更しないでください。
See Prune(*,G) to RPF'(*,G) This event is only relevant if RPF_interface(RP(G)) is a shared medium. This router sees another router on RPF_interface(RP(G)) send a Prune(*,G) to RPF'(*,G). As this router is in Joined state, it must override the Prune after a short random interval.
Prune（*、G）to RPF '（*、G）を参照してください。このイベントは、RPF_interface（RP（G））が共有メディアである場合にのみ関連します。このルーターは、RPF_interface（RP（G））上の別のルーターがPrune（*、G）をRPF '（*、G）に送信するのを確認します。このルーターは参加状態にあるため、短いランダムな間隔の後、プルーンをオーバーライドする必要があります。
The upstream (*,G) state machine remains in Joined state. If the Join Timer is set to expire in more than t_override seconds, reset it so that it expires after t_override seconds. If the Join Timer is set to expire in less than t_override seconds, leave it unchanged.
アップストリーム（*、G）の状態マシンは、Joined状態のままです。結合タイマーがt_override秒を超えて期限切れになるように設定されている場合は、t_override秒後に期限切れになるようにリセットします。結合タイマーがt_override秒未満で期限切れになるように設定されている場合は、変更しないでください。
RPF'(*,G) changes due to an Assert The current next hop towards the RP changes due to an Assert(*,G) on the RPF_interface(RP(G)).
アサートによるRPF '（*、G）の変化RPF_interface（RP（G））のアサート（*、G）によるRPへの現在のネクストホップの変化。
The upstream (*,G) state machine remains in Joined state. If the Join Timer is set to expire in more than t_override seconds, reset it so that it expires after t_override seconds. If the Join Timer is set to expire in less than t_override seconds, leave it unchanged.
アップストリーム（*、G）の状態マシンは、Joined状態のままです。結合タイマーがt_override秒を超えて期限切れになるように設定されている場合は、t_override秒後に期限切れになるようにリセットします。結合タイマーがt_override秒未満で期限切れになるように設定されている場合は、変更しないでください。
RPF'(*,G) changes not due to an Assert An event occurred that caused the next hop towards the RP for G to change. This may be caused by a change in the MRIB routing database or the group-to-RP mapping. Note that this transition does not occur if an Assert is active and the upstream interface does not change.
アサートによるものではないRPF '（*、G）変更GのRPへのネクストホップを変更させるイベントが発生しました。これは、MRIBルーティングデータベースまたはグループからRPへのマッピングの変更が原因である可能性があります。アサートがアクティブで、アップストリームインターフェイスが変更されていない場合、この遷移は発生しないことに注意してください。
The upstream (*,G) state machine remains in Joined state. Send Join(*,G) to the new upstream neighbor, which is the new value of RPF'(*,G). Send Prune(*,G) to the old upstream neighbor, which is the old value of RPF'(*,G). Use the new value of RP(G) in the Prune(*,G) message or all zeros if RP(G) becomes unknown (old value of RP(G) may be used instead to improve behavior in routers implementing older versions of this specification). Set the Join Timer (JT) to expire after t_periodic seconds.
アップストリーム（*、G）の状態マシンは、Joined状態のままです。 Join（*、G）を新しいアップストリームネイバーに送信します。これはRPF '（*、G）の新しい値です。 Prune（*、G）を古いアップストリームネイバーに送信します。これは、RPF '（*、G）の古い値です。 Prune（*、G）メッセージでRP（G）の新しい値を使用するか、RP（G）が不明になった場合はすべてゼロ（古いバージョンのRP（G）を代わりに使用して、この古いバージョンを実装するルーターの動作を改善することができます仕様）。結合タイマー（JT）をt_periodic秒後に期限切れになるように設定します。
RPF'(*,G) GenID changes The Generation ID of the router that is RPF'(*,G) changes. This normally means that this neighbor has lost state, and so the state must be refreshed.
RPF '（*、G）GenIDの変更RPF'（*、G）であるルーターの世代IDが変更されます。これは通常、このネイバーの状態が失われたことを意味するため、状態を更新する必要があります。
The upstream (*,G) state machine remains in Joined state. If the Join Timer is set to expire in more than t_override seconds, reset it so that it expires after t_override seconds.
アップストリーム（*、G）の状態マシンは、Joined状態のままです。結合タイマーがt_override秒を超えて期限切れになるように設定されている場合は、t_override秒後に期限切れになるようにリセットします。
The per-interface state machines for (S,G) hold join state from downstream PIM routers. This state then determines whether a router needs to propagate a Join(S,G) upstream towards the source.
（S、G）のインターフェイスごとのステートマシンは、ダウンストリームPIMルーターからの参加状態を保持します。次に、この状態は、ルーターがJoin（S、G）アップストリームをソースに向かって伝播する必要があるかどうかを決定します。
If a router wishes to propagate a Join(S,G) upstream, it must also watch for messages on its upstream interface from other routers on that subnet, and these may modify its behavior. If it sees a Join(S,G) to the correct upstream neighbor, it should suppress its own Join(S,G). If it sees a Prune(S,G), Prune(S,G,rpt), or Prune(*,G) to the correct upstream neighbor towards S, it should be prepared to override that prune by scheduling a Join(S,G) to be sent almost immediately. Finally, if it sees the Generation ID of its upstream neighbor change, it knows that the upstream neighbor has lost state, and it should refresh the state by scheduling a Join(S,G) to be sent almost immediately.
ルータがJoin（S、G）アップストリームを伝播したい場合は、そのサブネット上の他のルータからのアップストリームインターフェイスのメッセージも監視する必要があり、これらはその動作を変更する可能性があります。正しいアップストリームネイバーへのJoin（S、G）が検出された場合、自身のJoin（S、G）を抑制する必要があります。 Sへの正しい上流ネイバーへのPrune（S、G）、Prune（S、G、rpt）、またはPrune（*、G）が検出された場合、Join（S、 G）すぐに送信される。最後に、上流のネイバーの変更の世代IDを確認すると、上流のネイバーの状態が失われていることがわかり、Join（S、G）がほとんどすぐに送信されるようにスケジュールして、状態を更新する必要があります。
If an (S,G) Assert occurs on the upstream interface, and this changes this router's idea of the upstream neighbor, it should be prepared to ensure that the Assert winner is aware of downstream routers by scheduling a Join(S,G) to be sent almost immediately.
（S、G）アサートがアップストリームインターフェイスで発生し、これによりこのルーターのアップストリームネイバーの概念が変更された場合、アサートの勝者が次のようにJoin（S、G）をスケジューリングすることにより、アサートの勝者がダウンストリームルータを認識できるように準備する必要があります。ほとんどすぐに送信されます。
In addition, if MRIB changes cause the next hop towards the source to change, and either the upstream interface changes or there is no Assert winner on the upstream interface, the router should send a prune to the old next hop and a join to the new next hop.
さらに、MRIBの変更によりソースへのネクストホップが変更され、アップストリームインターフェイスが変更されるか、アップストリームインターフェイスにアサート勝者がない場合、ルータは古いネクストホップにプルーンを送信し、新しいネクストホップにジョインする必要があります。ネクストホップ。
The upstream (S,G) state machine only contains two states:
アップストリーム（S、G）ステートマシンには、次の2つの状態のみが含まれます。
Not Joined The downstream state machines and local membership information do not indicate that the router needs to join the shortest-path tree for this (S,G).
参加していないダウンストリームステートマシンとローカルメンバーシップ情報は、ルーターがこの（S、G）の最短パスツリーに参加する必要があることを示していません。
Joined The downstream state machines and local membership information indicate that the router should join the shortest-path tree for this (S,G).
参加ダウンストリームステートマシンとローカルメンバーシップ情報は、ルーターがこの（S、G）の最短パスツリーに参加する必要があることを示しています。
In addition, one timer JT(S,G) is kept that is used to trigger the sending of a Join(S,G) to the upstream next hop towards S, RPF'(S,G).
さらに、1つのタイマーJT（S、G）が保持され、Join（S、G）のSへのアップストリームネクストホップへの送信をトリガーするために使用されます。
Figure 6: Upstream (S,G) State Machine
図6：アップストリーム（S、G）ステートマシン
+-------------------+--------------------------------------------------+
| | Event |
| Prev State +-------------------------+------------------------+
| | JoinDesired(S,G) | JoinDesired(S,G) |
| | ->True | ->False |
+-------------------+-------------------------+------------------------+
| NotJoined (NJ) | -> J state | - |
| | Send Join(S,G); | |
| | set Join Timer to | |
| | t_periodic | |
+-------------------+-------------------------+------------------------+
| Joined (J) | - | -> NJ state |
| | | Send Prune(S,G); |
| | | set SPTbit(S,G) to |
| | | FALSE; cancel Join |
| | | Timer |
+-------------------+-------------------------+------------------------+
In addition, we have the following transitions, which occur within the Joined state:
さらに、Joined状態内で発生する次の遷移があります。
+----------------------------------------------------------------------+
| In Joined (J) State |
+-----------------+-----------------+-----------------+----------------+
| Timer Expires | See Join(S,G) | See Prune(S,G) | See Prune |
| | to RPF'(S,G) | to RPF'(S,G) | (S,G,rpt) to |
| | | | RPF'(S,G) |
+-----------------+-----------------+-----------------+----------------+
| Send | Increase Join | Decrease Join | Decrease Join |
| Join(S,G); set | Timer to | Timer to | Timer to |
| Join Timer to | t_joinsuppress | t_override | t_override |
| t_periodic | | | |
+-----------------+-----------------+-----------------+----------------+
+----------------------------------------------------------------------+
| In Joined (J) State |
+-----------------+-----------------+----------------+-----------------+
| See Prune(*,G) | RPF'(S,G) | RPF'(S,G) | RPF'(S,G) |
| to RPF'(S,G) | changes not | GenID changes | changes due to |
| | due to an | | an Assert |
| | Assert | | |
+-----------------+-----------------+----------------+-----------------+
| Decrease Join | Send Join(S,G) | Decrease Join | Decrease Join |
| Timer to | to new next | Timer to | Timer to |
| t_override | hop; send | t_override | t_override |
| | Prune(S,G) to | | |
| | old next hop; | | |
| | set Join Timer | | |
| | to t_periodic | | |
+-----------------+-----------------+----------------+-----------------+
This state machine uses the following macro:
このステートマシンは次のマクロを使用します。
bool JoinDesired(S,G) {
return( immediate_olist(S,G) != NULL
OR ( KeepaliveTimer(S,G) is running
AND inherited_olist(S,G) != NULL ) )
}
JoinDesired(S,G) is true when the router has forwarding state that would cause it to forward traffic for G using source tree state. The source tree state can be as a result of either active source-specific join state, or the (S,G) Keepalive Timer and active non-source-specific state. Note that although JoinDesired is true, the router's sending of a Join(S,G) message may be suppressed by another router sending a Join(S,G) onto the upstream interface.
JoinDesired（S、G）は、ソースツリーの状態を使用してGのトラフィックを転送する原因となる転送状態がルーターにある場合にtrueになります。ソースツリーの状態は、アクティブなソース固有の結合状態、または（S、G）キープアライブタイマーとアクティブな非ソース固有の状態のいずれかの結果である可能性があります。 JoinDesiredはtrueですが、Join（S、G）メッセージのルーターの送信は、Join（S、G）をアップストリームインターフェイスに送信する別のルーターによって抑制される場合があることに注意してください。
Transitions from NotJoined State
NotJoined状態からの遷移
When the upstream (S,G) state machine is in NotJoined state, the following event may trigger a state transition:
アップストリーム（S、G）状態マシンがNotJoined状態の場合、次のイベントが状態遷移をトリガーする可能性があります。
JoinDesired(S,G) becomes True The macro JoinDesired(S,G) becomes True, e.g., because the downstream state for (S,G) has changed so that at least one interface is in inherited_olist(S,G).
JoinDesired（S、G）がTrueになるマクロJoinDesired（S、G）がTrueになるのは、たとえば、（S、G）のダウンストリーム状態が変更され、少なくとも1つのインターフェイスがinherited_olist（S、G）になるためです。
The upstream (S,G) state machine transitions to the Joined state. Send Join(S,G) to the appropriate upstream neighbor, which is RPF'(S,G). Set the Join Timer (JT) to expire after t_periodic seconds.
アップストリーム（S、G）ステートマシンは、Joined状態に遷移します。 Join（S、G）をRPF '（S、G）である適切な上流ネイバーに送信します。結合タイマー（JT）をt_periodic秒後に期限切れになるように設定します。
Transitions from Joined State
参加国からの移行
When the upstream (S,G) state machine is in Joined state, the following events may trigger state transitions:
アップストリーム（S、G）状態マシンが結合状態にある場合、次のイベントが状態遷移をトリガーする可能性があります。
JoinDesired(S,G) becomes False The macro JoinDesired(S,G) becomes False, e.g., because the downstream state for (S,G) has changed so no interface is in inherited_olist(S,G).
JoinDesired（S、G）がFalseになるマクロJoinDesired（S、G）がFalseになるのは、たとえば（S、G）のダウンストリーム状態が変更されたため、inherited_olist（S、G）にインターフェイスがないためです。
The upstream (S,G) state machine transitions to the NotJoined state. Send Prune(S,G) to the appropriate upstream neighbor, which is RPF'(S,G). Cancel the Join Timer (JT), and set SPTbit(S,G) to FALSE.
アップストリーム（S、G）状態マシンは、NotJoined状態に遷移します。 Prune（S、G）をRPF '（S、G）である適切な上流ネイバーに送信します。結合タイマー（JT）をキャンセルし、SPTbit（S、G）をFALSEに設定します。
Join Timer Expires The Join Timer (JT) expires, indicating time to send a Join(S,G).
結合タイマーの期限切れ結合タイマー（JT）が期限切れになり、Join（S、G）を送信する時間を示します。
Send Join(S,G) to the appropriate upstream neighbor, which is RPF'(S,G). Restart the Join Timer (JT) to expire after t_periodic seconds.
Join（S、G）をRPF '（S、G）である適切な上流ネイバーに送信します。結合タイマー（JT）を再起動して、t_periodic秒後に期限切れにします。
See Join(S,G) to RPF'(S,G) This event is only relevant if RPF_interface(S) is a shared medium. This router sees another router on RPF_interface(S) send a Join(S,G) to RPF'(S,G). This causes this router to suppress its own Join.
Join（S、G）to RPF '（S、G）を参照してください。このイベントは、RPF_interface（S）が共有メディアである場合にのみ関連します。このルーターは、RPF_interface（S）上の別のルーターがJoin（S、G）をRPF '（S、G）に送信するのを確認します。これにより、このルーターは独自の参加を抑制します。
The upstream (S,G) state machine remains in Joined state.
アップストリーム（S、G）ステートマシンは、Joined状態のままです。
Let t_joinsuppress be the minimum of t_suppressed and the HoldTime from the Join/Prune message triggering this event.
t_joinsuppressをt_suppressedの最小値とし、このイベントをトリガーするJoin / PruneメッセージからのHoldTimeとします。
If the Join Timer is set to expire in less than t_joinsuppress seconds, reset it so that it expires after t_joinsuppress seconds. If the Join Timer is set to expire in more than t_joinsuppress seconds, leave it unchanged.
結合タイマーがt_joinsuppress秒未満で期限切れになるように設定されている場合は、タイマーをリセットしてt_joinsuppress秒後に期限切れになるようにします。結合タイマーがt_joinsuppress秒を超えて期限切れになるように設定されている場合は、変更しないでください。
See Prune(S,G) to RPF'(S,G) This event is only relevant if RPF_interface(S) is a shared medium. This router sees another router on RPF_interface(S) send a Prune(S,G) to RPF'(S,G). As this router is in Joined state, it must override the Prune after a short random interval.
Prune（S、G）to RPF '（S、G）を参照してください。このイベントは、RPF_interface（S）が共有メディアである場合にのみ関連します。このルーターは、RPF_interface（S）上の別のルーターがPrune（S、G）をRPF '（S、G）に送信するのを確認します。このルーターは参加状態にあるため、短いランダムな間隔の後、プルーンをオーバーライドする必要があります。
The upstream (S,G) state machine remains in Joined state. If the Join Timer is set to expire in more than t_override seconds, reset it so that it expires after t_override seconds.
アップストリーム（S、G）ステートマシンは、Joined状態のままです。結合タイマーがt_override秒を超えて期限切れになるように設定されている場合は、t_override秒後に期限切れになるようにリセットします。
See Prune(S,G,rpt) to RPF'(S,G) This event is only relevant if RPF_interface(S) is a shared medium. This router sees another router on RPF_interface(S) send a Prune(S,G,rpt) to RPF'(S,G). If the upstream router is an RFC-2362-compliant PIM router, then the Prune(S,G,rpt) will cause it to stop forwarding. For backwards compatibility, this router should override the prune so that forwarding continues.
Prune（S、G、rpt）to RPF '（S、G）を参照してください。このイベントは、RPF_interface（S）が共有メディアである場合にのみ関連します。このルーターは、RPF_interface（S）上の別のルーターがPrune（S、G、rpt）をRPF '（S、G）に送信するのを確認します。上流ルーターがRFC-2362準拠のPIMルーターである場合、Prune（S、G、rpt）は転送を停止します。下位互換性のために、このルーターはプルーニングをオーバーライドして、転送が続行されるようにする必要があります。
The upstream (S,G) state machine remains in Joined state. If the Join Timer is set to expire in more than t_override seconds, reset it so that it expires after t_override seconds.
アップストリーム（S、G）ステートマシンは、Joined状態のままです。結合タイマーがt_override秒を超えて期限切れになるように設定されている場合は、t_override秒後に期限切れになるようにリセットします。
See Prune(*,G) to RPF'(S,G) This event is only relevant if RPF_interface(S) is a shared medium. This router sees another router on RPF_interface(S) send a Prune(*,G) to RPF'(S,G). If the upstream router is an RFC-2362-compliant PIM router, then the Prune(*,G) will cause it to stop forwarding. For backwards compatibility, this router should override the prune so that forwarding continues.
Prune（*、G）to RPF '（S、G）を参照してください。このイベントは、RPF_interface（S）が共有メディアである場合にのみ関連します。このルーターは、RPF_interface（S）上の別のルーターがPrune（*、G）をRPF '（S、G）に送信するのを確認します。上流のルーターがRFC-2362準拠のPIMルーターである場合、Prune（*、G）は転送を停止します。下位互換性のために、このルーターはプルーニングをオーバーライドして、転送が続行されるようにする必要があります。
The upstream (S,G) state machine remains in Joined state. If the Join Timer is set to expire in more than t_override seconds, reset it so that it expires after t_override seconds.
アップストリーム（S、G）ステートマシンは、Joined状態のままです。結合タイマーがt_override秒を超えて期限切れになるように設定されている場合は、t_override秒後に期限切れになるようにリセットします。
RPF'(S,G) changes due to an Assert The current next hop towards S changes due to an Assert(S,G) on the RPF_interface(S).
アサートによるRPF '（S、G）の変化RPF_interface（S）でのアサート（S、G）によるSへの現在のネクストホップの変化。
The upstream (S,G) state machine remains in Joined state. If the Join Timer is set to expire in more than t_override seconds, reset it so that it expires after t_override seconds. If the Join Timer is set to expire in less than t_override seconds, leave it unchanged.
アップストリーム（S、G）ステートマシンは、Joined状態のままです。結合タイマーがt_override秒を超えて期限切れになるように設定されている場合は、t_override秒後に期限切れになるようにリセットします。結合タイマーがt_override秒未満で期限切れになるように設定されている場合は、変更しないでください。
RPF'(S,G) changes not due to an Assert An event occurred that caused the next hop towards S to change. Note that this transition does not occur if an Assert is active and the upstream interface does not change.
アサートによるものではないRPF '（S、G）変更Sへのネクストホップを変更させるイベントが発生しました。アサートがアクティブで、アップストリームインターフェイスが変更されていない場合、この遷移は発生しないことに注意してください。
The upstream (S,G) state machine remains in Joined state. Send Join(S,G) to the new upstream neighbor, which is the new value of RPF'(S,G). Send Prune(S,G) to the old upstream neighbor, which is the old value of RPF'(S,G). Set the Join Timer (JT) to expire after t_periodic seconds.
アップストリーム（S、G）ステートマシンは、Joined状態のままです。 Join（S、G）を新しいアップストリームネイバーに送信します。これはRPF '（S、G）の新しい値です。 Prune（S、G）をRPF '（S、G）の古い値である古いアップストリームネイバーに送信します。結合タイマー（JT）をt_periodic秒後に期限切れになるように設定します。
RPF'(S,G) GenID changes The Generation ID of the router that is RPF'(S,G) changes. This normally means that this neighbor has lost state, and so the state must be refreshed.
RPF '（S、G）GenIDの変更RPF'（S、G）であるルーターの世代IDが変更されます。これは通常、このネイバーの状態が失われたことを意味するため、状態を更新する必要があります。
The upstream (S,G) state machine remains in Joined state. If the Join Timer is set to expire in more than t_override seconds, reset it so that it expires after t_override seconds.
アップストリーム（S、G）ステートマシンは、Joined状態のままです。結合タイマーがt_override秒を超えて期限切れになるように設定されている場合は、t_override秒後に期限切れになるようにリセットします。
(S,G,rpt) Joins and Prunes are (S,G) Joins or Prunes sent on the RP tree with the RPT bit set, either to modify the results of (*,G) Joins, or to override the behavior of other upstream LAN peers. The next section describes the rules for sending triggered messages. This section describes the rules for including a Prune(S,G,rpt) message with a Join(*,G).
（S、G、rpt）結合とプルーンは（S、G）結合またはプルーンであり、RPTビットが設定されたRPツリーで送信され、（*、G）結合の結果を変更するか、他の結合の動作をオーバーライドします。アップストリームLANピア。次のセクションでは、トリガーされたメッセージを送信するためのルールについて説明します。このセクションでは、Prune（S、G、rpt）メッセージをJoin（*、G）に含めるためのルールについて説明します。
When a router is going to send a Join(*,G), it should use the following pseudocode, for each (S,G) for which it has state, to decide whether to include a Prune(S,G,rpt) in the compound Join/Prune message:
ルーターがJoin（*、G）を送信する場合、Prune（S、G、rpt）を含めるかどうかを決定するために、状態を持つ（S、G）ごとに次の疑似コードを使用する必要があります複合Join / Pruneメッセージ：
if( SPTbit(S,G) == TRUE ) {
# Note: If receiving (S,G) on the SPT, we only prune off the
# shared tree if the RPF neighbors differ.
if( RPF'(*,G) != RPF'(S,G) ) {
add Prune(S,G,rpt) to compound message
}
} else if ( inherited_olist(S,G,rpt) == NULL ) {
# Note: All (*,G) olist interfaces received RPT prunes for (S,G).
add Prune(S,G,rpt) to compound message
} else if ( RPF'(*,G) != RPF'(S,G,rpt) {
# Note: We joined the shared tree, but there was an (S,G) assert
# and the source tree RPF neighbor is different.
add Prune(S,G,rpt) to compound message
}
Note that Join(S,G,rpt) is normally sent not as a periodic message, but only as a triggered message.
Join（S、G、rpt）は通常、定期的なメッセージとしてではなく、トリガーされたメッセージとしてのみ送信されることに注意してください。
The state machine for (S,G,rpt) triggered messages is required per-(S,G) when there is (*,G) join state at a router, and the router or any of its upstream LAN peers wishes to prune S off the RP tree.
（S、G、rpt）でトリガーされたメッセージの状態マシンは、ルーターに（*、G）結合状態があり、ルーターまたはそのアップストリームLANピアのいずれかがSをプルーニングしたい場合、（S、G）ごとに必要です。 RPツリーから。
There are three states in the state machine. One of the states is when there is no (*,G) join state at this router. If there is (*,G) join state at the router, then the state machine must be at one of the other two states. The three states are:
ステートマシンには3つの状態があります。状態の1つは、このルーターに（*、G）結合状態がない場合です。ルーターに（*、G）結合状態がある場合、状態マシンは他の2つの状態のいずれかでなければなりません。 3つの状態は次のとおりです。
Pruned(S,G,rpt) (*,G) Joined, but (S,G,rpt) pruned.
Pruned（S、G、rpt）（*、G）結合されましたが、（S、G、rpt）は除去されました。
NotPruned(S,G,rpt) (*,G) Joined, and (S,G,rpt) not pruned.
NotPruned（S、G、rpt）（*、G）結合され、（S、G、rpt）は除去されません。
RPTNotJoined(G) (*,G) has not been joined.
RPTNotJoined（G）（*、G）は参加していません。
In addition, there is an (S,G,rpt) Override Timer, OT(S,G,rpt), which is used to delay triggered Join(S,G,rpt) messages to prevent implosions of triggered messages.
さらに、（S、G、rpt）オーバーライドタイマーOT（S、G、rpt）があります。これは、トリガーされたJoin（S、G、rpt）メッセージを遅延させて、トリガーされたメッセージの内破を防ぐために使用されます。
Figure 7: Upstream (S,G,rpt) State Machine for Triggered Messages
図7：トリガーされたメッセージのアップストリーム（S、G、rpt）ステートマシン
+------------++--------------------------------------------------------+
| || Event |
| ++--------------+--------------+-------------+------------+
|Prev State || PruneDesired | PruneDesired | RPTJoin | inherited_ |
| || (S,G,rpt) | (S,G,rpt) | Desired(G) | olist |
| || ->True | ->False | ->False | (S,G,rpt) |
| || | | | ->non-NULL |
+------------++--------------+--------------+-------------+------------+
|RPTNotJoined|| -> P state | - | - | -> NP state|
|(G) (NJ) || | | | |
+------------++--------------+--------------+-------------+------------+
|Pruned || - | -> NP state | -> NJ state | - |
|(S,G,rpt) || | Send Join | | |
|(P) || | (S,G,rpt) | | |
+------------++--------------+--------------+-------------+------------+
|NotPruned || -> P state | - | -> NJ state | - |
|(S,G,rpt) || Send Prune | | Cancel OT | |
|(NP) || (S,G,rpt); | | | |
| || cancel OT | | | |
+------------++--------------+--------------+-------------+------------+
Additionally, we have the following transitions within the NotPruned(S,G,rpt) state, which are all used for prune override behavior.
さらに、NotPruned（S、G、rpt）状態内に次の遷移があり、これらはすべてプルーンオーバーライド動作に使用されます。
+----------------------------------------------------------------------+
| In NotPruned(S,G,rpt) State |
+----------+--------------+--------------+--------------+--------------+
|Override | See Prune | See Join | See Prune | RPF' |
|Timer | (S,G,rpt) to | (S,G,rpt) to | (S,G) to | (S,G,rpt) -> |
|expires | RPF' | RPF' | RPF' | RPF' (*,G) |
| | (S,G,rpt) | (S,G,rpt) | (S,G,rpt) | |
+----------+--------------+--------------+--------------+--------------+
|Send Join | OT = min(OT, | Cancel OT | OT = min(OT, | OT = min(OT, |
|(S,G,rpt);| t_override) | | t_override) | t_override) |
|leave OT | | | | |
|unset | | | | |
+----------+--------------+--------------+--------------+--------------+
Note that the min function in the above state machine considers a non-running timer to have an infinite value (e.g., min(not-running, t_override) = t_override).
上記のステートマシンのmin関数は、非実行タイマーが無限値であると見なしていることに注意してください（例：min（not-running、t_override）= t_override）。
This state machine uses the following macros:
このステートマシンは、次のマクロを使用します。
bool RPTJoinDesired(G) {
return (JoinDesired(*,G))
}
RPTJoinDesired(G) is true when the router has forwarding state that would cause it to forward traffic for G using (*,G) shared tree state.
RPTJoinDesired（G）は、ルーターが（*、G）共有ツリー状態を使用してGのトラフィックを転送する転送状態になる場合にtrueになります。
bool PruneDesired(S,G,rpt) {
return ( RPTJoinDesired(G) AND
( inherited_olist(S,G,rpt) == NULL
OR (SPTbit(S,G)==TRUE
AND (RPF'(*,G) != RPF'(S,G)) )))
}
PruneDesired(S,G,rpt) can only be true if RPTJoinDesired(G) is true. If RPTJoinDesired(G) is true, then PruneDesired(S,G,rpt) is true either if there are no outgoing interfaces that S would be forwarded on, or if the router has active (S,G) forwarding state but RPF'(*,G) != RPF'(S,G).
PruneDesired（S、G、rpt）は、RPTJoinDesired（G）がtrueの場合にのみtrueになります。 RPTJoinDesired（G）がtrueの場合、Sが転送される発信インターフェイスがない場合、またはルーターのアクティブ（S、G）転送状態がRPF '（ *、G）！= RPF '（S、G）。
The state machine contains the following transition events:
ステートマシンには、次の遷移イベントが含まれています。
See Join(S,G,rpt) to RPF'(S,G,rpt) This event is only relevant in the "Not Pruned" state.
Join（S、G、rpt）to RPF '（S、G、rpt）を参照してください。このイベントは、「剪定されていない」状態でのみ関連します。
The router sees a Join(S,G,rpt) from someone else to RPF'(S,G,rpt), which is the correct upstream neighbor. If we're in "NotPruned" state and the (S,G,rpt) Override Timer is running, then this is because we have been triggered to send our own Join(S,G,rpt) to RPF'(S,G,rpt). Someone else beat us to it, so there's no need to send our own Join.
ルータは、他の誰かからのRPF '（S、G、rpt）へのJoin（S、G、rpt）を認識します。これは、正しいアップストリームネイバーです。 「NotPruned」状態にあり、（S、G、rpt）オーバーライドタイマーが実行されている場合、これはトリガーされて独自のJoin（S、G、rpt）をRPF '（S、G 、rpt）。他の誰かが私たちを打ち負かしたので、私たち自身のJoinを送る必要はありません。
The action is to cancel the Override Timer.
アクションは、オーバーライドタイマーをキャンセルすることです。
See Prune(S,G,rpt) to RPF'(S,G,rpt) This event is only relevant in the "NotPruned" state.
Prune（S、G、rpt）to RPF '（S、G、rpt）を参照してください。このイベントは、「NotPruned」状態でのみ関連します。
The router sees a Prune(S,G,rpt) from someone else to RPF'(S,G,rpt), which is the correct upstream neighbor. If we're in the "NotPruned" state, then we want to continue to receive traffic from S destined for G, and that traffic is being supplied by RPF'(S,G,rpt). Thus, we need to override the Prune.
ルータは、他の誰かからRPF '（S、G、rpt）へのPrune（S、G、rpt）を認識します。これは、正しいアップストリームネイバーです。 「NotPruned」状態にある場合、SからG宛てのトラフィックを引き続き受信し、そのトラフィックはRPF '（S、G、rpt）によって提供されます。したがって、Pruneをオーバーライドする必要があります。
The action is to set the (S,G,rpt) Override Timer to the randomized prune-override interval, t_override. However, if the Override Timer is already running, we only set the timer if doing so would set it to a lower value. At the end of this interval, if no one else has sent a Join, then we will do so.
アクションは、（S、G、rpt）オーバーライドタイマーをランダム化されたプルーンオーバーライドインターバルt_overrideに設定することです。ただし、オーバーライドタイマーが既に実行されている場合は、タイマーを設定すると、低い値に設定されます。この間隔の終わりに、他に誰もジョインを送信していない場合は、送信します。
See Prune(S,G) to RPF'(S,G,rpt) This event is only relevant in the "NotPruned" state.
Prune（S、G）to RPF '（S、G、rpt）を参照してください。このイベントは、「NotPruned」状態でのみ関連します。
This transition and action are the same as the above transition and action, except that the Prune does not have the RPT bit set. This transition is necessary to be compatible with routers implemented from RFC 2362 that don't maintain separate (S,G) and (S,G,rpt) state.
この遷移とアクションは、プルーンにRPTビットが設定されていないことを除いて、上記の遷移とアクションと同じです。この移行は、RFC 2362から実装されたルーターで、（S、G）と（S、G、rpt）の状態が別々に維持されないようにするために必要です。
The (S,G,rpt) prune Override Timer expires This event is only relevant in the "NotPruned" state.
（S、G、rpt）プルーンオーバーライドタイマーの期限切れこのイベントは、「NotPruned」状態でのみ関連します。
When the Override Timer expires, we must send a Join(S,G,rpt) to RPF'(S,G,rpt) to override the Prune message that caused the timer to be running. We only send this if RPF'(S,G,rpt) equals RPF'(*,G); if this were not the case, then the Join might be sent to a router that does not have (*,G) Join state, and so the behavior would not be well defined. If RPF'(S,G,rpt) is not the same as RPF'(*,G), then it may stop forwarding S. However, if this happens, then the router will send an AssertCancel(S,G), which would then cause RPF'(S,G,rpt) to become equal to RPF'(*,G) (see below).
オーバーライドタイマーの期限が切れたら、Join（S、G、rpt）をRPF '（S、G、rpt）に送信して、タイマーの実行を引き起こしたPruneメッセージをオーバーライドする必要があります。 RPF '（S、G、rpt）がRPF'（*、G）と等しい場合にのみこれを送信します。そうでない場合、Joinは（*、G）Join状態を持たないルーターに送信される可能性があるため、動作は明確に定義されません。 RPF '（S、G、rpt）がRPF'（*、G）と同じでない場合、Sの転送を停止することがあります。ただし、これが発生した場合、ルーターはAssertCancel（S、G）を送信します。次に、RPF '（S、G、rpt）がRPF'（*、G）と等しくなるようにします（以下を参照）。
RPF'(S,G,rpt) changes to become equal to RPF'(*,G) This event is only relevant in the "NotPruned" state.
RPF '（S、G、rpt）は、RPF'（*、G）と等しくなるように変更されます。このイベントは、「NotPruned」状態でのみ関連します。
RPF'(S,G,rpt) can only be different from RPF'(*,G) if an (S,G) Assert has happened, which means that traffic from S is arriving on the SPT, and so Prune(S,G,rpt) will have been sent to RPF'(*,G). When RPF'(S,G,rpt) changes to become equal to RPF'(*,G), we need to trigger a Join(S,G,rpt) to RPF'(*,G) to cause that router to start forwarding S again.
RPF '（S、G、rpt）は、（S、G）アサートが発生した場合にのみRPF'（*、G）と異なる可能性があります。つまり、SからのトラフィックがSPTに到達しているため、Prune（S、 G、rpt）はRPF '（*、G）に送信されます。 RPF '（S、G、rpt）がRPF'（*、G）と等しくなるように変更されたら、Join（S、G、rpt）をRPF '（*、G）にトリガーして、ルーターを起動する必要があります。 Sを再度転送します。
The action is to set the (S,G,rpt) Override Timer to the randomized prune-override interval t_override. However, if the timer is already running, we only set the timer if doing so would set it to a lower value. At the end of this interval, if no one else has sent a Join, then we will do so.
アクションは、（S、G、rpt）オーバーライドタイマーをランダム化されたプルーンオーバーライドインターバルt_overrideに設定することです。ただし、タイマーがすでに実行されている場合は、タイマーを設定すると、それが低い値に設定されます。この間隔の終わりに、他に誰もジョインを送信していない場合は、送信します。
PruneDesired(S,G,rpt)->TRUE See macro above. This event is relevant in the "NotPruned" and "RPTNotJoined(G)" states.
PruneDesired（S、G、rpt）-> TRUE上記のマクロを参照してください。このイベントは、「NotPruned」および「RPTNotJoined（G）」状態に関連しています。
The router wishes to receive traffic for G but does not wish to receive traffic from S destined for G. This causes the router to transition into the Pruned state.
ルータはGのトラフィックを受信することを望んでいますが、G宛てのSからのトラフィックを受信したくありません。これにより、ルータはプルーニング状態に移行します。
If the router was previously in NotPruned state, then the action is to send a Prune(S,G,rpt) to RPF'(S,G,rpt), and to cancel the Override Timer. If the router was previously in RPTNotJoined(G) state, then there is no need to trigger an action in this state machine because sending a Prune(S,G,rpt) is handled by the rules for sending the Join(*,G).
ルータが以前にNotPruned状態であった場合、アクションはPrune（S、G、rpt）をRPF '（S、G、rpt）に送信し、オーバーライドタイマーをキャンセルすることです。ルータが以前にRPTNotJoined（G）状態であった場合、Prune（S、G、rpt）の送信は、Join（*、G）を送信するためのルールによって処理されるため、この状態マシンでアクションをトリガーする必要はありません。 。
PruneDesired(S,G,rpt)->FALSE See macro above. This transition is only relevant in the "Pruned" state.
PruneDesired（S、G、rpt）-> FALSE上記のマクロを参照してください。この遷移は、「剪定」状態でのみ関連します。
If the router is in the Pruned(S,G,rpt) state, and PruneDesired(S,G,rpt) changes to FALSE, this could be because the router no longer has RPTJoinDesired(G) true, or it now wishes to receive traffic from S again. If it is the former, then this transition should not happen, but instead the "RPTJoinDesired(G)->FALSE" transition should happen. Thus, this transition should be interpreted as "PruneDesired(S,G,rpt)->FALSE AND RPTJoinDesired(G)==TRUE".
ルーターがPruned（S、G、rpt）状態にあり、PruneDesired（S、G、rpt）がFALSEに変化する場合、これは、ルーターがRPTJoinDesired（G）をtrueにしていないか、受信を希望しているためである再びSからのトラフィック。前者の場合、この遷移は発生しませんが、代わりに「RPTJoinDesired（G）-> FALSE」遷移が発生します。したがって、この遷移は「PruneDesired（S、G、rpt）-> FALSE AND RPTJoinDesired（G）== TRUE」として解釈されます。
The action is to send a Join(S,G,rpt) to RPF'(S,G,rpt).
アクションは、Join（S、G、rpt）をRPF '（S、G、rpt）に送信することです。
RPTJoinDesired(G)->FALSE This event is relevant in the "Pruned" and "NotPruned" states.
RPTJoinDesired（G）-> FALSEこのイベントは、「Pruned」および「NotPruned」状態に関連しています。
The router no longer wishes to receive any traffic destined for G on the RP Tree. This causes a transition to the RPTNotJoined(G) state, and the Override Timer is canceled if it was running. Any further actions are handled by the appropriate upstream state machine for (*,G).
ルータは、RPツリーでG宛てのトラフィックを受信する必要がなくなりました。これにより、RPTNotJoined（G）状態に遷移し、オーバーライドタイマーが実行されていた場合はキャンセルされます。それ以降のアクションは、（*、G）の適切な上流状態マシンによって処理されます。
inherited_olist(S,G,rpt) becomes non-NULL This transition is only relevant in the RPTNotJoined(G) state.
inherited_olist（S、G、rpt）が非NULLになるこの遷移は、RPTNotJoined（G）状態でのみ関連します。
The router has joined the RP tree (handled by the (*,G) upstream state machine as appropriate) and wants to receive traffic from S. This does not trigger any events in this state machine, but causes a transition to the NotPruned(S,G,rpt) state.
ルーターはRPツリーに参加し（（*、G）アップストリームステートマシンによって適切に処理されます）、Sからトラフィックを受信します。これにより、このステートマシンでイベントがトリガーされることはありませんが、NotPruned（S 、G、rpt）状態。
Where multiple PIM routers peer over a shared LAN, it is possible for more than one upstream router to have valid forwarding state for a packet, which can lead to packet duplication (see Section 3.6). PIM does not attempt to prevent this from occurring. Instead, it detects when this has happened and elects a single forwarder amongst the upstream routers to prevent further duplication. This election is performed using PIM Assert messages. Assert messages are also received by downstream routers on the LAN, and these cause subsequent Join/Prune messages to be sent to the upstream router that won the Assert.
複数のPIMルーターが共有LANを介してピアリングする場合、複数のアップストリームルーターがパケットの有効な転送状態になり、パケットの重複につながる可能性があります（セクション3.6を参照）。 PIMはこれが発生するのを防ぐことを試みません。代わりに、これが発生したことを検出し、それ以上の重複を防ぐために、上流のルーターの中から単一のフォワーダーを選びます。この選択は、PIMアサートメッセージを使用して実行されます。アサートメッセージは、LAN上のダウンストリームルーターでも受信されます。これにより、アサートを獲得したアップストリームルーターに後続のJoin / Pruneメッセージが送信されます。
In general, a PIM Assert message should only be accepted for processing if it comes from a known PIM neighbor. A PIM router hears about PIM neighbors through PIM Hello messages. If a router receives an Assert message from a particular IP source address and it has not seen a PIM Hello message from that source address, then the Assert message SHOULD be discarded without further processing. In addition, if the Hello message from a neighbor was authenticated (see Section 6.3), then all Assert messages from that neighbor MUST also be authenticated.
一般に、PIMアサートメッセージは、既知のPIMネイバーから送信された場合にのみ、処理のために受け入れられる必要があります。 PIMルーターは、PIM Helloメッセージを通じてPIMネイバーを認識します。ルータが特定のIP送信元アドレスからAssertメッセージを受信し、その送信元アドレスからのPIM Helloメッセージを受信していない場合、Assertメッセージは、それ以上処理せずに破棄する必要があります（SHOULD）。さらに、ネイバーからのHelloメッセージが認証された場合（セクション6.3を参照）、そのネイバーからのすべてのAssertメッセージも認証される必要があります。
We note that some older PIM implementations incorrectly fail to send Hello messages on point-to-point interfaces, so we also RECOMMEND that a configuration option be provided to allow interoperation with such older routers, but that this configuration option SHOULD NOT be enabled by default.
古いPIM実装の中には、ポイントツーポイントインターフェイスでのHelloメッセージの送信に失敗するものがあることに注意してください。そのため、このような古いルーターとの相互運用を可能にする構成オプションを提供することをお勧めしますが、この構成オプションはデフォルトで有効にすべきではありません（SHOULD NOT） 。
The (S,G) Assert state machine for interface I is shown in Figure 8. There are three states:
インターフェイスIの（S、G）アサートステートマシンを図8に示します。3つの状態があります。
NoInfo (NI) This router has no (S,G) assert state on interface I.
NoInfo（NI）このルーターには、インターフェースIに（S、G）アサート状態がありません。
I am Assert Winner (W) This router has won an (S,G) assert on interface I. It is now responsible for forwarding traffic from S destined for G out of interface I. Irrespective of whether it is the DR for I, while a router is the assert winner, it is also responsible for forwarding traffic onto I on behalf of local hosts on I that have made membership requests that specifically refer to S (and G).
私はアサートウィナー（W）です。このルーターは、インターフェースIで（S、G）アサートを獲得しました。SからG宛てのトラフィックをインターフェースIから転送する責任を負っています。それが自分のDRであるかどうかに関係なく、ルーターはアサートの勝者であり、特にS（およびG）を参照するメンバーシップ要求を行ったローカルホストの代わりにIにトラフィックを転送する役割もあります。
I am Assert Loser (L) This router has lost an (S,G) assert on interface I. It must not forward packets from S destined for G onto interface I. If it is the DR on I, it is no longer responsible for forwarding traffic onto I to satisfy local hosts with membership requests that specifically refer to S and G.
私はアサート敗者（L）です。このルーターは、インターフェースIで（S、G）アサートを失いました。SからG宛てのパケットをインターフェースIに転送することはできません。それがIのDRである場合、それはもはや責任がありません。特にSおよびGを参照するメンバーシップ要求でローカルホストを満たすためにIにトラフィックを転送する。
In addition, there is also an Assert Timer (AT) that is used to time out asserts on the assert losers and to resend asserts on the assert winner.
さらに、アサート敗者のアサートをタイムアウトし、アサート勝者のアサートを再送信するために使用されるアサートタイマー（AT）もあります。
Figure 8: Per-Interface (S,G) Assert State Machine
図8：インターフェースごとの（S、G）アサートステートマシン
+----------------------------------------------------------------------+
| In NoInfo (NI) State |
+---------------+-------------------+------------------+---------------+
| Receive | Receive Assert | Data arrives | Receive |
| Inferior | with RPTbit | from S to G on | Acceptable |
| Assert with | set and | I and | Assert with |
| RPTbit clear | CouldAssert | CouldAssert | RPTbit clear |
| | (S,G,I) | (S,G,I) | and AssTrDes |
| | | | (S,G,I) |
+---------------+-------------------+------------------+---------------+
| -> W state | -> W state | -> W state | -> L state |
| [Actions A1] | [Actions A1] | [Actions A1] | [Actions A6] |
+---------------+-------------------+------------------+---------------+
+----------------------------------------------------------------------+
| In I Am Assert Winner (W) State |
+----------------+------------------+-----------------+----------------+
| Assert Timer | Receive | Receive | CouldAssert |
| Expires | Inferior | Preferred | (S,G,I) -> |
| | Assert | Assert | FALSE |
+----------------+------------------+-----------------+----------------+
| -> W state | -> W state | -> L state | -> NI state |
| [Actions A3] | [Actions A3] | [Actions A2] | [Actions A4] |
+----------------+------------------+-----------------+----------------+
+---------------------------------------------------------------------+
| In I Am Assert Loser (L) State |
+-------------+-------------+-------------+-------------+-------------+
|Receive |Receive |Receive |Assert Timer |Current |
|Preferred |Acceptable |Inferior |Expires |Winner's |
|Assert |Assert with |Assert or | |GenID |
| |RPTbit clear |Assert | |Changes or |
| |from Current |Cancel from | |NLT Expires |
| |Winner |Current | | |
| | |Winner | | |
+-------------+-------------+-------------+-------------+-------------+
|-> L state |-> L state |-> NI state |-> NI state |-> NI state |
|[Actions A2] |[Actions A2] |[Actions A5] |[Actions A5] |[Actions A5] |
+-------------+-------------+-------------+-------------+-------------+
+----------------------------------------------------------------------+
| In I Am Assert Loser (L) State |
+----------------+-----------------+------------------+----------------+
| AssTrDes | my_metric -> | RPF_interface | Receive |
| (S,G,I) -> | better than | (S) stops | Join(S,G) on |
| FALSE | winner's | being I | interface I |
| | metric | | |
+----------------+-----------------+------------------+----------------+
| -> NI state | -> NI state | -> NI state | -> NI State |
| [Actions A5] | [Actions A5] | [Actions A5] | [Actions A5] |
+----------------+-----------------+------------------+----------------+
Note that for reasons of compactness, "AssTrDes(S,G,I)" is used in the state machine table to refer to AssertTrackingDesired(S,G,I).
コンパクト化の理由から、ステートマシンテーブルでは「AssTrDes（S、G、I）」を使用してAssertTrackingDesired（S、G、I）を参照していることに注意してください。
Terminology:
用語：
A "preferred assert" is one with a better metric than the current winner.
「優先アサート」は、現在の勝者よりも優れたメトリックを持つものです。
An "acceptable assert" is one that has a better metric than my_assert_metric(S,G,I). An assert is never considered acceptable if its metric is infinite.
「許容可能なアサート」は、my_assert_metric（S、G、I）よりも優れたメトリックを持つものです。メトリックが無限の場合、アサートは受け入れ可能とは見なされません。
An "inferior assert" is one with a worse metric than my_assert_metric(S,G,I). An assert is never considered inferior if my_assert_metric(S,G,I) is infinite.
「劣ったアサート」は、my_assert_metric（S、G、I）よりもメトリックが悪いものです。 my_assert_metric（S、G、I）が無限大の場合、アサートが劣ると見なされることはありません。
The state machine uses the following macros:
ステートマシンは次のマクロを使用します。
CouldAssert(S,G,I) =
SPTbit(S,G)==TRUE
AND (RPF_interface(S) != I)
AND (I in ( ( joins(*,G) (-) prunes(S,G,rpt) )
(+) ( pim_include(*,G) (-) pim_exclude(S,G) )
(-) lost_assert(*,G)
(+) joins(S,G) (+) pim_include(S,G) ) )
CouldAssert(S,G,I) is true for downstream interfaces that would be in the inherited_olist(S,G) if (S,G) assert information was not taken into account.
（Assetert（S、G、I））は、（S、G）アサート情報が考慮されていない場合、inherited_olist（S、G）に含まれるダウンストリームインターフェースに対してtrueです。
AssertTrackingDesired(S,G,I) =
(I in ( joins(*,G) (-) prunes(S,G,rpt)
(+) ( pim_include(*,G) (-) pim_exclude(S,G) )
(-) lost_assert(*,G)
(+) joins(S,G) ) )
OR (local_receiver_include(S,G,I) == TRUE
AND (I_am_DR(I) OR (AssertWinner(S,G,I) == me)))
OR ((RPF_interface(S) == I) AND (JoinDesired(S,G) == TRUE))
OR ((RPF_interface(RP(G)) == I) AND (JoinDesired(*,G) == TRUE)
AND (SPTbit(S,G) == FALSE))
AssertTrackingDesired(S,G,I) is true on any interface in which an (S,G) assert might affect the router's behavior on that interface.
AssertTrackingDesired（S、G、I）は、（S、G）アサートがそのインターフェイスでのルーターの動作に影響を与える可能性があるすべてのインターフェイスでtrueです。
The first three lines of AssertTrackingDesired account for (*,G) join and local membership information received on I that might cause the router to be interested in asserts on I.
AssertTrackingDesiredの最初の3行は、（*、G）の結合と、Iで受信したローカルメンバーシップ情報を示しており、ルーターがIのアサートに関心を持つ可能性があります。
The 4th line accounts for (S,G) join information received on I that might cause the router to be interested in asserts on I.
4行目は、Iで受信した（S、G）結合情報を説明しています。これにより、ルーターがIのアサートに関心を持つ可能性があります。
The 5th and 6th lines account for (S,G) local membership information on I. Note that we can't use the pim_include(S,G) macro, since it uses lost_assert(S,G,I) and would result in the router forgetting that it lost an assert if the only reason it was interested was local membership. The AssertWinner(S,G,I) check forces an assert winner to keep on being responsible for forwarding as long as local receivers are present. Removing this check would make the assert winner give up forwarding as soon as the information that originally caused it to forward went away, and the task of forwarding for local receivers would revert back to the DR.
5行目と6行目は、Iの（S、G）ローカルメンバーシップ情報を示しています。pis_include（S、G）マクロは、lost_assert（S、G、I）を使用しており、ルーターが興味を持った唯一の理由がローカルメンバーシップである場合、アサートを失ったことを忘れます。 AssertWinner（S、G、I）チェックは、ローカルレシーバーが存在する限り、アサートの勝者に転送の責任を負わせ続けます。このチェックを削除すると、最初に転送を引き起こした情報がなくなるとすぐに、アサートの勝者は転送を中止し、ローカルレシーバーの転送タスクがDRに戻ります。
The last three lines account for the fact that a router must keep track of assert information on upstream interfaces in order to send joins and prunes to the proper neighbor.
最後の3行は、結合とプルーニングを適切なネイバーに送信するために、ルータがアップストリームインターフェイスのアサート情報を追跡する必要があるという事実を説明しています。
Transitions from NoInfo State
NoInfo状態からの遷移
When in NoInfo state, the following events may trigger transitions:
NoInfo状態の場合、次のイベントが遷移をトリガーする可能性があります。
Receive Inferior Assert with RPTbit cleared An assert is received for (S,G) with the RPT bit cleared that is inferior to our own assert metric. The RPT bit cleared indicates that the sender of the assert had (S,G) forwarding state on this interface. If the assert is inferior to our metric, then we must also have (S,G) forwarding state (i.e., CouldAssert(S,G,I)==TRUE) as (S,G) asserts have priority over (*,G) asserts, and so we should be the assert winner. We transition to the "I am Assert Winner" state and perform Actions A1 (below).
RPTbitがクリアされた下位アサートの受信（S、G）に対して、独自のアサートメトリックよりも低いRPTビットがクリアされた状態でアサートが受信されます。クリアされたRPTビットは、アサートの送信者がこのインターフェイスで（S、G）転送状態にあったことを示します。アサートがメトリックよりも劣っている場合は、（S、G）アサートが（*、G）よりも優先されるため、（S、G）転送状態（つまり、CouldAssert（S、G、I）== TRUE）も必要です。 ）アサートするため、アサートの勝者になる必要があります。 「I am Assert Winner」状態に移行し、アクションA1（下記）を実行します。
Receive Assert with RPTbit set AND CouldAssert(S,G,I)==TRUE An assert is received for (S,G) on I with the RPT bit set (it is a (*,G) assert). CouldAssert(S,G,I) is TRUE only if we have (S,G) forwarding state on this interface, so we should be the assert winner. We transition to the "I am Assert Winner" state and perform Actions A1 (below).
RPTビットが設定された状態でAssertを受信し、かつCouldAssert（S、G、I）== TRUE RPTビットが設定されたIで（S、G）のアサートが受信されます（（*、G）アサートです）。 CouldAssert（S、G、I）は、このインターフェイスに（S、G）転送状態がある場合にのみTRUEになるため、アサートの勝者となる必要があります。 「I am Assert Winner」状態に移行し、アクションA1（下記）を実行します。
An (S,G) data packet arrives on interface I, AND CouldAssert(S,G,I)==TRUE An (S,G) data packet arrived on a downstream interface that is in our (S,G) outgoing interface list. We optimistically assume that we will be the assert winner for this (S,G), and so we transition to the "I am Assert Winner" state and perform Actions A1 (below), which will initiate the assert negotiation for (S,G).
（S、G）データパケットがインターフェイスIに到着し、かつCouldAssert（S、G、I）== TRUE（S、G）データパケットが、（S、G）発信インターフェイスリストにあるダウンストリームインターフェイスに到着した。この（S、G）のアサートの勝者になると楽観的に想定しているため、「I am Assert Winner」状態に移行し、（S、G）のアサートネゴシエーションを開始するアクションA1（下記）を実行します。 ）。
Receive Acceptable Assert with RPT bit clear AND AssertTrackingDesired(S,G,I)==TRUE We're interested in (S,G) Asserts, either because I is a downstream interface for which we have (S,G) or (*,G) forwarding state, or because I is the upstream interface for S and we have (S,G) forwarding state. The received assert has a better metric than our own, so we do not win the Assert. We transition to "I am Assert Loser" and perform Actions A6 (below).
RPTビットがクリアされ、かつAssertTrackingDesired（S、G、I）== TRUEのAcceptable Assertを受信します。（S、G）アサートに興味があります。これは、（S、G）または（* 、G）フォワーディングステート、またはIがSのアップストリームインターフェイスであり、（S、G）フォワーディングステートがあるため。受け取ったアサートは私たちのアサートよりも良いメトリックを持っているので、アサートに勝つことはありません。 「I am Assert Loser」に移行し、アクションA6（下記）を実行します。
Transitions from "I am Assert Winner" State
「I am Assert Winner」状態からの移行
When in "I am Assert Winner" state, the following events trigger transitions:
「I am Assert Winner」状態の場合、次のイベントが遷移をトリガーします。
Assert Timer Expires The (S,G) Assert Timer expires. As we're in the Winner state, we must still have (S,G) forwarding state that is actively being kept alive. We resend the (S,G) Assert and restart the Assert Timer (Actions A3 below). Note that the assert winner's Assert Timer is engineered to expire shortly before timers on assert losers; this prevents unnecessary thrashing of the forwarder and periodic flooding of duplicate packets.
アサートタイマーの期限切れ（S、G）アサートタイマーの期限切れ。 Winner状態であるため、アクティブに維持されている（S、G）フォワーディング状態がまだ残っている必要があります。 （S、G）アサートを再送信し、アサートタイマーを再起動します（以下のアクションA3）。アサート勝者のアサートタイマーは、アサート敗者のタイマーの直前に期限切れになるように設計されていることに注意してください。これにより、フォワーダーの不要なスラッシングと重複パケットの定期的なフラッディングが防止されます。
Receive Inferior Assert We receive an (S,G) assert or (*,G) assert mentioning S that has a worse metric than our own. Whoever sent the assert is in error, and so we resend an (S,G) Assert and restart the Assert Timer (Actions A3 below).
劣ったアサートを受け取る自分よりも悪いメトリックを持つSについて言及する（S、G）アサートまたは（*、G）アサートを受け取ります。アサートを送信した人はエラーなので、（S、G）アサートを再送信してアサートタイマーを再起動します（以下のアクションA3）。
Receive Preferred Assert We receive an (S,G) assert that has a better metric than our own. We transition to "I am Assert Loser" state and perform Actions A2 (below). Note that this may affect the value of JoinDesired(S,G) and PruneDesired(S,G,rpt), which could cause transitions in the upstream (S,G) or (S,G,rpt) state machines.
優先アサートの受信自分よりも良いメトリックを持つ（S、G）アサートを受信します。 「I am Assert Loser」状態に移行し、アクションA2（下記）を実行します。これは、JoinDesired（S、G）およびPruneDesired（S、G、rpt）の値に影響を与える可能性があることに注意してください。これにより、上流の（S、G）または（S、G、rpt）状態マシンで遷移が発生する可能性があります。
CouldAssert(S,G,I) -> FALSE Our (S,G) forwarding state or RPF interface changed so as to make CouldAssert(S,G,I) become false. We can no longer perform the actions of the assert winner, and so we transition to NoInfo state and perform Actions A4 (below). This includes sending a "canceling assert" with an infinite metric.
CouldAssert（S、G、I）-> FALSE CouldAssert（S、G、I）がfalseになるように、（S、G）転送状態またはRPFインターフェイスが変更されました。アサート勝者のアクションを実行できなくなったため、NoInfo状態に移行し、アクションA4（下記）を実行します。これには、無限のメトリックを持つ「キャンセルアサート」の送信が含まれます。
Transitions from "I am Assert Loser" State
「I am Assert Loser」状態からの移行
When in "I am Assert Loser" state, the following transitions can occur:
「I am Assert Loser」状態の場合、次の遷移が発生する可能性があります。
Receive Preferred Assert We receive an assert that is better than that of the current assert winner. We stay in Loser state and perform Actions A2 below.
優先アサートの受け取り現在のアサートの勝者よりも優れたアサートを受け取ります。私たちは敗者状態のままで、以下のアクションA2を実行します。
Receive Acceptable Assert with RPTbit clear from Current Winner We receive an assert from the current assert winner that is better than our own metric for this (S,G) (although the metric may be worse than the winner's previous metric). We stay in Loser state and perform Actions A2 below.
現在の勝者からRPTbitがクリアされた受諾可能なアサートを受信します現在のアサートの勝者から、この（S、G）の独自のメトリックよりも優れたアサートを受け取ります（ただし、メトリックは勝者の以前のメトリックよりも悪い場合があります）。私たちは敗者状態のままで、以下のアクションA2を実行します。
Receive Inferior Assert or Assert Cancel from Current Winner We receive an assert from the current assert winner that is worse than our own metric for this group (typically, because the winner's metric became worse or because it is an assert cancel). We transition to NoInfo state, deleting the (S,G) assert information and allowing the normal PIM Join/Prune mechanisms to operate. Usually, we will eventually re-assert and win when data packets from S have started flowing again.
現在の勝者からの劣ったアサートまたはアサートキャンセルの受信現在のアサート勝者から、このグループの独自のメトリックよりも悪いアサートを受け取ります（通常、勝者のメトリックが悪化したか、アサートキャンセルのため）。 NoInfo状態に移行し、（S、G）アサート情報を削除して、通常のPIM加入/プルーンメカニズムが動作できるようにします。通常、Sからのデータパケットが再び流れ始めたときに、最終的に再アサートして勝利します。
Assert Timer Expires The (S,G) Assert Timer expires. We transition to NoInfo state, deleting the (S,G) assert information (Actions A5 below).
アサートタイマーの期限切れ（S、G）アサートタイマーの期限切れ。 NoInfo状態に遷移し、（S、G）アサート情報を削除します（以下のアクションA5）。
Current Winner's GenID Changes or NLT Expires The Neighbor Liveness Timer associated with the current winner expires or we receive a Hello message from the current winner reporting a different GenID from the one it previously reported. This indicates that the current winner's interface or router has gone down (and may have come back up), and so we must assume that it no longer knows it was the winner. We transition to the NoInfo state, deleting this (S,G) assert information (Actions A5 below).
現在の勝者のGenIDの変更またはNLTの期限切れ現在の勝者に関連付けられたNeighbor Livenessタイマーが期限切れになるか、以前に報告したものとは異なるGenIDを報告する現在の勝者からHelloメッセージを受信します。これは、現在の勝者のインターフェイスまたはルーターがダウンしていることを示しています（そして、アップに戻っている可能性があります）。 NoInfo状態に移行し、この（S、G）アサート情報を削除します（以下のアクションA5）。
AssertTrackingDesired(S,G,I)->FALSE AssertTrackingDesired(S,G,I) becomes FALSE. Our forwarding state has changed so that (S,G) Asserts on interface I are no longer of interest to us. We transition to the NoInfo state, deleting the (S,G) assert information.
AssertTrackingDesired（S、G、I）-> FALSE AssertTrackingDesired（S、G、I）はFALSEになります。フォワーディングステートが変更されたため、インターフェイス上の（S、G）アサートは私には関係ありません。 NoInfo状態に遷移し、（S、G）アサート情報を削除します。
My metric becomes better than the assert winner's metric my_assert_metric(S,G,I) has changed so that now my assert metric for (S,G) is better than the metric we have stored for the current assert winner. This might happen when the underlying routing metric changes, or when CouldAssert(S,G,I) becomes true, for example, when SPTbit(S,G) becomes true. We transition to NoInfo state, delete this (S,G) assert state (Actions A5 below), and allow the normal PIM Join/Prune mechanisms to operate. Usually, we will eventually re-assert and win when data packets from S have started flowing again.
私のメトリックは、アサート勝者のメトリックmy_assert_metric（S、G、I）が変更されたため、現在の（S、G）のアサートメトリックは、現在のアサート勝者用に格納したメトリックよりも優れています。これは、基になるルーティングメトリックが変更されたとき、または、CouldAssert（S、G、I）がtrueになったとき、たとえばSPTbit（S、G）がtrueになったときに発生する可能性があります。 NoInfo状態に移行し、この（S、G）アサート状態（下記のアクションA5）を削除して、通常のPIM結合/プルーニングメカニズムが動作するようにします。通常、Sからのデータパケットが再び流れ始めたときに、最終的に再アサートして勝利します。
RPF_interface(S) stops being interface I Interface I used to be the RPF interface for S, and now it is not. We transition to NoInfo state, deleting this (S,G) assert state (Actions A5 below).
RPF_interface（S）がインターフェイスIであるのをやめるインターフェイス以前はSのRPFインターフェイスでしたが、現在はそうではありません。 NoInfo状態に移行し、この（S、G）アサート状態を削除します（以下のアクションA5）。
Receive Join(S,G) on Interface I We receive a Join(S,G) that has the Upstream Neighbor Address field set to my primary IP address on interface I. The action is to transition to NoInfo state, delete this (S,G) assert state (Actions A5 below), and allow the normal PIM Join/Prune mechanisms to operate. If whoever sent the Join was in error, then the normal assert mechanism will eventually re-apply, and we will lose the assert again. However, whoever sent the assert may know that the previous assert winner has died, and so we may end up being the new forwarder.
インターフェイスIでJoin（S、G）を受信します。アップストリームネイバーアドレスフィールドがインターフェイスIのプライマリIPアドレスに設定されているJoin（S、G）を受信します。アクションはNoInfo状態に移行し、これを削除します（S、 G）状態（以下のアクションA5）をアサートし、通常のPIM加入/プルーンメカニズムが動作することを許可します。 Joinを送信した人がエラーになった場合、通常のアサートメカニズムが最終的に再適用され、アサートが再び失われます。ただし、アサートを送信した人は誰でも、前のアサートの勝者が死亡したことを知っている可能性があるため、新しいフォワーダーになる可能性があります。
(S,G) Assert State Machine Actions
（S、G）ステートマシンアクションのアサート
A1: Send Assert(S,G). Set Assert Timer to (Assert_Time - Assert_Override_Interval). Store self as AssertWinner(S,G,I). Store spt_assert_metric(S,I) as AssertWinnerMetric(S,G,I).
A1：Assert（S、G）を送信します。アサートタイマーを（Assert_Time-Assert_Override_Interval）に設定します。自身をAssertWinner（S、G、I）として保存します。 spt_assert_metric（S、I）をAssertWinnerMetric（S、G、I）として保存します。
A2: Store new assert winner as AssertWinner(S,G,I) and assert winner metric as AssertWinnerMetric(S,G,I). Set Assert Timer to Assert_Time.
A2：新しいアサート勝者をAssertWinner（S、G、I）として保存し、勝者メトリックをAssertWinnerMetric（S、G、I）としてアサートします。 Assert TimerをAssert_Timeに設定します。
A3: Send Assert(S,G). Set Assert Timer to (Assert_Time - Assert_Override_Interval).
A3：Assert（S、G）を送信します。アサートタイマーを（Assert_Time-Assert_Override_Interval）に設定します。
A4: Send AssertCancel(S,G). Delete assert information (AssertWinner(S,G,I) and AssertWinnerMetric(S,G,I) will then return to their default values).
A4：AssertCancel（S、G）を送信します。アサート情報を削除します（AssertWinner（S、G、I）とAssertWinnerMetric（S、G、I）はデフォルト値に戻ります）。
A5: Delete assert information (AssertWinner(S,G,I) and AssertWinnerMetric(S,G,I) will then return to their default values).
A5：アサート情報を削除します（AssertWinner（S、G、I）とAssertWinnerMetric（S、G、I）はデフォルト値に戻ります）。
A6: Store new assert winner as AssertWinner(S,G,I) and assert winner metric as AssertWinnerMetric(S,G,I). Set Assert Timer to Assert_Time. If (I is RPF_interface(S)) AND (UpstreamJPState(S,G) == Joined) set SPTbit(S,G) to TRUE.
A6：新しいアサート勝者をAssertWinner（S、G、I）として保存し、勝者メトリックをAssertWinnerMetric（S、G、I）としてアサートします。 Assert TimerをAssert_Timeに設定します。 （IがRPF_interface（S））AND（UpstreamJPState（S、G）== Joined）の場合、SPTbit（S、G）をTRUEに設定します。
Note that some of these actions may cause the value of JoinDesired(S,G), PruneDesired(S,G,rpt), or RPF'(S,G) to change, which could cause further transitions in other state machines.
これらのアクションの一部は、JoinDesired（S、G）、PruneDesired（S、G、rpt）、またはRPF '（S、G）の値を変化させ、他の状態マシンでさらに遷移を引き起こす可能性があることに注意してください。
The (*,G) Assert state machine for interface I is shown in Figure 9. There are three states:
インターフェースIの（*、G）アサートステートマシンを図9に示します。3つの状態があります。
NoInfo (NI) This router has no (*,G) assert state on interface I.
NoInfo（NI）このルーターには、インターフェースIに（*、G）アサート状態がありません。
I am Assert Winner (W) This router has won a (*,G) assert on interface I. It is now responsible for forwarding traffic destined for G onto interface I with the exception of traffic for which it has (S,G) "I am Assert Loser" state. Irrespective of whether it is the DR for I, it is also responsible for handling the membership requests for G from local hosts on I.
私はアサートウィナー（W）です。このルーターは、インターフェースIで（*、G）アサートを獲得しました。G宛てのトラフィックを（S、G）のトラフィックを除いて、インターフェースIに転送する役割を果たします。私はアサート敗者」の状態です。 IのDRであるかどうかに関係なく、IのローカルホストからのGのメンバーシップ要求の処理も行います。
I am Assert Loser (L) This router has lost a (*,G) assert on interface I. It must not forward packets for G onto interface I with the exception of traffic from sources for which it has (S,G) "I am Assert Winner" state. If it is the DR, it is no longer responsible for handling the membership requests for group G from local hosts on I.
私はアサート敗者（L）です。このルーターは、インターフェースIで（*、G）アサートを失いました。GのパケットをインターフェースSに転送しないでください。ただし、（S、G） "Iのソースからのトラフィックは例外です。アサート勝者」状態。それがDRの場合、IのローカルホストからのグループGのメンバーシップ要求を処理する責任はなくなります。
In addition, there is also an Assert Timer (AT) that is used to time out asserts on the assert losers and to resend asserts on the assert winner.
さらに、アサート敗者のアサートをタイムアウトし、アサート勝者のアサートを再送信するために使用されるアサートタイマー（AT）もあります。
When an Assert message is received with a source address other than zero, a PIM implementation must first match it against the possible events in the (S,G) assert state machine and process any transitions and actions, before considering whether the Assert message matches against the (*,G) assert state machine.
Assertメッセージがゼロ以外の送信元アドレスで受信されると、PIM実装はまずそれを（S、G）アサートステートマシンで発生する可能性のあるイベントと照合し、遷移とアクションを処理してから、Assertメッセージが照合されるかどうかを検討する（*、G）アサートステートマシン。
It is important to note that NO TRANSITION CAN OCCUR in the (*,G) state machine as a result of receiving an Assert message unless the (S,G) assert state machine for the relevant S and G is in the "NoInfo" state after the (S,G) state machine has processed the message. Also, NO TRANSITION CAN OCCUR in the (*,G) state machine as a result of receiving an assert message if that message triggers any change of state in the (S,G) state machine. Obviously, when the source address in the received message is set to zero, an (S,G) state machine for the S and G does not exist and can be assumed to be in the "NoInfo" state.
関連するSとGの（S、G）アサートステートマシンが "NoInfo"状態でない限り、アサートメッセージを受信した結果として、（*、G）ステートマシンでNO TRANSITION CAN OCCURが発生することに注意することが重要です。 （S、G）ステートマシンがメッセージを処理した後。また、メッセージが（S、G）ステートマシンの状態の変化をトリガーした場合、assertメッセージを受信した結果として、（*、G）ステートマシンでTRANSITION CAN OCCURは発生しません。明らかに、受信したメッセージの送信元アドレスがゼロに設定されている場合、SおよびGの（S、G）ステートマシンは存在せず、「NoInfo」状態であると見なすことができます。
For example, if both the (S,G) and (*,G) assert state machines are in the NoInfo state when an Assert message arrives, and the message causes the (S,G) state machine to transition to either "W" or "L" state, then the assert will not be processed by the (*,G) assert state machine.
たとえば、アサートメッセージが到着したときに、（S、G）と（*、G）の両方のアサートステートマシンがNoInfo状態にあり、そのメッセージによって（S、G）ステートマシンが「W」のいずれかに遷移する場合または「L」状態の場合、アサートは（*、G）アサートステートマシンによって処理されません。
Another example: if the (S,G) assert state machine is in "L" state when an assert message is received, and the assert metric in the message is worse than my_assert_metric(S,G,I), then the (S,G) assert state machine will transition to NoInfo state. In such a case, if the (*,G) assert state machine were in NoInfo state, it might appear that it would transition to "W" state, but this is not the case because this message already triggered a transition in the (S,G) assert state machine.
別の例：アサートメッセージを受信したときに（S、G）アサートステートマシンが "L"状態で、メッセージ内のアサートメトリックがmy_assert_metric（S、G、I）よりも悪い場合、（S、G） G）ステートマシンがNoInfo状態に遷移することをアサートします。そのような場合、（*、G）アサートステートマシンがNoInfo状態にあると、「W」状態に遷移するように見えるかもしれませんが、このメッセージはすでに（S 、G）ステートマシンをアサートします。
Figure 9: Per-Interface (*,G) Assert State Machine
図9：インターフェースごとの（*、G）アサートステートマシン
+----------------------------------------------------------------------+
| In NoInfo (NI) State |
+-----------------------+-----------------------+----------------------+
| Receive Inferior | Data arrives for G | Receive Acceptable |
| Assert with RPTbit | on I and | Assert with RPTbit |
| set and | CouldAssert | set and AssTrDes |
| CouldAssert(*,G,I) | (*,G,I) | (*,G,I) |
+-----------------------+-----------------------+----------------------+
| -> W state | -> W state | -> L state |
| [Actions A1] | [Actions A1] | [Actions A2] |
+-----------------------+-----------------------+----------------------+
+---------------------------------------------------------------------+
| In I Am Assert Winner (W) State |
+----------------+-----------------+-----------------+----------------+
| Assert Timer | Receive | Receive | CouldAssert |
| Expires | Inferior | Preferred | (*,G,I) -> |
| | Assert | Assert | FALSE |
+----------------+-----------------+-----------------+----------------+
| -> W state | -> W state | -> L state | -> NI state |
| [Actions A3] | [Actions A3] | [Actions A2] | [Actions A4] |
+----------------+-----------------+-----------------+----------------+
+---------------------------------------------------------------------+
| In I Am Assert Loser (L) State |
+-------------+-------------+-------------+-------------+-------------+
|Receive |Receive |Receive |Assert Timer |Current |
|Preferred |Acceptable |Inferior |Expires |Winner's |
|Assert with |Assert from |Assert or | |GenID |
|RPTbit set |Current |Assert | |Changes or |
| |Winner with |Cancel from | |NLT Expires |
| |RPTbit set |Current | | |
| | |Winner | | |
+-------------+-------------+-------------+-------------+-------------+
|-> L state |-> L state |-> NI state |-> NI state |-> NI state |
|[Actions A2] |[Actions A2] |[Actions A5] |[Actions A5] |[Actions A5] |
+-------------+-------------+-------------+-------------+-------------+
+----------------------------------------------------------------------+
| In I Am Assert Loser (L) State |
+----------------+----------------+-----------------+------------------+
| AssTrDes | my_metric -> | RPF_interface | Receive |
| (*,G,I) -> | better than | (RP(G)) stops | Join(*,G) on |
| FALSE | Winner's | being I | Interface I |
| | metric | | |
+----------------+----------------+-----------------+------------------+
| -> NI state | -> NI state | -> NI state | -> NI State |
| [Actions A5] | [Actions A5] | [Actions A5] | [Actions A5] |
+----------------+----------------+-----------------+------------------+
The state machine uses the following macros:
ステートマシンは次のマクロを使用します。
CouldAssert(*,G,I) =
( I in ( joins(*,G) (+) pim_include(*,G)) )
AND (RPF_interface(RP(G)) != I)
CouldAssert(*,G,I) is true on downstream interfaces for which we have (*,G) join state, or local members that requested any traffic destined for G.
CouldAssert（*、G、I）は、（*、G）結合状態があるダウンストリームインターフェイス、またはG宛てのトラフィックを要求したローカルメンバーでtrueです。
AssertTrackingDesired(*,G,I) =
CouldAssert(*,G,I)
OR (local_receiver_include(*,G,I)==TRUE
AND (I_am_DR(I) OR AssertWinner(*,G,I) == me))
OR (RPF_interface(RP(G)) == I AND RPTJoinDesired(G))
AssertTrackingDesired(*,G,I) is true on any interface on which a (*,G) assert might affect the router's behavior on that interface.
AssertTrackingDesired（*、G、I）は、（*、G）アサートがそのインターフェイスでのルーターの動作に影響を与える可能性があるすべてのインターフェイスでtrueです。
Note that for reasons of compactness, "AssTrDes(*,G,I)" is used in the state machine table to refer to AssertTrackingDesired(*,G,I).
コンパクトさの理由から、ステートマシンテーブルでは「AssTrDes（*、G、I）」を使用してAssertTrackingDesired（*、G、I）を参照しています。
Terminology:
用語：
A "preferred assert" is one with a better metric than the current winner.
「優先アサート」は、現在の勝者よりも優れたメトリックを持つものです。
An "acceptable assert" is one that has a better metric than my_assert_metric(*,G,I). An assert is never considered acceptable if its metric is infinite.
「許容可能なアサート」は、my_assert_metric（*、G、I）よりも優れたメトリックを持つものです。メトリックが無限の場合、アサートは受け入れ可能とは見なされません。
An "inferior assert" is one with a worse metric than my_assert_metric(*,G,I). An assert is never considered inferior if my_assert_metric(*,G,I) is infinite.
「劣ったアサート」は、my_assert_metric（*、G、I）よりもメトリックが悪いものです。 my_assert_metric（*、G、I）が無限である場合、アサートは決して劣ると見なされません。
Transitions from NoInfo State
NoInfo状態からの遷移
When in NoInfo state, the following events trigger transitions, but only if the (S,G) assert state machine is in NoInfo state before and after consideration of the received message:
NoInfo状態の場合、次のイベントが遷移をトリガーしますが、（S、G）アサートステートマシンが受信メッセージの検討の前後にNoInfo状態にある場合のみです。
Receive Inferior Assert with RPTbit set AND CouldAssert(*,G,I)==TRUE An Inferior (*,G) assert is received for G on Interface I. If CouldAssert(*,G,I) is TRUE, then I is our downstream interface, and we have (*,G) forwarding state on this interface, so we should be the assert winner. We transition to the "I am Assert Winner" state and perform Actions A1 (below).
RPTbitが設定された下位アサートを受信し、かつAND Assassert（*、G、I）== TRUEインターフェースIでGに対して下位（*、G）アサートを受信した。CouldAssert（*、G、I）がTRUEの場合、私はダウンストリームインターフェイス、およびこのインターフェイスに（*、G）転送状態があるため、アサートの勝者となる必要があります。 「I am Assert Winner」状態に移行し、アクションA1（下記）を実行します。
A data packet destined for G arrives on interface I, AND CouldAssert(*,G,I)==TRUE A data packet destined for G arrived on a downstream interface that is in our (*,G) outgoing interface list. We therefore believe we should be the forwarder for this (*,G), and so we transition to the "I am Assert Winner" state and perform Actions A1 (below).
G宛てのデータパケットがインターフェイスIに到着し、かつCouldAssert（*、G、I）== TRUE G宛てのデータパケットが、（*、G）発信インターフェイスリストにあるダウンストリームインターフェイスに到着しました。したがって、この（*、G）のフォワーダーである必要があると考え、「I am Assert Winner」状態に移行し、アクションA1（下記）を実行します。
Receive Acceptable Assert with RPT bit set AND AssertTrackingDesired(*,G,I)==TRUE We're interested in (*,G) Asserts, either because I is a downstream interface for which we have (*,G) forwarding state, or because I is the upstream interface for RP(G) and we have (*,G) forwarding state. We get a (*,G) Assert that has a better metric than our own, so we do not win the Assert. We transition to "I am Assert Loser" and perform Actions A2 (below).
RPTビットが設定され、かつAssertTrackingDesired（*、G、I）== TRUEでAcceptable Assertを受信します。（*、G）アサートに興味があります。これは、（*、G）転送状態を持つダウンストリームインターフェイスであるためです。または、私がRP（G）のアップストリームインターフェイスであり、（*、G）転送状態にあるためです。 （*、G）アサートを取得し、それよりもメトリックが優れているため、アサートを獲得できません。 「I am Assert Loser」に移行し、アクションA2（下記）を実行します。
Transitions from "I am Assert Winner" State
「I am Assert Winner」状態からの移行
When in "I am Assert Winner" state, the following events trigger transitions, but only if the (S,G) assert state machine is in NoInfo state before and after consideration of the received message:
「I am Assert Winner」状態の場合、次のイベントが遷移をトリガーしますが、（S、G）アサートステートマシンが受信したメッセージの検討の前後にNoInfo状態にある場合のみです。
Receive Inferior Assert We receive a (*,G) assert that has a worse metric than our own. Whoever sent the assert has lost, and so we resend a (*,G) Assert and restart the Assert Timer (Actions A3 below).
劣ったアサートの受信自分よりも悪いメトリックを持つ（*、G）アサートを受信します。アサートを送信した人は誰も失ったため、（*、G）アサートを再送信してアサートタイマーを再起動します（以下のアクションA3）。
Receive Preferred Assert We receive a (*,G) assert that has a better metric than our own. We transition to "I am Assert Loser" state and perform Actions A2 (below).
優先アサートの受信自分よりも良いメトリックを持つ（*、G）アサートを受信します。 「I am Assert Loser」状態に移行し、アクションA2（下記）を実行します。
When in "I am Assert Winner" state, the following events trigger transitions:
「I am Assert Winner」状態の場合、次のイベントが遷移をトリガーします。
Assert Timer Expires The (*,G) Assert Timer expires. As we're in the Winner state, then we must still have (*,G) forwarding state that is actively being kept alive. To prevent unnecessary thrashing of the forwarder and periodic flooding of duplicate packets, we resend the (*,G) Assert and restart the Assert Timer (Actions A3 below).
アサートタイマーの期限切れ（*、G）アサートタイマーの期限切れ。 Winner状態であるため、アクティブに維持されている（*、G）転送状態がまだ必要です。フォワーダーの不要なスラッシングと重複パケットの定期的なフラッディングを防ぐために、（*、G）アサートを再送信してアサートタイマーを再起動します（以下のアクションA3）。
CouldAssert(*,G,I) -> FALSE Our (*,G) forwarding state or RPF interface changed so as to make CouldAssert(*,G,I) become false. We can no longer perform the actions of the assert winner, and so we transition to NoInfo state and perform Actions A4 (below).
CouldAssert（*、G、I）-> FALSE CouldAssert（*、G、I）がfalseになるように、（*、G）転送状態またはRPFインターフェイスが変更されました。アサート勝者のアクションを実行できなくなったため、NoInfo状態に移行し、アクションA4（下記）を実行します。
Transitions from "I am Assert Loser" State
「I am Assert Loser」状態からの移行
When in "I am Assert Loser" state, the following events trigger transitions, but only if the (S,G) assert state machine is in NoInfo state before and after consideration of the received message:
「I am Assert Loser」状態の場合、次のイベントが遷移をトリガーしますが、（S、G）アサートステートマシンが受信したメッセージの検討の前後にNoInfo状態にある場合のみです。
Receive Preferred Assert with RPTbit set We receive a (*,G) assert that is better than that of the current assert winner. We stay in Loser state and perform Actions A2 below.
RPTbitが設定された優先アサートを受け取る現在のアサート勝者よりも優れた（*、G）アサートを受け取ります。私たちは敗者状態のままで、以下のアクションA2を実行します。
Receive Acceptable Assert from Current Winner with RPTbit set We receive a (*,G) assert from the current assert winner that is better than our own metric for this group (although the metric may be worse than the winner's previous metric). We stay in Loser state and perform Actions A2 below.
RPTbitが設定された現在の勝者からの受け入れ可能なアサートの受信現在のアサートの勝者から、このグループの独自のメトリックよりも優れた（*、G）アサートを受け取ります（ただし、メトリックは勝者の以前のメトリックよりも悪い場合があります）。私たちは敗者状態のままで、以下のアクションA2を実行します。
Receive Inferior Assert or Assert Cancel from Current Winner We receive an assert from the current assert winner that is worse than our own metric for this group (typically because the winner's metric became worse or is now an assert cancel). We transition to NoInfo state, delete this (*,G) assert state (Actions A5), and allow the normal PIM Join/Prune mechanisms to operate. Usually, we will eventually re-assert and win when data packets for G have started flowing again.
現在の勝者からの劣ったアサートまたはアサートキャンセルの受信現在のアサートの勝者から、このグループの独自のメトリックよりも悪いアサートを受け取ります（通常、勝者のメトリックが悪化したか、現在はアサートキャンセルです）。 NoInfo状態に移行し、この（*、G）アサート状態（アクションA5）を削除して、通常のPIM結合/プルーニングメカニズムが動作できるようにします。通常、Gのデータパケットが再び流れ始めたときに、最終的に再アサートして勝利します。
When in "I am Assert Loser" state, the following events trigger transitions:
「I am Assert Loser」状態の場合、次のイベントが遷移をトリガーします。
Assert Timer Expires The (*,G) Assert Timer expires. We transition to NoInfo state and delete this (*,G) assert information (Actions A5).
アサートタイマーの期限切れ（*、G）アサートタイマーの期限切れ。 NoInfo状態に移行し、この（*、G）アサート情報を削除します（アクションA5）。
Current Winner's GenID Changes or NLT Expires The Neighbor Liveness Timer associated with the current winner expires or we receive a Hello message from the current winner reporting a different GenID from the one it previously reported. This indicates that the current winner's interface or router has gone down (and may have come back up), and so we must assume that it no longer knows it was the winner. We transition to the NoInfo state, deleting the (*,G) assert information (Actions A5).
現在の勝者のGenIDの変更またはNLTの期限切れ現在の勝者に関連付けられたNeighbor Livenessタイマーが期限切れになるか、以前に報告したものとは異なるGenIDを報告する現在の勝者からHelloメッセージを受信します。これは、現在の勝者のインターフェイスまたはルーターがダウンしていることを示しています（そして、アップに戻っている可能性があります）。 NoInfo状態に移行し、（*、G）アサート情報を削除します（アクションA5）。
AssertTrackingDesired(*,G,I)->FALSE AssertTrackingDesired(*,G,I) becomes FALSE. Our forwarding state has changed so that (*,G) Asserts on interface I are no longer of interest to us. We transition to NoInfo state and delete this (*,G) assert information (Actions A5).
AssertTrackingDesired（*、G、I）-> FALSE AssertTrackingDesired（*、G、I）はFALSEになります。転送状態が変更されたため、インターフェース上の（*、G）アサートはもう関係ありません。 NoInfo状態に移行し、この（*、G）アサート情報を削除します（アクションA5）。
My metric becomes better than the assert winner's metric My routing metric, rpt_assert_metric(G,I), has changed so that now my assert metric for (*,G) is better than the metric we have stored for the current assert winner. We transition to NoInfo state, delete this (*,G) assert state (Actions A5), and allow the normal PIM Join/Prune mechanisms to operate. Usually, we will eventually re-assert and win when data packets for G have started flowing again.
メトリックがアサート勝者のメトリックよりも向上しました。ルーティングメトリックrpt_assert_metric（G、I）が変更されたため、（*、G）のアサートメトリックは、現在のアサート勝者用に保存したメトリックよりも優れています。 NoInfo状態に移行し、この（*、G）アサート状態（アクションA5）を削除して、通常のPIM結合/プルーニングメカニズムが動作できるようにします。通常、Gのデータパケットが再び流れ始めたときに、最終的に再アサートして勝利します。
RPF_interface(RP(G)) stops being interface I Interface I used to be the RPF interface for RP(G), and now it is not. We transition to NoInfo state and delete this (*,G) assert state (Actions A5).
RPF_interface（RP（G））がインターフェイスIであるのを停止しましたインターフェイスRP（G）のRPFインターフェイスでしたが、現在はそうではありません。 NoInfo状態に移行し、この（*、G）アサート状態を削除します（アクションA5）。
Receive Join(*,G) on interface I We receive a Join(*,G) that has the Upstream Neighbor Address field set to my primary IP address on interface I. The action is to transition to NoInfo state, delete this (*,G) assert state (Actions A5), and allow the normal PIM Join/Prune mechanisms to operate. If whoever sent the Join was in error, then the normal assert mechanism will eventually re-apply, and we will lose the assert again. However, whoever sent the assert may know that the previous assert winner has died, so we may end up being the new forwarder.
インターフェイスIでJoin（*、G）を受信します。アップストリームネイバーアドレスフィールドがインターフェイスIのプライマリIPアドレスに設定されているJoin（*、G）を受信します。アクションはNoInfo状態に移行することで、これを削除します（*、 G）状態を表明し（アクションA5）、通常のPIM加入/プルーンメカニズムが動作することを許可します。 Joinを送信した人がエラーになった場合、通常のアサートメカニズムが最終的に再適用され、アサートが再び失われます。ただし、アサートを送信した人は誰でも、前のアサートの勝者が死亡したことを知っている可能性があるため、新しいフォワーダーになる可能性があります。
(*,G) Assert State Machine Actions
（*、G）ステートマシンアクションのアサート
A1: Send Assert(*,G). Set Assert Timer to (Assert_Time - Assert_Override_Interval). Store self as AssertWinner(*,G,I). Store rpt_assert_metric(G,I) as AssertWinnerMetric(*,G,I).
A1：Assert（*、G）を送信します。アサートタイマーを（Assert_Time-Assert_Override_Interval）に設定します。自身をAssertWinner（*、G、I）として保存します。 rpt_assert_metric（G、I）をAssertWinnerMetric（*、G、I）として保存します。
A2: Store new assert winner as AssertWinner(*,G,I) and assert winner metric as AssertWinnerMetric(*,G,I). Set Assert Timer to Assert_Time.
A2：新しいアサート勝者をAssertWinner（*、G、I）として保存し、勝者メトリックをAssertWinnerMetric（*、G、I）としてアサートします。 Assert TimerをAssert_Timeに設定します。
A3: Send Assert(*,G). Set Assert Timer to (Assert_Time - Assert_Override_Interval).
A3：Assert（*、G）を送信します。アサートタイマーを（Assert_Time-Assert_Override_Interval）に設定します。
A4: Send AssertCancel(*,G). Delete assert information (AssertWinner(*,G,I) and AssertWinnerMetric(*,G,I) will then return to their default values).
A4：AssertCancel（*、G）を送信します。アサート情報を削除します（AssertWinner（*、G、I）とAssertWinnerMetric（*、G、I）はデフォルト値に戻ります）。
A5: Delete assert information (AssertWinner(*,G,I) and AssertWinnerMetric(*,G,I) will then return to their default values).
A5：アサート情報を削除します（AssertWinner（*、G、I）とAssertWinnerMetric（*、G、I）はデフォルト値に戻ります）。
Note that some of these actions may cause the value of JoinDesired(*,G) or RPF'(*,G) to change, which could cause further transitions in other state machines.
これらのアクションの一部により、JoinDesired（*、G）またはRPF '（*、G）の値が変化し、他のステートマシンでさらに遷移する可能性があることに注意してください。
Assert metrics are defined as:
アサートメトリックは次のように定義されます。
struct assert_metric {
rpt_bit_flag;
metric_preference;
route_metric;
ip_address;
};
When comparing assert_metrics, the rpt_bit_flag, metric_preference, and route_metric fields are compared in order, where the first lower value wins. If all fields are equal, the primary IP address of the router that sourced the Assert message is used as a tie-breaker, with the highest IP address winning.
assert_metricsを比較するとき、rpt_bit_flag、metric_preference、およびroute_metricフィールドが順番に比較され、最初に小さい値が優先されます。すべてのフィールドが等しい場合、Assertメッセージを発信したルーターのプライマリIPアドレスがタイブレーカーとして使用され、最高のIPアドレスが優先されます。
An assert metric for (S,G) to include in (or compare against) an Assert message sent on interface I should be computed using the following pseudocode:
（S、G）のアサートメトリックは、インターフェイスに送信されたアサートメッセージに含める（または比較する）ため、次の疑似コードを使用して計算する必要があります。
assert_metric
my_assert_metric(S,G,I) {
if( CouldAssert(S,G,I) == TRUE ) {
return spt_assert_metric(S,I)
} else if( CouldAssert(*,G,I) == TRUE ) {
return rpt_assert_metric(G,I)
} else {
return infinite_assert_metric()
}
}
spt_assert_metric(S,I) gives the assert metric we use if we're sending an assert based on active (S,G) forwarding state:
spt_assert_metric（S、I）は、アクティブな（S、G）転送状態に基づいてアサートを送信する場合に使用するアサートメトリックを提供します。
assert_metric
spt_assert_metric(S,I) {
return {0,MRIB.pref(S),MRIB.metric(S),my_ip_address(I)}
}
rpt_assert_metric(G,I) gives the assert metric we use if we're sending an assert based only on (*,G) forwarding state:
rpt_assert_metric（G、I）は、（*、G）転送状態のみに基づいてアサートを送信する場合に使用するアサートメトリックを提供します。
assert_metric
rpt_assert_metric(G,I) {
return {1,MRIB.pref(RP(G)),MRIB.metric(RP(G)),my_ip_address(I)}
}
MRIB.pref(X) and MRIB.metric(X) are the routing preference and routing metrics associated with the route to a particular (unicast) destination X, as determined by the MRIB. my_ip_address(I) is simply the router's primary IP address that is associated with the local interface I.
MRIB.pref（X）およびMRIB.metric（X）は、MRIBによって決定された、特定の（ユニキャスト）宛先Xへのルートに関連付けられたルーティング設定とルーティングメトリックです。 my_ip_address（I）は、ローカルインターフェイスIに関連付けられているルーターのプライマリIPアドレスです。
infinite_assert_metric() is an assert metric that the router uses for an Assert that does not match either (S,G) or (*,G) forwarding state:
infinite_assert_metric()は、（S、G）または（*、G）転送状態のいずれにも一致しないアサートに対してルーターが使用するアサートメトリックです。
assert_metric
infinite_assert_metric() {
return {1,infinity,infinity,0}
}
An AssertCancel message is simply an RPT Assert message but with an infinite metric. It is sent by the assert winner when it deletes the forwarding state that had caused the assert to occur. Other routers will see this metric, and it will cause any other router that has forwarding state to send its own assert, and to take over forwarding.
AssertCancelメッセージは、RPT Assertメッセージですが、メトリックは無限です。アサートを発生させた転送状態を削除すると、アサートの勝者によって送信されます。他のルーターにはこのメトリックが表示され、転送状態にある他のルーターが独自のアサートを送信し、転送を引き継ぎます。
An AssertCancel(S,G) is an infinite metric assert with the RPT bit set that names S as the source.
AssertCancel（S、G）は、Sをソースとして指定するRPTビットが設定された無限メトリックアサートです。
An AssertCancel(*,G) is an infinite metric assert with the RPT bit set and the source set to zero.
AssertCancel（*、G）は、RPTビットがセットされ、ソースがゼロに設定された無限メトリックアサートです。
AssertCancel messages are simply an optimization. The original Assert timeout mechanism will allow a subnet to eventually become consistent; the AssertCancel mechanism simply causes faster convergence. No special processing is required for an AssertCancel message, since it is simply an Assert message from the current winner.
AssertCancelメッセージは単に最適化です。元のアサートタイムアウトメカニズムでは、サブネットが最終的に整合するようになります。 AssertCancelメカニズムは、より高速な収束を引き起こすだけです。 AssertCancelメッセージは現在の勝者からの単にAssertメッセージなので、特別な処理は必要ありません。
The macros lost_assert(S,G,rpt,I), lost_assert(S,G,I), and lost_assert(*,G,I) are used in the olist computations of Section 4.1 and are defined as:
マクロlost_assert（S、G、rpt、I）、lost_assert（S、G、I）、およびlost_assert（*、G、I）は、セクション4.1のolist計算で使用され、次のように定義されます。
bool lost_assert(S,G,rpt,I) {
if ( RPF_interface(RP(G)) == I OR
( RPF_interface(S) == I AND SPTbit(S,G) == TRUE ) ) {
return FALSE
} else {
return ( AssertWinner(S,G,I) != NULL AND
AssertWinner(S,G,I) != me )
}
}
bool lost_assert(S,G,I) {
if ( RPF_interface(S) == I ) {
return FALSE
} else {
return ( AssertWinner(S,G,I) != NULL AND
AssertWinner(S,G,I) != me AND
(AssertWinnerMetric(S,G,I) is better
than spt_assert_metric(S,I) )
}
}
Note: The term "AssertWinnerMetric(S,G,I) is better than spt_assert_metric(S,I)" is required to correctly handle the transition phase when a router has (S,G) join state but has not yet set the SPTbit. In this case, it needs to ignore the assert state if it will win the assert once the SPTbit is set.
注：「AssertWinnerMetric（S、G、I）はspt_assert_metric（S、I）より優れている」という用語は、ルーターが（S、G）加入状態にあるが、まだSPTbitを設定していない場合に遷移フェーズを正しく処理するために必要です。この場合、SPTbitが設定されたときにアサートに勝つ場合は、アサート状態を無視する必要があります。
bool lost_assert(*,G,I) {
if ( RPF_interface(RP(G)) == I ) {
return FALSE
} else {
return ( AssertWinner(*,G,I) != NULL AND
AssertWinner(*,G,I) != me )
}
}
AssertWinner(S,G,I) is the IP source address of the Assert(S,G) packet that won an Assert.
AssertWinner（S、G、I）は、Assertを獲得したAssert（S、G）パケットのIPソースアドレスです。
AssertWinner(*,G,I) is the IP source address of the Assert(*,G) packet that won an Assert.
AssertWinner（*、G、I）は、Assertを獲得したAssert（*、G）パケットのIPソースアドレスです。
AssertWinnerMetric(S,G,I) is the Assert metric of the Assert(S,G) packet that won an Assert.
AssertWinnerMetric（S、G、I）は、Assertを獲得したAssert（S、G）パケットのAssertメトリックです。
AssertWinnerMetric(*,G,I) is the Assert metric of the Assert(*,G) packet that won an Assert.
AssertWinnerMetric（*、G、I）は、Assertを獲得したAssert（*、G）パケットのAssertメトリックです。
AssertWinner(S,G,I) defaults to NULL and AssertWinnerMetric(S,G,I) defaults to Infinity when in the NoInfo state.
NoInfo状態の場合、AssertWinner（S、G、I）はデフォルトでNULLになり、AssertWinnerMetric（S、G、I）はデフォルトでInfinityになります。
Summary of Assert Rules and Rationale
アサートルールと根拠の概要
This section summarizes the key rules for sending and reacting to asserts and the rationale for these rules. This section is not intended to be and should not be treated as a definitive specification of protocol behavior. The state machines and pseudocode should be consulted for that purpose. Rather, this section is intended to document important aspects of the Assert protocol behavior and to provide information that may prove helpful to the reader in understanding and implementing this part of the protocol.
このセクションでは、アサートを送信してアサートするための主要なルールと、これらのルールの根拠をまとめています。このセクションは、プロトコルの動作の明確な仕様として意図されておらず、そのように扱われるべきではありません。そのためには、状態マシンと疑似コードを調べる必要があります。むしろ、このセクションは、プロトコルのアサート動作の重要な側面を文書化し、プロトコルのこの部分の理解と実装において読者に役立つと思われる情報を提供することを目的としています。
1. Behavior: Downstream neighbors send Join(*,G) and Join(S,G) periodic messages to the appropriate RPF' neighbor, i.e., the RPF neighbor as modified by the assert process. They are not always sent to the RPF neighbor as indicated by the MRIB. Normal suppression and override rules apply.
1. 動作：下流のネイバーは、Join（*、G）およびJoin（S、G）の定期的なメッセージを適切なRPFネイバー、つまりアサートプロセスによって変更されたRPFネイバーに送信します。それらは、MRIBによって示されるように、常にRPFネイバーに送信されるわけではありません。通常の抑制および上書きルールが適用されます。
Rationale: By sending the periodic and triggered Join messages to the RPF' neighbor instead of the RPF neighbor, the downstream router avoids re-triggering the Assert process with every Join. A side effect of sending Joins to the Assert winner is that traffic will not switch back to the "normal" RPF neighbor until the Assert times out. This will not happen until data stops flowing, if item 8, below, is implemented.
理論的根拠：RPFネイバーではなくRPFネイバーに定期的でトリガーされた参加メッセージを送信することにより、ダウンストリームルータは、すべての参加でアサートプロセスを再トリガーすることを回避します。アサートの勝者に結合を送信することの副作用は、アサートがタイムアウトするまでトラフィックが「通常の」RPFネイバーに戻らないことです。これは、以下の項目8が実装されている場合、データのフローが停止するまで発生しません。
2. Behavior: The assert winner for (*,G) acts as the local DR for (*,G) on behalf of IGMP/MLD members.
2. 動作：（*、G）のアサート勝者は、IGMP / MLDメンバーに代わって（*、G）のローカルDRとして機能します。
Rationale: This is required to allow a single router to merge PIM and IGMP/MLD joins and leaves. Without this, overrides don't work.
根拠：これは、単一のルーターがPIMとIGMP / MLDの結合と脱退をマージできるようにするために必要です。これがないと、オーバーライドは機能しません。
3. Behavior: The assert winner for (S,G) acts as the local DR for (S,G) on behalf of IGMPv3 members.
3. 動作：（S、G）のアサート勝者は、IGMPv3メンバーに代わって（S、G）のローカルDRとして機能します。
Rationale: Same rationale as for item 2.
根拠：項目2と同じ理由。
4. Behavior: (S,G) and (*,G) prune overrides are sent to the RPF' neighbor and not to the regular RPF neighbor.
4. 動作：（S、G）および（*、G）プルーンオーバーライドは、通常のRPFネイバーではなくRPF 'ネイバーに送信されます。
Rationale: Same rationale as for item 1.
理論的根拠：項目1と同じ理由。
5. Behavior: An (S,G,rpt) prune override is not sent (at all) if RPF'(S,G,rpt) != RPF'(*,G).
5. 動作：RPF '（S、G、rpt）！= RPF'（*、G）の場合、（S、G、rpt）プルーンオーバーライドは送信されません（まったく送信されません）。
Rationale: This avoids keeping state alive on the (S,G) tree when only (*,G) downstream members are left. Also, it avoids sending (S,G,rpt) joins to a router that is not on the (*,G) tree. This behavior might be confusing, although this specification does indicate that such a join SHOULD be dropped.
理論的根拠：これは、（*、G）のダウンストリームメンバーのみが残っている場合に、（S、G）ツリーで状態を維持することを回避します。また、（S、G、rpt）ジョインを（*、G）ツリー上にないルーターに送信することを回避します。この動作は混乱を招く可能性がありますが、この仕様では、そのような結合を削除する必要があることを示しています。
6. Behavior: An assert loser that receives a Join(S,G) with an Upstream Neighbor Address that is its primary IP address on that interface expires the (S,G) Assert Timer.
6. 動作：そのインターフェイスのプライマリIPアドレスであるアップストリームネイバーアドレスでJoin（S、G）を受信するアサート敗者は、（S、G）アサートタイマーを期限切れにします。
Rationale: This is necessary in order to have rapid convergence in the event that the downstream router that initially sent a join to the prior Assert winner has undergone a topology change.
理論的根拠：これは、以前にAssertの勝者に最初に参加を送信したダウンストリームルーターがトポロジーの変更を受けた場合に迅速に収束するために必要です。
7. Behavior: An assert loser that receives a Join(*,G) with an Upstream Neighbor Address that is its primary IP address on that interface expires the (*,G) Assert Timer and all (S,G) assert timers that do not have corresponding Prune(S,G,rpt) messages in the compound Join/Prune message.
7. 動作：そのインターフェースのプライマリIPアドレスであるアップストリームネイバーアドレスを使用してJoin（*、G）を受信するアサート敗者は、（*、G）アサートタイマーとすべての（S、G）アサートタイマーを期限切れにします複合Join / Pruneメッセージ内の対応するPrune（S、G、rpt）メッセージ。
Rationale: Same rationale as for item 6.
根拠：項目6と同じ理由。
8. Behavior: An assert winner for (*,G) or (S,G) sends a canceling assert when it is about to stop forwarding on a (*,G) or an (S,G) entry. This behavior does not apply to (S,G,rpt).
8. 動作：（*、G）または（S、G）エントリの転送を停止しようとするときに、（*、G）または（S、G）のアサート勝者がキャンセルアサートを送信します。この動作は（S、G、rpt）には適用されません。
Rationale: This allows switching back to the shared tree after the last SPT router on the LAN leaves. Doing this prevents downstream routers on the shared tree from keeping SPT state alive.
理論的根拠：これにより、LAN上の最後のSPTルーターが去った後、共有ツリーに切り替えることができます。これにより、共有ツリーのダウンストリームルーターがSPT状態を維持できなくなります。
9. Behavior: Resend the assert messages before timing out an assert. (This behavior is optional.)
9. 動作：アサートをタイムアウトする前に、アサートメッセージを再送信します。 （この動作はオプションです。）
Rationale: This prevents the periodic duplicates that would otherwise occur each time that an assert times out and is then re-established.
根拠：これにより、アサートがタイムアウトして再確立されるたびに発生する定期的な重複が防止されます。
10. Behavior: When RPF'(S,G,rpt) changes to be the same as RPF'(*,G), we need to trigger a Join(S,G,rpt) to RPF'(*,G).
10. 動作：RPF '（S、G、rpt）がRPF'（*、G）と同じになるように変更した場合、RPF '（*、G）へのJoin（S、G、rpt）をトリガーする必要があります。
Rationale: This allows switching back to the RPT after the last SPT member leaves.
理論的根拠：これにより、最後のSPTメンバーが去った後、RPTに切り替えることができます。
For correct operation, every PIM router within a PIM domain must be able to map a particular multicast group address to the same RP. If this is not the case, then black holes may appear, where some receivers in the domain cannot receive some groups. A domain in this context is a contiguous set of routers that all implement PIM and are configured to operate within a common boundary.
正しく動作させるには、PIMドメイン内のすべてのPIMルーターが特定のマルチキャストグループアドレスを同じRPにマップできる必要があります。そうでない場合、ドメイン内の一部の受信者が一部のグループを受信できないブラックホールが表示されることがあります。このコンテキストのドメインは、すべてがPIMを実装し、共通の境界内で動作するように構成されている連続したルーターのセットです。
A notable exception to this is where a PIM domain is broken up into multiple administrative scope regions; these are regions where a border has been configured so that a range of multicast groups will not be forwarded across that border. For more information on Administratively Scoped IP Multicast, see RFC 2365. The modified criteria for admin-scoped regions are that the region is convex with respect to forwarding based on the MRIB, and that all PIM routers within the scope region map scoped groups to the same RP within that region.
これの注目すべき例外は、PIMドメインが複数の管理スコープ領域に分割される場合です。これらは、マルチキャストグループの範囲がその境界を越えて転送されないように境界が構成されている領域です。管理スコープのIPマルチキャストの詳細については、RFC 2365を参照してください。管理スコープ領域の変更された基準は、MRIBに基づく転送に関して領域が凸状であり、スコープ領域内のすべてのPIMルーターがスコープグループをその地域内の同じRP。
This specification does not mandate the use of a single mechanism to provide routers with the information to perform the group-to-RP mapping. Currently, four mechanisms are possible, and all four have associated problems:
この仕様は、グループからRPへのマッピングを実行するための情報をルーターに提供する単一のメカニズムの使用を義務付けていません。現在、4つのメカニズムが可能であり、4つすべてに関連する問題があります。
Static Configuration A PIM router MUST support the static configuration of group-to-RP mappings. Such a mechanism is not robust to failures but does at least provide a basic interoperability mechanism.
静的構成PIMルーターは、グループからRPへのマッピングの静的構成をサポートする必要があります。このようなメカニズムは障害に対して堅牢ではありませんが、少なくとも基本的な相互運用性メカニズムを提供します。
Embedded-RP Embedded-RP defines an address allocation policy in which the address of the Rendezvous Point (RP) is encoded in an IPv6 multicast group address [16].
Embedded-RP Embedded-RPは、Rendezvous Point（RP）のアドレスがIPv6マルチキャストグループアドレスにエンコードされるアドレス割り当てポリシーを定義します[16]。
Cisco's Auto-RP Auto-RP uses a PIM Dense-Mode (PIM-DM) multicast group to announce group-to-RP mappings from a central location. This mechanism is not useful if PIM Dense Mode is not being run in parallel with PIM Sparse Mode; it was only intended for use with PIM Sparse Mode Version 1. No standard specification currently exists.
シスコのAuto-RP Auto-RPは、PIM Dense-Mode（PIM-DM）マルチキャストグループを使用して、中央の場所からグループからRPへのマッピングをアナウンスします。このメカニズムは、PIM密モードがPIM希薄モードと並行して実行されていない場合は役に立ちません。 PIMスパースモードバージョン1での使用のみを目的としています。現在、標準仕様は存在しません。
Bootstrap Router (BSR) RFC 2362 specifies a bootstrap mechanism based on the automatic election of a BSR. Any router in the domain that is configured to be a possible RP reports its candidacy to the BSR, and then a domain-wide flooding mechanism distributes the BSR's chosen set of RPs throughout the domain. As specified in RFC 2362, the BSR mechanism is flawed in its handling of admin-scoped regions that are smaller than a PIM domain, but the mechanism does work for global-scoped groups.
ブートストラップルーター（BSR）RFC 2362は、BSRの自動選択に基づくブートストラップメカニズムを指定しています。可能なRPになるように構成されたドメイン内のルーターは、その候補をBSRに報告し、ドメイン全体のフラッディングメカニズムにより、BSRで選択されたRPのセットがドメイン全体に分散されます。 RFC 2362で指定されているように、BSRメカニズムには、PIMドメインより小さい管理スコープの領域の処理に欠陥がありますが、メカニズムはグローバルスコープのグループに対しては機能します。
As far as PIM-SM is concerned, the only important requirement is that all routers in the domain (or admin scope zone for scoped regions) receive the same set of group-range-to-RP mappings. This may be achieved through the use of any of these mechanisms, or through alternative mechanisms not currently specified.
PIM-SMに関する限り、唯一の重要な要件は、ドメイン内のすべてのルーター（またはスコープリージョンの管理スコープゾーン）が同じグループ範囲からRPへのマッピングのセットを受信することです。これは、これらのメカニズムのいずれかを使用するか、現在指定されていない代替メカニズムを使用して実現できます。
It must be operationally ensured that any RP address configured, learned, or advertised is reachable from all routers in the PIM domain.
設定、学習、またはアドバタイズされたすべてのRPアドレスがPIMドメイン内のすべてのルータから到達可能であることを運用上保証する必要があります。
Using one of the mechanisms described above, a PIM router receives one or more possible group-range-to-RP mappings. Each mapping specifies a range of multicast groups (expressed as a group and mask) and the RP to which such groups should be mapped. Each mapping may also have an associated priority. It is possible to receive multiple mappings, all of which might match the same multicast group; this is the common case with the BSR mechanism. The algorithm for performing the group-to-RP mapping is as follows:
上記のメカニズムの1つを使用して、PIMルーターは1つ以上の可能なグループ範囲からRPへのマッピングを受信します。各マッピングは、マルチキャストグループの範囲（グループおよびマスクとして表現）と、そのようなグループをマッピングする必要のあるRPを指定します。各マッピングには、関連付けられた優先度もあります。複数のマッピングを受信することが可能であり、そのすべてが同じマルチキャストグループと一致する場合があります。これは、BSRメカニズムの一般的なケースです。グループからRPへのマッピングを実行するためのアルゴリズムは次のとおりです。
1. Perform longest match on group range to obtain a list of RPs.
1. グループ範囲で最長一致を実行して、RPのリストを取得します。
2. From this list of matching RPs, find the ones with highest priority.
2. この一致するRPのリストから、優先順位が最も高いRPを見つけます。
Eliminate any RPs from the list that have lower priorities.
優先度の低いRPをリストから削除します。
3. If only one RP remains in the list, use that RP.
3. リストにRPが1つだけ残っている場合は、そのRPを使用します。
4. If multiple RPs are in the list, use the PIM hash function to choose one.
4. リストに複数のRPがある場合は、PIMハッシュ関数を使用して1つを選択します。
Thus, if two or more group-range-to-RP mappings cover a particular group, the one with the longest mask is the mapping to use. If the mappings have the same mask length, then the one with the highest priority is chosen. If there is more than one matching entry with the same longest mask and the priorities are identical, then a hash function (see Section 4.7.2) is applied to choose the RP.
したがって、2つ以上のグループ範囲からRPへのマッピングが特定のグループをカバーする場合、最も長いマスクを持つものが使用するマッピングです。マッピングのマスク長が同じである場合、優先順位が最も高いマッピングが選択されます。同じ最長マスクを持つ複数の一致するエントリがあり、優先順位が同一である場合、RPを選択するためにハッシュ関数（セクション4.7.2を参照）が適用されます。
This algorithm is invoked by a DR when it needs to determine an RP for a given group, e.g., upon reception of a packet or IGMP/MLD membership indication for a group for which the DR does not know the RP.
このアルゴリズムは、DRが特定のグループのRPを決定する必要がある場合、たとえば、DRがRPを認識していないグループのパケットまたはIGMP / MLDメンバーシップ表示を受信したときに呼び出されます。
Furthermore, the mapping function is invoked by all routers upon receiving a (*,G) Join/Prune message.
さらに、マッピング機能は、（*、G）Join / Pruneメッセージを受信すると、すべてのルーターによって呼び出されます。
Note that if the set of possible group-range-to-RP mappings changes, each router will need to check whether any existing groups are affected. This may, for example, cause a DR or acting DR to re-join a group, or cause it to restart register encapsulation to the new RP.
可能なグループ範囲とRPのマッピングのセットが変更された場合、各ルーターは既存のグループが影響を受けるかどうかを確認する必要があることに注意してください。これにより、たとえば、DRまたは代理DRがグループに再度参加したり、新しいRPへのレジスタカプセル化を再開したりすることがあります。
Implementation note: The bootstrap mechanism described in RFC 2362 omitted step 1 above. However, of the implementations we are aware of, approximately half performed step 1 anyway. Note that implementations of BSR that omit step 1 will not correctly interoperate with implementations of this specification when used with the BSR mechanism described in [11].
実装上の注意：RFC 2362で説明されているブートストラップメカニズムは、上記のステップ1を省略しました。ただし、私たちが認識している実装のうち、いずれにしても約半分はステップ1を実行しました。ステップ1を省略したBSRの実装は、[11]で説明されているBSRメカニズムと共に使用すると、この仕様の実装と正しく相互運用できないことに注意してください。
The hash function is used by all routers within a domain, to map a group to one of the RPs from the matching set of group-range-to-RP mappings (this set of mappings all have the same longest mask length and same highest priority). The algorithm takes as input the group address, and the addresses of the candidate RPs from the mappings, and gives as output one RP address to be used.
ハッシュ関数は、ドメイン内のすべてのルーターによって使用され、グループ範囲からRPへのマッピングの一致するセットからのRPの1つにグループをマッピングします（このマッピングのセットはすべて、最長のマスク長と最高の優先度が同じです）。アルゴリズムは、入力としてグループアドレスと、マッピングからの候補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 matching group-range-to-RP mappings, compute a value:
1. 一致するグループ範囲からRPへのマッピングの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. If BSR is being used, the hash-mask is given in the Bootstrap messages. If BSR is not being used, the alternative mechanism that supplies the group-range-to-RP mappings may supply the value, or else it defaults to a mask with the most significant 30 bits being one for IPv4 and the most significant 126 bits being one for IPv6. 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はハッシュマスクです。 BSRが使用されている場合、ハッシュマスクはブートストラップメッセージで提供されます。 BSRが使用されていない場合、グループ範囲からRPへのマッピングを提供する代替メカニズムが値を提供する可能性があります。そうでない場合、デフォルトで、最上位の30ビットがIPv4の1つで、最上位の126ビットがマスクになるマスクになります。 1つはIPv6用です。ハッシュマスクを使用すると、少数の連続したグループ（4など）が常に同じRPにハッシュできます。たとえば、階層的にエンコードされたデータを連続したグループアドレスに送信して、同じ遅延と運命共有の特性を得ることができます。
For address families other than IPv4, a 32-bit digest to be used as C(i) and G must first be derived from the actual RP or group address. Such a digest method must be used consistently throughout the PIM domain. For IPv6 addresses, it is RECOMMENDED to use the equivalent IPv4 address for an IPv4-compatible address, and the exclusive-or of each 32-bit segment of the address for all other IPv6 addresses. For example, the digest of the IPv6 address 3ffe:b00:c18:1::10 would be computed as 0x3ffe0b00 ^ 0x0c180001 ^ 0x00000000 ^ 0x00000010, where the '^' symbol represents the exclusive-or operation.
IPv4以外のアドレスファミリの場合、C（i）およびGとして使用される32ビットダイジェストは、最初に実際のRPまたはグループアドレスから派生する必要があります。このようなダイジェスト方式は、PIMドメイン全体で一貫して使用する必要があります。 IPv6アドレスの場合、IPv4互換アドレスには同等のIPv4アドレスを使用し、他のすべてのIPv6アドレスにはアドレスの各32ビットセグメントの排他的論理和を使用することをお勧めします。たとえば、IPv6アドレス3ffe：b00：c18：1 :: 10のダイジェストは0x3ffe0b00 ^ 0x0c180001 ^ 0x00000000 ^ 0x00000010として計算されます。ここで、「^」記号は排他的論理和演算を表します。
2. The candidate RP with the highest resulting hash value is then the RP chosen by this hash function. If more than one RP has the same highest hash value, the RP with the highest IP address is chosen.
2. 結果のハッシュ値が最も高い候補RPは、このハッシュ関数によって選択されたRPです。複数のRPが同じ最高のハッシュ値を持つ場合、最高のIPアドレスを持つRPが選択されます。
The Source-Specific Multicast (SSM) service model [6] can be implemented with a strict subset of the PIM-SM protocol mechanisms. Both regular IP Multicast and SSM semantics can coexist on a single router, and both can be implemented using the PIM-SM protocol. A range of multicast addresses, currently 232.0.0.0/8 in IPv4 and ff3x::/32 for IPv6, is reserved for SSM, and the choice of semantics is determined by the multicast group address in both data packets and PIM messages.
Source-Specific Multicast（SSM）サービスモデル[6]は、PIM-SMプロトコルメカニズムの厳密なサブセットで実装できます。通常のIPマルチキャストとSSMの両方のセマンティクスが単一のルーターに共存でき、どちらもPIM-SMプロトコルを使用して実装できます。マルチキャストアドレスの範囲は、現在IPv4では232.0.0.0/8、IPv6ではff3x :: / 32で、SSM用に予約されています。セマンティクスの選択は、データパケットとPIMメッセージの両方のマルチキャストグループアドレスによって決まります。
The following rules override the normal PIM-SM behavior for a multicast address G in the SSM range:
次のルールは、SSM範囲のマルチキャストアドレスGの通常のPIM-SM動作を上書きします。
o A router MUST NOT send a (*,G) Join/Prune message for any reason.
o ルーターは、何らかの理由で（*、G）Join / Pruneメッセージを送信してはなりません（MUST NOT）。
o A router MUST NOT send an (S,G,rpt) Join/Prune message for any reason.
o ルーターは、何らかの理由で（S、G、rpt）Join / Pruneメッセージを送信してはなりません（MUST NOT）。
o A router MUST NOT send a Register message for any packet that is destined to an SSM address.
o ルーターは、SSMアドレス宛のパケットに対して登録メッセージを送信してはなりません（MUST NOT）。
o A router MUST NOT forward packets based on (*,G) or (S,G,rpt) state. The (*,G)- and (S,G,rpt)-related state summarization macros are NULL for any SSM address, for the purposes of packet forwarding.
o ルーターは、（*、G）または（S、G、rpt）状態に基づいてパケットを転送してはなりません（MUST NOT）。 （*、G）および（S、G、rpt）関連の状態要約マクロは、パケット転送の目的で、すべてのSSMアドレスに対してNULLです。
o A router acting as an RP MUST NOT forward any Register-encapsulated packet that has an SSM destination address and SHOULD respond with a Register-Stop message to such a Register message.
o RPとして機能するルーターは、SSM宛先アドレスを持つRegisterカプセル化パケットを転送してはならず、そのようなRegisterメッセージに対してRegister-Stopメッセージで応答する必要があります（SHOULD）。
o A router MAY optimize out the creation and maintenance of (S,G,rpt) and (*,G) state for SSM destination addresses -- this state is not needed for SSM packets.
o ルーターは、SSM宛先アドレスの（S、G、rpt）と（*、G）状態の作成と保守を最適化できます（MAY）。この状態はSSMパケットには必要ありません。
The last three rules are present to deal with SSM-unaware "legacy" routers that may be sending (*,G) and (S,G,rpt) Join/Prunes, or Register messages for SSM destination addresses. Note that this specification does not attempt to aid an SSM-unaware "legacy" router with SSM operations.
最後の3つのルールは、SSM宛先アドレスの（*、G）および（S、G、rpt）Join / Prunes、またはRegisterメッセージを送信する可能性があるSSM非対応の「レガシー」ルーターを処理するために存在します。この仕様は、SSM非対応の「レガシー」ルーターをSSM操作で支援することを意図していないことに注意してください。
An implementer may choose to implement only the subset of PIM Sparse Mode that provides SSM forwarding semantics.
実装者は、SSM転送セマンティクスを提供するPIMスパースモードのサブセットのみを実装することを選択できます。
A PIM-SSM-only router MUST implement the following portions of this specification:
PIM-SSMのみのルーターは、この仕様の次の部分を実装する必要があります。
o Upstream (S,G) state machine (Section 4.5.5)
o アップストリーム（S、G）ステートマシン（セクション4.5.5）
o Downstream (S,G) state machine (Section 4.5.2)
o ダウンストリーム（S、G）ステートマシン（セクション4.5.2）
o (S,G) Assert state machine (Section 4.6.1)
o （S、G）ステートマシンをアサート（セクション4.6.1）
o Hello messages, neighbor discovery, and DR election (Section 4.3)
o Helloメッセージ、ネイバー探索、DR選出（セクション4.3）
o Packet forwarding rules (Section 4.2)
o パケット転送ルール（セクション4.2）
A PIM-SSM-only router does not need to implement the following protocol elements:
PIM-SSMのみのルーターは、次のプロトコル要素を実装する必要はありません。
o Register state machine (Section 4.4)
o ステートマシンの登録（セクション4.4）
o (*,G) and (S,G,rpt) downstream state machines (Sections 4.5.1 and 4.5.3)
o （*、G）および（S、G、rpt）ダウンストリームステートマシン（セクション4.5.1および4.5.3）
o (*,G) and (S,G,rpt) upstream state machines (Sections 4.5.4, 4.5.6, and 4.5.7)
o （*、G）および（S、G、rpt）アップストリームステートマシン（セクション4.5.4、4.5.6、および4.5.7）
o (*,G) Assert state machine (Section 4.6.2)
o （*、G）ステートマシンをアサート（セクション4.6.2）
o Bootstrap RP election (Section 4.7)
o ブートストラップRPの選択（セクション4.7）
o Keepalive Timer
o キープアライブタイマー
o SPTbit (Section 4.2.2)
o SPTbit（セクション4.2.2）
The Keepalive Timer should be treated as always running, and the SPTbit should be treated as always being set for an SSM address. Additionally, the packet forwarding rules of Section 4.2 can be simplified in a PIM-SSM-only router:
キープアライブタイマーは常に実行されているものとして扱い、SPTbitは常にSSMアドレスに設定されているものとして扱う必要があります。さらに、セクション4.2のパケット転送ルールは、PIM-SSMのみのルーターで簡略化できます。
oiflist = NULL
if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined ) {
oiflist = inherited_olist(S,G)
} else if( iif is in inherited_olist(S,G) ) {
send Assert(S,G) on iif
}
oiflist = oiflist (-) iif forward packet on all interfaces in oiflist
oiflist = oiflist（-）oiflistのすべてのインターフェースでiif転送パケット
This is nothing more than the reduction of the normal PIM-SM forwarding rule, with all (S,G,rpt) and (*,G) clauses replaced with NULL.
これは、すべての（S、G、rpt）句と（*、G）句がNULLに置き換えられた、通常のPIM-SM転送ルールの削減にすぎません。
This section describes the details of the packet formats for PIM control messages.
このセクションでは、PIM制御メッセージのパケット形式の詳細について説明します。
All PIM control messages have IP protocol number 103.
すべてのPIM制御メッセージのIPプロトコル番号は103です。
PIM messages are either unicast (e.g., Registers and Register-Stop) or multicast with TTL 1 to the 'ALL-PIM-ROUTERS' group (e.g., Join/Prune, Asserts). The source address used for unicast messages is a domain-wide reachable address; the source address used for multicast messages is the link-local address of the interface on which the message is being sent.
PIMメッセージは、ユニキャスト（RegistersおよびRegister-Stopなど）またはTTL 1を使用して 'ALL-PIM-ROUTERS'グループ（Join / Prune、Assertsなど）にマルチキャストされます。ユニキャストメッセージに使用される送信元アドレスは、ドメイン全体の到達可能なアドレスです。マルチキャストメッセージに使用される送信元アドレスは、メッセージが送信されているインターフェイスのリンクローカルアドレスです。
The IPv4 'ALL-PIM-ROUTERS' group is '224.0.0.13'. The IPv6 'ALL-PIM-ROUTERS' group is 'ff02::d'.
IPv4「ALL-PIM-ROUTERS」グループは「224.0.0.13」です。 IPv6の「ALL-PIM-ROUTERS」グループは「ff02 :: d」です。
The PIM header common to all PIM messages is:
すべてのPIMメッセージに共通のPIMヘッダーは次のとおりです。
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タイプは次のとおりです。
Message Type Destination
---------------------------------------------------------------------
0 = Hello Multicast to ALL-PIM-ROUTERS
1 = Register Unicast to RP
2 = Register-Stop Unicast to source of Register
packet
3 = Join/Prune Multicast to ALL-PIM-ROUTERS
4 = Bootstrap Multicast to ALL-PIM-ROUTERS
5 = Assert Multicast to ALL-PIM-ROUTERS
6 = Graft (used in PIM-DM only) Unicast to RPF'(S)
7 = Graft-Ack (used in PIM-DM only) Unicast to source of Graft
packet
8 = Candidate-RP-Advertisement Unicast to Domain's BSR
Reserved
Set to zero on transmission. Ignored upon receipt.
Checksum The checksum is a standard IP checksum, i.e., the 16-bit one's complement of the one's complement sum of the entire PIM message, excluding the "Multicast data packet" section of the Register message. For computing the checksum, the checksum field is zeroed. If the packet's length is not an integral number of 16-bit words, the packet is padded with a trailing byte of zero before performing the checksum.
チェックサムチェックサムは標準のIPチェックサムです。つまり、登録メッセージの「マルチキャストデータパケット」セクションを除く、PIMメッセージ全体の1の補数の16ビットの補数です。チェックサムを計算する場合、チェックサムフィールドはゼロに設定されます。パケットの長さが16ビットワードの整数でない場合、チェックサムを実行する前に、パケットの末尾のバイトがゼロで埋められます。
For IPv6, the checksum also includes the IPv6 "pseudo-header", as specified in RFC 2460, Section 8.1 [5]. This "pseudo-header" is prepended to the PIM header for the purposes of calculating the checksum. The "Upper-Layer Packet Length" in the pseudo-header is set to the length of the PIM message, except in Register messages where it is set to the length of the PIM register header (8). The Next Header value used in the pseudo-header is 103.
IPv6の場合、RFC 2460のセクション8.1 [5]で指定されているように、チェックサムにはIPv6の「疑似ヘッダー」も含まれます。この「疑似ヘッダー」は、チェックサムを計算する目的でPIMヘッダーの前に付加されます。疑似ヘッダーの「上位パケット長」は、PIMメッセージの長さに設定されます。ただし、PIMレジスタヘッダーの長さに設定されているRegisterメッセージでは例外です（8）。疑似ヘッダーで使用される次のヘッダー値は103です。
If a message is received with an unrecognized PIM Ver or Type field, or if a message's destination does not correspond to the table above, the message MUST be discarded, and an error message SHOULD be logged to the administrator in a rate-limited manner.
認識されないPIM VerまたはTypeフィールドを含むメッセージが受信された場合、またはメッセージの宛先が上記の表に対応していない場合は、メッセージを破棄する必要があり、エラーメッセージはレート制限された方法で管理者に記録する必要があります（SHOULD）。
Encoded Unicast Address
エンコードされたユニキャストアドレス
An encoded unicast address takes the following format:
エンコードされたユニキャストアドレスの形式は次のとおりです。
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 PIM address family of the 'Unicast Address' field of this address.
Addr Familyこのアドレスの「ユニキャストアドレス」フィールドのPIMアドレスファミリ。
Values 0-127 are as assigned by the IANA for Internet Address Families in [7]. Values 128-250 are reserved to be assigned by the IANA for PIM-specific Address Families. Values 251 through 255 are designated for Private Use. As there is no assignment authority for this space, collisions should be expected.
値0〜127は、[7]のインターネットアドレスファミリに対してIANAによって割り当てられたものです。値128〜250は、PIM固有のアドレスファミリ用にIANAによって割り当てられるように予約されています。 251〜255の値は、私的使用に指定されています。このスペースには割り当て権限がないため、衝突が予想されます。
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.
ユニキャストアドレス指定されたアドレスファミリとエンコーディングタイプで表されるユニキャストアドレス。
Encoded Group Address
エンコードされたグループアドレス
Encoded group addresses take the following format:
エンコードされたグループアドレスの形式は次のとおりです。
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 |B| Reserved |Z| Mask Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group multicast Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
Addr Family Described above.
上記のアドレスファミリ。
Encoding Type Described above.
上記のエンコーディングタイプ。
[B]idirectional PIM Indicates that the group range uses Bidirectional PIM [13]. For PIM-SM as defined in this specification, this bit MUST be zero.
[B] idirectional PIMグループ範囲が双方向PIM [13]を使用することを示します。この仕様で定義されているPIM-SMの場合、このビットはゼロでなければなりません。
Reserved Transmitted as zero. Ignored upon receipt.
予約済みゼロとして送信されます。受領時に無視されます。
Admin Scope [Z]one Indicates that the group range is an admin scope zone. This is used in the Bootstrap Router mechanism [11] only. For all other purposes, this bit is set to zero and ignored on receipt.
管理スコープ[Z] oneグループ範囲が管理スコープゾーンであることを示します。これは、Bootstrap Routerメカニズム[11]でのみ使用されます。他のすべての目的では、このビットはゼロに設定され、受信時に無視されます。
Mask Len The Mask length field is 8 bits. The value is the number of contiguous one bits that are left-justified and used as a mask; when combined with the group address, it describes a range of groups. 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, 128 for IPv6 native encoding).
マスク長マスク長フィールドは8ビットです。値は、左寄せされ、マスクとして使用される連続する1ビットの数です。グループアドレスと組み合わせると、グループの範囲を示します。指定されたアドレスファミリとエンコーディングタイプのアドレス長（ビット単位）以下です。メッセージが単一のグループに送信される場合、マスクの長さは、指定されたアドレスファミリおよびエンコーディングタイプのビット単位のアドレス長と同じでなければなりません（たとえば、IPv4ネイティブエンコーディングの場合は32、IPv6ネイティブエンコーディングの場合は128）。
Group multicast Address Contains the group address.
グループマルチキャストアドレスグループアドレスが含まれます。
Encoded Source Address
エンコードされた送信元アドレス
An encoded source address takes the following format:
エンコードされた送信元アドレスの形式は次のとおりです。
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 The Sparse bit is a 1-bit value, set to 1 for PIM-SM. It is used for PIM Version 1 compatibility.
Sスパースビットは1ビット値で、PIM-SMの場合は1に設定されます。 PIMバージョン1との互換性のために使用されます。
W The WC (or WildCard) bit is a 1-bit value for use with PIM Join/Prune messages (see Section 4.9.5.1).
W WC（またはワイルドカード）ビットは、PIM Join / Pruneメッセージで使用する1ビット値です（セクション4.9.5.1を参照）。
R The RPT (or Rendezvous Point Tree) bit is a 1-bit value for use with PIM Join/Prune messages (see Section 4.9.5.1). If the WC bit is 1, the RPT bit MUST be 1.
R RPT（またはランデブーポイントツリー）ビットは、PIM Join / Pruneメッセージで使用する1ビットの値です（セクション4.9.5.1を参照）。 WCビットが1の場合、RPTビットは1でなければなりません。
Mask Len The mask length field is 8 bits. The value is the number of contiguous one bits that are left-justified and used as a mask; when combined with the source address, it describes a source subnet. The mask length MUST be equal to the mask length in bits for the given Address Family and Encoding Type (32 for IPv4 native and 128 for IPv6 native). A router SHOULD ignore any messages received with any other mask length.
マスク長マスク長フィールドは8ビットです。値は、左寄せされ、マスクとして使用される連続する1ビットの数です。送信元アドレスと組み合わせると、送信元サブネットを示します。マスクの長さは、指定されたアドレスファミリとエンコーディングタイプのビット単位のマスク長に等しい必要があります（IPv4ネイティブの場合は32、IPv6ネイティブの場合は128）。ルータは、他のマスク長で受信されたメッセージを無視する必要があります（SHOULD）。
Source Address The source address.
送信元アドレス送信元アドレス。
A Hello message is sent periodically by routers on all interfaces.
Helloメッセージは、すべてのインターフェイスのルーターによって定期的に送信されます。
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 in Section 4.9.
PIMバージョン、タイプ、予約済み、チェックサムセクション4.9で説明。
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:
オプションフィールドには、次の値が含まれる場合があります。
o OptionType 1: Holdtime
o OptionType 1：ホールドタイム
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Holdtime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 dial-on-demand links, to avoid keeping the link up with periodic Hello messages.
ホールドタイムは、受信者がネイバーに到達可能な状態を維持する必要がある時間を秒単位で表したものです。 Holdtimeが「0xffff」に設定されている場合、このメッセージの受信者はネイバーをタイムアウトすることはありません。これは、定期的なHelloメッセージでリンクを維持し続けるのを避けるために、ダイヤルオンデマンドリンクで使用できます。
An implementation MAY provide a configuration mechanism to reject a Hello message with holdtime 0xffff, and/or provide a mechanism to remove a neighbor.
実装は、ホールドタイム0xffffのHelloメッセージを拒否するための構成メカニズムを提供したり、ネイバーを削除するメカニズムを提供したりする場合があります。
Hello messages with a Holdtime value set to '0' are also sent by a router on an interface about to go down or changing IP address (see Section 4.3.1). These are effectively goodbye messages, and the receiving routers SHOULD immediately time out the neighbor information for the sender.
Holdtime値が「0」に設定されたHelloメッセージも、ダウンするか、IPアドレスを変更しようとしているインターフェース上のルーターによって送信されます（セクション4.3.1を参照）。これらは事実上さようならメッセージであり、受信側ルーターは送信側のネイバー情報をすぐにタイムアウトする必要があります（SHOULD）。
o OptionType 2: LAN Prune Delay
o OptionType 2：LANプルーニング遅延
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| Propagation_Delay | Override_Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The LAN Prune Delay option is used to tune the prune propagation delay on multi-access LANs. The T bit specifies the ability of the sending router to disable Join suppression. Propagation_Delay and Override_Interval are time intervals in units of milliseconds. A router originating a LAN Prune Delay option on interface I sets the Propagation_Delay field to the configured value of Propagation_Delay(I) and the value of the Override_Interval field to the value of Override_Interval(I). On a receiving router, the values of the fields are used to tune the value of the Effective_Override_Interval(I) and its derived timer values.
LAN Prune Delayオプションは、マルチアクセスLANでのプルーン伝搬遅延を調整するために使用されます。 Tビットは、送信ルーターが参加抑制を無効にする機能を指定します。 Propagation_DelayおよびOverride_Intervalは、ミリ秒単位の時間間隔です。インターフェイスIでLANプルーニング遅延オプションを発信するルーターは、Propagation_DelayフィールドをPropagation_Delay（I）の構成された値に設定し、Override_Intervalフィールドの値をOverride_Interval（I）の値に設定します。受信ルーターでは、フィールドの値を使用して、Effective_Override_Interval（I）の値とその派生タイマー値を調整します。
Section 4.3.3 describes how these values affect the behavior of a router.
セクション4.3.3では、これらの値がルーターの動作にどのように影響するかについて説明します。
o OptionTypes 3 through 16: Reserved; to be defined in future versions of this document.
o OptionTypes 3から16：予約済み。このドキュメントの将来のバージョンで定義される予定です。
o OptionType 18: Deprecated and should not be used.
o OptionType 18：推奨されていません。使用しないでください。
o OptionType 19: DR Priority
o OptionType 19：DR優先度
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 19 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DR Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DR Priority is a 32-bit unsigned number and should be considered in the DR election as described in Section 4.3.2.
DR優先度は32ビットの符号なしの数値であり、セクション4.3.2で説明されているように、DR選定で検討する必要があります。
o OptionType 20: Generation ID
o OptionType 20：世代ID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 20 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Generation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Generation ID is a random 32-bit value for the interface on which the Hello message is sent. The Generation ID is regenerated whenever PIM forwarding is started or restarted on the interface.
世代IDは、Helloメッセージが送信されるインターフェイスのランダムな32ビット値です。生成IDは、PIM転送がインターフェイスで開始または再起動されるたびに再生成されます。
o OptionType 24: Address List
o OptionType 24：アドレス一覧
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 24 | Length = <Variable> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Secondary Address 1 (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Secondary Address N (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The contents of the Address List Hello option are described in Section 4.3.4. All addresses within a single Address List must belong to the same address family.
Address List Helloオプションの内容については、4.3.4項で説明しています。 1つのアドレスリスト内のすべてのアドレスは、同じアドレスファミリに属している必要があります。
OptionTypes 17 through 65000 are assigned by the IANA. OptionTypes 65001 through 65535 are reserved for Private Use, as defined in [9].
OptionType 17〜65000はIANAによって割り当てられます。 [9]で定義されているように、OptionTypes 65001から65535は私用に予約されています。
Unknown options MUST be ignored and MUST NOT prevent a neighbor relationship from being formed. The Holdtime option MUST be implemented; the DR Priority and Generation ID options SHOULD be implemented. The Address List option MUST be implemented for IPv6.
不明なオプションは無視する必要があり、隣接関係の形成を妨げてはなりません（MUST NOT）。 Holdtimeオプションを実装する必要があります。 DR PriorityおよびGeneration IDオプションを実装する必要があります。 IPv6では、アドレス一覧オプションを実装する必要があります。
A Register message is sent by the DR to the RP when a multicast packet needs to be transmitted on the RP-tree. The IP source address is set to the address of the DR, the destination address to the RP's address. The IP TTL of the PIM packet is the system's normal unicast TTL.
Registerメッセージは、マルチキャストパケットをRPツリーで送信する必要があるときに、DRによってRPに送信されます。 IP送信元アドレスはDRのアドレスに設定され、宛先アドレスはRPのアドレスに設定されます。 PIMパケットのIP TTLは、システムの通常のユニキャストTTLです。
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| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Multicast data packet .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Type, Reserved, Checksum
Described in Section 4.9. Note that in order to reduce
encapsulation overhead, the checksum for Registers is done only
on the first 8 bytes of the packet, including the PIM header
and the next 4 bytes, excluding the data packet portion. For
interoperability reasons, a message carrying a checksum
calculated over the entire PIM Register message should also be
accepted. When calculating the checksum, the IPv6
pseudo-header "Upper-Layer Packet Length" is set to 8.
B The Border bit. This specification deprecates the Border bit. A router MUST set the B bit to 0 on transmission and MUST ignore this bit on reception.
Bボーダービット。この仕様では、ボーダービットは廃止されています。ルータは送信時にBビットを0に設定しなければならず（MUST）、受信時にこのビットを無視しなければなりません（MUST）。
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に設定します。
Reserved2 Transmitted as zero, ignored on receipt.
Reserved2ゼロとして送信され、受信時に無視されます。
Multicast data packet The original packet sent by the source. This packet must be of the same address family as the encapsulating PIM packet, e.g., an IPv6 data packet must be encapsulated in an IPv6 PIM packet. Note that the TTL of the original packet is decremented before encapsulation, just like any other packet that is forwarded. In addition, the RP decrements the TTL after decapsulating, before forwarding the packet down the shared tree.
マルチキャストデータパケットソースによって送信された元のパケット。このパケットは、カプセル化するPIMパケットと同じアドレスファミリである必要があります。たとえば、IPv6データパケットはIPv6 PIMパケットにカプセル化する必要があります。転送される他のパケットと同様に、元のパケットのTTLはカプセル化の前に減分されることに注意してください。さらに、RPはカプセル化を解除した後、共有ツリーにパケットを転送する前にTTLを減らします。
For (S,G) Null-Registers, the Multicast data packet portion contains a dummy IP header with S as the source address and G as the destination address. When generating an IPv4 Null-Register message, the fields in the dummy IPv4 header SHOULD be filled in according to the following table. Other IPv4 header fields may contain any value that is valid for that field.
（S、G）Null-Registersの場合、マルチキャストデータパケット部分には、送信元アドレスがSで宛先アドレスがGのダミーIPヘッダーが含まれています。 IPv4 Null-Registerメッセージを生成する場合、次の表に従って、ダミーIPv4ヘッダーのフィールドに入力する必要があります（SHOULD）。他のIPv4ヘッダーフィールドには、そのフィールドに有効な任意の値が含まれる場合があります。
Field Value
---------------------------------------
IP Version 4
Header Length 5
Checksum Header checksum
Fragmentation offset 0
More Fragments 0
Total Length 20
IP Protocol 103 (PIM)
On receipt of an (S,G) Null-Register, if the Header Checksum
field is non-zero, the recipient SHOULD check the checksum and
discard Null-Registers that have a bad checksum. The recipient
SHOULD NOT check the value of any individual fields; a correct
IP header checksum is sufficient. If the Header Checksum field
is zero, the recipient MUST NOT check the checksum.
With IPv6, an implementation generates a dummy IP header followed by a dummy PIM header with values according to the following table in addition to the source and group. Other IPv6 header fields may contain any value that is valid for that field.
IPv6では、実装はダミーのIPヘッダーを生成し、その後にソースとグループに加えて、次の表に従って値を持つダミーのPIMヘッダーを生成します。他のIPv6ヘッダーフィールドには、そのフィールドに有効な任意の値が含まれる場合があります。
Header Field Value
--------------------------------------
IP Version 6
Next Header 103 (PIM)
Length 4
PIM Version 0
PIM Type 0
PIM Reserved 0
PIM Checksum PIM checksum, including
IPv6 "pseudo-header";
see Section 4.9
On receipt of an IPv6 (S,G) Null-Register, if the dummy PIM header is present, the recipient SHOULD check the checksum and discard Null-Registers that have a bad checksum.
IPv6（S、G）Null-Registerを受信すると、ダミーのPIMヘッダーが存在する場合、受信者はチェックサムをチェックして、不正なチェックサムを持つNull-Registerを破棄する必要があります（SHOULD）。
A Register-Stop is unicast from the RP to the sender of the Register message. The IP source address is the address to which the register was addressed. The IP destination address is the source address of the register message.
Register-Stopは、RPからRegisterメッセージの送信者へのユニキャストです。 IPソースアドレスは、レジスタがアドレス指定されたアドレスです。 IP宛先アドレスは、登録メッセージの送信元アドレスです。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Type, Reserved, Checksum
Described in Section 4.9.
Group Address The group address from the multicast data packet in the Register. The format for this address is described in Section 4.9.1. Note that for Register-Stops the Mask Len field contains the full address length * 8 (e.g., 32 for IPv4 native encoding), if the message is sent for a single group.
グループアドレスレジスタ内のマルチキャストデータパケットからのグループアドレス。このアドレスの形式については、4.9.1項を参照してください。 Register-Stopsの場合、メッセージが単一のグループに送信される場合、Mask Lenフィールドには完全なアドレス長* 8（たとえば、IPv4ネイティブエンコーディングの場合は32）が含まれます。
Source Address The host address of the source from the multicast data packet in the register. The format for this address is given in the encoded unicast address in Section 4.9.1. A special wildcard value consisting of an address field of all zeros can be used to indicate any source.
送信元アドレスレジスタ内のマルチキャストデータパケットからの送信元のホストアドレス。このアドレスの形式は、セクション4.9.1のエンコードされたユニキャストアドレスに記載されています。すべてゼロのアドレスフィールドで構成される特別なワイルドカード値を使用して、任意のソースを示すことができます。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Upstream Neighbor Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Num groups | Holdtime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address 1 (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Joined Sources | Number of Pruned Sources |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Joined Source Address 1 (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Joined Source Address n (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pruned Source Address 1 (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pruned Source Address n (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address m (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Joined Sources | Number of Pruned Sources |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Joined Source Address 1 (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Joined Source Address n (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pruned Source Address 1 (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pruned Source Address n (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Type, Reserved, Checksum
Described in Section 4.9.
Unicast Upstream Neighbor Address The primary address of the upstream neighbor that is the target of the message. The format for this address is given in the encoded unicast address in Section 4.9.1.
ユニキャストアップストリームネイバーアドレスメッセージのターゲットであるアップストリームネイバーのプライマリアドレス。このアドレスの形式は、セクション4.9.1のエンコードされたユニキャストアドレスに記載されています。
Reserved Transmitted as zero, ignored on receipt.
予約済みゼロとして送信され、受信時に無視されます。
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 SHOULD hold the state until canceled by the appropriate canceling Join/Prune message, or timed out according to local policy. This may be used with dial-on-demand links, to avoid keeping the link up with periodic Join/Prune messages.
HoldtimeレシーバーがJoin / Prune状態を維持する必要がある時間（秒単位）。 Holdtimeが「0xffff」に設定されている場合、このメッセージの受信者は、適切なキャンセルのJoin / Pruneメッセージによってキャンセルされるか、ローカルポリシーに従ってタイムアウトするまで、状態を保持する必要があります（SHOULD）。これは、定期的なJoin / Pruneメッセージでリンクを維持し続けるのを避けるために、ダイヤルオンデマンドリンクで使用できます。
Note that the HoldTime MUST be larger than the J/P_Override_Interval(I).
HoldTimeはJ / P_Override_Interval（I）よりも大きくなければならないことに注意してください。
Number of Groups The number of multicast group sets contained in the message.
グループ数メッセージに含まれるマルチキャストグループセットの数。
Multicast group address For format description, see Section 4.9.1.
マルチキャストグループアドレスフォーマットの説明については、セクション4.9.1を参照してください。
Number of Joined Sources Number of joined source addresses listed for a given group.
結合されたソースの数特定のグループに対してリストされた結合されたソースアドレスの数。
Joined Source Address 1 .. n This list contains the sources for a given group that the sending router will forward multicast datagrams from if received on the interface on which the Join/Prune message is sent.
Joined Source Address 1 .. nこのリストには、Join / Pruneメッセージが送信されるインターフェイスで受信された場合に、送信ルーターがマルチキャストデータグラムを転送する特定のグループのソースが含まれます。
See Section 4.9.1 for the format description for the encoded source address.
エンコードされた送信元アドレスの形式の説明については、セクション4.9.1を参照してください。
Number of Pruned Sources Number of pruned source addresses listed for a group.
プルーニングされたソースの数グループにリストされたプルーニングされたソースアドレスの数。
Pruned Source Address 1 .. n This list contains the sources for a given group that the sending router does not want to forward multicast datagrams from when received on the interface on which the Join/Prune message is sent.
Pruned Source Address 1 .. nこのリストには、Join / Pruneメッセージが送信されるインターフェイスで受信したときに、送信ルーターがマルチキャストデータグラムを転送したくない特定のグループのソースが含まれます。
Within one PIM Join/Prune message, all the Multicast Group addresses, Joined Source addresses, and Pruned Source addresses MUST be of the same address family. It is NOT PERMITTED to mix IPv4 and IPv6 addresses within the same message. In addition, the address family of the fields in the message SHOULD be the same as the IP source and destination addresses of the packet. This permits maximum implementation flexibility for dual-stack IPv4/IPv6 routers. If a router receives a message with mixed family addresses, it SHOULD only process the addresses that are of the same family as the unicast upstream neighbor address.
1つのPIM Join / Pruneメッセージ内では、すべてのマルチキャストグループアドレス、Joined Sourceアドレス、およびPruned Sourceアドレスは、同じアドレスファミリのものでなければなりません。同じメッセージ内でIPv4アドレスとIPv6アドレスを混在させることは許可されていません。さらに、メッセージ内のフィールドのアドレスファミリは、パケットのIP送信元および宛先アドレスと同じである必要があります（SHOULD）。これにより、デュアルスタックIPv4 / IPv6ルーターの実装を最大限に柔軟に行うことができます。ルーターは、ファミリーアドレスが混在するメッセージを受信した場合、ユニキャストアップストリームネイバーアドレスと同じファミリーのアドレスのみを処理する必要があります（SHOULD）。
As described above, Join/Prune messages are composed of one or more group sets. Each set contains two source lists: the Joined Sources and the Pruned Sources. This section describes the different types of group sets and source list entries that can exist in a Join/Prune message.
上記のように、Join / Pruneメッセージは1つ以上のグループセットで構成されます。各セットには、2つのソースリストが含まれます。結合されたソースとプルーニングされたソースです。このセクションでは、Join / Pruneメッセージに存在する可能性のあるさまざまなタイプのグループセットとソースリストエントリについて説明します。
There is one valid group set type:
有効なグループセットタイプが1つあります。
Group-Specific Set A Group-Specific Set is represented by a valid IP multicast address in the group address field and the full length of the IP address in the mask length field of the Multicast Group Address. Each Join/Prune message SHOULD NOT contain more than one group-specific set for the same IP multicast address. Each group-specific set may contain (*,G), (S,G,rpt), and (S,G) source list entries in the Joined or Pruned lists.
グループ固有のセットグループ固有のセットは、グループアドレスフィールドの有効なIPマルチキャストアドレスと、マルチキャストグループアドレスのマスク長フィールドのIPアドレスの全長で表されます。各Join / Pruneメッセージは、同じIPマルチキャストアドレスに対して複数のグループ固有のセットを含むべきではありません（SHOULD NOT）。各グループ固有のセットには、JoinedリストまたはPrunedリストの（*、G）、（S、G、rpt）、および（S、G）ソースリストエントリが含まれる場合があります。
(*,G) The (*,G) source list entry is used in Join/Prune messages sent towards the RP for the specified group. It expresses interest (or lack thereof) in receiving traffic sent to the group through the RP shared tree. There MUST only be one such entry in both the Joined and Pruned lists of a group-specific set.
（*、G）（*、G）ソースリストエントリは、指定されたグループのRPに向けて送信されるJoin / Pruneメッセージで使用されます。 RP共有ツリーを介してグループに送信されたトラフィックを受信することに関心がある（またはない）ことを表します。グループ固有のセットのJoinedリストとPrunedリストの両方に、このようなエントリが1つだけ存在する必要があります。
(*,G) source list entries have the Source-Address set to the address of the RP for group G, the Source-Address Mask-Len set to the full length of the IP address, and both the WC and RPT bits of the encoded-source-address set.
（*、G）ソースリストエントリには、グループGのRPのアドレスに設定されたSource-Address、IPアドレスの全長に設定されたSource-Address Mask-Len、およびのWCビットとRPTビットの両方があります。エンコードされたソースアドレスセット。
(S,G,rpt) The (S,G,rpt) source list entry is used in Join/Prune messages sent towards the RP for the specified group. It expresses interest (or lack thereof) in receiving traffic through the shared tree sent by the specified source to this group. For each source address, the entry MUST exist in only one of the Joined and Pruned source lists of a group-specific set, but not both.
（S、G、rpt）（S、G、rpt）ソースリストエントリは、指定されたグループのRPに送信されるJoin / Pruneメッセージで使用されます。これは、指定されたソースからこのグループに送信された共有ツリーを介してトラフィックを受信することへの関心（またはその欠如）を表します。送信元アドレスごとに、エントリはグループ固有のセットのJoinedおよびPruned送信元リストの1つだけに存在する必要があります。
(S,G,rpt) source list entries have the Source-Address set to the address of the source S, the Source-Address Mask-Len set to the full length of the IP address, and the WC bit cleared and the RPT bit set in the encoded source address.
（S、G、rpt）ソースリストエントリのSource-AddressはソースSのアドレスに設定され、Source-Address Mask-LenはIPアドレスの全長に設定され、WCビットはクリアされ、RPTビットはエンコードされた送信元アドレスに設定されます。
(S,G) The (S,G) source list entry is used in Join/Prune messages sent towards the specified source. It expresses interest (or lack thereof) in receiving traffic through the shortest path tree sent by the source to the specified group. For each source address, the entry MUST exist in only one of the Joined and Pruned source lists of a group-specific set, but not both.
（S、G）（S、G）ソースリストエントリは、指定されたソースに向けて送信されるJoin / Pruneメッセージで使用されます。送信元から指定されたグループに送信された最短パスツリーを介してトラフィックを受信することに関心がある（またはない）ことを示します。送信元アドレスごとに、エントリはグループ固有のセットのJoinedおよびPruned送信元リストの1つだけに存在する必要があります。
(S,G) source list entries have the Source-Address set to the address of the source S, the Source-Address Mask-Len set to the full length of the IP address, and both the WC and RPT bits of the encoded source address cleared.
（S、G）ソースリストエントリには、Source-AddressがソースSのアドレスに設定され、Source-Address Mask-LenがIPアドレスの全長に設定され、エンコードされたソースのWCビットとRPTビットの両方が設定されますアドレスがクリアされました。
The rules described above are sufficient to prevent invalid combinations of source list entries in group-specific sets. There are, however, a number of combinations that have a valid interpretation but that are not generated by the protocol as described in this specification:
上記のルールは、グループ固有のセットのソースリストエントリの無効な組み合わせを防ぐのに十分です。ただし、有効な解釈はあるが、この仕様で説明されているプロトコルによって生成されない組み合わせは多数あります。
o Combining a (*,G) Join and an (S,G,rpt) Join entry in the same message is redundant, as the (*,G) entry covers the information provided by the (S,G,rpt) entry.
o （*、G）エントリは（S、G、rpt）エントリによって提供される情報をカバーするため、同じメッセージ内で（*、G）結合エントリと（S、G、rpt）結合エントリを組み合わせると冗長になります。
o The same applies for a (*,G) Prune and an (S,G,rpt) Prune.
o 同じことが（*、G）プルーンと（S、G、rpt）プルーンにも当てはまります。
o The combination of a (*,G) Prune and an (S,G,rpt) Join is also not generated. (S,G,rpt) Joins are only sent when the router is receiving all traffic for a group on the shared tree and it wishes to indicate a change for the particular source. As a (*,G) prune indicates that the router no longer wishes to receive shared tree traffic, the (S,G,rpt) Join would be meaningless.
o （*、G）プルーンと（S、G、rpt）結合の組み合わせも生成されません。 （S、G、rpt）参加は、ルーターが共有ツリー上のグループのすべてのトラフィックを受信していて、特定のソースの変更を示したい場合にのみ送信されます。 （*、G）プルーンは、ルーターが共有ツリートラフィックを受信したくないことを示しているため、（S、G、rpt）結合は意味がありません。
o As Join/Prune messages are targeted to a single PIM neighbor, including both an (S,G) Join and an (S,G,rpt) Prune in the same message is usually redundant. The (S,G) Join informs the neighbor that the sender wishes to receive the particular source on the shortest path tree. It is therefore unnecessary for the router to say that it no longer wishes to receive it on the shared tree. However, there is a valid interpretation for this combination of entries. A downstream router may have to instruct its upstream only to start forwarding a specific source once it has started receiving the source on the shortest-path tree.
o Join / Pruneメッセージは単一のPIMネイバーをターゲットにしているため、同じメッセージ内の（S、G）Joinと（S、G、rpt）Pruneの両方が含まれることは通常冗長です。 （S、G）Joinは、送信者が最短パスツリーで特定のソースを受信したいことをネイバーに通知します。したがって、ルータが共有ツリーで受信する必要がなくなったとルータが言う必要はありません。ただし、このエントリの組み合わせには有効な解釈があります。ダウンストリームルータは、最短パスツリーでソースの受信を開始すると、特定のソースの転送を開始するようにアップストリームに指示する必要がある場合があります。
o The combination of an (S,G) Prune and an (S,G,rpt) Join could possibly be used by a router to switch from receiving a particular source on the shortest-path tree back to receiving it on the shared tree (provided that the RPF neighbor for the shortest-path and shared trees is common). However, Sparse-Mode PIM does not provide a mechanism for explicitly switching back to the shared tree.
o （S、G）Pruneと（S、G、rpt）Joinの組み合わせをルーターで使用して、最短パスツリーで特定のソースを受信することから、共有ツリー（特定の最短パスと共有ツリーのRPFネイバーは一般的です）。ただし、スパースモードPIMには、共有ツリーに明示的に切り替えるメカニズムはありません。
The rules are summarized in the table below.
ルールは以下の表にまとめられています。
+----------++------+-------+-----------+-----------+-------+-------+
| ||Join | Prune | Join | Prune | Join | Prune |
| ||(*,G) | (*,G) | (S,G,rpt) | (S,G,rpt) | (S,G) | (S,G) |
+----------++------+-------+-----------+-----------+-------+-------+
|Join ||- | no | ? | yes | yes | yes |
|(*,G) || | | | | | |
+----------++------+-------+-----------+-----------+-------+-------+
|Prune ||no | - | ? | ? | yes | yes |
|(*,G) || | | | | | |
+----------++------+-------+-----------+-----------+-------+-------+
|Join ||? | ? | - | no | yes | ? |
|(S,G,rpt) || | | | | | |
+----------++------+-------+-----------+-----------+-------+-------+
|Prune ||yes | ? | no | - | yes | ? |
|(S,G,rpt) || | | | | | |
+----------++------+-------+-----------+-----------+-------+-------+
|Join ||yes | yes | yes | yes | - | no |
|(S,G) || | | | | | |
+----------++------+-------+-----------+-----------+-------+-------+
|Prune ||yes | yes | ? | ? | no | - |
|(S,G) || | | | | | |
+----------++------+-------+-----------+-----------+-------+-------+
yes Allowed and expected.
no Combination is not allowed by the protocol and MUST NOT be generated by a router. A router MAY accept these messages, but the result is undefined. An error message MAY be logged to the administrator in a rate-limited manner.
プロトコルによって組み合わせが許可されておらず、ルーターによって生成されてはなりません。ルーターはこれらのメッセージを受け入れることができますが、結果は未定義です。エラーメッセージがレート制限された方法で管理者に記録される場合があります。
? Combination not expected by the protocol, but well defined. A router MAY accept it but SHOULD NOT generate it.
？プロトコルで予期されていない組み合わせですが、明確に定義されています。ルータはそれを受け入れるかもしれませんが、それを生成するべきではありません。
The order of source list entries in a group set source list is not important, except where limited by the packet format itself.
グループセットソースリスト内のソースリストエントリの順序は、パケットフォーマット自体によって制限されている場合を除いて、重要ではありません。
When building a Join/Prune for a particular neighbor, a router should try to include in the message as much of the information it needs to convey to the neighbor as possible. This implies adding one group set for each multicast group that has information pending transmission and within each set including all relevant source list entries.
特定のネイバーのJoin / Pruneを構築する場合、ルーターは、ネイバーに送信する必要がある情報をできるだけ多くメッセージに含めようとする必要があります。これは、送信保留中の情報があるマルチキャストグループごとに、関連するすべてのソースリストエントリを含む各セット内に1つのグループセットを追加することを意味します。
On a router with a large amount of multicast state, the number of entries that must be included may result in packets that are larger than the maximum IP packet size. In most such cases, the information may be split into multiple messages.
大量のマルチキャストステートを持つルータでは、含める必要があるエントリの数によって、最大IPパケットサイズよりも大きなパケットになる場合があります。ほとんどの場合、情報は複数のメッセージに分割されることがあります。
There is an exception with group sets that contain a (*,G) Joined source list entry. The group set expresses the router's interest in receiving all traffic for the specified group on the shared tree, and it MUST include an (S,G,rpt) Pruned source list entry for every source that the router does not wish to receive. This list of (S,G,rpt) Pruned source list entries MUST NOT be split in multiple messages.
（*、G）結合ソースリストエントリを含むグループセットには例外があります。グループセットは、共有ツリーで指定されたグループのすべてのトラフィックを受信するルーターの関心を表し、ルーターが受信したくないすべてのソースの（S、G、rpt）プルーニングされたソースリストエントリを含める必要があります。 （S、G、rpt）プルーニングされたソースリストエントリのこのリストは、複数のメッセージに分割してはなりません。
If only N (S,G,rpt) Prune entries fit into a maximum-sized Join/Prune message, but the router has more than N (S,G,rpt) Prunes to add, then the router MUST choose to include the first N (numerically smallest in network byte order) IP addresses, and the rest are ignored (not included).
N（S、G、rpt）Pruneエントリのみが最大サイズのJoin / Pruneメッセージに適合するが、ルーターに追加するN（S、G、rpt）Prunesが多い場合、ルーターは最初のPruneを含めることを選択する必要があります。 N（ネットワークバイト順で数値的に最小）IPアドレス、およびその他は無視されます（含まれません）。
The Assert message is used to resolve forwarder conflicts between routers on a link. It is sent when a router receives a multicast data packet on an interface on which the router would normally have forwarded that packet. Assert messages may also be sent in response to an Assert message from another router.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Metric Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Type, Reserved, Checksum Described in Section 4.9.
PIMバージョン、タイプ、予約済み、チェックサムセクション4.9で説明。
Group Address The group address for which the router wishes to resolve the forwarding conflict. This is an encoded group address, as specified in Section 4.9.1.
グループアドレスルーターが転送の競合を解決したいグループアドレス。これは、セクション4.9.1で指定されている、エンコードされたグループアドレスです。
Source Address Source address for which the router wishes to resolve the forwarding conflict. The source address MAY be set to zero for (*,G) asserts (see below). The format for this address is given in the encoded unicast address in Section 4.9.1.
送信元アドレスルーターが転送の競合を解決したい送信元アドレス。 （*、G）アサートのソースアドレスはゼロに設定できます（下記参照）。このアドレスの形式は、セクション4.9.1のエンコードされたユニキャストアドレスに記載されています。
R RPTbit is a 1-bit value. The RPTbit is set to 1 for Assert(*,G) messages and 0 for Assert(S,G) messages.
R RPTbitは1ビット値です。 RPTbitは、Assert（*、G）メッセージの場合は1、Assert（S、G）メッセージの場合は0に設定されます。
Metric Preference Preference value assigned to the unicast routing protocol that provided the route to the multicast source or Rendezvous Point.
メトリックプリファレンスマルチキャストソースまたはランデブーポイントへのルートを提供するユニキャストルーティングプロトコルに割り当てられたプリファレンス値。
Metric The unicast routing table metric associated with the route used to reach the multicast source or Rendezvous Point. The metric is in units applicable to the unicast routing protocol used.
メトリックマルチキャストソースまたはランデブーポイントに到達するために使用されるルートに関連付けられたユニキャストルーティングテーブルメトリック。メトリックは、使用されるユニキャストルーティングプロトコルに適用可能な単位です。
Assert messages can be sent to resolve a forwarding conflict for all traffic to a given group or for a specific source and group.
アサートメッセージを送信して、特定のグループまたは特定の送信元とグループへのすべてのトラフィックの転送競合を解決できます。
Assert(S,G) Source-specific asserts are sent by routers forwarding a specific source on the shortest-path tree (SPTbit is TRUE). (S,G) Asserts have the Group-Address field set to the group G and the Source-Address field set to the source S. The RPTbit is set to 0, the Metric-Preference is set to MRIB.pref(S), and the Metric is set to MRIB.metric(S).
Assert（S、G）ソース固有のアサートは、最短パスツリーで特定のソースを転送するルーターによって送信されます（SPTbitはTRUE）。 （S、G）アサートのGroup-AddressフィールドはグループGに設定され、Source-AddressフィールドはソースSに設定されます。RPTbitは0に設定され、Metric-PreferenceはMRIB.pref（S）に設定されます。メトリックはMRIB.metric（S）に設定されます。
Assert(*,G) Group-specific asserts are sent by routers forwarding data for the group and source(s) under contention on the shared tree. (*,G) asserts have the Group-Address field set to the group G. For data-triggered Asserts, the Source-Address field MAY be set to the IP source address of the data packet that triggered the Assert and is set to zero otherwise. The RPTbit is set to 1, the Metric-Preference is set to MRIB.pref(RP(G)), and the Metric is set to MRIB.metric(RP(G)).
Assert（*、G）グループ固有のアサートは、共有ツリーの競合下にあるグループとソースのデータを転送するルーターによって送信されます。 （*、G）アサートでは、Group-AddressフィールドがグループGに設定されています。データによってトリガーされるアサートの場合、Source-Addressフィールドは、アサートをトリガーしたデータパケットのIPソースアドレスに設定でき、ゼロに設定されます。さもないと。 RPTbitは1に設定され、Metric-PreferenceはMRIB.pref（RP（G））に設定され、MetricはMRIB.metric（RP（G））に設定されます。
PIM-SM maintains the following timers, as discussed in Section 4.11. All timers are countdown timers; they are set to a value and count down to zero, at which point they typically trigger an action. Of course, they can just as easily be implemented as count-up timers, where the absolute expiry time is stored and compared against a real-time clock, but the language in this specification assumes that they count downwards to zero.
セクション4.11で説明したように、PIM-SMは次のタイマーを維持します。すべてのタイマーはカウントダウンタイマーです。これらは値に設定され、ゼロまでカウントダウンします。その時点で、通常アクションをトリガーします。もちろん、それらはカウントアップタイマーと同じくらい簡単に実装できます。この場合、絶対有効期限が保存され、リアルタイムクロックと比較されますが、この仕様の言語では、カウントダウンしてゼロになると想定しています。
Global Timers
グローバルタイマー
Per interface (I):
インターフェースごと（I）：
Hello Timer: HT(I)
ハロータイマー：HT（I）
Per neighbor (N):
ネイバーごと（N）：
Neighbor Liveness Timer: NLT(N,I)
ネイバー活性タイマー：NLT（N、I）
Per Group (G):
グループごと（G）：
(*,G) Join Expiry Timer: ET(*,G,I)
(*,G) Prune-Pending Timer: PPT(*,G,I)
(*,G) Assert Timer: AT(*,G,I)
Per Source (S):
ソースごと（S）：
(S,G) Join Expiry Timer: ET(S,G,I)
（S、G）有効期限タイマーに参加：ET（S、G、I）
(S,G) Prune-Pending Timer: PPT(S,G,I)
（S、G）プルーニング保留タイマー：PPT（S、G、I）
(S,G) Assert Timer: AT(S,G,I)
（S、G）アサートタイマー：AT（S、G、I）
(S,G,rpt) Prune Expiry Timer: ET(S,G,rpt,I)
（S、G、rpt）プルーン有効期限タイマー：ET（S、G、rpt、I）
(S,G,rpt) Prune-Pending Timer: PPT(S,G,rpt,I)
（S、G、rpt）プルーニング保留タイマー：PPT（S、G、rpt、I）
Per Group (G):
グループごと（G）：
(*,G) Upstream Join Timer: JT(*,G)
Per Source (S):
ソースごと（S）：
(S,G) Upstream Join Timer: JT(S,G)
（S、G）アップストリーム参加タイマー：JT（S、G）
(S,G) Keepalive Timer: KAT(S,G)
（S、G）キープアライブタイマー：KAT（S、G）
(S,G,rpt) Upstream Override Timer: OT(S,G,rpt)
（S、G、rpt）アップストリームオーバーライドタイマー：OT（S、G、rpt）
At the DRs or relevant Assert Winners only:
DRまたは関連するAssert Winnersのみ：
Per Source,Group pair (S,G):
ソースごと、グループのペア（S、G）：
Register-Stop Timer: RST(S,G)
レジスターストップタイマー：RST（S、G）
When timers are started or restarted, they are set to default values. This section summarizes those default values.
タイマーが開始または再起動すると、タイマーはデフォルト値に設定されます。このセクションでは、これらのデフォルト値を要約します。
Note that protocol events or configuration may change the default value of a timer on a specific interface. When timers are initialized in this document, the value specific to the interface in context must be used.
プロトコルイベントまたは設定によって、特定のインターフェイスのタイマーのデフォルト値が変更される場合があることに注意してください。このドキュメントでタイマーを初期化するときは、コンテキスト内のインターフェイスに固有の値を使用する必要があります。
Some of the timers listed below (Prune-Pending, Upstream Join, Upstream Override) can be set to values that depend on the settings of the Propagation_Delay and Override_Interval of the corresponding interface. The default values for these are given below.
以下にリストされている一部のタイマー（プルーンペンディング、アップストリームジョイン、アップストリームオーバーライド）は、対応するインターフェイスのPropagation_DelayおよびOverride_Intervalの設定に依存する値に設定できます。これらのデフォルト値を以下に示します。
Variable Name: Propagation_Delay(I)
変数名：Propagation_Delay（I）
+-------------------------------+--------------+----------------------+
| Value Name | Value | Explanation |
+-------------------------------+--------------+----------------------+
| Propagation_delay_default | 0.5 secs | Expected |
| | | propagation delay |
| | | over the local |
| | | link. |
+-------------------------------+--------------+----------------------+
The default value of the Propagation_delay_default is chosen to be relatively large to provide compatibility with older PIM implementations.
Propagation_delay_defaultのデフォルト値は、古いPIM実装との互換性を提供するために、比較的大きくなるように選択されています。
Variable Name: Override_Interval(I)
変数名：Override_Interval（I）
+--------------------------+-----------------+-------------------------+
| Value Name | Value | Explanation |
+--------------------------+-----------------+-------------------------+
| t_override_default | 2.5 secs | Default delay |
| | | interval over |
| | | which to randomize |
| | | when scheduling a |
| | | delayed Join |
| | | message. |
+--------------------------+-----------------+-------------------------+
Timer Name: Hello Timer (HT(I))
タイマー名：Helloタイマー（HT（I））
+---------------------+--------+---------------------------------------+
|Value Name | Value | Explanation |
+---------------------+--------+---------------------------------------+
|Hello_Period | 30 secs| Periodic interval for Hello messages. |
+---------------------+--------+---------------------------------------+
|Triggered_Hello_Delay| 5 secs | Randomized interval for initial Hello |
| | | message on bootup or triggered Hello |
| | | message to a rebooting neighbor. |
+---------------------+--------+---------------------------------------+
At system power-up, the timer is initialized to rand(0, Triggered_Hello_Delay) to prevent synchronization. When a new or rebooting neighbor is detected, a responding Hello is sent within rand(0, Triggered_Hello_Delay).
システムの電源投入時に、タイマーはrand（0、Triggered_Hello_Delay）に初期化され、同期を防ぎます。新しいネイバーまたは再起動中のネイバーが検出されると、応答するHelloがrand（0、Triggered_Hello_Delay）内で送信されます。
Timer Name: Neighbor Liveness Timer (NLT(N,I))
タイマー名：Neighbor Liveness Timer（NLT（N、I））
+--------------------------+----------------------+--------------------+
| Value Name | Value | Explanation |
+--------------------------+----------------------+--------------------+
| Default_Hello_Holdtime | 3.5 * Hello_Period | Default holdtime |
| | | to keep neighbor |
| | | state alive |
+--------------------------+----------------------+--------------------+
| Hello_Holdtime | from message | Holdtime from |
| | | Hello message |
| | | Holdtime option. |
+--------------------------+----------------------+--------------------+
The Holdtime in a Hello message should be set to (3.5 * Hello_Period), giving a default value of 105 seconds.
HelloメッセージのHoldtimeは（3.5 * Hello_Period）に設定する必要があり、デフォルト値は105秒です。
Timer Names: Expiry Timer (ET(*,G,I), ET(S,G,I), ET(S,G,rpt,I))
+----------------+----------------+------------------------------------+
| Value Name | Value | Explanation |
+----------------+----------------+------------------------------------+
| J/P_HoldTime | from message | Holdtime from Join/Prune message |
+----------------+----------------+------------------------------------+
The value of J/P Holdtime that is included in Join/Prune messages is specified below, in the description of "Upstream Join Timer (JT(*,G), JT(S,G))".
Join / Pruneメッセージに含まれるJ / P Holdtimeの値は、「アップストリームJoinタイマー（JT（*、G）、JT（S、G））」の説明で以下に指定されています。
Timer Names: Prune-Pending Timer (PPT(*,G,I), PPT(S,G,I),
PPT(S,G,rpt,I))
+--------------------------+---------------------+---------------------+
|Value Name | Value | Explanation |
+--------------------------+---------------------+---------------------+
|J/P_Override_Interval(I) | Default: | Short period after |
| | Effective_ | a join or prune to |
| | Propagation_ | allow other |
| | Delay(I) + | routers on the LAN |
| | Effective_Override_ | to override the |
| | Interval(I) | join or prune |
+--------------------------+---------------------+---------------------+
Note that both Effective_Propagation_Delay(I) and Effective_Override_Interval(I) are interface-specific values that may change when Hello messages are received (see Section 4.3.3).
Effective_Propagation_Delay（I）とEffective_Override_Interval（I）はどちらもインターフェイス固有の値であり、Helloメッセージを受信すると変更される場合があることに注意してください（セクション4.3.3を参照）。
Timer Names: Assert Timer (AT(*,G,I), AT(S,G,I))
+---------------------------+---------------------+--------------------+
| Value Name | Value | Explanation |
+---------------------------+---------------------+--------------------+
| Assert_Override_Interval | Default: 3 secs | Short interval |
| | | before an assert |
| | | times out where |
| | | the assert winner |
| | | resends an Assert |
| | | message |
+---------------------------+---------------------+--------------------+
| Assert_Time | Default: 180 secs | Period after last |
| | | assert before |
| | | assert state is |
| | | timed out |
+---------------------------+---------------------+--------------------+
Note that for historical reasons, the Assert message lacks a Holdtime field. Thus, changing the Assert Time from the default value is not recommended.
歴史的な理由により、AssertメッセージにはHoldtimeフィールドがないことに注意してください。したがって、アサート時間をデフォルト値から変更することはお勧めしません。
Timer Names: Upstream Join Timer (JT(*,G), JT(S,G))
+-------------+--------------------+-----------------------------------+
|Value Name | Value | Explanation |
+-------------+--------------------+-----------------------------------+
|t_periodic | Default: 60 secs | Period between Join/Prune messages|
+-------------+--------------------+-----------------------------------+
|t_suppressed | rand(1.1 * | Suppression period when someone |
| | t_periodic, 1.4 * | else sends a J/P message so we |
| | t_periodic) when | don't need to do so. |
| | Suppression_ | |
| | Enabled(I) is | |
| | true, 0 otherwise | |
+-------------+--------------------+-----------------------------------+
|t_override | rand(0, Effective_ | Randomized delay to prevent |
| | Override_ | response implosion when sending a |
| | Interval(I)) | Join message to override someone |
| | | else's Prune message. |
+-------------+--------------------+-----------------------------------+
t_periodic 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). If the Join/Prune-Period is modified during operation, 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.
t_periodicは、接続されたネットワークまたはリンクの構成された帯域幅や予想されるマルチキャストルートエントリの平均数などを考慮するように設定できます（たとえば、低速リンクの場合、または中央のルーターの場合、期間が長くなります）より多くのエントリがあると予想されるネットワーク）。動作中にJoin / Prune-Periodが変更された場合、これらの変更は比較的頻繁に行われるべきではなく、アップストリームを許可するために、ルータは以前のJoin / Prune-Periodで少なくともJoin / Prune-Holdtimeの間リフレッシュし続ける必要があります。適応するルータ。
The Holdtime specified in a Join/Prune message should be set to (3.5 * t_periodic).
Join / Pruneメッセージで指定されたHoldtimeは（3.5 * t_periodic）に設定する必要があります。
t_override depends on the Effective Override Interval of the upstream interface, which may change when Hello messages are received.
t_overrideは、上流インターフェースの有効オーバーライド間隔に依存します。これは、Helloメッセージを受信したときに変更される可能性があります。
t_suppressed depends on the Suppression State of the upstream interface (Section 4.3.3) and becomes zero when suppression is disabled.
t_suppressedは、上流インターフェースの抑制状態（セクション4.3.3）に依存し、抑制が無効にされるとゼロになります。
Timer Name: Upstream Override Timer (OT(S,G,rpt))
タイマー名：アップストリームオーバーライドタイマー（OT（S、G、rpt））
+---------------+--------------------------+---------------------------+
| Value Name | Value | Explanation |
+---------------+--------------------------+---------------------------+
| t_override | see Upstream Join Timer | see Upstream Join Timer |
+---------------+--------------------------+---------------------------+
The Upstream Override Timer is only ever set to the t_override value; this value is defined earlier in this section, under "Timer Names: Upstream Join Timer (JT(*,G), JT(S,G))".
アップストリームオーバーライドタイマーは、常にt_override値にのみ設定されます。この値は、このセクションの前半の「タイマー名：アップストリーム結合タイマー（JT（*、G）、JT（S、G））」で定義されています。
Timer Name: Keepalive Timer (KAT(S,G))
タイマー名：キープアライブタイマー（KAT（S、G））
+-----------------------+-----------------------+----------------------+
| Value Name | Value | Explanation |
+-----------------------+-----------------------+----------------------+
| Keepalive_Period | Default: 210 secs | Period after last |
| | | (S,G) data packet |
| | | during which (S,G) |
| | | Join state will be |
| | | maintained even in |
| | | the absence of |
| | | (S,G) Join |
| | | messages. |
+-----------------------+-----------------------+----------------------+
| RP_Keepalive_Period | ( 3 * Register_ | As |
| | Suppression_Time ) | Keepalive_Period, |
| | + Register_ | but at the RP when |
| | Probe_Time | a Register-Stop is |
| | | sent. |
+-----------------------+-----------------------+----------------------+
The normal keepalive period for the KAT(S,G) defaults to 210 seconds. However, at the RP, the keepalive period must be at least the Register_Suppression_Time, or the RP may time out the (S,G) state before the next Null-Register arrives. Thus, the KAT(S,G) is set to max(Keepalive_Period, RP_Keepalive_Period) when a Register-Stop is sent.
KAT（S、G）の通常のキープアライブ期間は、デフォルトで210秒です。ただし、RPでは、キープアライブ期間は少なくともRegister_Suppression_Timeである必要があります。そうでない場合、RPは次のヌルレジスタが到着する前に（S、G）状態をタイムアウトすることがあります。したがって、Register-Stopが送信されると、KAT（S、G）はmax（Keepalive_Period、RP_Keepalive_Period）に設定されます。
Timer Name: Register-Stop Timer (RST(S,G))
タイマー名：レジスター停止タイマー（RST（S、G））
+---------------------------+--------------------+---------------------+
|Value Name | Value | Explanation |
+---------------------------+--------------------+---------------------+
|Register_Suppression_Time | Default: 60 secs | Period during |
| | | which a DR stops |
| | | sending Register- |
| | | encapsulated data |
| | | to the RP after |
| | | receiving a |
| | | Register-Stop |
| | | message. |
+---------------------------+--------------------+---------------------+
|Register_Probe_Time | Default: 5 secs | Time before RST |
| | | expires when a DR |
| | | may send a Null- |
| | | Register to the RP |
| | | to cause it to |
| | | resend a Register- |
| | | Stop message. |
+---------------------------+--------------------+---------------------+
If the Register_Suppression_Time or the Register_Probe_Time is configured to values other than the defaults, it MUST be ensured that the value of the Register_Probe_Time is less than half the value of the Register_Suppression_Time to prevent a possible negative value in the setting of the Register-Stop Timer.
Register_Suppression_TimeまたはRegister_Probe_Timeがデフォルト以外の値に設定されている場合、Register_Probe_Timeの値がRegister_Suppression_Timeの値の半分未満であることを確認して、Register-Stop Timerの設定で負の値が発生するのを防ぐ必要があります。
The PIM Address Family field was chosen to be 8 bits as a tradeoff between packet format and use of the IANA-assigned numbers. Because when the PIM packet format was designed only 15 values were assigned for Address Families, and large numbers of new Address Family values were not envisioned, 8 bits seemed large enough. However, the IANA assigns Address Families in a 16-bit field. Therefore, the PIM Address Family is allocated as follows:
PIMアドレスファミリフィールドは、パケットフォーマットとIANA割り当て番号の使用との間のトレードオフとして8ビットになるように選択されました。 PIMパケット形式が設計されたとき、アドレスファミリに割り当てられた値は15のみであり、多数の新しいアドレスファミリ値が想定されていなかったため、8ビットは十分に大きいように見えました。ただし、IANAはアドレスファミリを16ビットフィールドに割り当てます。したがって、PIMアドレスファミリは次のように割り当てられます。
Values 0 through 127 are designated to have the same meaning as IANA-assigned Address Family Numbers [7].
0〜127の値は、IANAによって割り当てられたアドレスファミリ番号と同じ意味を持つように指定されています[7]。
Values 128 through 250 are designated to be assigned for PIM by the IANA based upon IESG Approval, as defined in [9].
[9]で定義されているように、128〜250の値は、IESG承認に基づいてIANAによってPIMに割り当てられるように指定されています。
Values 251 through 255 are designated for Private Use, as defined in [9].
[9]で定義されているように、251〜255の値は私用に指定されています。
Values 17 through 65000 are to be assigned by the IANA. Since the space is large, they may be assigned as First Come First Served, as defined in [9]. Such assignments are valid for one year and may be renewed. Permanent assignments require a specification (see "Specification Required" in [9]).
17から65000までの値は、IANAによって割り当てられます。スペースが大きいため、[9]で定義されているように、先着順として割り当てることができます。このような割り当ては1年間有効で、更新される場合があります。恒久的な割り当てには仕様が必要です（[9]の「必要な仕様」を参照）。
This section describes various possible security concerns related to the PIM-SM protocol. The reader is referred to [8], [14], and [15] for further discussion of PIM-SM and multicast security.
このセクションでは、PIM-SMプロトコルに関連して考えられるさまざまなセキュリティの問題について説明します。 PIM-SMとマルチキャストセキュリティの詳細については、[8]、[14]、および[15]を参照してください。
Note that PIM relies upon an MRIB populated outside of PIM; therefore, securing the sources of change to the MRIB is RECOMMENDED.
PIMはPIMの外部に実装されたMRIBに依存していることに注意してください。したがって、MRIBへの変更のソースを保護することをお勧めします。
The extent of possible damage depends on the type of counterfeit messages accepted. We next consider the impact of possible forgeries, including forged link-local (Join/Prune, Hello, and Assert) and forged unicast (Register and Register-Stop) messages.
起こり得る被害の程度は、受け入れられる偽造メッセージの種類によって異なります。次に、偽造されたリンクローカル（Join / Prune、Hello、およびAssert）および偽造されたユニキャスト（RegisterおよびRegister-Stop）メッセージを含む、可能な偽造の影響について検討します。
Join/Prune, Hello, and Assert messages are all sent to the link-local ALL-PIM-ROUTERS multicast address and thus are not forwarded by a compliant router. A forged message of this type can only reach a LAN if it was sent by a local host or if it was allowed onto the LAN by a compromised or non-compliant router.
Join / Prune、Hello、およびAssertメッセージはすべてリンクローカルのALL-PIM-ROUTERSマルチキャストアドレスに送信されるため、準拠するルーターによって転送されません。このタイプの偽造メッセージは、ローカルホストから送信された場合、またはセキュリティが侵害されたルーターまたは非準拠のルーターによってLANに許可された場合にのみ、LANに到達できます。
1. A forged Join/Prune message can cause multicast traffic to be delivered to links where there are no legitimate requesters, potentially wasting bandwidth on that link. A forged leave message on a multi-access LAN is generally not a significant attack in PIM, because any legitimately joined router on the LAN would override the leave with a join before the upstream router stops forwarding data to the LAN.
1. 偽造されたJoin / Pruneメッセージにより、正当なリクエスタが存在しないリンクにマルチキャストトラフィックが配信され、そのリンクの帯域幅を浪費する可能性があります。マルチアクセスLANでの偽造されたLeaveメッセージは、PIMでは通常、重大な攻撃ではありません。これは、上流のルーターがLANへのデータ転送を停止する前に、LANに合法的に参加したルーターが参加で脱退をオーバーライドするためです。
2. By forging a Hello message, an unauthorized router can cause itself to be elected as the Designated Router on a LAN. The Designated Router on a LAN is (in the absence of asserts) responsible for forwarding traffic to that LAN on behalf of any local members. The Designated Router is also responsible for register-encapsulating to the RP any packets that are originated by hosts on the LAN. Thus, the ability of local hosts to send and receive multicast traffic may be compromised by a forged Hello message.
2. Helloメッセージを偽造することにより、無許可のルーターがLAN上の指定ルーターとして選出される可能性があります。 LAN上の指定ルーターは（アサートがない場合）、ローカルメンバーに代わってそのLANにトラフィックを転送する責任があります。指定ルーターは、LAN上のホストから発信されたパケットをRPに登録カプセル化する役割も果たします。したがって、ローカルホストがマルチキャストトラフィックを送受信する機能は、偽造されたHelloメッセージによって危険にさらされる可能性があります。
3. By forging an Assert message on a multi-access LAN, an attacker could cause the legitimate designated forwarder to stop forwarding traffic to the LAN. Such a forgery would prevent any hosts downstream of that LAN from receiving traffic.
3. 攻撃者は、マルチアクセスLANでAssertメッセージを偽造することにより、正当な指定フォワーダーにLANへのトラフィックの転送を停止させる可能性があります。このような偽造は、そのLANの下流にあるホストがトラフィックを受信することを妨げます。
Register messages and Register-Stop messages are forwarded by intermediate routers to their destination using normal IP forwarding. Without data origin authentication, an attacker who is located anywhere in the network may be able to forge a Register or Register-Stop message. We next consider the effect of a forgery of each of these messages.
RegisterメッセージとRegister-Stopメッセージは、通常のIP転送を使用して、中間ルーターによって宛先に転送されます。データ発信元認証がないと、ネットワーク内のどこかにいる攻撃者が登録または登録停止メッセージを偽造できる可能性があります。次に、これらの各メッセージの偽造の影響について検討します。
1. By forging a Register message, an attacker can cause the RP to inject forged traffic onto the shared multicast tree.
1. 攻撃者は、登録メッセージを偽造することで、RPに偽造トラフィックを共有マルチキャストツリーに注入させることができます。
2. By forging a Register-Stop message, an attacker can prevent a legitimate DR from registering packets to the RP. This can prevent local hosts on that LAN from sending multicast packets.
2. 攻撃者は、Register-Stopメッセージを偽造することにより、正当なDRがパケットをRPに登録するのを防ぐことができます。これにより、そのLAN上のローカルホストがマルチキャストパケットを送信できなくなります。
The above two PIM messages are not changed by intermediate routers and need only be examined by the intended receiver. Thus, these messages can be authenticated end-to-end. Attacks on Register and Register-Stop messages do not apply to a PIM-SSM-only implementation, as these messages are not required for PIM-SSM.
上記の2つのPIMメッセージは中間ルーターによって変更されず、意図された受信者によってのみ検査される必要があります。したがって、これらのメッセージはエンドツーエンドで認証できます。 RegisterおよびRegister-Stopメッセージに対する攻撃は、PIM-SSMのみの実装には適用されません。これらのメッセージはPIM-SSMには必要ないためです。
A PIM router SHOULD provide an option to limit the set of neighbors from which it will accept Join/Prune, Assert, and Hello messages. Either static configuration of IP addresses or an IPsec security association MAY be used. Furthermore, a PIM router SHOULD NOT accept protocol messages from a router from which it has not yet received a valid Hello message.
PIMルーターは、Join / Prune、Assert、Helloメッセージを受け入れる一連のネイバーを制限するオプションを提供する必要があります（SHOULD）。 IPアドレスの静的構成またはIPsecセキュリティアソシエーションのいずれかを使用できます。さらに、PIMルーターは、有効なHelloメッセージをまだ受信していないルーターからのプロトコルメッセージを受け入れるべきではありません（SHOULD NOT）。
A Designated Router MUST NOT register-encapsulate a packet and send it to the RP unless the source address of the packet is a legal address for the subnet on which the packet was received. Similarly, a Designated Router SHOULD NOT accept a Register-Stop packet whose IP source address is not a valid RP address for the local domain.
指定ルーターは、パケットの送信元アドレスが、パケットが受信されたサブネットの正当なアドレスでない限り、パケットを登録カプセル化してRPに送信してはなりません（MUST NOT）。同様に、指定ルータは、IP送信元アドレスがローカルドメインの有効なRPアドレスではないRegister-Stopパケットを受け入れてはなりません（SHOULD NOT）。
An implementation SHOULD provide a mechanism to allow an RP to restrict the range of source addresses from which it accepts Register-encapsulated packets.
実装は、RPがRegisterカプセル化パケットを受け入れる送信元アドレスの範囲を制限できるようにするメカニズムを提供する必要があります（SHOULD）。
All options that restrict the range of addresses from which packets are accepted MUST default to allowing all packets.
パケットが受け入れられるアドレスの範囲を制限するすべてのオプションは、デフォルトですべてのパケットを許可する必要があります。
This document refers to RFC 5796 [8], which specifies mechanisms to authenticate PIM-SM link-local messages using the IPsec Encapsulating Security Payload (ESP) or (optionally) the Authentication Header (AH). It also points out that non-link-local PIM-SM messages (i.e., Register and Register-Stop messages) can be secured by a normal unicast IPsec Security Association (SA) between two communicants.
このドキュメントはRFC 5796 [8]を参照しており、IPsecカプセル化セキュリティペイロード（ESP）または（オプションで）認証ヘッダー（AH）を使用してPIM-SMリンクローカルメッセージを認証するメカニズムを指定しています。また、非リンクローカルPIM-SMメッセージ（つまり、登録メッセージと登録停止メッセージ）は、2つのコミュニカント間の通常のユニキャストIPsecセキュリティアソシエーション（SA）によって保護できることも指摘しています。
There are a number of possible denial-of-service attacks against PIM that can be caused by generating false PIM protocol messages or even by generating false traffic. Authenticating PIM protocol traffic prevents some, but not all, of these attacks. Two of the possible attacks include the following:
PIMに対するサービス拒否攻撃には、偽のPIMプロトコルメッセージを生成したり、偽のトラフィックを生成したりすることで発生する可能性のあるものがいくつかあります。 PIMプロトコルトラフィックを認証することで、これらの攻撃のすべてではなく一部を防ぎます。次の2つの攻撃が考えられます。
o Sending packets to many different group addresses quickly can be a denial-of-service attack in and of itself. This will cause many register-encapsulated packets, loading the DR, the RP, and the routers between the DR and the RP.
o さまざまなグループアドレスにすばやくパケットを送信すると、それ自体がサービス拒否攻撃になる可能性があります。これにより、多くのレジスタカプセル化パケットが発生し、DR、RP、およびDRとRPの間のルーターにロードされます。
o Forging Join messages can cause a multicast tree to get set up. A large number of forged joins can consume router resources and result in denial of service.
o Joinメッセージを偽造すると、マルチキャストツリーがセットアップされる可能性があります。多数の偽造された結合がルーターのリソースを消費し、サービス拒否を引き起こす可能性があります。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, <http://www.rfc-editor.org/info/rfc3376>.
[2] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、B。、およびA. Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC 3376、DOI 10.17487 / RFC3376、2002年10月、<http：/ /www.rfc-editor.org/info/rfc3376>。
[3] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, DOI 10.17487/RFC1112, August 1989, <http://www.rfc-editor.org/info/rfc1112>.
[3] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、DOI 10.17487 / RFC1112、1989年8月、<http://www.rfc-editor.org/info/rfc1112>。
[4] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, DOI 10.17487/RFC2710, October 1999, <http://www.rfc-editor.org/info/rfc2710>.
[4] Deering、S.、Fenner、W.、and B. Haberman、 "Multicast Listener Discovery（MLD）for IPv6"、RFC 2710、DOI 10.17487 / RFC2710、October 1999、<http://www.rfc-editor.org/ info / rfc2710>。
[5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[5] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、DOI 10.17487 / RFC2460、1998年12月、<http://www.rfc-editor.org/info/rfc2460>。
[6] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, <http://www.rfc-editor.org/info/rfc4607>.
[6] Holbrook、H。およびB. Cain、「IPのソース固有のマルチキャスト」、RFC 4607、DOI 10.17487 / RFC4607、2006年8月、<http://www.rfc-editor.org/info/rfc4607>。
[7] IANA, "Address Family Numbers", <http://www.iana.org/assignments/address-family-numbers>.
[7] IANA、「Address Family Numbers」、<http://www.iana.org/assignments/address-family-numbers>。
[8] Atwood, W., Islam, S., and M. Siami, "Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages", RFC 5796, DOI 10.17487/RFC5796, March 2010, <http://www.rfc-editor.org/info/rfc5796>.
[8] Atwood、W.、Islam、S.、and M. Siami、 "Authentication and Confidentiality in Protocol Independent Multicast Multicast Sparse Mode（PIM-SM）Link-Local Messages"、RFC 5796、DOI 10.17487 / RFC5796、March 2010、<http： //www.rfc-editor.org/info/rfc5796>。
[9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[9] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http://www.rfc-editor.org/info/ rfc5226>。
[10] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, <http://www.rfc-editor.org/info/rfc4760>.
[10] Bates、T.、Chandra、R.、Katz、D。、およびY. Rekhter、「BGP-4のマルチプロトコル拡張機能」、RFC 4760、DOI 10.17487 / RFC4760、2007年1月、<http：//www.rfc-editor .org / info / rfc4760>。
[11] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)", RFC 5059, DOI 10.17487/RFC5059, January 2008, <http://www.rfc-editor.org/info/rfc5059>.
[11] Bhaskar、N.、Gall、A.、Lingard、J。、およびS. Venaas、「プロトコル独立型マルチキャスト（PIM）のブートストラップルーター（BSR）メカニズム」、RFC 5059、DOI 10.17487 / RFC5059、2008年1月、<http： //www.rfc-editor.org/info/rfc5059>。
[12] Black, D., "Differentiated Services and Tunnels", RFC 2983, DOI 10.17487/RFC2983, October 2000, <http://www.rfc-editor.org/info/rfc2983>.
[12] ブラックD。、「Differentiated Services and Tunnels」、RFC 2983、DOI 10.17487 / RFC2983、2000年10月、<http://www.rfc-editor.org/info/rfc2983>。
[13] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, <http://www.rfc-editor.org/info/rfc5015>.
[13] Handley、M.、Kouvelas、I.、Speakman、T。、およびL. Vicisano、「Bidirectional Protocol Independent Multicast（BIDIR-PIM）」、RFC 5015、DOI 10.17487 / RFC5015、2007年10月、<http：// www。 rfc-editor.org/info/rfc5015>。
[14] Savola, P., Lehtonen, R., and D. Meyer, "Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements", RFC 4609, DOI 10.17487/RFC4609, October 2006, <http://www.rfc-editor.org/info/rfc4609>.
[14] Savola、P.、Lehtonen、R。、およびD. Meyer、「Protocol Independent Multicast-Sparse Mode（PIM-SM）Multicast Routing Security Issues and Enhancements」、RFC 4609、DOI 10.17487 / RFC4609、2006年10月、<http：/ /www.rfc-editor.org/info/rfc4609>。
[15] Savola, P. and J. Lingard, "Host Threats to Protocol Independent Multicast (PIM)", RFC 5294, DOI 10.17487/RFC5294, August 2008, <http://www.rfc-editor.org/info/rfc5294>.
[15] Savola、P。およびJ. Lingard、「Host Threats to Protocol Independent Multicast（PIM）」、RFC 5294、DOI 10.17487 / RFC5294、2008年8月、<http://www.rfc-editor.org/info/rfc5294>。
[16] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, DOI 10.17487/RFC3956, November 2004, <http://www.rfc-editor.org/info/rfc3956>.
[16] Savola、P。およびB. Haberman、「IPv6マルチキャストアドレスへのランデブーポイント（RP）アドレスの埋め込み」、RFC 3956、DOI 10.17487 / RFC3956、2004年11月、<http://www.rfc-editor.org/info / rfc3956>。
[17] Zheng, L., Zhang, J., and R. Parekh, "Survey Report on Protocol Independent Multicast - Sparse Mode (PIM-SM) Implementations and Deployments", RFC 7063, DOI 10.17487/RFC7063, December 2013, <http://www.rfc-editor.org/info/rfc7063>.
[17] Zheng、L.、Zhang、J。、およびR. Parekh、「プロトコルに依存しないマルチキャストに関する調査レポート-スパースモード（PIM-SM）の実装と展開」、RFC 7063、DOI 10.17487 / RFC7063、2013年12月、<http：/ /www.rfc-editor.org/info/rfc7063>。
Based on a survey of PIM implementations and deployments [17] conducted by the IETF PIM working group, the following functionality of RFC 4601 has been removed due to lack of sufficient implementation and deployment experience:
IETF PIMワーキンググループが実施したPIMの実装と展開[17]の調査に基づいて、十分な実装と展開の経験がないため、RFC 4601の次の機能が削除されました。
o (*,*,RP) State
o （*、*、RP）状態
o PIM Multicast Border Router (PMBR)
o PIMマルチキャストボーダールーター（PMBR）
o Authentication using IPsec
o IPsecを使用した認証
Acknowledgements
謝辞
PIM-SM was designed over many years by a large group of people, including ideas, comments, and corrections from Deborah Estrin, Dino Farinacci, Ahmed Helmy, David Thaler, Steve Deering, Van Jacobson, C. Liu, Puneet Sharma, Liming Wei, Tom Pusateri, Tony Ballardie, Scott Brim, Jon Crowcroft, Paul Francis, Joel Halpern, Horst Hodel, Polly Huang, Stephen Ostrowski, Lixia Zhang, Girish Chandranmenon, Brian Haberman, Hal Sandick, Mike Mroz, Garry Kump, Pavlin Radoslavov, Mike Davison, James Huang, Christopher Thomas Brown, and James Lingard.
PIM-SMは、Deborah Estrin、Dino Farinacci、Ahmed Helmy、David Thaler、Steve Deering、Van Jacobson、C。Liu、Puneet Sharma、Liming Weiからのアイデア、コメント、修正を含め、長年にわたって大勢の人々によって設計されました、トム・プサテリ、トニー・バラディ、スコット・ブリム、ジョン・クロウクロフト、ポール・フランシス、ジョエル・ハルパーン、ホルスト・ホデル、ポリー・ファン、スティーブン・オストロフスキー、リクシア・チャン、ギリッシュ・チャンドランメノン、ブライアン・ハーバーマン、ハル・サンディック、マイク・モロズ、ギャリー・カンプ、パヴリン・ラドスラヴォフ、マイクDavison、James Huang、Christopher Thomas Brown、James Lingard。
Thanks are due to the American Licorice Company, for its obscure but possibly essential role in the creation of this document.
American Licorice Companyには、このドキュメントの作成においてあいまいでありながら重要な役割を果たす可能性があることに感謝します。
Authors' Addresses
著者のアドレス
Bill Fenner Arista Networks
ビルフェナーアリスタネットワークス
Email: fenner@arista.com
Mark Handley Department of Computer Science University College London Gower Street London WC1E 6BT United Kingdom
マークハンドラリーコンピューターサイエンス大学カレッジロンドンガワーストリートロンドンWC1E 6BTイギリス
Email: M.Handley@cs.ucl.ac.uk Hugh Holbrook Arista Networks 5453 Great America Parkway Santa Clara, CA 95054
メール：M.Handley@cs.ucl.ac.uk Hugh Holbrook Arista Networks 5453 Great America Parkway Santa Clara、CA 95054
Email: holbrook@arista.com
Isidor Kouvelas Arista Networks 5453 Great America Parkway Santa Clara, CA 95054
Isidore Kouvelasエクセレントニューヨーク5453グレートアメリカパークウェイサンタクララ、950 95054
Email: kouvelas@arista.com
Rishabh Parekh Cisco Systems, Inc. 170 W. Tasman Drive San Jose, CA 95134
Rishabh Parekh Cisco Systems、Inc. 170 W. Tasman Drive San Jose、CA 95134
Email: riparekh@cisco.com
Zhaohui Zhang Juniper Networks 10 Technology Park Drive Westford, MA 01886
Zhaohui Zhang Juniper Networks 10 Technology Park Drive Westford、MA 01886
Email: zzhang@juniper.net
Lianshu Zheng Huawei Technologies Co., Ltd Huawei Campus, 156 Beiqing Road, Hai-dian District Beijing 100089 China
l Ian番号Zは非常にGH UAはテクノロジー株式会社hu Aはキャンパス、156はiqing道路、hラブポイント地区北京100089中国
Email: vero.zheng@huawei.com