[要約] RFC 4601は、PIM-SMプロトコルの仕様を定義しており、マルチキャスト通信の効率的な配信を目指しています。このRFCの目的は、スパースモードでのプロトコル独立のマルチキャスト通信を実現するためのガイドラインを提供することです。
Network Working Group B. Fenner
Request for Comments: 4601 AT&T Labs - Research
Obsoletes: 2362 M. Handley
Category: Standards Track UCL
H. Holbrook
Arastra
I. Kouvelas
Cisco
August 2006
Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)
プロトコル独立したマルチキャスト - スパースモード（PIM -SM）：プロトコル仕様（改訂）
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
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 optionally creates shortest-path trees per source.
このドキュメントは、Protocol Independent Multicast -Sparse Mode（PIM -SM）を指定しています。PIM-SMは、基礎となるユニキャストルーティング情報ベースまたは別のマルチキャスト対応ルーティング情報ベースを使用できるマルチキャストルーティングプロトコルです。グループごとにランデブーポイント（RP）に根付いた単方向の共有ツリーを構築し、オプションでソースごとに最短パスツリーを作成します。
This document obsoletes RFC 2362, an Experimental version of PIM-SM.
このドキュメントは、PIM-SMの実験バージョンであるRFC 2362を廃止します。
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 ...................................8
3.3. Phase Three: Shortest-Path Tree ............................9
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. (*,*,RP) State .....................................15
4.1.3. (*,G) State ........................................16
4.1.4. (S,G) State ........................................17
4.1.5. (S,G,rpt) State ....................................20
4.1.6. State Summarization Macros .........................21
4.2. Data Packet Forwarding Rules ..............................26
4.2.1. Last-Hop Switchover to the SPT .....................28
4.2.2. Setting and Clearing the (S,G) SPTbit ..............29
4.3. Designated Routers (DR) and Hello Messages ................30
4.3.1. Sending Hello Messages .............................30
4.3.2. DR Election ........................................32
4.3.3. Reducing Prune Propagation Delay on LANs ...........34
4.3.4. Maintaining Secondary Address Lists ................37
4.4. PIM Register Messages .....................................38
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 ...................................45
4.5.1. Receiving (*,*,RP) Join/Prune Messages .............45
4.5.2. Receiving (*,G) Join/Prune Messages ................49
4.5.3. Receiving (S,G) Join/Prune Messages ................53
4.5.4. Receiving (S,G,rpt) Join/Prune Messages ............56
4.5.5. Sending (*,*,RP) Join/Prune Messages ...............62
4.5.6. Sending (*,G) Join/Prune Messages ..................66
4.5.7. Sending (S,G) Join/Prune Messages ..................71
4.5.8. (S,G,rpt) Periodic Messages ........................76
4.5.9. State Machine for (S,G,rpt) Triggered Messages .....77
4.5.10. Background: (*,*,RP) and (S,G,rpt) Interaction ....82
4.6. PIM Assert Messages .......................................83
4.6.1. (S,G) Assert Message State Machine .................83
4.6.2. (*,G) Assert Message State Machine .................91
4.6.3. Assert Metrics .....................................98
4.6.4. AssertCancel Messages ..............................99
4.6.5. Assert State Macros ...............................100
4.7. PIM Bootstrap and RP Discovery ...........................103
4.7.1. Group-to-RP Mapping ...............................104
4.7.2. Hash Function .....................................105
4.8. Source-Specific Multicast ................................106
4.8.1. Protocol Modifications for SSM Destination
Addresses .........................................106
4.8.2. PIM-SSM-Only Routers ..............................107
4.9. PIM Packet Formats .......................................108
4.9.1. Encoded Source and Group Address Formats ..........110
4.9.2. Hello Message Format ..............................113
4.9.3. Register Message Format ...........................116
4.9.4. Register-Stop Message Format ......................119
4.9.5. Join/Prune Message Format .........................119
4.9.5.1. Group Set Source List Rules ..............122
4.9.5.2. Group Set Fragmentation ..................126
4.9.6. Assert Message Format .............................126
4.10. PIM Timers ..............................................128
4.11. Timer Values ............................................129
5. IANA Considerations ...........................................135
5.1. PIM Address Family .......................................135
5.2. PIM Hello Options ........................................136
6. Security Considerations .......................................136
6.1. Attacks Based on Forged Messages .........................136
6.1.1. Forged Link-Local Messages ........................136
6.1.2. Forged Unicast Messages ...........................137
6.2. Non-Cryptographic Authentication Mechanisms ..............137
6.3. Authentication Using IPsec ...............................138
6.3.1. Protecting Link-Local Multicast Messages ..........138
6.3.2. Protecting Unicast Messages .......................139
6.3.2.1. Register Messages ........................139
6.3.2.2. Register-Stop Messages ...................139
6.4. Denial-of-Service Attacks ................................140
7. Acknowledgements ..............................................140
8. Normative References ..........................................141
9. Informative References ........................................141
Appendix A. PIM Multicast Border Router Behavior .................143
A.1. Sources External to the PIM-SM Domain ....................143
A.2. Sources Internal to the PIM-SM Domain ...................144
Appendix B. Index ................................................146
List of Figures
図のリスト
Figure 1. Per-(S,G) register state machine at a DR ................38
Figure 2. Downstream per-interface (*,*,RP) state machine .........46
Figure 3. Downstream per-interface (*,G) state machine ............50
Figure 4. Downstream per-interface (S,G) state machine ............53
Figure 5. Downstream per-interface (S,G,rpt) state machine ........57
Figure 6. Upstream (*,*,RP) state machine .........................62
Figure 7. Upstream (*,G) state machine ............................67
Figure 8. Upstream (S,G) state machine ............................71
Figure 9. Upstream (S,G,rpt) state machine for triggered
messages ................................................77
Figure 10. Per-interface (S,G) Assert State machine ...............84
Figure 11. Per-interface (*,G) Assert State machine ...............92
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 originally specified in RFC 2117 and was revised in RFC 2362, both Experimental RFCs. This document is intended to obsolete RFC 2362, to correct a number of deficiencies that have been identified with the way PIM-SM was previously specified, and to bring PIM-SM onto the IETF Standards Track. As far as possible, this document specifies the same protocol as RFC 2362 and only diverges from the behavior intended by RFC 2362 when the previously specified behavior was clearly incorrect. Routers implemented according to the specification in this document will be able to interoperate successfully with routers implemented according to RFC 2362.
PIM-SMバージョン2はもともとRFC 2117で指定され、両方の実験RFCのRFC 2362で改訂されました。このドキュメントは、PIM-SMが以前に指定された方法で特定された多くの欠陥を修正し、PIM-SMをIETF標準トラックに導入するために、RFC 2362を廃止することを目的としています。可能な限り、このドキュメントはRFC 2362と同じプロトコルを指定し、以前に指定された動作が明らかに間違っていたRFC 2362によって意図された動作とのみ分岐します。このドキュメントの仕様に従って実装されたルーターは、RFC 2362に従って実装されたルーターと正常に相互運用できるようになります。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and indicate requirement levels for compliant PIM-SM implementations.
このドキュメントでは、キーワードは「必要はない」、「必須」、「必要」、「shall」、「suff」、 "nove"、 "bulsed"、 "becommended"、 "、"、 "、" optional "RFC 2119 [1]で説明されているように解釈され、準拠したPIM-SM実装の要件レベルを示します。
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.
Rendezvous Point（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またはその他）ごとに1つの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の二次機能は、宛先アドレスにルーティングメトリックを提供することです。これらのメトリックは、アサートメッセージを送信および処理するときに使用されます。
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 Neighbor RPFは、「逆パス転送」の略です。アドレスに関するルーターのRPF隣接は、MRIBがそのアドレスにパケットを転送するために使用する必要があることを示す隣接です。PIM-SMマルチキャストグループの場合、RPF隣接は、アサート状態の変更がない場合、そのグループの結合メッセージが指示されるルーターです。
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.
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 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.
再起動を検出するために使用される遺伝子生成識別子。
PMBR PIM Multicast Border Router, joining a PIM domain with another multicast domain.
PMBR PIMマルチキャストボーダールーター。PIMドメインを別のマルチキャストドメインで結合します。
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.
ブレース{および}は、グループ化に使用されます。
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が結合/プルーンメッセージが送信される次の隣人を決定するために使用されます。データは、結合メッセージの逆パスに沿って流れます。したがって、データパケットがサブネットに到達するために取る次のホップを指定するユニキャストリブとは対照的に、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に参加するため、a（*、g）結合として知られています。（*、g）は、グループのRPに向かってTravels Hop-by-hopに結合し、各ルーターで通過する各ルーターでは、グループGのマルチキャストツリー状態がインスタンス化されます。最終的に、（*、g）結合はRPに到達するか、そのグループの既に（*、g）結合状態を持っているルーターに到達します。多くのレシーバーがグループに参加すると、結合メッセージがRPに収束し、RPに根付いているグループGの分布ツリーを形成します。これはRPツリー（RPT）として知られており、そのグループに送信するすべてのソースによって共有されるため、共有ツリーとしても知られています。受信機がグループに残っている限り、メッセージは定期的にresします。リーフネットワークのすべてのレシーバーがグループを離れると、DRはそのマルチキャストグループのRPにPIM（*、g）プルーンメッセージを送信します。ただし、プルーンメッセージが何らかの理由で送信されない場合、状態は最終的にタイムアウトします。
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レジスタパケットとして知られています。
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.
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）ソース固有の結合を開始します。パスに沿ったルーターのインスタンス化（s、g）マルチキャストツリー状態。（S、G）マルチキャストツリー状態は、これらのパケットがソースSから来た場合にのみ使用されます。これらのパケットがソースSから来た場合、最終的に結合メッセージは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.
At the end of phase 2, 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からRPに、そしてそこから共有ツリーに沿ってレシーバーにネイティブに流れます。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.
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.
この時点で、受信機（またはレシーバーの上流のルーター）は、SPTから1つ、RPTから2つのデータのコピーを受信します。最初のトラフィックがSPTから到着し始めると、DRまたは上流のルーターは、RPツリーを介して到着したSからGのパケットをドロップし始めます。さらに、RPに向かって（s、g）プルーンメッセージを送信します。これは、（s、g、rpt）プルーンとして知られています。プルーンメッセージは、RPへのパスに沿ってホップバイホップでインスタンス化された状態を移動し、GのSからのトラフィックをこの方向に転送しないでください。プルーンは、他のレシーバーのSからのトラフィックが必要なRPまたはルーターに到達するまで伝播されます。
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を発行することができます（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, as described in Section 4.8.
232.0.0.0から232.255.255.255までのマルチキャストアドレスの範囲は、現在IPv4のソース固有のマルチキャストのために確保されています。この範囲のグループの場合、受信機はソース固有のIGMPV3結合のみを発行する必要があります。PIMルーターがこの範囲のグループの非ソース固有の結合を受信する場合、セクション4.8で説明されているように、それを無視する必要があります。
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は、受信者がグループに参加し、そのトラフィックが特定のソースまたはソースから来ていない場合にのみグループのトラフィックを受け取ることを望んでいることを指定することを許可しています。この場合、DRは通常どおりA（*、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上の異なる上流のルーターに結合する可能性があります。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、G）は、ソースSに到達する方法について一貫性のないMRIBエントリを持つため、LAN上の異なる上流のルーターに結合します。LANに表示されるSからのすべてのトラフィックのコピー。
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）結合を発行し、LAN上の別のルーターが同じLAN上の別のアップストリームルーターに結合を発行する場合があります。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 or both router has (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 to source-specific trees.
これらの問題はすべて、グループまたはソースグループのペアに結合状態を備えた複数の上流ルーターがあることによって引き起こされます。PIMは、このような複製結合が発生しないようにしません。代わりに、さまざまなルーターのLANにデータパケットが表示されると、これらのルーターはこれに気付き、単一のフォワーダーを選択します。この選挙は、PIMアサートメッセージを使用して実行されます。これにより、（s、g）状態を持つ上流のルーターに有利な問題を解決します。または、Routerが（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.
これらのアサートメッセージは、LAN上の下流のルーターによっても受信され、これらはその後の結合メッセージをアサートを獲得した上流のルーターに送信します。
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 Bootstrap Router 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つのルーターが、単純な選挙プロセスを通じてブートストラップルーターに選出されます。ドメイン内のすべてのルーターは、RPSになるように候補になるように構成されており、定期的にBSRに対する立候補を固定します。候補者から、BSRはRPセットを選択し、このセットをブートストラップメッセージで定期的に発表します。ブートストラップメッセージは、ドメイン内のすべてのルーターがRPセットを知るまで、ドメイン全体にホップバイホップにあふれます。
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セットが変更された場合に変更を最小限に抑える）を使用します。結果のRPは、そのグループの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の結合/プルーン生成および処理ルールを指定します。
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 The subset of PIM required to support Source-Specific Multicast, PIM-SSM, is described in Section 4.8.
o ソース固有のマルチキャストであるPIM-SSMをサポートするために必要なPIMのサブセットは、セクション4.8で説明されています。
o PIM packet formats are specified in Section 4.9.
o PIMパケット形式は、セクション4.9で指定されています。
o A summary of PIM-SM timers and their default values is given in Section 4.10.
o PIM-SMタイマーの概要とそのデフォルト値は、セクション4.10に記載されています。
o Appendix A specifies the PIM Multicast Border Router behavior.
o 付録Aは、PIMマルチキャストボーダールーターの動作を指定しています。
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 four sections:
TIB状態を4つのセクションに分けます。
(*,*,RP) state State that maintains per-RP trees, for all groups served by a given RP.
（*、*、RP）特定のRPが提供するすべてのグループに対して、RPごとのツリーを維持する状態状態。
(*,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 抑制状態：{"enable"、 "disable"の1つ}
Neighbor State:
近隣の州：
For each neighbor:
隣人ごとに：
o Information from neighbor's Hello
o 隣人のこんにちはからの情報
o Neighbor's GenID.
o 隣人の遺伝子。
o Neighbor Liveness Timer (NLT)
o Neighbor Livensionタイマー（NLT）
Designated Router (DR) State:
指定ルーター（DR）状態：
o Designated Router's IP Address
o 指定されたルーターのIPアドレス
o DR's DR Priority
o 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 RP, a router keeps the following state:
すべてのRPについて、ルーターは次の状態を保持します。
(*,*,RP) state: For each interface:
（*、*、rp）状態：各インターフェイスの場合：
PIM (*,*,RP) Join/Prune State:
pim（*、*、rp）Join/Prune State：
o State: One of {"NoInfo" (NI), "Join" (J), "Prune-Pending" (PP)}
o 州：{"noinfo"（ni）、 "join"（j）、 "prune-pending"（pp）}の1つ
o Prune-Pending Timer (PPT)
o プルーンペンディングタイマー（PPT）
o Join/Prune Expiry Timer (ET)
o 結合/プルーンExpiry Timer（ET）
Not interface specific:
インターフェイス固有のものではありません：
Upstream (*,*,RP) Join/Prune State:
上流（*、*、rp）結合/プルーン状態：
o State: One of {"NotJoined(*,*,RP)", "Joined(*,*,RP)"}
o 状態：{"notjoned（*、*、rp）"、 "inged（*、*、rp）"}の1つ
o Upstream Join/Prune Timer (JT)
o 上流の結合/プルーンタイマー（JT）
o Last RPF Neighbor towards RP that was used
o 使用されたRPへの最後のRPF隣人
PIM (*,*,RP) Join/Prune state is the result of receiving PIM (*,*,RP) Join/Prune messages on this interface and is specified in Section 4.5.1.
PIM（*、*、RP）結合/プルーン状態は、このインターフェイスでPIM（*、*、RP）結合メッセージを受信した結果であり、セクション4.5.1で指定されています。
The upstream (*,*,RP) Join/Prune State reflects the state of the upstream (*,*,RP) state machine described in Section 4.5.5.
上流（*、*、RP）結合/プルーン状態は、セクション4.5.5で説明されている上流（*、*、RP）状態マシンの状態を反映しています。
The upstream (*,*,RP) Join/Prune Timer is used to send out periodic Join(*,*,RP) messages, and to override Prune(*,*,RP) messages from peers on an upstream LAN interface.
上流（*、*、RP）結合/プルーンタイマーを使用して、定期的な参加（*、*、RP）メッセージを送信し、上流のLANインターフェイスでピアからのプルーン（*、*、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(*,*,RP) to the new upstream neighbor and a Prune(*,*,RP) 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(*,*,RP). These mechanisms are specified in Section 4.5.5.
MRIBが変更された場合、RPに向かってRPF隣接が変更される可能性があるため、RPに向かう最後のRPF隣接が保存されます。もしそうなら、新しい上流の隣人に新しい結合（*、*、RP）をトリガーし、古い上流の隣人にプルーン（*、*、RP）をトリガーする必要があります。同様に、RPに向かって上流の隣人が再起動したというハローメッセージで、ルーターが変化した遺伝子を介して検出した場合、Join（*、*、RP）を送信して状態を再インスタンス化する必要があります。これらのメカニズムは、セクション4.5.5で指定されています。
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）Join/Prune State：
o State: One of {"NoInfo" (NI), "Join" (J), "Prune-Pending" (PP)}
o 州：{"noinfo"（ni）、 "join"（j）、 "prune-pending"（pp）}の1つ
o Prune-Pending Timer (PPT)
o プルーンペンディングタイマー（PPT）
o Join/Prune Expiry Timer (ET)
o 結合/プルーンExpiry Timer（ET）
(*,G) Assert Winner State
（*、g）勝者の状態を主張します
o State: One of {"NoInfo" (NI), "I lost Assert" (L), "I won Assert" (W)}
o
o Assert Timer (AT)
o アサートタイマー（at）
o Assert winner's IP Address (AssertWinner)
o 勝者のIPアドレスをアサートする（AssertWinner）
o Assert winner's Assert Metric (AssertWinnerMetric)
o assert winner's assert metric（assertwinmetric）
Not interface specific:
インターフェイス固有のものではありません：
Upstream (*,G) Join/Prune State:
上流（*、g）結合/プルーン状態：
o State: One of {"NotJoined(*,G)", "Joined(*,G)"}
o 状態：{"notjoined（*、g）"、 "ingined（*、g）"}の1つ
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. 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_include(*,G) macro described in Section 4.1.6.
ローカルメンバーシップは、そのインターフェイスで実行されているローカルメンバーシップメカニズム（IGMPやMLDなど）の結果です。このルーターがこのグループのインターフェイスで（*、g）をアサートしない限り、このルーターがそのインターフェイスのDRではない場合は、保持する必要はありません。可能であれば、この情報を保存することをお勧めします。これは、障害が発生した後に安定した動作条件に収束するレイテンシを減らすためです。この情報は、セクション4.1.6で説明されている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.2. The state is used by the macros that calculate the outgoing interface list in Section 4.1.6, and in the JoinDesired(*,G) macro (defined in Section 4.5.6) that is used in deciding whether a Join(*,G) should be sent upstream.
PIM（*、g）結合/プルーン状態は、このインターフェイスでPIM（*、g）結合メッセージを受信した結果であり、セクション4.5.2で指定されています。状態は、セクション4.1.6の発信インターフェイスリストを計算するマクロによって使用されます。上流に送信する必要があります。
(*,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）Assert Winner Stateは、このインターフェイスでメッセージを送信または受信（*、G）アサートメッセージの結果です。セクション4.6.2で指定されています。
The upstream (*,G) Join/Prune State reflects the state of the upstream (*,G) state machine described in Section 4.5.6.
上流（*、g）結合/プルーン状態は、セクション4.5.6で説明されている上流（*、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）結合/プルーンタイマーは、定期的な結合（*、g）メッセージを送信し、上流のLANインターフェイスでピアからのプルーン（*、g）メッセージをオーバーライドするために使用されます。
The last RP used must be stored because if the RP-Set changes (Section 4.7), then state must be torn down and rebuilt for groups whose RP changes.
使用された最後のRPは、RPセットが変更された場合（セクション4.7）、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.6.
MRIBが変更された場合、RPに向かってRPF隣接が変更される可能性があるため、RPに向かう最後のRPF隣接が保存されます。そうする場合は、新しい上流の隣人に新しい結合（*、g）をトリガーし、古い上流の隣人にプルーン（*、g）をトリガーする必要があります。同様に、RPに向かって上流の隣人が再起動したというハローメッセージで、ルーターが変化した遺伝子を介して検出した場合、結合（*、g）を送信して状態を再インスタンス化する必要があります。これらのメカニズムは、セクション4.5.6で指定されています。
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）JOIN/PRUNE STATE：
o State: One of {"NoInfo" (NI), "Join" (J), "Prune-Pending" (PP)}
o 州：{"noinfo"（ni）、 "join"（j）、 "prune-pending"（pp）}の1つ
o Prune-Pending Timer (PPT)
o プルーンペンディングタイマー（PPT）
o Join/Prune Expiry Timer (ET)
o 結合/プルーンExpiry Timer（ET）
(S,G) Assert Winner State
o State: One of {"NoInfo" (NI), "I lost Assert" (L), "I won Assert" (W)}
o 州：{"noinfo"（ni）、「assertを失った」（l）の1つ、「assert」（w）}
o Assert Timer (AT)
o アサートタイマー（at）
o Assert winner's IP Address (AssertWinner)
o
o Assert winner's Assert Metric (AssertWinnerMetric)
o assert winner's assert metric（assertwinmetric）
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）"、 "ingined（s、g）"}の1つ
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)
o （S、G）KeepAlive Timer（KAT）
Additional (S,G) state at the DR:
drの追加（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）}の1つ
o Register-Stop timer
o レジスタストップタイマー
Additional (S,G) state at the RP:
RPで追加（s、g）状態：
o PMBR: the first PMBR to send a Register for this source with the Border bit set.
o PMBR：Border Bit Setでこのソースの登録簿を送信した最初のPMBR。
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 a (S,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_include(S,G) macro described in Section 4.1.6.
ローカルメンバーシップは、そのインターフェイスで実行され、この特定のソースを含める必要があることを指定するローカルソース固有のメンバーシップメカニズム（IGMPバージョン3など）の結果です。ここに保存されているように、この状態は、IGMPV3の矛盾が解決された後、結果の状態です。このルーターがこのグループのインターフェイスでAssertを獲得しない限り、このルーターがそのインターフェイスのDRではない場合は、保持する必要はありません。ただし、DRの変更を引き起こす障害後に安定した動作条件に収束するレイテンシを減らすため、可能であればこの情報を保存することをお勧めします。この情報は、セクション4.1.6で説明されている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.6, and in the JoinDesired(S,G) macro (defined in Section 4.5.7) that is used in deciding whether a Join(S,G) should be sent upstream.
PIM（S、G）結合/プルーン状態は、このインターフェイスでPIM（S、G）結合メッセージを受信した結果であり、セクション4.5.2で指定されています。状態は、セクション4.1.6の発信インターフェイスリストを計算するマクロによって使用されます。上流に送信する必要があります。
(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.
The upstream (S,G) Join/Prune State reflects the state of the upstream (S,G) state machine described in Section 4.5.7.
上流（s、g）結合/プルーン状態は、セクション4.5.7で説明されている上流（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）の結合/プルーンタイマーは、定期的な結合（s、g）メッセージを送信し、上流のLANインターフェイスでピアからのプルーン（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.7.
Sに向かって最後のRPF隣接は保存されます。MRIBが変更された場合、Sに向かうRPF隣接が変更される可能性があるためです。そうする場合は、新しい上流の隣人に新しい結合（s、g）をトリガーし、古い上流の隣人にプルーン（s、g）をトリガーする必要があります。同様に、RouterがSに向かって上流の隣人が再起動したというハローメッセージで変化した遺伝子を介して検出した場合、Join（S、G）を送信して状態を再インスタンス化する必要があります。これらのメカニズムは、セクション4.5.7で指定されています。
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が真の場合、（*、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）KeepAliveタイマーは、この（S、G）転送状態を使用して転送されるデータによって更新されます。これは、明示的な（s、g）結合がない場合に状態を生かし続けるために使用されます。とりわけ、これはいわゆる「ターンアラウンドルール」に必要です。RPが（S、G）が結合してカプセル化を停止し、次に（S、G）プルーンがRPに不必要に到達するのを防ぐために（S、G）プルーネに必要です。
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）に対してカプセル化が再び開始されるまでの期間を追跡します。
On an RP, the PMBR value must be cleared when the Keepalive Timer expires.
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"の1つ}
o Prune-Pending Timer (PPT)
o プルーンペンディングタイマー（PPT）
o Join/Prune Expiry Timer (ET)
o 結合/プルーンExpiry Timer（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）"}の1つ
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.6.
ローカルメンバーシップは、そのインターフェイスで実行され、（*、g）が状態が含まれているにもかかわらず、この特定のソースを除外する必要があることを指定するローカルソース固有のメンバーシップメカニズム（IGMPV3など）の結果です。ここに保存されているように、この状態は、LANメンバー間のIGMPV3の矛盾が解決された後、結果として生じる状態です。このルーターがこのグループのこのインターフェイスで（*、g）をアサートしない限り、このルーターがそのインターフェイスのDRではない場合は、保持する必要はありません。ただし、DRの変更を引き起こす障害後に安定した動作条件に収束するレイテンシを減らすため、可能であればこの情報を保存することをお勧めします。この情報は、セクション4.1.6で説明されている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.4. The state is used by the macros that calculate the outgoing interface list in Section 4.1.6, and in the rules for adding Prune(S,G,rpt) messages to Join(*,G) messages specified in Section 4.5.8.
PIM（S、G、RPT）結合/プルーン状態は、このインターフェイスでPIM（S、G、RPT）の結合/プルーンメッセージを受信した結果であり、セクション4.5.4で指定されています。状態は、セクション4.1.6で発信インターフェイスリストを計算するマクロによって使用され、セクション4.5.8で指定された[*、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.9.
上流（s、g、rpt）の結合/プルーン状態は、オーバーライドタイマーとともに使用され、LAN上の上流のピアが送信したメッセージに応じて正しいオーバーライドメッセージを送信します。この状態と動作は、セクション4.5.9で指定されています。
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.
最も重要なマクロは、関連状態の発信インターフェイスリスト（または「オリスト」）を定義するマクロです。関連するタイプの状態から直接構築される場合、オリストは「即時」にすることができます。たとえば、firth_olist（s、g）は、ルーターに（s、g）状態とno（*、g）または（s、g、rpt）状態しかない場合に構築されるオリストです。対照的に、「継承された」オリストは、他のタイプから状態を継承します。たとえば、Ensulited_olist（S、G）は、ソース固有とグループ固有の状態の両方を使用して、SからGへのパケットの転送に関連するオリストです。
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(*,*,RP) (+) immediate_olist(*,G)).
（s、g、rpt）状態は負の状態であるasive_olist（s、g、rpt）はありません。実際にトラフィックを転送するために使用されるオリストから（*、g）オリストのインターフェイスを削除します。したがって、internited_olist（s、g、rpt）は、rpツリーのsからGへのパケットに使用されるオリストです。これは、（*、*、rp）（）emmeroy_olist（*、g））の厳格なサブセットです。
Generally speaking, the inherited olists are used for forwarding, and the immediate_olists are used to make decisions about state maintenance.
一般的に言えば、継承されたオリストは転送に使用され、即時_olistは状態のメンテナンスに関する決定を下すために使用されます。
immediate_olist(*,*,RP) =
joins(*,*,RP)
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(*,*,RP(G)) (+) 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からsから送信されたトラフィックをgに具体的に受け取ることを望んでいると判断した場合に当てはまります。、i）「IGMP/MLDモジュールまたは他のローカルメンバーシップメカニズムが、Gに送信されたすべてのトラフィックを受け取ることを望んでいるインターフェースのローカルメンバー（おそらく特定のソースセットからトラフィックを除外）を希望すると判断した場合です。「local_receiver_exclude（s、g、i）は、「local_receiver_include（*、g、i）」が真実である場合に真ですが、地元のメンバーはSからトラフィックを受け取ることを望んでいません。
The set "joins(*,*,RP)" is the set of all interfaces on which the router has received (*,*,RP) Joins:
joins(*,*,RP) =
{ all interfaces I such that
DownstreamJPState(*,*,RP,I) is either Join or
Prune-Pending }
DownstreamJPState(*,*,RP,I) is the state of the finite state machine in Section 4.5.1.
DownstreamJPState（*、*、RP、I）は、セクション4.5.1の有限状態マシンの状態です。
The set "joins(*,G)" is the set of all interfaces on which the router has received (*,G) Joins:
セット「結合（*、g）」は、ルーターが受信した（*、g）結合したすべてのインターフェイスのセットです。
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.2.
ダウンストリームJPState（*、g、i）は、セクション4.5.2の有限状態マシンの状態です。
The set "joins(S,G)" is the set of all interfaces on which the router has received (S,G) Joins:
セット「結合（s、g）」は、ルーターが受信した（s、g）結合したすべてのインターフェイスのセットです。
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.3.
ダウンストリームJPState（S、G、I）は、セクション4.5.3の有限状態マシンの状態です。
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.4.
ダウンストリームJPSTATE（S、G、RPT、I）は、セクション4.5.4の有限状態マシンの状態です。
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）アサートを失ったすべてのインターフェイスのセットです。Macro 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) =
{ 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）アサートを失ったすべてのインターフェイスのセットです。Macro 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アサートが隣接の通常の選択をオーバーライドしていない限り、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.8).
rpf '（s、g、rpt）は、基本的にrpf'（*、g）は、rpf_interface（rp（g））のアサート（s、g）の結果によって変更されます。このような場合、Sからのパケットは、RPF '（*、g）とは異なるルーターから発生します。アクティブ（*、g）のみが状態のみを持っている場合、RPF '（s、g、rpt）からパケットを受け入れ、Prune（s、g、rpt）を定期的な結合（*、g）メッセージに追加する必要があります。RPF '（*、g）に送信します（セクション4.5.8を参照）。
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に戻します。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メッセージのソースとして使用するアドレスです。スコープの問題により、近隣のIPアドレスはPIM Neighborデータベース内で非不合理である可能性があることに注意してください。ただし、アドレスは、特定のインターフェイス上のすべての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が「I Am Assert Loser」状態にある（*、g）のアサート状態マシン（*、g）のアサート状態マシン（*、g）の場合です。
The PIM-SM packet forwarding rules are defined below in pseudocode.
PIM-SMパケット転送ルールは、Pseudocodeで以下に定義されています。
iif is the incoming interface of the packet. S is the source address of the packet. G is the destination address of the packet (group address). RP is the address of the Rendezvous Point for this group. RPF_interface(S) is the interface the MRIB indicates would be used to route packets to S. RPF_interface(RP) is the interface the MRIB indicates would be used to route packets to RP, except at the RP when it is the decapsulation interface (the "virtual" interface on which register packets are received).
IIFは、パケットの着信インターフェイスです。Sはパケットのソースアドレスです。Gは、パケットの宛先アドレス（グループアドレス）です。RPは、このグループのランデブーポイントのアドレスです。RPF_INTERFACE（s）は、MRIBが示すインターフェイスであり、パケットをS. RPF_INTERFACE（RP）にルーティングするために使用されます。RPPF_INTERFACE（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）状態のkeepAliveタイマーを再起動します。
If the packet should be forwarded using (*,*,RP) or (*,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.
パケットを（*、*、rp）または（*、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
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 FSM 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
oiリスト=オリストのすべてのインターフェイス上のフォワードパケットのリスト（ - ）
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が任意のサブネット上にある場合に真です。
inherited_olist(S,G) and inherited_olist(S,G,rpt) are defined in Section 4.1.
internited_olist（s、g）およびnemeritited_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 (*,*,RP) state, (*,G) state, asserts, etc.
基本的に、Enturitited_olist（s、g）は、（s、g）状態に転送されたパケットの発信インターフェイスリスト（*、*、rp）状態、（*、g）状態、assertsなどを考慮して。
inherited_olist(S,G,rpt) is the outgoing interface list for packets forwarded on (*,*,RP) or (*,G) state, taking into account (S,G,rpt) prune state, asserts, etc.
internited_olist（s、g、rpt）は、（*、*、rp）または（*、g）状態に転送されたパケットの発信インターフェイスリストであり、（s、g、rpt）prune状態、assertsなど。
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.7.
UpstreamJPState（S、G）は、セクション4.5.7の有限状態マシンの状態です。
Keepalive_Period is defined in Section 4.10.
keepalive_periodはセクション4.10で定義されています。
Data-triggered PIM-Assert messages sent from the above forwarding code should be rate-limited in a implementation-dependent manner.
上記の転送コードから送信されたデータトリガーされたPIMアサートメッセージは、実装依存的にレート制限する必要があります。
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）を常に返すようにすることで実装できます。SwitchToSptDesired（S、g）がソースとグループの単一のパケットを受信したら、SwitchToSptDesired（s、G）をtrueにすることにより、「最初のパケットのスイッチ」ポリシーを実装できます。
The (S,G) SPTbit is used to distinguish whether to forward on (*,*,RP)/(*,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 (*,*,RP)/(*,G) state while upstream (S,G) state is being established, during which time a router should continue to forward only on (*,*,RP)/(*,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は、（*、*、rp）/（*、g）または（s、g）状態を転送するかどうかを区別するために使用されます。RPツリーからソースツリーに切り替えると、上流（*、*、RP）/（*、g）状態のためにデータが到着する遷移期間があります。ルーターは（*、*、rp）/（*、g）状態でのみ転送し続ける必要があります。これにより、上流（s、g）状態が確立される前にプルーン（s、g、rpt）を送信することによって引き起こされる一時的なブラックホールを防ぎます。
Thus, when a packet arrives, the (S,G) SPTbit is updated as follows:
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）でアサート（s、g）を受信する場合など、他の場合にsptbit（s、g）を真に設定できます（セクション4.6.1を参照）。
JoinDesired(S,G) is defined in Section 4.5.7 and indicates whether we have the appropriate (S,G) Join state to wish to send a Join(S,G) upstream.
Joindesinedired（S、G）はセクション4.5.7で定義されており、適切な（s、g）結合状態があるかどうかを示し、Join（S、G）の上流を送信したいと考えています。
Basically, Update_SPTbit 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 applies:
基本的に、適切な（s、g）結合状態がある場合、update_sptbitはsptbitを設定します。
1. The source is directly connected, in which case the switch to the SPT is a no-op.
1. ソースは直接接続されています。その場合、SPTへの切り替えはNO-OPです。
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インターフェイスは、RPFインターフェイスとRPへの異なりです。パケットはrpf_interfaceに到着したため、SPTが完了している必要があります。
3. Noone 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.
4. rpf '（s、g）== rpf'（*、g）。この場合、ルーターはSPTが完了したかどうかを判断することができないため、すぐに切り替える必要があります。
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が完了したと考えています。ただし、アサート（s、g）が発生することをトリガーする（*、g）状態がない場合があるため、上記の項目（3）が必要です。
The SPTbit is cleared in the (S,G) upstream state machine (see Section 4.5.7) when JoinDesired(S,G) becomes FALSE.
sptbitは、（s、g）の上流の状態マシン（セクション4.5.7を参照）でクリアされます（s、g）がfalseになります。
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つを区別しません。したがって、選挙博士は、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.
博士選挙は、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 Designated Router (DR), and to negotiate additional capabilities. A router must record the Hello information received from each PIM neighbor.
PIM Helloメッセージは、各PIM対応インターフェイスで定期的に送信されます。ルーターは、各インターフェイスの隣接するPIMルーターについて学習できます。こんにちはメッセージは、指定されたルーター（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).
ハローメッセージは、物理的なポイントツーポイントリンクを含むすべてのアクティブなインターフェイスで送信する必要があり、IPv4および 'ff02 :: d' for ipv6の「All-PIM-Routers」グループアドレス（ '224.0.0.13' '' 224.0.0.13 '」）。
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.
インターフェイスごとのハロータイマー（HT（i））を使用して、各アクティブインターフェイスでハローメッセージの送信をトリガーします。インターフェイスまたはルーターでPIMが最初に開始されると、そのインターフェイスのハロータイマーは0とtriggered_hello_delayの間のランダムな値に設定されます。これにより、複数のルーターが同時に電源が入っている場合、ハローメッセージの同期を防ぎます。最初のランダム化された間隔の後、Helloメッセージはhello_period秒ごとに送信する必要があります。ハロータイマーが失効した場合を除き、リセットしないでください。
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.
隣人は、最初にそのルーターからハローメッセージを聞いた場合を除き、ルーターからの結合/プルーンまたはアサートを受け入れないことに注意してください。したがって、ルーターが現在構成されているIPアドレスでまだハローメッセージを送信していないインターフェイスに参加/プルーンまたはアサートメッセージを送信する必要がある場合、ハロータイマーを待つことなく関連するハローメッセージをすぐに送信する必要があります有効期限が切れ、その後、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_PRIORITYオプションにより、ネットワーク管理者は、DRの選挙プロセスで特定のルーターを優先することができます。DRの優先度がそのインターフェイスで明示的に構成されていない場合でも、DR_PriorityオプションはすべてのHelloメッセージに含める必要があります。これは、DR_Priorityオプションを使用できることをインターフェイス上のすべての隣人が宣伝する場合にのみ、優先順位ベースの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メッセージに含める必要があります。GenIDオプションには、ルーター自体が再起動するときを含め、PIM転送が開始または再起動されるたびに再生されるランダムに生成された32ビット値が含まれています。隣人から新しい遺伝子を含むハローメッセージが受信されると、その隣人に関する古いハロー情報は、新しいHelloメッセージからの情報に捨てられ、置き換える必要があります。これにより、新しい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遅延オプションは、マルチアクセスLANに送信されたすべてのハローメッセージに含める必要があります。このオプションは、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.
アドレスリストオプションは、メッセージを発信するルーターのソースインターフェイスに関連付けられたすべてのセカンダリアドレスを宣伝します。ソースインターフェイスに関連付けられたセカンダリアドレスがある場合は、すべてのハローメッセージにオプションを含める必要があり、セカンダリアドレスが存在しない場合は省略される場合があります。
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.
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アドレスを変更する前に、ゼロホールドタイムのハローメッセージをすぐに送信する必要があります（IPアドレスが変更された場合は古いIPアドレスを使用）。これにより、PIM Neighborsはこの隣人（またはその古いIPアドレス）をすぐに削除します。インターフェイスがIPアドレスを変更した後、新しいIPアドレスでHelloメッセージを送信する必要があります。インターフェイスがセカンダリIPアドレスのいずれかを変更する場合、更新されたaddress_listオプションを備えたハローメッセージと非ゼロホールドタイムをすぐに送信する必要があります。これにより、PIM Neighborsはこの隣人のセカンダリアドレスのリストをすぐに更新します。
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.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 neighborの生成ID。
neighbor.dr_priority The DR Priority field of the PIM neighbor, if it is present in the Hello message.
helloメッセージに存在する場合、neighbor.dr_priority pim neighborのDR優先フィールド。
neighbor.dr_priority_present A flag indicating if the DR Priority field was present in the Hello message.
neighbor.dr_priority_present dr優先フィールドがHelloメッセージに存在するかどうかを示すフラグ。
neighbor.timeout A timer value to time out the neighbor state when it becomes stale, also known as the Neighbor Liveness Timer.
neighbor.timeoutは、近隣状態が古くなったときにタイムアウトするタイマーの値であり、近隣のliveningタイマーとしても知られています。
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.
Neighbor Livensionタイマー（NLT（N、I））は、Hello_HoldTime（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の「メトリック」を比較するために使用される関数：
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インターフェイスで実行する必要があります。
In addition to the information recorded for the DR Election, the following per neighbor information is obtained from the LAN Prune Delay Hello option:
博士選挙のために記録された情報に加えて、LAN Prune Delay Hello Optionから近隣の情報ごとの以下が取得されます。
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 LAN Prune遅延オプションがHelloメッセージに存在するかどうかを示すフラグ。
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 lan prune遅延オプションにtビューの値を保存するフラグがHelloメッセージに存在する場合。これは、隣人が参加メッセージ抑制の参加を無効にする能力を示しています。
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遅延オプション（存在する場合）の伝播遅延フィールド。
neighbor.override_interval The Override_Interval field of the LAN Prune Delay option (if present) in the Hello message.
neighbor.override_intervalハローメッセージのLAN Prune遅延オプション（存在する場合）のOverride_intervalフィールド。
The additional state described above is deleted along with the DR neighbor state when the neighbor timeout expires.
上記の追加の状態は、隣人のタイムアウトが期限切れになったときに隣人の博士状態とともに削除されます。
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_Priorityオプションと同様に、LAN Prune遅延オプションで提供される情報は、リンク上のすべての隣人がオプションを宣伝しない限り使用されません。以下の関数はこの状態を計算します。
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 Prune遅延オプションにルーターによって挿入された伝播遅延は、リンクの予想されるメッセージ伝播遅延を表現し、システム管理者が構成できるはずです。アップストリームルーターで使用されて、インターフェイスを剪定する前に結合オーバーライドメッセージを待つ必要があるかどうかを把握します。
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実装者は、この遅延の許可された値の下限を強制して、ルーター内のスケジューリングと処理の遅延を可能にする必要があります。このような遅延により、受信したメッセージが後で処理される可能性があり、トリガーされたメッセージが意図したよりも遅れて送信される場合があります。下流のルーターが上流の隣人が転送を停止する前に隣人のプルーンメッセージを無効にすることができないため、この伝播遅延を値が低すぎると一時的な転送停止が発生する可能性があります。
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:
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, 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.
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.10).
suptression_enabled（i）の設定は、t_suppressedの値に影響することに注意してください（セクション4.10を参照）。
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情報をマッピングするメカニズムを、結合/プルーンメッセージの宛先として使用できるプライマリアドレスに提供するために必要です。マッピングはNBRマクロを介して実行されます。PIM隣接の主なアドレスは、PIM Helloメッセージで使用されているソースIPアドレスから取得されます。セカンダリアドレスは、アドレスリストのhelloメッセージのHello OptionのHelloメッセージ内に掲載されています。ルーターのソースインターフェイスの主要なアドレスは、アドレスリストのhello optionにリストされてはなりません。
In addition to the information recorded for the DR Election, the following per neighbor information is obtained from the Address List Hello option:
博士選挙で記録された情報に加えて、近隣の情報ごとの以下は、アドレスリストから取得されます。こんにちはオプション：
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 neightが使用する二次アドレスのリスト。
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.
受信したPIM Helloメッセージを処理すると、アドレスリストのHello Optionを含む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.
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のレジスタストップメッセージを受け取っていない限り、関連するグループのローカルソースからRPへのマルチキャストパケットをカプセル化します。）RPから。DRがRPからレジスターストップメッセージを受信すると、この状態を維持するためにレジスタストップタイマーを起動します。レジスタストップタイマーが切れる直前に、DRはRPにnull-registerメッセージをRPに送信して、RPがDRでレジスタストップ情報を更新できるようにします。レジスタストップタイマーが実際に期限切れになった場合、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）オリストに追加または削除されます。トンネルインターフェイスは、セクション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のPER-（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）登録トンネルは「プルーニング」されます（これは、レジスタストップを受信したときに発生します）。
Join-Pending (JP) The register tunnel is pruned but the DR is contemplating adding it back.
結合ペンディング（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.
Figure 1: Per-(S,G) register state machine at a DR in tabular form
図1：Per-（s、g）表形式のDRに状態マシンを登録
+----------++----------------------------------------------------------+
| || 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.
（ *）レジスタストップタイマーは、間隔から均一に選択されたランダムな値に設定されます（0.5 * register_suppression_time、1.5 * register_suppression_time）minus 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 spec and is kept for compatibility.
register_probe_timeを差し引くことは、Register_suppression_timeに比べて非常に小さいため、少し不要ですが、これは古い仕様であり、互換性のために保持されます。
(**) The Register-Stop Timer is set to Register_Probe_Time.
（**）レジスタストップタイマーは、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).
レジスタトゥンネル仮想インターフェイスであるVIが作成され（まだ存在していない場合）、カプセル化ターゲットはRP（g）です。DownstreamJpState（S、G、VI）は状態になるように設定されており、トンネルインターフェイスをfidel_olist（s、g）およびenserted_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）のカプセル化ターゲットを備えたレジスタトンネル仮想インターフェイスです。ダウンストリームJPSTATE（S、G、VI）はnoinfo状態に設定されており、トンネルインターフェイスをfrom empry_olist（s、g）およびenternited_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）を備えたレジスタトンネル仮想インターフェイスです。レジスタトゥンネル仮想インターフェイス、VI_Newが作成され（まだ存在していない場合）、そのカプセル化ターゲットはNew_RP（g）です。DownstreamJPState（S、G、VI_OLD）はNoinfo Stateに設定され、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)
register（s、g）
The macro "CouldRegister" in the state machine is defined as:
状態マシンのマクロ「登録」は、次のように定義されています。
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でのパケットの受信時に、keepAlivetimer（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.
概念的には、登録トンネルは、RPに向かう基礎となるIPインターフェイスよりも小さいMTUを持つインターフェイスです。登録トンネルに転送されたパケットのIP断片化は、この小さなMTUに基づいて実行されます。カプセル化DRは、RPにPATH 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はPATH MTU発見を実行する必要があり、ICMPパケットは、トンネルの効果的なMTUに収まらないパケットを受け取っている場合、カプセル化DRによって送信する必要があります。DRとRPの間のMTUの結果、有効トンネルMTUが1280（IPv6最小MTU）より小さい場合、DRは1280のMTU値で断片化が必要なメッセージを送信し、必要に応じてPIMレジスタメッセージを断片化する必要があります。外側IPv6ヘッダーとPIMレジスタヘッダーの間の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 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でのレジスタストップ（*、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は、すべてのゼロに設定されたソースアドレスでレジスタストップメッセージを送信する場合があります。これは、RPC 2362の通常のアクションコースであり、レジスタメッセージがRPで（*、g）状態と一致し、「このグループのすべてのソースをカプセル化する停止」と定義されました。ただし、このようなレジスターストップ（*、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はレジスタストップ（*、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.
レジスタストップ（*、g）は、noinfo状態にないすべての（s、g）レジスタステートマシンのレジスタストップ（s、g）として扱う必要があります。ルーターは、レジスタストップ（*、g）を受信した後にアクティブになるソースにレジスタストップ（*、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 ( register.borderbit == TRUE ) {
if ( PMBR(S,G) == unknown ) {
PMBR(S,G) = outer.src
} else if ( outer.src != PMBR(S,G) ) {
send Register-Stop(S,G) to outer.src
drop the packet silently.
}
}
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.
I_AM_RP（g）は、グループ間マッピングがこのルーターがグループのRPであることを示している場合に真です。
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が行われる前に新しいグループ間マッピングについて学んだ場合、Register_Suppression_TimeのSからのトラフィックをブロックする場合があります。ただし、RPがGのRPになっていることにまだ気付いていない場合、RPが参加する（*、g）を受け入れる方法を理解しない限り、これは問題ではありません。これはすべて一度整理されますRPは、新しいグループからRPへのマッピングを学習します。私たちはこれについて何もしないことを決め、RPの変更後にPIMが中断された（*、g）接続を受ける可能性があるという事実を受け入れることにしました。
Note (+): Implementations are advised not to make this a special case, but to 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.
注（）：実装は、これを特別なケースにするのではなく、このパスが通常のパケット転送パスに再加入することを手配することをお勧めします。セクション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.
keepalivetimer（s、g）は、パケットが適切なトンネルインターフェイスに到着し、RPがSPTに切り替えるか、SPTBitがすでに設定されている場合、RPで再起動されます。これにより、上流（s、g）状態マシンが、internited_olist（s、g）がnullでない場合に結合をトリガーする可能性があります。
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 * Regist_Suppression_Time）のレジスタメッセージに応じて作成された（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ビットは、レジスタパケットのIPヘッダーから脱カプセル化パケットにコピーする必要があります。
The Diffserv Code Point (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].
Diffservコードポイント（DSCP）は、レジスタパケットの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 (*,*,RP), (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メッセージの処理の場合、グループの結合または剪定された各ソースは、効果的に個別に考慮され、次の1つまたは複数の状態マシンに適用されます。上流の近隣アドレスフィールドがこのルーターをアドレス指定する結合メッセージを検討するとき、（*、g）結合し、プルーンは（*、g）および（s、g、rpt）下流の状態マシンの両方に影響を与えますが、（*、*、rp）、（s、g）、および（s、g、rpt）が結合し、プルーンはそれぞれの下流の状態マシンにのみ影響します。上流の近隣アドレスフィールドが別のルーターをアドレス指定する結合/プルーンメッセージを検討するとき、ほとんどの結合またはプルーンメッセージは各上流の状態マシンに影響を与える可能性があります。
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 using IPsec AH (see Section 6.3), then all Join/Prune messages from that neighbor MUST also be authenticated using IPsec AH.
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メッセージを誤って送信できないことに注意してください。したがって、このような古いルーターとの相互操作を可能にする構成オプションを提供することもお勧めしますが、この構成オプションはデフォルトで有効にするべきではないことをお勧めします。。
The per-interface state machine for receiving (*,*,RP) Join/Prune Messages is given below. There are three states:
受信（*、*、RP）結合/プルーンメッセージを受信するためのインターフェイス状態マシンを以下に示します。3つの状態があります。
NoInfo (NI) The interface has no (*,*,RP) Join state and no timers running.
noinfo（ni）インターフェイスには（*、*、rp）状態が結合されており、実行中のタイマーはありません。
Join (J) The interface has (*,*,RP) Join state, which will cause the router to forward packets destined for any group handled by RP from this interface except if there is also (S,G,rpt) prune information (see Section 4.5.4) or the router lost an assert on this interface.
[j）結合（j）インターフェイスには（*、*、rp）結合状態があります。これにより、ルーターは、（s、g、rpt）プルーン情報がある場合を除き、このインターフェイスからRPによって処理されたグループ用に運命づけられている任意のグループに向けられたパケットを転送します。セクション4.5.4を参照）またはルーターがこのインターフェイスでアサートを失いました。
Prune-Pending (PP) The router has received a Prune(*,*,RP) 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.
プルーンペンディング（PP）ルーターは、下流の隣人からこのインターフェイスにプルーン（*、*、*、RP）を受け取り、プルーンが別の下流ルーターによってオーバーライドされるかどうかを確認するのを待っています。転送のために、剪定状態は結合状態とまったく同じように機能します。
In addition, the state machine uses two timers:
さらに、状態マシンは2つのタイマーを使用しています。
ExpiryTimer (ET) This timer is restarted when a valid Join(*,*,RP) is received. Expiry of the ExpiryTimer causes the interface state to revert to NoInfo for this RP.
expirytimer（et）このタイマーは、有効な結合（*、*、RP）を受信したときに再起動されます。Expirytimerの有効期限は、このRPのインターフェイス状態がNOINFOに戻ります。
Prune-Pending Timer (PPT) This timer is set when a valid Prune(*,*,RP) is received. Expiry of the Prune-Pending Timer causes the interface state to revert to NoInfo for this RP.
プルーンペンディングタイマー（PPT）このタイマーは、有効なプルーン（*、*、RP）を受信したときに設定されます。プルーンペンディングタイマーの有効期限は、このRPのインターフェイス状態がNOINFOに戻ります。
Figure 2: Downstream per-interface (*,*,RP) state machine in tabular form
図2：interfaceごとの下流（*、*、RP）状態マシンの形式の状態マシン
+------------++--------------------------------------------------------+
| || Event |
| ++-------------+-------------+--------------+-------------+
|Prev State ||Receive | Receive | Prune- | Expiry Timer|
| ||Join(*,*,RP) | Prune | Pending | Expires |
| || | (*,*,RP) | 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(*,*,RP) | |
+------------++-------------+-------------+--------------+-------------+
The transition events "Receive Join(*,*,RP)" and "Receive Prune(*,*,RP)" 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.
トランジションイベントは、「Join（*、*、rp）を受信します」と「Prune（*、*、RP）を受信することを意味します。上流の隣接アドレスフィールドが正しくない場合、この状態マシンのこれらの状態遷移は発生してはなりませんが、そのようなパケットを見ると他の状態マシンの状態遷移が発生する可能性があります。
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 we also recommend that for backwards compatibility PIM Join/Prune messages with an upstream neighbor address field of all zeros are also accepted.
Transitions from NoInfo State
Noinfo州からの移行
When in NoInfo state, the following event may trigger a transition:
Noinfo州では、次のイベントが移行をトリガーする場合があります。
Receive Join(*,*,RP) A Join(*,*,RP) is received on interface I with its Upstream Neighbor Address set to the router's primary IP address on I.
JOIN（*、*、rp）を受信します（*、*、*、RP）は、I.のルーターの主要なIPアドレスに設定されたアップストリームネイバーアドレスを使用して、インターフェイスIで受信されます。
The (*,*,RP) 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.
（*、*、rp）インターフェイス上の下流の状態マシンIは、結合状態に移行します。Expiry Timer（ET）が開始され、トリガーJoin/PruneメッセージからHoldTimeに設定されます。
Note that it is possible to receive a Join(*,*,RP) message for an RP for which we do not have information telling us that it is an RP. In the case of (*,*,RP) state, so long as we have a route to the RP, this will not cause a problem, and the transition should still take place.
RPの参加（*、*、RP）メッセージを受け取ることができることに注意してください。（*、*、RP）状態の場合、RPへのルートがある限り、これは問題を引き起こすことはなく、遷移がまだ発生するはずです。
Transitions from Join State
When in Join state, the following events may trigger a transition:
参加状態にある場合、次のイベントが遷移をトリガーする場合があります。
Receive Join(*,*,RP) A Join(*,*,RP) is received on interface I with its Upstream Neighbor Address set to the router's primary IP address on I.
JOIN（*、*、rp）を受信します（*、*、*、RP）は、I.のルーターの主要なIPアドレスに設定されたアップストリームネイバーアドレスを使用して、インターフェイスIで受信されます。
The (*,*,RP) downstream state machine on interface I remains in Join state, and the Expiry Timer (ET) is restarted, set to maximum of its current value and the HoldTime from the triggering Join/Prune message.
（*、*、RP）インターフェイスIの下流の状態マシンIは、結合状態のままであり、有効期限タイマー（ET）が再起動され、現在の値の最大値とトリガーJON/PRUNEメッセージの保留タイムが設定されます。
Receive Prune(*,*,RP) A Prune(*,*,RP) is received on interface I with its Upstream Neighbor Address set to the router's primary IP address on I.
Prune（*、*、RP）Prune（*、*、RP）は、I.のルーターの主要なIPアドレスに設定されたアップストリームネイバーアドレスを使用して、インターフェイスIで受信されます。
The (*,*,RP) 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.
（*、*、rp）インターフェイス上の下流の状態マシンIは、プルーンペンディング状態に移行します。プルーンペンディングタイマーが開始されます。ルーターにそのインターフェイスに複数の隣接がある場合、j/p_override_interval（i）に設定されます。それ以外の場合は、ゼロに設定されているため、すぐに失効します。
Expiry Timer Expires The Expiry Timer for the (*,*,RP) downstream state machine on interface I expires.
Expiryタイマーは、（*、*、rp）下流の状態マシンの有効期限タイマーが期限切れになります。
The (*,*,RP) downstream state machine on interface I transitions to the NoInfo state.
（*、*、rp）インターフェイス上の下流の状態マシンIは、noinfo状態に遷移します。
Transitions from Prune-Pending State
剪定状態からの移行
When in Prune-Pending state, the following events may trigger a transition:
剪定状態では、次のイベントが遷移をトリガーする可能性があります。
Receive Join(*,*,RP) A Join(*,*,RP) is received on interface I with its Upstream Neighbor Address set to the router's primary IP address on I.
JOIN（*、*、rp）を受信します（*、*、*、RP）は、I.のルーターの主要なIPアドレスに設定されたアップストリームネイバーアドレスを使用して、インターフェイスIで受信されます。
The (*,*,RP) 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 is restarted, set to maximum of its current value and the HoldTime from the triggering Join/Prune message.
（*、*、rp）インターフェイス上の下流の状態マシンIは、結合状態に移行します。プルーンペンディングタイマーはキャンセルされます（有効期限イベントをトリガーすることなく）。有効期限タイマーは再起動され、現在の値の最大値とトリガーのJoin/Pruneメッセージから保留タイムが設定されます。
Expiry Timer Expires The Expiry Timer for the (*,*,RP) downstream state machine on interface I expires.
Expiryタイマーは、（*、*、rp）下流の状態マシンの有効期限タイマーが期限切れになります。
The (*,*,RP) downstream state machine on interface I transitions to the NoInfo state.
（*、*、rp）インターフェイス上の下流の状態マシンIは、noinfo状態に遷移します。
Prune-Pending Timer Expires The Prune-Pending Timer for the (*,*,RP) downstream state machine on interface I expires.
プルーンペンディングタイマーは、（*、*、RP）下流の状態マシンのプルーンペンディングタイマーが、私が期限切れにします。
The (*,*,RP) downstream state machine on interface I transitions to the NoInfo state. A PruneEcho(*,*,RP) is sent onto the subnet connected to interface I.
（*、*、rp）インターフェイス上の下流の状態マシンIは、noinfo状態に遷移します。PruneEcho（*、*、RP）がインターフェイスIに接続されたサブネットに送信されます。
The action "Send PruneEcho(*,*,RP)" is triggered when the router stops forwarding on an interface as a result of a prune. A PruneEcho(*,*,RP) is simply a Prune(*,*,RP) 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(*,*,RP) 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.
アクション「Send Pruneecho（*、*、rp）」は、プルーンの結果としてルーターがインターフェイス上で転送を停止するとトリガーされます。Pruneecho（*、*、RP）は、上流の隣接アドレスフィールドに独自のアドレスを持つ上流のルーターによって上流のルーターによって送信されたプルーン（*、*、RP）メッセージです。その目的は、他のルーターによってオーバーライドされていたプルーンがLAN上で局所的に失われるように、追加の信頼性を追加することです。PruneEcho（*、*、RP）は、この状態マシンがプルーンペンディング状態にあったときに、単一のPIM隣接のみを含むインターフェイスに送信する必要はありません。
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).
ルーターが結合（*、g）を受信する場合、最初にメッセージのRPがRP（g）（RPが誰であるかというルーターのアイデア）と一致するかどうかを確認する必要があります。メッセージのRPがRP（g）と一致しない場合、結合（*、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）結合/プルーンメッセージを受信するためのインターフェイスステートマシンを以下に示します。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.4) or the router lost an assert on this interface.
[j）結合（j）インターフェイスには（*、g）結合状態があります。これにより、ルーターはこのインターフェイスからgに導かれるパケットを転送します。または、ルーターがこのインターフェイスでアサートを失いました。
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.
プルーンペンディング（PP）ルーターは、下流の隣人からこのインターフェイスにプルーン（*、g）を受け取り、プルーンが別の下流ルーターによってオーバーライドされるかどうかを確認するのを待っています。転送のために、剪定状態は結合状態とまったく同じように機能します。
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）このタイマーは、有効な結合（*、g）が受信されたときに再起動されます。有効期限タイマーの有効期限は、このグループのインターフェイス状態が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.
プルーンペンディングタイマー（PPT）このタイマーは、有効なプルーン（*、g）を受信したときに設定されます。プルーンペンディングタイマーの有効期限は、このグループのインターフェイス状態がnoinfoに戻ります。
Figure 3: Downstream per-interface (*,G) state machine in tabular form
図3：interfaceごとの下流（*、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.
トランジションイベントは、「Join（*、g）を受信」および「受信Prune（*、G）」を意味します。上流の隣接アドレスフィールドが正しくない場合、この状態マシンのこれらの状態遷移は発生してはなりませんが、そのようなパケットを見ると他の状態マシンの状態遷移が発生する可能性があります。
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 we also recommend that for backwards compatibility PIM Join/Prune messages with an upstream neighbor address field of all zeros are also accepted.
ポイントツーポイントリンク上の番号のないインターフェイスでは、ルーターのアドレスは、そのインターフェイスに送信したハローメッセージで選択したソースアドレスと同じでなければなりません。ただし、ポイントツーポイントリンクでは、すべてのゼロの上流の近隣アドレスフィールドを使用して、後方互換性のPIM結合/プルーンメッセージも受け入れることをお勧めします。
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.
（*、g）インターフェイスIの下流の状態マシンは、結合状態に移行します。Expiry Timer（ET）が開始され、トリガーJoin/PruneメッセージからHoldTimeに設定されます。
Transitions from Join State
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, set to maximum of its current value and the HoldTime from the triggering Join/Prune message.
（*、g）インターフェイスIの下流の状態マシンIは結合状態に留まり、有効期限タイマー（ET）が再起動され、最大値の最大値とトリガーの結合/プルーンメッセージから保留タイムが設定されます。
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.
（*、g）インターフェイスIの下流の状態マシンは、プルーンペンディング状態に移行します。プルーンペンディングタイマーが開始されます。ルーターにそのインターフェイスに複数の隣接がある場合、j/p_override_interval（i）に設定されます。それ以外の場合は、ゼロに設定されているため、すぐに失効します。
Expiry Timer Expires The Expiry Timer for the (*,G) downstream state machine on interface I expires.
Expiryタイマーは、（*、g）ダウンストリーム状態マシンの有効期限が切れるインターフェイスの期限が切れます。
The (*,G) downstream state machine on interface I transitions to the NoInfo state.
Transitions from Prune-Pending State
剪定状態からの移行
When in Prune-Pending 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 transitions to the Join state. The Prune-Pending Timer is canceled (without triggering an expiry event). The Expiry Timer is restarted, set to maximum of its current value and the HoldTime from the triggering Join/Prune message.
（*、g）インターフェイスIの下流の状態マシンは、結合状態に移行します。プルーンペンディングタイマーはキャンセルされます（有効期限イベントをトリガーすることなく）。有効期限タイマーは再起動され、現在の値の最大値とトリガーのJoin/Pruneメッセージから保留タイムが設定されます。
Expiry Timer Expires The Expiry Timer for the (*,G) downstream state machine on interface I expires.
Expiryタイマーは、（*、g）ダウンストリーム状態マシンの有効期限が切れるインターフェイスの期限が切れます。
The (*,G) downstream state machine on interface I transitions to the NoInfo state.
（*、g）インターフェイスIの下流の状態マシンは、noinfo状態に移行します。
Prune-Pending Timer Expires The Prune-Pending Timer for the (*,G) downstream state machine on interface I expires.
プルーンペンディングタイマーは、（*、g）ダウンストリームステートマシンのプルーンペンディングタイマーが期限切れになります。
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.
（*、g）インターフェイスIの下流の状態マシンは、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.
アクション「Send Pruneecho（*、G）」は、プルーンの結果としてルーターがインターフェイス上で転送を停止するとトリガーされます。Pruneecho（*、g）は、上流の隣のアドレスフィールドに独自のアドレスを持つ上流のルーターによって上流のルーターによって送信されるプルーン（*、g）メッセージです。その目的は、他のルーターによってオーバーライドされていたプルーンがLAN上で局所的に失われるように、追加の信頼性を追加することです。Pruneecho（*、g）は、この状態マシンがプルーンペンディング状態にあったときに、単一の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）結合/プルーンメッセージのインターフェイス状態マシンを以下に示し、（*、g）メッセージの場合とほぼ同じです。3つの状態があります。
NoInfo (NI) The interface has no (S,G) Join state and no (S,G) timers running.
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）結合（j）インターフェイスには（s、g）がステートに結合します。これにより、（s、g）状態がアクティブである場合（sptbitが設定されている）場合、ルーターはこのインターフェイスから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.
プルーンペンディング（PP）ルーターは、下流の隣人からこのインターフェイスにプルーン（S、G）を受け取り、プルーンが別の下流ルーターによってオーバーライドされるかどうかを確認するのを待っています。転送のために、剪定状態は結合状態とまったく同じように機能します。
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）このタイマーは、有効な結合（s、g）を受信したときに設定されます。有効期限のあるタイマーの有効期限は、この状態マシンが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.
プルーンペンディングタイマー（PPT）このタイマーは、有効なプルーン（S、G）を受信したときに設定されます。プルーンペンディングタイマーの有効期限は、この状態マシンがNOINFO状態に戻ります。
Figure 4: Downstream per-interface (S,G) state machine in tabular form
図4：段階の下流のインターフェイス（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.
トランジションイベント「Join（S、G）を受信」および「受信Prune（S、G）」は、受信されたインターフェイス上のこのルーターのプライマリIPアドレスをターゲットにした結合またはプルーンを受信することを意味します。上流の隣接アドレスフィールドが正しくない場合、この状態マシンのこれらの状態遷移は発生してはなりませんが、そのようなパケットを見ると他の状態マシンの状態遷移が発生する可能性があります。
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 we also recommend that for backwards compatibility PIM Join/Prune messages with an upstream neighbor address field of all zeros are also accepted.
ポイントツーポイントリンク上の番号のないインターフェイスでは、ルーターのアドレスは、そのインターフェイスに送信したハローメッセージで選択したソースアドレスと同じでなければなりません。ただし、ポイントツーポイントリンクでは、すべてのゼロの上流の近隣アドレスフィールドを使用して、後方互換性のPIM結合/プルーンメッセージも受け入れることをお勧めします。
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）を受信します。結合（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.
（s、g）インターフェイス上の下流の状態マシンIは、結合状態に移行します。Expiry Timer（ET）が開始され、トリガーJoin/PruneメッセージからHoldTimeに設定されます。
Transitions from Join State
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）を受信します。結合（s、g）は、I.のルーターのプライマリIPアドレスに設定されたアップストリームネイバーアドレスを使用して、インターフェイスIで受信されます。
The (S,G) downstream state machine on interface I remains in Join state, and the Expiry Timer (ET) is restarted, set to maximum of its current value and the HoldTime from the triggering Join/Prune message.
（s、g）インターフェイスIの下流の状態マシンIは結合状態のままであり、有効期限タイマー（ET）が再起動され、最大値の最大値に設定され、トリガーJoin/Pruneメッセージから保留タイムが設定されます。
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.
（s、g）インターフェイス上の下流の状態マシンIは、プルーンペンディング状態に移行します。プルーンペンディングタイマーが開始されます。ルーターにそのインターフェイスに複数の隣接がある場合、j/p_override_interval（i）に設定されます。それ以外の場合は、ゼロに設定されているため、すぐに失効します。
Expiry Timer Expires The Expiry Timer for the (S,G) downstream state machine on interface I expires.
Expiryタイマーは、（s、g）下流の状態マシンの有効期限タイマーが、私が期限切れにします。
The (S,G) downstream state machine on interface I transitions to the NoInfo state.
（s、g）インターフェイスIの下流の状態マシンは、noinfo状態に移行します。
Transitions from Prune-Pending State
剪定状態からの移行
When in Prune-Pending 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）を受信します。結合（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 is restarted, set to maximum of its current value and the HoldTime from the triggering Join/Prune message.
（s、g）インターフェイス上の下流の状態マシンIは、結合状態に移行します。プルーンペンディングタイマーはキャンセルされます（有効期限イベントをトリガーすることなく）。有効期限タイマーは再起動され、現在の値の最大値とトリガーのJoin/Pruneメッセージから保留タイムが設定されます。
Expiry Timer Expires The Expiry Timer for the (S,G) downstream state machine on interface I expires.
The (S,G) downstream state machine on interface I transitions to the NoInfo state.
（s、g）インターフェイスIの下流の状態マシンは、noinfo状態に移行します。
Prune-Pending Timer Expires The Prune-Pending Timer for the (S,G) downstream state machine on interface I expires.
プルーンペンディングタイマーは、（s、g）ダウンストリームステートマシンのプルーンペンディングタイマーが期限切れになります。
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.
（s、g）インターフェイスIの下流の状態マシンは、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.
アクション「Send Pruneecho（S、G）」は、プルーンの結果としてルーターがインターフェイス上で転送を停止するとトリガーされます。Pruneecho（s、g）は、上流の隣接アドレスフィールドに独自のアドレスを持つ上流のルーターによって上流のルーターによって送信された単にプルーン（s、g）メッセージです。その目的は、他のルーターによってオーバーライドされていたプルーンがLAN上で局所的に失われるように、追加の信頼性を追加することです。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）の結合/プルーンメッセージのインターフェイスステートマシンを以下に示します。5つの州があります：
NoInfo (NI) The interface has no (S,G,rpt) Prune state and no (S,G,rpt) timers running.
noinfo（ni）インターフェイスには、no（s、g、rpt）プルーン状態があり、no（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）プルーン状態があります。これにより、インターフェイスがアクティブ（*、g）が接合されている場合でも、ルーターはこのインターフェイスからgの運命にあるSからパケットを転送しません。
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.
プルーンペンディング（PP）ルーターは、下流の隣人からこのインターフェイスにプルーン（S、G、RPT）を受け取り、プルーンが別の下流ルーターによってオーバーライドされるかどうかを確認するのを待っています。転送のために、剪定状態は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 a (S,G,rpt) prune, then we will revert to NoInfo state in this state machine.
PrunetMP（P '）この状態は、転送のためにプルーン状態とまったく同じように振る舞う一時的な状態です。（*、g）結合が受信されました（（s、g、rpt）プルーンをキャンセルする場合があります）。結合メッセージを上から下に解析するとき、メッセージに（*、g）結合が含まれている場合、最初にこの状態に入ります。メッセージの後半では、通常、プルーン状態を復活させるために（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 PP state.
Prune-Pending-TMP（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）このタイマーは、有効なプルーン（S、G、RPT）を受信したときに設定されます。有効期限のあるタイマーの有効期限は、この状態マシンが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.
プルーンペンディングタイマー（PPT）このタイマーは、有効なプルーン（S、G、RPT）を受信したときに設定されます。プルーンペンディングタイマーの有効期限は、この状態マシンが剪定状態に移行するようになります。
Figure 5: Downstream per-interface (S,G,rpt) state machine in tabular form
図5：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.
トランジションイベント「Join（S、G、RPT）を受信」、「Prune（S、G、RPT）を受信」、および「Join（*、G）を受信することを意味します。受信されたインターフェイスで。上流の隣接アドレスフィールドが正しくない場合、この状態マシンのこれらの状態遷移は発生してはなりませんが、そのようなパケットを見ると他の状態マシンの状態遷移が発生する可能性があります。
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 we also recommend that PIM Join/Prune messages with an upstream neighbor address field of all zeros are also accepted.
ポイントツーポイントリンク上の番号のないインターフェイスでは、ルーターのアドレスは、そのインターフェイスに送信したハローメッセージで選択したソースアドレスと同じでなければなりません。ただし、ポイントツーポイントリンクでは、すべてのゼロの上流の近隣アドレスフィールドを使用したPIMが結合/プルンメッセージを受け入れることもお勧めします。
Transitions from NoInfo State
Noinfo州からの移行
When in NoInfo (NI) state, the following event may trigger a transition:
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.
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 Prune-Pending-Tmp state whilst the remainder of the compound Join/Prune message containing the Join(*,G) is processed.
（s、g、rpt）インターフェース上の下流の状態マシンIは、プルーンペンディングTMP状態に遷移しますが、接合部（*、g）を含む化合物結合メッセージ/プルーンメッセージの残りの部分が処理されます。
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）を受信します。結合（s、g、rpt）は、上流の近隣アドレスがIのルーターのプライマリIPアドレスに設定されたインターフェイスIで受信されます。
The (S,G,rpt) downstream state machine on interface I transitions to NoInfo state. ET and PPT are canceled.
Prune-Pending Timer Expires The Prune-Pending Timer for the (S,G,rpt) downstream state machine on interface I expires.
プルーンペンディングタイマーは、（s、g、rpt）下流の状態マシンのプルーンペンディングタイマーが、私が有効にするインターフェイス上の下流の状態マシンの有効期限が切れます。
The (S,G,rpt) downstream state machine on interface I transitions to the Prune state.
（s、g、rpt）インターフェース上の下流の状態マシンIは、プルーン状態に移行します。
Transitions from Prune State
プルーン状態からの移行
When in Prune (P) state, the following events may trigger a transition:
Prune（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 PruneTmp state whilst the remainder of the compound Join/Prune message containing the Join(*,G) is processed.
（s、g、rpt）インターフェイス上の下流の状態マシンIは、プレーネット状態に移行しますが、接合された接合メッセージ/プルーンメッセージの残り（*、g）が処理されます。
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）を受信します。結合（s、g、rpt）は、上流の近隣アドレスがIのルーターのプライマリIPアドレスに設定されたインターフェイスIで受信されます。
The (S,G,rpt) downstream state machine on interface I transitions to NoInfo state. ET and PPT are canceled.
（s、g、rpt）インターフェイス上の下流の状態マシンIは、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, set to maximum of its current value and the HoldTime from the triggering Join/Prune message.
（s、g、rpt）インターフェイス上の下流の状態マシンIは、プルーン状態にとどまります。有効期限タイマー（ET）は再起動され、現在の値の最大値とトリガージャー/プルーンメッセージから保留タイムが設定されます。
Expiry Timer Expires The Expiry Timer for the (S,G,rpt) downstream state machine on interface I expires.
The (S,G,rpt) downstream state machine on interface I transitions to the NoInfo state.
（s、g、rpt）インターフェイス上の下流の状態マシンIは、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 '）状態で、化合物結合/Pruneメッセージを処理すると、次のイベントが遷移をトリガーする場合があります。
Receive Prune(S,G,rpt) The compound Join/Prune message contains a Prune(S,G,rpt).
PRUNE（S、G、RPT）を受信する化合物結合/プルーンメッセージには、プルーン（S、G、RPT）が含まれています。
The (S,G,rpt) downstream state machine on interface I transitions back to the Prune-Pending state. The Expiry Timer (ET) is restarted, set to maximum of its current value and the HoldTime from the triggering Join/Prune message.
（s、g、rpt）インターフェース上の下流の状態マシンIは、プルーンペンディング状態に戻ります。有効期限タイマー（ET）は再起動され、現在の値の最大値とトリガージャー/プルーンメッセージから保留タイムが設定されます。
End of Message The end of the compound Join/Prune message is reached.
メッセージの終了化合物の結合/プルーンメッセージの終わりに到達します。
The (S,G,rpt) downstream state machine on interface I transitions to the NoInfo state. ET and PPT are canceled.
（s、g、rpt）インターフェイス上の下流の状態マシンIは、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 '）状態で、化合物結合/プルーンメッセージを処理すると、次のイベントが遷移をトリガーする場合があります。
Receive Prune(S,G,rpt) The compound Join/Prune message contains a Prune(S,G,rpt).
PRUNE（S、G、RPT）を受信する化合物結合/プルーンメッセージには、プルーン（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, set to maximum of its current value and the HoldTime from the triggering Join/Prune message.
（s、g、rpt）インターフェイス上の下流の状態マシンIは、プルーン状態に戻ります。有効期限タイマー（ET）は再起動され、現在の値の最大値とトリガージャー/プルーンメッセージから保留タイムが設定されます。
End of Message The end of the compound Join/Prune message is reached.
メッセージの終了化合物の結合/プルーンメッセージの終わりに到達します。
The (S,G,rpt) downstream state machine on interface I transitions to the NoInfo state. ET is canceled.
（s、g、rpt）インターフェイス上の下流の状態マシンIは、noinfo状態に移行します。ETがキャンセルされます。
Notes:
ノート：
Receiving a Prune(*,G) does not affect the (S,G,rpt) downstream state machine.
プルーン（*、g）を受信しても、（s、g、rpt）下流の状態マシンには影響しません。
Receiving a Join(*,*,RP) does not affect the (S,G,rpt) downstream state machine. If a router has originated Join(*,*,RP) and pruned a source off it using Prune(S,G,rpt), then to receive that source again it should explicitly re-join using Join(S,G,rpt) or Join(*,G). In some LAN topologies it is possible for a router sending a new Join(*,*,RP) to have to wait as much as a Join/Prune Interval before noticing that it needs to override a neighbor's preexisting Prune(S,G,rpt). This is considered acceptable, as (*,*,RP) state is intended to be used only in long-lived and persistent scenarios.
結合（*、*、RP）を受信しても、（s、g、rpt）下流の状態マシンには影響しません。ルーターがJoin（*、*、RP）を発信し、Prune（S、G、RPT）を使用してソースを剪定した場合、そのソースを再度受信するには、Join（S、G、RPT）を使用して明示的に再結合する必要があります。または結合（*、g）。一部のLANトポロジでは、ルーターが新しい結合（*、*、RP）を送信して、隣人の既存のプルン（S、G、RPTをオーバーライドする必要があることに気付く前に、結合/プルーン間隔と同じくらい待つ必要があります。）。（*、*、RP）状態は、長命の永続的なシナリオでのみ使用されることを目的としているため、これは許容できると見なされます。
The per-interface state machines for (*,*,RP) hold join state from downstream PIM routers. This state then determines whether a router needs to propagate a Join(*,*,RP) upstream towards the RP.
（*、*、RP）のインターフェイス状態マシンは、下流のPIMルーターから結合状態を保持します。次に、この状態は、ルーターがRPに向かって上流の結合（*、*、RP）を伝播する必要があるかどうかを決定します。
If a router wishes to propagate a Join(*,*,RP) 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(*,*,RP) to the correct upstream neighbor, it should suppress its own Join(*,*,RP). If it sees a Prune(*,*,RP) to the correct upstream neighbor, it should be prepared to override that prune by sending a Join(*,*,RP) 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(*,*,RP) almost immediately.
ルーターが結合（*、*、RP）の上流の伝播を希望する場合、そのサブネット上の他のルーターからのアップストリームインターフェイスのメッセージを監視する必要があり、これらはその動作を変更する可能性があります。正しい上流の隣人に結合（*、*、RP）が表示される場合、独自の結合（*、*、RP）を抑制する必要があります。プルーン（*、*、rp）が正しい上流の隣人に表示される場合、Join（*、*、RP）をほぼすぐに送信して、そのプルーンをオーバーライドする準備をする必要があります。最後に、正しい上流の隣人の変更の生成ID（セクション4.3を参照）を確認した場合、上流の隣人が状態を失ったことを知っており、結合を送信して状態を更新する準備をする必要があります（*、*、RP）ほぼすぐに。
In addition, if the MRIB changes to indicate that the next hop towards the RP has changed, the router should prune off from the old next hop and join towards the new next hop.
The upstream (*,*,RP) state machine contains only two states:
上流（*、*、RP）状態マシンには、2つの状態のみが含まれています。
Not Joined The downstream state machines and local membership information do not indicate that the router needs to join the (*,*,RP) tree for this RP.
下流の状態マシンとローカルメンバーシップ情報に結合していないことは、このRPのルーターが（*、*、RP）ツリーを結合する必要があることを示していません。
Joined The downstream state machines and local membership information indicate that the router should join the (*,*,RP) tree for this RP.
下流の状態マシンに参加し、ローカルメンバーシップ情報は、このRPのルーターが（*、*、RP）ツリーを結合する必要があることを示しています。
In addition, one timer JT(*,*,RP) is kept that is used to trigger the sending of a Join(*,*,RP) to the upstream next hop towards the RP, NBR(RPF_interface(RP), MRIB.next_hop(RP)).
さらに、1つのタイマーJT（*、*、RP）が保持され、JON（*、*、RP）の送信をトリガーしてRP、NBR（RPF_INTERFACE（RP）、MRIBへの次の上流ホップにトリガーします。next_hop（rp））。
Figure 6: Upstream (*,*,RP) state machine in tabular form
+-------------------++-------------------------------------------------+
| || Event |
| Prev State ++-------------------------+-----------------------+
| || JoinDesired | JoinDesired |
| || (*,*,RP) ->True | (*,*,RP) ->False |
+-------------------++-------------------------+-----------------------+
| || -> J state | - |
| NotJoined (NJ) || Send Join(*,*,RP); | |
| || Set Join Timer to | |
| || t_periodic | |
+-------------------++-------------------------+-----------------------+
| Joined (J) || - | -> NJ state |
| || | Send Prune |
| || | (*,*,RP); Cancel |
| || | Join Timer |
+-------------------++-------------------------+-----------------------+
In addition, we have the following transitions, which occur within the Joined state:
さらに、結合された状態内で発生する次の遷移があります。
+----------------------------------------------------------------------+
| In Joined (J) State |
+-------------------+--------------------+-----------------------------+
| Timer Expires | See | See |
| | Join(*,*,RP) | Prune(*,*,RP) |
| | to MRIB. | to MRIB. |
| | next_hop(RP) | next_hop(RP) |
+-------------------+--------------------+-----------------------------+
| Send | Increase Join | Decrease Join |
| Join(*,*,RP); | Timer to | Timer to |
| Set Join Timer | t_joinsuppress | t_override |
| to t_periodic | | |
+-------------------+--------------------+-----------------------------+
+----------------------------------------------------------------------+
| In Joined (J) State |
+-----------------------------------+----------------------------------+
| NBR(RPF_interface(RP), | MRIB.next_hop(RP) GenID |
| MRIB.next_hop(RP)) | changes |
| changes | |
+-----------------------------------+----------------------------------+
| Send Join(*,*,RP) to new | Decrease Join Timer to |
| next hop; Send | t_override |
| Prune(*,*,RP) to old | |
| next hop; set Join Timer | |
| to t_periodic | |
+-----------------------------------+----------------------------------+
This state machine uses the following macro:
この状態マシンは、次のマクロを使用します。
bool JoinDesired(*,*,RP) {
if immediate_olist(*,*,RP) != NULL
return TRUE
else
return FALSE
}
JoinDesired(*,*,RP) is true when the router has received (*,*,RP) Joins from any downstream interface. Note that although JoinDesired is true, the router's sending of a Join(*,*,RP) message may be suppressed by another router sending a Join(*,*,RP) onto the upstream interface.
Joindesided（*、*、rp）は、ルーターが下流インターフェイスから受信した（*、*、RP）を受信した場合に当てはまります。Joindesined isは真ですが、RouterのJoin（*、*、RP）メッセージの送信は、別のルーターによって抑制される場合があります。
Transitions from NotJoined State
接続されていない状態からの移行
When the upstream (*,*,RP) state machine is in NotJoined state, the following event may trigger a state transition:
上流（*、*、rp）状態マシンがNotinged Stateにある場合、次のイベントが状態移行をトリガーする場合があります。
JoinDesired(*,*,RP) becomes True The downstream state for (*,*,RP) has changed so that at least one interface is in immediate_olist(*,*,RP), making JoinDesired(*,*,RP) become True.
joindesinedired（*、*、rp）がtrueになります（*、*、rp）の下流状態が変更され、少なくとも1つのインターフェイスがfirems_olist（*、*、rp）になり、Joindesided（*、*、rp）になります真実。
The upstream (*,*,RP) state machine transitions to Joined state. Send Join(*,*,RP) to the appropriate upstream neighbor, which is NBR(RPF_interface(RP), MRIB.next_hop(RP)). Set the Join Timer (JT) to expire after t_periodic seconds.
上流（*、*、RP）状態マシンが参加した状態に移行します。join（*、*、rp）を適切な上流の隣人に送信します。T_PERIODIC秒後には、Join Timer（JT）を期限切れに設定します。
Transitions from Joined State
参加した州からの移行
When the upstream (*,*,RP) state machine is in Joined state, the following events may trigger state transitions:
上流（*、*、RP）状態マシンが結合された状態にある場合、次のイベントは状態遷移を引き起こす可能性があります。
JoinDesired(*,*,RP) becomes False The downstream state for (*,*,RP) has changed so no interface is in immediate_olist(*,*,RP), making JoinDesired(*,*,RP) become False.
joindesinedired（*、*、rp）はfalse（*、*、rp）の下流状態が変更されているため、インターフェイスはintimper_olist（*、*、rp）にはありません。
The upstream (*,*,RP) state machine transitions to NotJoined state. Send Prune(*,*,RP) to the appropriate upstream neighbor, which is NBR(RPF_interface(RP), MRIB.next_hop(RP)). Cancel the Join Timer (JT).
上流（*、*、RP）状態マシンは、接続されていない状態に移行します。Prune（*、*、rp）を適切な上流の隣人（rpf_interface（rp）、mrib.next_hop（rp））に送信します。Join Timer（JT）をキャンセルします。
Join Timer Expires The Join Timer (JT) expires, indicating time to send a Join(*,*,RP)
JOIN TIMERの有効期限が切れるJION TIMER（JT）有効期限が切れ、Join（*、*、RP）を送信する時間を示します
Send Join(*,*,RP) to the appropriate upstream neighbor, which is NBR(RPF_interface(RP), MRIB.next_hop(RP)). Restart the Join Timer (JT) to expire after t_periodic seconds.
join（*、*、rp）を適切な上流の隣人に送信します。Join Timer（JT）を再起動して、t_periodic秒後に期限切れになります。
See Join(*,*,RP) to MRIB.next_hop(RP) This event is only relevant if RPF_interface(RP) is a shared medium. This router sees another router on RPF_interface(RP) send a Join(*,*,RP) to NBR(RPF_interface(RP), MRIB.next_hop(RP)). This causes this router to suppress its own Join.
The upstream (*,*,RP) state machine remains in Joined state.
上流（*、*、RP）状態マシンは、結合状態に残ります。
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を、このイベントをトリガーするJoin/PruneメッセージのT_SuppressedとHoldTimeの最小値とします。Join TimerがT_JOINSUPPRESS秒未満で期限切れに設定されている場合、T_JOINSUPPRESSの後に期限切れになるようにリセットします。Join TimerがT_JOINSUPPRESS秒以上に期限切れに設定されている場合は、変更しないままにしておきます。
See Prune(*,*,RP) to MRIB.next_hop(RP) This event is only relevant if RPF_interface(RP) is a shared medium. This router sees another router on RPF_interface(RP) send a Prune(*,*,RP) to NBR(RPF_interface(RP), MRIB.next_hop(RP)). As this router is in Joined state, it must override the Prune after a short random interval.
rpf_interface（rp）が共有媒体である場合にのみ、prune（*、*、rp）をmrib.next_hop（rp）に参照してください。このルーターは、rpf_interface（rp）で別のルーターを表示します。このルーターは結合された状態にあるため、短いランダム間隔の後にプルーンをオーバーライドする必要があります。
The upstream (*,*,RP) 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.
上流（*、*、RP）状態マシンは、結合状態に残ります。結合タイマーがT_OVERRIDE秒以上で期限切れに設定されている場合は、T_OVERRIDE秒後に期限切れになるようにリセットします。結合タイマーがT_OVERRIDE秒未満で期限切れに設定されている場合は、変更せずに残します。
NBR(RPF_interface(RP), MRIB.next_hop(RP)) changes A change in the MRIB routing base causes the next hop towards the RP to change.
NBR（RPF_INTERFACE（RP）、MRIB.NEXT_HOP（RP））MRIBルーティングベースの変更により、RPへの次のホップが変更されます。
The upstream (*,*,RP) state machine remains in Joined state. Send Join(*,*,RP) to the new upstream neighbor, which is the new value of NBR(RPF_interface(RP), MRIB.next_hop(RP)). Send Prune(*,*,RP) to the old upstream neighbor, which is the old value of NBR(RPF_interface(RP), MRIB.next_hop(RP)). Set the Join Timer (JT) to expire after t_periodic seconds.
上流（*、*、RP）状態マシンは、結合状態に残ります。nbr（rpf_interface（rp）、mrib.next_hop（rp））の新しい値である新しい上流の隣人にjoin（*、*、rp）を送信します。Prune（*、*、rp）を古い上流の隣人に送信します。これは、NBR（RPF_INTERFACE（RP）、MRIB.NEXT_HOP（RP）の古い値です。T_PERIODIC秒後には、Join Timer（JT）を期限切れに設定します。
MRIB.next_hop(RP) GenID changes The Generation ID of the router that is MRIB.next_hop(RP) changes. This normally means that this neighbor has lost state, and so the state must be refreshed.
mrib.next_hop（rp）genidは、mrib.next_hop（rp）の変更であるルーターの生成IDを変更します。これは通常、この隣人が状態を失ったことを意味するため、状態をリフレッシュする必要があります。
The upstream (*,*,RP) 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.
上流（*、*、RP）状態マシンは、結合状態に残ります。結合タイマーがT_OVERRIDE秒以上で期限切れに設定されている場合は、T_OVERRIDE秒後に期限切れになるようにリセットします。
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ルーターから結合状態を保持します。この状態は、ルーターがRPに向かって上流の結合（*、g）を伝播する必要があるかどうかを決定します。
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.
ルーターが結合（*、g）の上流の伝播を希望する場合、そのサブネット上の他のルーターからのアップストリームインターフェイス上のメッセージを監視する必要があり、これらはその動作を変更する可能性があります。正しい上流の隣人に結合（*、g）が表示される場合、それは独自の結合（*、g）を抑制する必要があります。正しい上流の隣人にプルーン（*、g）を見た場合、ほぼすぐに結合（*、g）を送信することにより、そのプルーンをオーバーライドする準備をする必要があります。最後に、正しい上流の隣人の変化の生成ID（セクション4.3を参照）を確認した場合、上流の隣人が状態を失ったことを知っており、ほぼすぐに結合（*、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.
a（*、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への次のホップが変更され、アップストリームインターフェイスが変更されたか、上流インターフェイスにアサート勝者がないことを示すためにMRIBが変更された場合、ルーターは古い次のホップから剪定し、新しい次のホップ。
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).
さらに、1つのタイマーJT（*、g）が保持され、RP、RPF '（*、G）に向けて上流の次のホップへの結合（*、g）の送信をトリガーします。
Figure 7: Upstream (*,G) state machine in tabular form
図7：上流（*、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:
さらに、結合された状態内で発生する次の遷移があります。
+----------------------------------------------------------------------+
| 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 OR
(JoinDesired(*,*,RP(G)) AND
AssertWinner(*, G, RPF_interface(RP(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.
Joindesidedired（*、g）は、ルーターが共有ツリー状態を使用してGのトラフィックを転送する原因となる転送状態を持っている場合に真です。Joindesinedは真ですが、ルーターの結合（*、g）メッセージの送信は、別のルーターによって抑制される場合があります。
Transitions from NotJoined State
接続されていない状態からの移行
When the upstream (*,G) state machine is in NotJoined state, the following event may trigger a state transition:
アップストリーム（*、g）状態マシンがNoted Stateにある場合、次のイベントが状態移行をトリガーする場合があります。
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).
Joindesinedired（*、g）は真実になります。マクロは（*、g）が真実になります。
The upstream (*,G) state machine transitions to 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）状態のマシンは、接続された状態に移行します。join（*、g）を適切な上流の隣人、rpf '（*、g）に送信します。T_PERIODIC秒後には、Join Timer（JT）を期限切れに設定します。
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).
The upstream (*,G) state machine transitions to NotJoined state. Send Prune(*,G) to the appropriate upstream neighbor, which is RPF'(*,G). Cancel the Join Timer (JT).
上流（*、g）状態マシンは、接続されていない状態に移行します。Prune（*、g）を適切な上流の隣人に送信します。これはrpf '（*、g）です。Join Timer（JT）をキャンセルします。
Join Timer Expires The Join Timer (JT) expires, indicating time to send a Join(*,G)
JOIN TIMERは、Join Timer（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）に送信します。Join Timer（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.
rpf_interface（rp（g））が共有媒体である場合にのみ、このイベントはrpf '（*、g）からrpf'（*、g）を参照してください。このルーターは、rpf_interface（rp（g））に別のルーターを表示します。これにより、このルーターは独自の結合を抑制します。
The upstream (*,G) state machine remains in Joined state.
上流（*、g）状態マシンは、結合状態に残ります。
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を、このイベントをトリガーするJoin/PruneメッセージのT_SuppressedとHoldTimeの最小値とします。Join TimerがT_JOINSUPPRESS秒未満で期限切れに設定されている場合、T_JOINSUPPRESSの後に期限切れになるようにリセットします。Join Timerが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.
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）状態マシンは、結合状態に残ります。結合タイマーが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)).
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）状態マシンは、結合状態に残ります。結合タイマーが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ルーティングデータベースまたはグループ間マッピングの変更によって引き起こされる場合があります。アサートがアクティブであり、アップストリームインターフェイスが変更されない場合、この遷移は発生しないことに注意してください。
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 spec). Set the Join Timer (JT) to expire after t_periodic seconds.
上流（*、g）状態マシンは、結合状態に残ります。join（*、g）を新しい上流の隣人に送信します。これは、RPF '（*、g）の新しい値です。Prune（*、g）を古い上流の隣人に送信します。これはRPFの古い値です（*、g）。Rp（g）が不明になった場合、Prune（*、G）メッセージまたはすべてのゼロでRP（G）の新しい値（G）を使用します（代わりにRP（g）の古い値を使用して、この古いバージョンを実装するルーターの動作を改善するために使用できます。仕様）。T_PERIODIC秒後には、Join Timer（JT）を期限切れに設定します。
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）遺伝子は、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）状態マシンは、結合状態に残ります。結合タイマーが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ルーターから結合状態を保持します。次に、この状態は、ルーターがソースに向かって上流に結合（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.
ルーターが結合（s、g）の上流の伝播を希望する場合、そのサブネット上の他のルーターからのアップストリームインターフェイスのメッセージを監視する必要があり、これらはその動作を変更する可能性があります。正しい上流の隣人に結合（s、g）が表示される場合、独自の結合（s、g）を抑制する必要があります。プルーン（s、g）、プルーン（s、g、rpt）、またはプルーン（*、g）が正しい上流の隣人にsに向かっていることがある場合、結合をスケジュールすることでプルーンを上書きする準備をする必要があります（s、g）ほぼすぐに送信されます。最後に、上流の隣人の変化の生成IDが表示された場合、上流の隣人が状態を失ったことを知っており、ほぼすぐに送信される参加（s、g）をスケジュールすることで状態を更新するはずです。
If a (S,G) Assert occurs on the upstream interface, and this changes the 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.
a（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）が保持され、s、rpf '（s、g）に向けて上流のホップへの結合（s、g）の送信をトリガーします。
Figure 8: Upstream (S,G) state machine in tabular form
+-------------------+--------------------------------------------------+
| | 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:
さらに、結合された状態内で発生する次の遷移があります。
+----------------------------------------------------------------------+
| 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.
Transitions from NotJoined State
接続されていない状態からの移行
When the upstream (S,G) state machine is in NotJoined state, the following event may trigger a state transition:
上流（s、g）状態マシンがNoted Stateにある場合、次のイベントが状態の移行をトリガーする可能性があります。
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).
The upstream (S,G) state machine transitions to 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）状態が州に移行します。join（s、g）を適切な上流の隣人に送信します。これはrpf '（s、g）です。T_PERIODIC秒後には、Join Timer（JT）を期限切れに設定します。
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).
joindesinedired（s、g）はfalseになります。マクロは（s、g）がfalseになります。
The upstream (S,G) state machine transitions to 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）状態マシンは、接続されていない状態に移行します。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)
JOIN TIMERはJoin Timer（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）です。Join Timer（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.
rpf_interfaceが共有媒体である場合にのみ、このイベントはrpf '（s、g）からrpf'（s、g）を参照してください。このルーターは、rpf_interfaceで別のルーターを表示します（s）rpf '（s、g）に結合（s、g）を送信します。これにより、このルーターは独自の結合を抑制します。
The upstream (S,G) state machine remains in Joined state.
上流（s、g）状態マシンは、結合された状態に残ります。
Let t_joinsuppress be the minimum of t_suppressed and the HoldTime from the Join/Prune message triggering this event.
t_joinsuppressを、このイベントをトリガーするJoin/PruneメッセージのT_Suppressedと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.
Join TimerがT_JOINSUPPRESS秒未満で期限切れに設定されている場合、T_JOINSUPPRESSの後に期限切れになるようにリセットします。Join Timerが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.
RPF_INTERFACEが共有メディアである場合にのみ、Prune（S、G）からRPF '（S、G）を参照してください。このルーターは、rpf_interfaceで別のルーターを表示します（s）rpf '（s、g）にプルーン（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）状態マシンは、結合された状態に残ります。結合タイマーが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.
RPF_INTERFACEが共有媒体である場合にのみ、Prune（S、G、RPT）からRPF '（S、G）を参照してください。このルーターは、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）状態マシンは、結合された状態に残ります。結合タイマーが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.
RPF_INTERFACEが共有メディアである場合にのみ、Prune（*、g）からRPF '（s、g）を参照してください。このルーターは、rpf_interfaceで別のルーターを表示します（*、g）をRPF '（s、g）に送信します。上流のルーターがRFC-2362に準拠したPIMルーターである場合、プルーン（*、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）状態マシンは、結合された状態に残ります。結合タイマーが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）状態マシンは、結合された状態に残ります。結合タイマーが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）状態マシンは、結合された状態に残ります。rpf '（s、g）の新しい値である新しい上流の隣人に巻き（s、g）を送信します。Prune（s、g）を古い上流の隣人に送信します。これはRPF '（s、g）の古い値です。T_PERIODIC秒後には、Join Timer（JT）を期限切れに設定します。
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）遺伝子は、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）状態マシンは、結合された状態に残ります。結合タイマーが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ツリーに送信された（s、g）結合またはプルーンが結合またはプルーンが送信されます。上流のLANピア。次のセクションでは、トリガーされたメッセージを送信するためのルールについて説明します。このセクションでは、Join（*、G）を備えたPrune（S、G、RPT）メッセージを含めるためのルールについて説明します。
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:
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) or (*,*,RP) 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）または（*、*、rp）がルーターで状態を結合し、ルーターまたは任意の場合に状態を結合する場合、（s、g）トリガーメッセージが必要です。その上流のLANピアは、RPツリーからSを剪定したいと考えています。
There are three states in the state machine. One of the states is when there is neither (*,G) nor (*,*,RP(G)) join state at this router. If there is (*,G) or (*,*,RP(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）または（*、*、rp（g））に参加していない場合です。（*、g）または（*、*、rp（g））がルーターに状態がある場合、状態マシンは他の2つの状態のいずれかにある必要があります。3つの州は次のとおりです。
Pruned(S,G,rpt)
(*,G) or (*,*,RP(G)) Joined, but (S,G,rpt) pruned
NotPruned(S,G,rpt)
(*,G) or (*,*,RP(G)) Joined, and (S,G,rpt) not pruned
RPTNotJoined(G) neither (*,G) nor (*,*,RP(G)) has been joined.
rptnotjoined（g）（*、g）も（*、*、rp（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）があります。これは、トリガーされた結合（s、g、rpt）メッセージを遅延させるために使用され、トリガーメッセージの崩壊を防ぐために使用されます。
Figure 9: Upstream (S,G,rpt) state machine for triggered messages in tabular form
図9：表形式でトリガーされたメッセージ用の上流（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.
さらに、剪定されていない（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) OR JoinDesired(*,*,RP(G)))
}
RPTJoinDesired(G) is true when the router has forwarding state that would cause it to forward traffic for G using either (*,G) or (*,*,RP) shared tree state.
RPTJOINDESIRED（g）は、ルーターが転送状態を持っている場合に真です。
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）は、rptjoindesidedired（g）が真である場合にのみ真です。rptjoindeSired（g）が真である場合、sが転送される発信インターフェイスがない場合、またはルーターにアクティブ（s、g）転送状態がある場合、RPF '（rpf'）の場合、prunedesired（s、g、rpt）が真実です（*、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）から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）への結合（s、g、rpt）を見ます。これは正しい上流の隣接です。私たちが「プルーニングされていない」状態にあり、（s、g、rpt）オーバーライドタイマーが実行されている場合、これは私たちが自分の参加（s、g、rpt）をrpf '（s、gに送信するようにトリガーされたためです。、rpt）。他の誰かが私たちを打ち負かしたので、私たち自身の参加を送る必要はありません。
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）からRPF '（S、G、RPT）を参照してください。
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.
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 noone else has sent a Join, then we will do so.
アクションは、（s、g、rpt）のオーバーライドタイマーをランダム化されたプルーンオーバーライド間隔、t_overrideに設定することです。ただし、Overrideタイマーが既に実行されている場合、タイマーを設定すると、それがより低い値に設定された場合にのみ設定します。この間隔の終わりに、他の誰も参加していない場合は、そうします。
See Prune(S,G) to RPF'(S,G,rpt) This event is only relevant in the "NotPruned" state.
Prune（S、G）からRPF '（S、G、RPT）を参照してください。このイベントは、「装備されていない」状態でのみ関連しています。
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 RFC2362 that don't maintain separate (S,G) and (S,G,rpt) state.
The (S,G,rpt) prune Override Timer expires This event is only relevant in the "NotPruned" state.
（s、g、rpt）プリューンオーバーライドタイマーは、このイベントの有効期限が切れます。「非プルーヌ」状態でのみ関連しています。
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) or (*,*,RP(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）に送信して、タイマーが実行される原因となったプルーンメッセージをオーバーライドする必要があります。rpf '（s、g、rpt）がrpf'（*、g）に等しい場合にのみこれを送信します。そうでない場合、結合は（*、g）または（*、*、rp（g））結合状態を持たないルーターに送信される可能性があるため、動作は十分に定義されません。rpf '（s、g、rpt）がrpf'（*、g）と同じでない場合、Sを転送するのを停止する可能性がありますが、これが発生した場合、ルーターはアサートキャンセル（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）に等しくなるように変更されます。
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）とは異なる可能性があります。G、RPT）はRPF '（*、g）に送信されます。rpf '（s、g、rpt）がRPF'（*、g）に等しくなるように変更される場合、routerを起動するために、結合（s、g、rpt）をrpf '（*、g）にトリガーする必要があります再び転送。
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 noone 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) or Join(*,*,RP).
ルーターが以前にプルーニングされていない状態にあった場合、アクションはプルーン（s、g、rpt）をRPF '（s、g、rpt）に送信し、オーバーライドタイマーをキャンセルすることです。ルーターが以前にrptNotjoined（g）状態であった場合、プルーン（s、g、rpt）を送信することは、結合（*、g）を送信するためのルールによって処理されるため、この状態マシンでアクションをトリガーする必要はありません。または結合（*、*、rp）。
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".
ルーターが剪定された（s、g、rpt）状態にある場合、および剪定された（s、g、rpt）falsに変更された場合、これはルーターがもはやrptjoindesidedired（g）trueを持っていないか、今では受け取りたいと思う可能性があります再びSからのトラフィック。前者の場合、この遷移は発生するのではなく、代わりに「rptjoindeSired（g） - > false」遷移が発生するはずです。したがって、この遷移は、「s、g、rpt） - > falseおよび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このイベントは、「剪定された」および「編集されていない」状態に関連しています。
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) or (*,*,RP).
ルーターは、RPツリー上のGのトラフィックを受け取ることを望んでいません。これにより、RPTNOTに合わせた（g）状態への移行が発生し、Overrideタイマーが実行されている場合はキャンセルされます。それ以上のアクションは、（*、g）または（*、*、rp）の適切な上流の状態マシンによって処理されます。
inherited_olist(S,G,rpt) becomes non-NULL This transition is only relevant in the RPTNotJoined(G) state.
internited_olist（s、g、rpt）は非ヌルになります。
The router has joined the RP tree (handled by the (*,G) or (*,*,RP) 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）または（*、*、*、RP）上流のマシンによって処理されたRPツリーに参加しており、Sからトラフィックを受け取りたいと考えています。非プルーネド（s、g、rpt）状態への移行を引き起こします。
In Sections 4.5.8 and 4.5.9, the mechanisms for sending periodic and triggered (S,G,rpt) messages are described. The astute reader will note that periodic Prune(S,G,rpt) messages are only sent in PIM Join/Prune messages containing a Join(*,G), whereas it is possible for a triggered Prune(S,G,rpt) message to be sent when the router has no (*,G) join state. This may seem like a contradiction, but in fact it is intentional and is a side effect of not optimizing (*,*,RP) behavior.
セクション4.5.8および4.5.9では、周期的およびトリガーされた（S、G、RPT）メッセージを送信するメカニズムについて説明します。Astute Readerは、定期的なPrune（S、G、RPT）メッセージは、結合（*、G）を含むPIM Join/Pruneメッセージでのみ送信されることに注意してください。ルーターに（*、g）が状態になっていない場合に送信されます。これは矛盾のように思えるかもしれませんが、実際には意図的であり、最適化（*、*、RP）の動作をしない副作用です。
We first note that reception of a Join(*,*,RP) by itself does not cancel (S,G,rpt) prune state on that interface, whereas receiving a Join(*,G) by itself does cancel (S,G,rpt) prune state on that interface. Similarly, reception of a Prune(*,G) on an interface with (*,*,RP) join state does not by itself prevent forwarding of G using the (*,*,RP) state; this is because a Prune(*,G) only serves to cancel (*,G) join state. Conceptually (*,*,RP) state functions "above" the normal (*,G) and (S,G) mechanisms, and so neither Join(*,*,RP) nor Prune(*,*,RP) messages affect any other state.
最初に、Join（*、*、RP）の受信自体がそのインターフェイスで（S、G、RPT）プルーン状態をキャンセルしないのに対し、結合（*、g）を受信するとキャンセル（S、G）がキャンセルすることに注意してください。、rpt）そのインターフェイスのプルーン状態。同様に、（*、*、rp）結合状態とのインターフェイスでのプルーン（*、g）の受信は、（*、*、rp）状態を使用したgの転送を防ぐことはできません。これは、プルーン（*、g）がキャンセル（*、g）にのみ状態のみに役立つためです。概念的に（*、*、rp）状態は、「上記」の「上記」「*、g）および（s、g）メカニズムを「上記」にしているため、結合（*、*、rp）もプルーン（*、*、rp）メッセージは影響しません。他の状態。
The upshot of this is that to prevent forwarding (S,G) on (*,*,RP) state, a Prune(S,G,rpt) must be used.
We also note that for historical reasons there is no Assert(*,*,RP) message, so any forwarding contention is resolved using Assert(*,G) messages.
また、歴史的な理由で、アサート（*、*、RP）メッセージはないため、転送競合はASST（*、g）メッセージを使用して解決されることに注意してください。
We now need to consider the interaction between (*,*,RP) state and (*,G) state. If there is a need for an assert between two upstream routers on a LAN, we need to ensure that the correct thing happens for all combinations of (*,*,RP) and (*,G) forwarding state. As there is no Assert(*,*,RP) message, no router can tell whether the assert winner has (*,*,RP) state or (*,G) state. Thus, a downstream router has to treat the two the same and send its periodic Prune(S,G,rpt) messages to RPF'(*,G).
ここで、（*、*、rp）状態と（*、g）状態間の相互作用を考慮する必要があります。LAN上の2つの上流ルーター間でアサートが必要な場合、（*、*、rp）と（*、g）転送状態のすべての組み合わせで正しいことが起こることを確認する必要があります。アサート（*、*、rp）メッセージがないため、アサート勝者が（*、*、rp）状態を持っているか（*、g）状態を持っているかどうかをルーターは知ることができません。したがって、下流のルーターは、2つを同じで処理し、周期的なプルーン（s、g、rpt）メッセージをrpf '（*、g）に送信する必要があります。
To avoid needing to specify all the complex override rules between (*,*,RP), (*,G), and (S,G,rpt), we simply require that to prune (S,G) off the (*,*,RP) tree, a Join(*,G) must also be sent.
（*、*、rp）、（*、g）、および（s、g、rpt）の間のすべての複雑なオーバーライドルールを指定する必要がないようにするために、（*、g）を（*、g）除去する必要があります。*、rp）ツリー、結合（*、g）も送信する必要があります。
If a router is receiving on (*,*,RP) state and has not yet had (*,G) state instantiated, it may still need to send a triggered Join(S,G,rpt) to override a Prune(S,G,rpt) that it sees directed to RPF'(*,G) on its upstream interface. Hence, triggered (S,G,rpt) messages may be sent when JoinDesired(*,G) is false but JoinDesired(*,*,RP) is true.
ルーターが（*、*、rp）状態で受信されており、まだ（*、g）状態がインスタンス化されていない場合、プルーンをオーバーライドするためにトリガーされた結合（s、g、rpt）を送信する必要がある場合があります（s、g、rpt）上流インターフェイスでRPF '（*、g）に向けられていると見ています。したがって、joindesinedired（*、g）が虚偽であるが、joindesided（*、*、rp）が真である場合、トリガーされた（s、g、rpt）メッセージは送信される場合があります。
Finally, we note that there is an unoptimized case when the upstream router on a LAN already has (*,G) join and (S,G,rpt) prune state caused by an existing downstream router. If at this time a new Join(*,*,RP) is sent to the upstream router from a different downstream router, this will not override the (S,G,rpt) prune state at the upstream router. The override will not occur until the next time the original downstream router resends its Prune(S,G,rpt). This case was not considered worth optimizing, as (*,*,RP) state is generally very long lived, and so any minor delays in getting traffic to a new PMBR seem unimportant.
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上の下流のルーターによっても受信され、これらはその後の結合/プルーンメッセージをアサートを獲得した上流のルーターに送信します。
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 using the IPsec Authentication Header (AH) (see Section 6.3), then all Assert messages from that neighbor MUST also be authenticated using IPsec AH.
一般に、PIMアサートメッセージは、既知のPIM隣接からの場合にのみ、処理に受け入れられる必要があります。PIMルーターは、PIM Helloメッセージを介してPim Neighborsについて聞きます。ルーターが特定のIPソースアドレスからアサートメッセージを受信し、そのソースアドレスからPIM Helloメッセージが表示されていない場合、アサートメッセージはさらに処理せずに破棄する必要があります。さらに、隣人からのHelloメッセージがIPSEC認証ヘッダー（AH）を使用して認証された場合（セクション6.3を参照）、その隣人からのすべてのアサートメッセージもIPSEC AHを使用して認証する必要があります。
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メッセージを誤って送信できないことに注意してください。したがって、このような古いルーターとの相互操作を可能にする構成オプションを提供することもお勧めしますが、この構成オプションはデフォルトで有効にするべきではないことをお勧めします。。
The (S,G) Assert state machine for interface I is shown in Figure 10. There are three states:
（s、g）インターフェースIのアサートステートマシンを図10に示します。3つの状態があります。
NoInfo (NI) This router has no (S,G) assert state on interface I.
noinfo（ni）このルーターには、インターフェイスIにno（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).
私は、このルーターがインターフェイスIで（s、g）アサートを獲得したことをアサートしました（w）インターフェースIの運命にあるトラフィックをインターフェースIに向けて転送する責任があります。ルーターはアサートの勝者であり、Iのローカルホストに代わってトラフィックを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）アサートを失いました。それはgに導かれたパケットをインターフェースIに転送してはなりません。Iにトラフィックを転送して、Sおよび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.
Figure 10: Per-interface (S,G) Assert State machine in tabular form
図10：インターフェイスごと（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 |
| and | (S,G,I) | (S,G,I) | and AssTrDes |
| CouldAssert | | | (S,G,I) |
| (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(*,*,RP(G)) (+) 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.
CanAssert（S、G、I）は、（S、G）がAssert情報が考慮されていない場合、ensuleited_olist（s、g）にある下流インターフェイスに当てはまります。
AssertTrackingDesired(S,G,I) =
(I in ( ( joins(*,*,RP(G)) (+) 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 our behavior.
AssertTrackingDesired（s、g、i）は、（s、g）アサートが私たちの動作に影響を与える可能性のあるインターフェイスで真です。
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.
（s、g）の4行目は、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行目は（s、g）Iのローカルメンバーシップ情報を説明します。Pim_include（s、g）マクロはlose_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 AND CouldAssert(S,G,I)==TRUE 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 beat (*,G) asserts, and so we should be the assert winner. We transition to the "I am Assert Winner" state and perform Actions A1 (below).
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's 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).
rptbitセットでアサートを受信し、canastert（s、g、i）== true rpt bit set（a（*、g）assert）を使用してiに対して（s、g）のアサートを受信します。CanAssert（s、g、i）は、このインターフェイスに（s、g）転送状態を持っている場合にのみ真です。「I Am Arsert Winner」状態に移行し、アクションA1（以下）を実行します。
An (S,G) data packet arrives on interface I, AND CouldAssert(S,G,I)==TRUE An (S,G) data packet arrived on an 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に到着し、可能性（s、g、i）== true an（s、g）データパケットが（s、g）発信インターフェイスリストにある下流インターフェイスに到着しました。私たちは楽観的に、私たちはこれ（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で許容可能なアサートを受け取ります。、g）転送状態、または私はSの上流インターフェイスであり、（s、g）転送状態があるためです。受け取ったアサートは私たち自身よりも優れたメトリックを持っているので、私たちはアサートに勝ちません。「私は敗者を主張している」に移行し、アクション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 Arsert 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）アサートタイマーの有効期限が切れます。私たちは勝者の状態にあるので、積極的に生き続けている状態（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、g）assertまたは（*、g）assert assert言及を受け取ります。アサートを送信した人は誤っているので、（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）アサートを受け取ります。「私は敗者をアサート」状態に移行し、アクションA2を実行します（以下）。これは、上流（s、g、rpt）のジョインドデザイン（s、g）とprunedesiredired（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.
canassert（s、g、i） - > false（s、g）転送状態またはrpfインターフェイスが変更され、可能性（s、g、i）がfalseになります。アサート勝者のアクションを実行できなくなるため、Noinfo Stateに移行し、アクションA4（以下）を実行します。これには、無限のメトリックで「キャンセルアサート」を送信することが含まれます。
Transitions from "I am Assert Loser" State
「I Am Arsert Loser」州からの移行
When in "I am Assert Loser" state, the following transitions can occur:
「私は敗者をアサートする」状態で、次の移行が発生する可能性があります。
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 it no longer knows it was the winner. We transition to the NoInfo state, deleting this (S,G) assert information (Actions A5 below).
現在の勝者の遺伝子の変更またはNLTは、現在の勝者に関連付けられているNeighbor Livensionタイマーの有効期限が切れるか、現在の勝者から以前に報告した遺伝子とは異なる遺伝子を報告する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 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.
私のメトリックは、Assert WinnerのME_ASSERT_METRIC（s、g、i）が変更されたため、現在のアサート勝者のために保存したメトリックよりも優れているようになりました。これは、基礎となるルーティングメトリックが変更された場合、またはAssert（S、G、I）が真実になったときに発生する可能性があります。たとえば、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.
インターフェイスでJoin（S、G）を受信します。インターフェイスIでプライマリIPアドレスに設定されているアップストリームネイバーアドレスフィールドを備えたJOIN（S、G）を受け取ります。g）状態（以下のアクションA5）をアサートし、通常のPIM結合/プルーンメカニズムを動作させます。結合を送信した人が誤っている場合、通常のアサートメカニズムは最終的に再適用され、再びアサートを失います。しかし、アサートを送った人は誰でも、以前のアサートの勝者が死亡したことを知っているかもしれないので、私たちは新しいフォワーダーになる可能性があります。
(S,G) Assert State machine Actions
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タイマーを（assert_time -assert_override_interval）に設定します。AssertWinner（s、g、i）として自己保存します。spt_assert_metric（s、i）をassertwinmetric（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）として新しいアサート受賞者を保存し、AssertWinMetric（S、G、I）として勝者メトリックをアサートします。ASSERT_TIMEにアサートタイマーを設定します。
A3: Send Assert(S,G). Set Assert Timer to (Assert_Time - Assert_Override_Interval).
A3：Assert（S、G）を送信します。Assertタイマーを（assert_time -assert_override_interval）に設定します。
A4: Send AssertCancel(S,G). Delete assert info (AssertWinner(S,G,I) and AssertWinnerMetric(S,G,I) will then return their default values).
A4：AssertCancel（S、G）を送信します。Assert Info（AssertWinner（s、g、i）およびassertwinnermetric（s、g、i）を削除し、デフォルト値を返します）。
A5: Delete assert info (AssertWinner(S,G,I) and AssertWinnerMetric(S,G,I) will then return their default values).
A5：Assert Info（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) == true) set SPTbit(S,G) to TRUE.
A6：AssertWinner（S、G、I）として新しいアサート受賞者を保存し、AssertWinMetric（S、G、I）として勝者メトリックをアサートします。ASSERT_TIMEにアサートタイマーを設定します。if（i is rpf_interface（s））および（upstreamjpstate（s、g）== true）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.
これらのアクションの一部は、Joindesidedired（S、G）、Prunedesired（S、G、RPT）、またはRPF '（S、G）の値を変更し、他の州のマシンのさらなる遷移を引き起こす可能性があることに注意してください。
The (*,G) Assert state machine for interface I is shown in Figure 11. There are three states:
（*、g）インターフェイスIのアサートステートマシンを図11に示します。3つの状態があります。
NoInfo (NI) This router has no (*,G) assert state on interface I.
noinfo（ni）このルーターには、インターフェイスIにno（*、g）アサート状態があります。
I am Assert Winner (W) This router has won an (*,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.
私は、このルーターがインターフェイスIで（*、g）アサートを獲得したことを主張しています。これは、それが持っているトラフィックを除いて、gのためのトラフィックをインターフェイスIに転送する責任があります（s、g）」私は敗者を主張しています。IのDRであるかどうかに関係なく、I IのローカルホストからGのメンバーシップリクエストを処理する責任もあります。
I am Assert Loser (L) This router has lost an (*,G) assert on interface I. It must not forward packets for G onto interface I with the exception of traffic from sources for which is 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）アサートを失いましたIインターフェイスIにgのパケットを転送してはなりません。Am Assert Winner "State。それがDRである場合、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）もあります。
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.
アサートメッセージがゼロ以外のソースアドレスで受信される場合、PIMの実装は、アサートメッセージが一致するかどうかを検討する前に、（s、g）の可能なイベントと（s、g）アサートマシンの可能なイベントと一致させる必要があります。（*、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のアサート状態マシンが「noinfo」状態にある場合を除き、アサートメッセージを受信した結果として、（*、g）状態マシンで移行が発生しないことに注意することが重要です。（s、g）状態マシンがメッセージを処理した後。また、そのメッセージが（s、g）状態マシンの状態の変更をトリガーした場合、アサートメッセージを受信した結果として、（*、g）状態マシンでは移行は発生しません。明らかに、受信したメッセージのソースアドレスがゼロに設定されている場合、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）の両方のアサート状態マシンが、アサートメッセージが届き、メッセージが（s、g）状態マシンに「w」に移行する（s、g）状態マシンを引き起こす場合、noinfo状態にある場合または「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）アサート状態マシンはNoInfo状態に移行します。そのような場合、（*、g）アサート状態マシンがnoinfo状態にある場合、それは「w」状態に移行するように見えるかもしれませんが、このメッセージはすでに（sの遷移をトリガーしているため、そうではありません。、g）アサートステートマシン。
Figure 11: Per-interface (*,G) Assert State machine in tabular form
図11：インターフェイスごと（*、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) or |
| FALSE | Winner's | being I | Join |
| | metric | | (*,*,RP(G)) on |
| | | | Interface I |
+----------------+----------------+-----------------+------------------+
| -> 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(*,*,RP(G)) (+) joins(*,G)
(+) pim_include(*,G)) )
AND (RPF_interface(RP(G)) != I)
CouldAssert(*,G,I) is true on downstream interfaces for which we have (*,*,RP(G)) or (*,G) join state, or local members that requested any traffic destined for G.
canassert（*、g、i）は、Gのために運命づけられているトラフィックを要求した（*、*、rp（g））または（*、g）を結合している（*、*、rp（g））または（*、g）を持っている下流のインターフェイスで真です。
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 an (*,G) assert might affect our behavior.
AssertTrackingDesired（*、g、i）は、（*、g）assertが動作に影響を与える可能性のあるインターフェイスで真です。
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セットで劣ったアサートを受け取ることができます（*、g、i）== true and or（*、g）assertはインターフェイスIで受信されます。ダウンストリームインターフェイス、およびこのインターフェイスに（*、g）転送状態があるため、アサートの勝者になる必要があります。「I Am Arsert 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に到着し、（*、g、i）== true g用のデータパケットは、（*、g）発信インターフェイスリストにある下流インターフェイスに到着しました。したがって、私たちはこれ（*、g）のフォワーダーであるべきだと考えているので、「私はas ast 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 BIT SETおよびASSERTTRACKINGDESIRED（*、g、i）== true（*、g）のasserttrackingdesidedを使用して許容可能なアサートを受け取ります。または、私はRP（g）の上流インターフェイスであり、（*、g）転送状態があるためです。（*、g）は、自分よりも優れたメトリックを持っていると主張するので、アサートに勝ちません。「私は敗者を主張している」に移行し、アクション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:
「私はアサート勝者」状態で、次のイベントは遷移をトリガーしますが、（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）を受け取ります。アサートを送信した人は誰でも失われたため、アサートタイマーをアサートして再起動します（以下のアクション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）Assertを受け取ります。「私は敗者をアサート」状態に移行し、アクションA2を実行します（以下）。
When in "I am Assert Winner" state, the following events trigger transitions:
「I Am Arsert 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）アサートタイマーの有効期限が切れます。私たちは勝者の状態にあるので、積極的に生き続けている（*、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).
canassert（*、g、i） - > false（*、g）転送状態またはRPFインターフェイスが変更され、可能性（*、g、i）がfalseになります。アサート勝者のアクションを実行できなくなるため、Noinfo Stateに移行し、アクションA4（以下）を実行します。
Transitions from "I am Assert Loser" State
「I Am Arsert 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:
「私は敗者です」状態で、次のイベントは遷移をトリガーしますが、（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.
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:
「私は敗者をアサートする」状態で、次のイベントが遷移をトリガーします。
Assert Timer Expires The (*,G) Assert Timer expires. We transition to NoInfo state and delete this (*,G) assert info (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 it no longer knows it was the winner. We transition to the NoInfo state, deleting the (*,G) assert information (Actions A5).
現在の勝者の遺伝子の変更またはNLTは、現在の勝者に関連付けられているNeighbor Livensionタイマーの有効期限が切れるか、現在の勝者から以前に報告した遺伝子とは異なる遺伝子を報告する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 info (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 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.
私のメトリックは、Assert Winner's Metricの私のルーティングメトリックであるRPT_ASSERT_METRIC（g、i）よりも良くなり、現在のアサート勝者のために保存したメトリックよりも私のアサートメトリックが優れているように変更されました。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) or Join(*,*,RP(G)) on interface I We receive a Join(*,G) or a Join(*,*,RP(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.
INTERFACEでJOIN（*、G）またはJOIN（*、*、rp（g））を受信しますI neight（*、g）または上流の隣接アドレスを持つJoin（*、*、rp（g））を受け取りますインターフェイスIのプライマリIPアドレスに設定されたフィールドは、アクションは、NoInfo状態に移行し、これ（*、g）アサート状態（アクションA5）を削除し、通常のPIM結合/プルーンメカニズムを動作させることです。結合を送信した人が誤っている場合、通常のアサートメカニズムは最終的に再適用され、再びアサートを失います。しかし、アサートを送った人は誰でも、以前のアサートの勝者が死亡したことを知っているかもしれないので、私たちは新しい転送者になる可能性があります。
(*,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タイマーを（assert_time -assert_override_interval）に設定します。AssertWinner（*、g、i）として自己保存します。rpt_assert_metric（g、i）をassertwinmetric（*、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）として新しいアサート受賞者を保存し、AssertWinmetric（*、g、i）として勝者のメトリックをアサートします。ASSERT_TIMEにアサートタイマーを設定します。
A3: Send Assert(*,G) Set Assert Timer to (Assert_Time - Assert_Override_Interval).
A3：ASSERT（*、g）を[ASSERT_TIME -ASSERT_OVERRIDE_INTERVAL）にSET ASSERT（*、g）SEEDを送信します。
A4: Send AssertCancel(*,G). Delete assert info (AssertWinner(*,G,I) and AssertWinnerMetric(*,G,I) will then return their default values).
A4：AssertCancel（*、g）を送信します。Assert Info（AssertWinner（*、g、i）およびassertwinnermetric（*、g、i）を削除し、デフォルト値を返します）。
A5: Delete assert info (AssertWinner(*,G,I) and AssertWinnerMetric(*,G,I) will then return their default values).
A5：Assert Info（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.
これらのアクションの一部は、Joindesidedired（*、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 field 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_PREFERECE、およびROUTE_METRICフィールドが順番に比較され、最初の低い値が勝ちます。すべてのフィールドが等しい場合、アサートメッセージを供給したルーターの主要な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メトリックは、次の擬似コードを使用して計算する必要があります。
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() gives the assert metric we need to send an assert but don't match either (S,G) or (*,G) forwarding state:
infinite_assert_metric（）は、アサートメトリックを与えます。
assert_metric
infinite_assert_metric() {
return {1,infinity,infinity,0}
}
An AssertCancel message is simply an RPT Assert message but with 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アサートメッセージですが、無限のメトリックを使用しています。アサートの勝者は、アサートを発生させた転送状態を削除したときに送信されます。他のルーターはこのメトリックが表示され、転送状態が独自の主張を送信し、転送を引き継ぐ他のルーターを引き起こします。
An AssertCancel(S,G) is an infinite metric assert with the RPT bit set that names S as the source.
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メッセージには特別な処理は必要ありません。これは、現在の勝者からのアサートメッセージであるためです。
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:
Macros lost_assert（s、g、rpt、i）、lost_assert（s、g、i）、およびlost_assert（*、g、i）は、セクション4.1のオリスト計算で使用され、次のように定義されています。
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 SPT bit. In this case, it needs to ignore the assert state if it will win the assert once the SPTbit is set.
注：「assertwinmetric（s、g、i）はspt_assert_metric（s、i）よりも優れています」という用語は、ルーターが（s、g）が状態になっているが、まだSPTを設定していないときに遷移フェーズを正しく処理するために必要です。少し。この場合、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）は、アサートを獲得したアサート（*、g）パケットのIPソースアドレスです。
AssertWinnerMetric(S,G,I) is the Assert metric of the Assert(S,G) packet that won an Assert.
ASSERTWINNEMTRIC（S、G、I）は、アサートを獲得したアサート（S、G）パケットのアサートメトリックです。
AssertWinnerMetric(*,G,I) is the Assert metric of the Assert(*,G) packet that won an Assert.
ASSERTWINNETRIC（*、g、i）は、アサートを獲得したアサート（*、g）パケットのアサートメトリックです。
AssertWinner(S,G,I) defaults to NULL and AssertWinnerMetric(S,G,I) defaults to Infinity when in the NoInfo state.
AssertWinner（s、g、i）は、noinfo状態の場合、null and asstwinnermetric（s、g、i）がデフォルトでデフォルトになります。
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）を送信し、適切なRPF '隣人、つまりアサートプロセスによって変更されたRPF隣人に定期的なメッセージを送信します。MRIBが示すように、それらは常にRPF隣人に送られるとは限りません。通常の抑制とオーバーライドルールが適用されます。
Rationale: By sending the periodic and triggered Join messages to the RPF' neighbor instead of to 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.
2. Behavior: The assert winner for (*,G) acts as the local DR for (*,G) on behalf of IGMP/MLD members.
2.
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.
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 cancels the (S,G) Assert Timer.
6. 動作：インターフェイスの主要なIPアドレスである上流の近隣アドレスで結合（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.
理論的根拠：これは、以前のアサート勝者に最初に結合を送信した下流のルーターがトポロジの変更を受けた場合に急速な収束を得るために必要です。
7. Behavior: An assert loser that receives a Join(*,G) or a Join(*,*,RP(G)) with an Upstream Neighbor Address that is its primary IP address on that interface cancels 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アドレスである上流の近隣アドレスを持つ結合（*、g）または結合（*、*、rp（g））を受信するアサート敗者（*、g）アサートタイマーをキャンセルするコンパウンド結合/プルーンメッセージに対応するプルーン（s、g、rpt）メッセージがないすべて（s、g）はタイマーをアサートします。
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）に結合（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.
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:
この仕様では、グループ間マッピングを実行するための情報をルーターに提供するための単一のメカニズムの使用を義務付けるものではありません。現在、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ルーターは、グループ間マッピングの静的構成をサポートする必要があります。このようなメカニズムは、障害に対して堅牢ではありませんが、少なくとも基本的な相互運用性メカニズムを提供します。
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 [17].
埋め込みRP埋め込みRPは、Rendezvous Point（RP）のアドレスがIPv6マルチキャストグループアドレスでエンコードされるアドレス割り当てポリシーを定義します[17]。
Cisco's Auto-RP Auto-RP uses a PIM Dense-Mode 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, and was only intended for use with PIM Sparse-Mode Version 1. No standard specification currently exists.
CiscoのAuto-RP Auto-RPは、PIM Dense-Modeマルチキャストグループを使用して、中央の場所からグループ間マッピングを発表します。このメカニズムは、PIM密度モードがPIMスパースモードと並行して実行されておらず、PIM Sparse-Modeバージョン1でのみ使用することを目的としていた場合、有用ではありません。現在標準仕様は存在しません。
BootStrap Router (BSR) RFC 2362 specifies a bootstrap mechanism based on the automatic election of a bootstrap router (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, BSR 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 BSR. The algorithm for performing the group-to-RP mapping is as follows:
上記のメカニズムの1つを使用して、PIMルーターは1つ以上の可能なグループ範囲からRPへのマッピングを受信します。各マッピングは、さまざまなマルチキャストグループ（グループとマスクとして表現）と、そのようなグループをマッピングするRPを指定します。各マッピングには、関連する優先度もあります。複数のマッピングを受け取ることができます。これらはすべて同じマルチキャストグループと一致する可能性があります。これはBSRの一般的なケースです。グループ間マッピングを実行するためのアルゴリズムは次のとおりです。
1. Perform longest match on group-range to obtain a list of RPs.
1. Group-Rangeで最も長い試合を実行して、RPSのリストを取得します。
2. From this list of matching RPs, find the one with highest priority. Eliminate any RPs from the list that have lower priorities.
2. 一致するRPSのこのリストから、優先度が最も高いものを見つけます。優先順位が低いリストからRPを排除します。
3. If only one RP remains in the list, use that RP.
3. リストに1つのRPのみが残っている場合は、その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つ以上のGroup-Range-to-RPマッピングが特定のグループをカバーする場合、最長マスクのあるグループが使用するマッピングです。マッピングが同じマスクの長さを持っている場合、最優先度の高いマッピングが選択されます。同じ長いマスクを備えた複数のマッチングエントリがあり、優先順位が同一である場合、ハッシュ関数（セクション4.7.2を参照）がRPを選択します。
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. It is invoked by any router that has (*,*,RP) state when a packet is received for which there is no corresponding (S,G) or (*,G) entry. Furthermore, the mapping function is invoked by all routers upon receiving a (*,G) or (*,*,RP) Join/Prune message.
このアルゴリズムは、DRがRPを知らないグループのパケットまたはIGMP/MLDメンバーシップの表示を受信したときに、特定のグループのRPを決定する必要がある場合にDRによって呼び出されます。対応する（s、g）または（*、g）エントリがないパケットを受信したときに（*、*、rp）状態を持つルーターによって呼び出されます。さらに、マッピング関数は、（*、g）または（*、*、rp）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.
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 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.
ハッシュ関数は、ドメイン内のすべてのルーターで使用され、グループを一致するセットの1つにグループをRPSの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. 一致するグループRange-to-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が使用されていない場合、Group-Range-to-RPマッピングを供給する代替メカニズムは値を提供する可能性があります。そうしないと、最も重要な30ビットがIPv4の1つであり、最も重要な126ビットが1つであるマスクがデフォルトです。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, we recommend using 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 ^ represents the exclusive-or operation.
IPv4以外のアドレスファミリーの場合、C（i）として使用される32ビットダイジェストとGは、最初に実際のRPまたはグループアドレスから導出する必要があります。このようなダイジェスト法は、PIMドメイン全体で一貫して使用する必要があります。IPv6アドレスの場合、IPv4互換アドレスに等価IPv4アドレスを使用することをお勧めします。たとえば、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.
ソース固有のマルチキャスト（SSM）サービスモデル[6]は、PIM-SMプロトコルメカニズムの厳密なサブセットで実装できます。通常のIPマルチキャストとSSMセマンティクスはどちらも単一のルーターに共存でき、両方ともPIM-SMプロトコルを使用して実装できます。IPv4のIPv4およびFF3x ::/32の現在232.0.0.0/8の範囲のマルチキャストアドレスは、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）結合/プルーンメッセージを送信してはなりません。
o A router MUST NOT send an (S,G,rpt) Join/Prune message for any reason.
o ルーターは、何らかの理由で（s、g、rpt）結合/プルーンメッセージを送信してはなりません。
o A router MUST NOT send a Register message for any packet that is destined to an SSM address.
o ルーターは、SSMアドレスに運命づけられているパケットにレジスタメッセージを送信してはなりません。
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）状態に基づいてパケットを転送してはなりません。（*、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.
o RPとして作用するルーターは、SSM宛先アドレスを持つレジスタにカプセル化されたパケットを転送してはなりません。
The last two rules are present to deal with "legacy" routers unaware of SSM that may be sending (*,G) and (S,G,rpt) Join/Prunes, or Register messages for SSM destination addresses.
最後の2つのルールは、（*、g）および（s、g、rpt）結合/プルーンを送信する可能性のあるSSMを認識していない「レガシー」ルーターを扱うか、SSM宛先アドレスのメッセージを登録します。
Additionally:
さらに：
o A router MAY be configured to advertise itself as a Candidate RP for an SSM address. If so, it SHOULD respond with a Register-Stop message to any Register message containing a packet destined for an SSM address.
o ルーターは、SSMアドレスの候補RPとして自分自身を宣伝するように構成することができます。その場合、SSMアドレスに向けられたパケットを含むレジスタメッセージにレジスタストップメッセージで応答する必要があります。
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）状態の作成とメンテナンスを最適化する場合があります。この状態は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.7)
o 上流（s、g）状態マシン（セクション4.5.7）
o Downstream (S,G) state machine (Section 4.5.3)
o ダウンストリーム（s、g）状態マシン（セクション4.5.3）
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 こんにちはメッセージ、隣人の発見、および博士選挙（セクション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), (S,G,rpt), and (*,*,RP) Downstream state machines (Sections 4.5.2, 4.5.4, and 4.5.1)
o （*、g）、（s、g、rpt）、および（*、*、rp）下流の状態マシン（セクション4.5.2、4.5.4、および4.5.1）
o (*,G), (S,G,rpt), and (*,*,RP) Upstream state machines (Sections 4.5.6, 4.5.8, and 4.5.5)
o （*、g）、（s、g、rpt）、および（*、*、rp）上流の状態マシン（セクション4.5.6、4.5.8、および4.5.5）
o (*,G) Assert state machine (Section 4.6.2)
o （*、g）ステートマシンをアサートする（セクション4.6.2）
o Bootstrap RP Election (Section 4.7) o Keepalive Timer
o ブートストラップRP選挙（セクション4.7）oキープライブタイマー
o SPTbit (Section 4.2.2)
o sptbit（セクション4.2.2）
The Keepalive Timer should be treated as always running, and 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:
Keepalive Timerは、常に実行されているように扱う必要があり、SPTBitは常にSSMアドレスに設定されているように扱う必要があります。さらに、セクション4.2のパケット転送ルールは、PIM-SSMのみのルーターで簡素化できます。
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
oiリスト=オリストのすべてのインターフェイス上のフォワードパケットのリスト（ - ）
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.
これは、通常のPIM-SM転送ルールの減少にすぎず、すべて（S、G、RPT）および（*、G）条項がNULLに置き換えられています。
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, etc.). 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メッセージは、ユニキャスト（レジスタやレジスタストップなど）または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メッセージ全体の補数合計を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ヘッダーに加えられています。Pseudo-Headerの「上層層パケットの長さ」は、PIMレジスタヘッダー（8）の長さに設定されているレジスタメッセージを除き、PIMメッセージの長さに設定されます。擬似ヘッダーで使用される次のヘッダー値は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またはタイプフィールドでメッセージが受信される場合、またはメッセージの宛先が上のテーブルに対応していない場合、メッセージを破棄する必要があり、エラーメッセージを管理者にレート制限する方法で記録する必要があります。
Encoded-Unicast Address
エンコードされたUnicastアドレス
An Encoded-Unicast address takes the following format:
エンコードされたUnicastアドレスは、次の形式を取ります。
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ファミリーこのアドレスの「ユニキャストアドレス」フィールドの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 though 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.
上記のaddrファミリー。
Encoding Type Described above.
上記のエンコードタイプ。
[B]idirectional PIM Indicates the group range should use Bidirectional PIM [13]. For PIM-SM defined in this specification, this bit MUST be zero.
[b]副回転PIMは、グループ範囲が双方向PIMを使用する必要があることを示しています[13]。この仕様で定義されているPIM-SMの場合、このビットはゼロでなければなりません。
Reserved Transmitted as zero. Ignored upon receipt.
予約されたゼロとして送信されました。受領時に無視されます。
Admin Scope [Z]one indicates 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.
Admin Scope [z] 1つは、グループ範囲が管理スコープゾーンであることを示します。これは、ブートストラップルーターメカニズム[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
エンコードされたソースアドレス
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.
上記のaddrファミリー。
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結合/プルーンメッセージで使用する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（またはRendezvous Point Tree）ビットは、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 left justified used as a mask which, combined with the Source Address, 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ビットです。値は、ソースアドレスと組み合わせて、ソースサブネットを記述するマスクとして使用されている正当化された隣接するビットの数です。マスクの長さは、指定されたアドレスファミリとエンコードタイプのビットのマスク長に等しくなければなりません（IPv4ネイティブでは32、IPv6ネイティブの場合は128）。ルーターは、他のマスク長で受信したメッセージを無視する必要があります。
Source Address The source address.
ソースアドレスソースアドレス。
It is sent periodically by routers on all interfaces.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OptionType | OptionLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OptionValue |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OptionType | OptionLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OptionValue |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Type, Reserved, Checksum Described in Section 4.9.
PIMバージョン、タイプ、予約済み、セクション4.9で説明されているチェックサム。
OptionType The type of the option given in the following OptionValue field.
OptionType次のオプション数値フィールドに与えられたオプションのタイプ。
OptionLength The length of the OptionValue field in bytes.
Option -Lengthバイトのオプション数値フィールドの長さ。
OptionValue A variable length field, carrying the value of the option.
オプションバリューオプションの値を運ぶ可変長さフィールド。
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.
ホールドタイムとは、レシーバーが数秒で隣人に到達可能に保つ必要がある時間です。ホールドタイムが「0xffff」に設定されている場合、このメッセージの受信者は隣人を決して締め出すことはありません。これは、リンクを定期的なハローメッセージに留めないように、ダイヤルオンデマンドリンクで使用できます。
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.
「0」に設定されたホールドタイム値を持つこんにちはメッセージは、インターフェイス上のルーターによって送信されます。これらは効果的に別れのメッセージであり、受信ルーターはすぐに送信者の近隣情報をタイムアウトする必要があります。
o OptionType 2: LAN Prune Delay
o OptionType 2：LAN Prune Delay
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 joins 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. Section 4.3.3 describes how these values affect the behavior of a router.
LAN Prune遅延オプションは、マルチアクセスLANのプルーン伝播遅延を調整するために使用されます。Tビットは、送信ルーターが抑制を無効にする能力を指定します。propagation_delayとoverride_intervalは、ミリ秒単位の時間間隔です。インターフェイス上のLAN Prune遅延オプションを発信するルーターは、Propagation_delay（i）の構成値にPropagation_delayフィールドを設定し、override_interval（i）の値にoverride_intervalフィールドの値を設定します。受信ルーターでは、フィールドの値を使用して、effection_override_interval（i）とその派生したタイマー値の値を調整します。セクション4.3.3では、これらの値がルーターの動作にどのように影響するかについて説明します。
o OptionType 3 to 16: reserved to be defined in future versions of this document.
o
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 Priorityは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.
Generation IDは、Helloメッセージが送信されるインターフェイスのランダムな32ビット値です。PIM転送が開始またはインターフェイスで再起動されるたびに、生成IDは再生されます。
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.
アドレスリストの内容ハローオプションは、セクション4.3.4で説明されています。単一のアドレスリスト内のすべてのアドレスは、同じアドレスファミリに属している必要があります。
OptionTypes 17 through 65000 are assigned by the IANA. OptionTypes 65001 through 65535 are reserved for Private Use, as defined in [9].
OptionTypes 17〜65000はIANAによって割り当てられます。[9]で定義されているように、OptionTypes 65001から65535から65535から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.
未知のオプションは無視する必要があり、隣人の関係が形成されないようにしてはなりません。「保留タイム」オプションを実装する必要があります。「DR優先度」および「生成ID」オプションを実装する必要があります。IPv6には「アドレスリスト」オプションを実装する必要があります。
A Register message is sent by the DR or a PMBR to the RP when a multicast packet needs to be transmitted on the RP-tree. 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.
RP-Treeでマルチキャストパケットを送信する必要がある場合、DRまたはPMBRからRPに登録メッセージが送信されます。IPソースアドレスは、RPのアドレスの宛先アドレスであるDRのアドレスに設定されます。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 pseudoheader
"Upper-Layer Packet Length" is set to 8.
B The Border bit. If the router is a DR for a source that it is directly connected to, it sets the B bit to 0. If the router is a PMBR for a source in a directly connected cloud, it sets the B bit to 1.
bボーダービット。ルーターが直接接続されているソースのDRである場合、Bビットを0に設定します。ルーターが直接接続されたクラウドのソースのPMBRである場合、Bビットを1に設定します。
N The Null-Register bit. Set to 1 by a DR that is probing the RP before expiring its local Register-Suppression Timer. Set to 0 otherwise.
n null-registerビット。ローカルレジスタサブレッションタイマーを期限切れにする前に、RPを調査しているDRによって1に設定されます。それ以外の場合は0に設定します。
Reserved2 Transmitted as zero, ignored on receipt.
ゼロとして送信され、受領時に無視されます。
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, 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を掲載したダミーIPヘッダー、宛先アドレスとしてgが含まれています。IPv4 null-registerメッセージを生成する場合、ダミーIPv4ヘッダーのフィールドを次の表に従って入力する必要があります。他の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ヘッダーが存在する場合、受信者はチェックサムをチェックし、悪いチェックサムを持つヌルレジスタを廃棄する必要があります。
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.
RPからレジスタメッセージの送信者までのレジスタストップがユニキャストです。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.
PIMバージョン、タイプ、予約済み、セクション4.9で説明されているチェックサム。
Group Address The group address from the multicast data packet in the Register. Format 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で説明されている形式。レジスタストップの場合、マスクレンフィールドには、単一のグループにメッセージが送信される場合、レジンレンフィールドには完全なアドレス長 * 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 wild card value consisting of an address field of all zeros can be used to indicate any source.
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.
結合/プルーンメッセージは、ルーターによって上流のソースと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 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. For IPv6 the source address used for multicast messages is the link-local address of the interface on which the message is being sent. For IPv4, the source address is the primary address associated with that interface.
Unicast Upstreem Neighborアドレスメッセージのターゲットである上流の隣人のアドレス。このアドレスの形式は、セクション4.9.1のエンコードされたUnicastアドレスに記載されています。IPv6の場合、マルチキャストメッセージに使用されるソースアドレスは、メッセージが送信されているインターフェイスのリンクローカルアドレスです。IPv4の場合、ソースアドレスはそのインターフェイスに関連付けられた主要なアドレスです。
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が「0xffff」に設定されている場合、このメッセージの受信者は、適切なキャンセルJoin/Pruneメッセージによってキャンセルされるまで状態を保持するか、ローカルポリシーに従ってタイミングを出す必要があります。これは、定期的な結合/プルーンメッセージを使用しないように、ダイヤルオンデマンドリンクで使用できます。
Note that the HoldTime must be larger than the J/P_Override_Interval(I).
ホールドタイムは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.
結合されたソースアドレス1 .. nこのリストには、送信ルーターがJoin/Pruneメッセージが送信されるインターフェイスで受信した場合からマルチキャストデータグラムを転送する特定のグループのソースが含まれています。
See Encoded-Source-Address format in Section 4.9.1.
セクション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.
剪定されたソースアドレス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結合/プルーンメッセージ内で、すべてのマルチキャストグループアドレス、結合されたソースアドレス、および剪定されたソースアドレスは、同じアドレスファミリでなければなりません。同じメッセージ内でIPv4とIPv6アドレスを混合することは許可されていません。さらに、メッセージ内のフィールドのアドレスファミリは、パケットのIPソースおよび宛先アドレスと同じでなければなりません。これにより、デュアルスタックIPv4/IPv6ルーターの最大実装の柔軟性が可能になります。ルーターが家族の混合アドレスを含むメッセージを受信した場合、ユニキャスト上流の近隣住所と同じファミリのアドレスのみを処理する必要があります。
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.
上記のように、結合/プルーンメッセージは1つ以上のグループセットで構成されています。各セットには、結合されたソースと剪定されたソースの2つのソースリストが含まれています。このセクションでは、Join/Pruneメッセージに存在できるさまざまな種類のグループセットとソースリストエントリについて説明します。
There are two valid group set types:
Wildcard Group Set The wildcard group set is represented by the entire multicast range: the beginning of the multicast address range in the group address field and the prefix length of the multicast address range in the mask length field of the Multicast Group Address (i.e., '224.0.0.0/4' for IPv4 or 'ff00::/8' for IPv6). Each Join/Prune message SHOULD contain at most one wildcard group set. Each wildcard group set may contain one or more (*,*,RP) source list entries in either the Joined or Pruned lists.
ワイルドカードグループセットWildCardグループセットは、マルチキャスト範囲全体で表されます。グループアドレスフィールドのマルチキャストアドレス範囲の開始と、マルチキャストグループアドレスのマスク長範囲のマルチキャストアドレス範囲のプレフィックス長範囲（つまり、 'IPv4または 'ff00 ::/8'の場合は224.0.0.0/4 'IPv6の場合）。各Join/Pruneメッセージには、最大1つのWildCardグループセットに含まれる必要があります。各WildCardグループセットには、結合またはプルーニングリストのいずれかに1つ以上の（*、*、RP）ソースリストエントリが含まれている場合があります。
A (*,*,RP) source list entry may only exist in a wildcard group set. When added to a Joined source list, this type of source entry expresses the router's interest in receiving traffic for all groups mapping to the specified RP. When added to a Pruned source list a (*,*,RP) entry expresses the router's interest to stop receiving such traffic. Note that as indicated by the Join/Prune state machines, such a Join or Prune will NOT override Join/Prune state created using a Group-Specific Set (see below).
（*、*、rp）ソースリストエントリは、ワイルドカードグループセットにのみ存在する場合があります。結合されたソースリストに追加されると、このタイプのソースエントリは、指定されたRPにマッピングするすべてのグループのトラフィックを受信するというルーターの関心を表します。剪定されたソースリストA（*、*、RP）エントリに追加されると、そのようなトラフィックの受信を停止することはルーターの関心を表します。Join/Prune Stateマシンで示されているように、このようなJoinまたはPruneは、グループ固有のセットを使用して作成されたJoin/Prune状態をオーバーライドしないことに注意してください（以下を参照）。
(*,*,RP) source list entries have the Source-Address set to the address of the RP, the Source-Address Mask-Len set to the full length of the IP address, and both the WC and RPT bits of the Source-Address set to 1.
（*、*、RP）ソースリストエントリは、RPのアドレスにソースアドレスを設定し、ソースアドレスマスク-LenがIPアドレスの全長に設定され、ソースのWCとRPTビットの両方が設定されています。-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マルチキャストアドレスに対して複数のグループ固有のセットを含めるべきではありません。各グループ固有のセットには、結合またはプルーニドリストに（*、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 Rendezvous-Point shared tree. There may only be one such entry in both the Joined and Pruned lists of a group-specific set.
（*、g）（*、g）ソースリストエントリは、指定されたグループのRPに向けて送信されたJoin/Pruneメッセージで使用されます。ランデブーポイント共有ツリーを介してグループに送信されるトラフィックを受信することに関心（またはその欠如）を表明します。グループ固有のセットの結合リストとプルーニングリストの両方に、そのようなエントリが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）ソースリストエントリは、Source-AddressをグループGのRPのアドレスに設定し、IPアドレスの全長に設定されたソースアドレスマスクLen、およびWCとRPTの両方の両方のBITSを設定します。エンコードされたソースアドレスセット。
(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 may 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メッセージで使用されます。指定されたソースからこのグループに送信された共有ツリーを介してトラフィックを受信することに関心（またはその欠如）を表明します。各ソースアドレスについて、エントリは、グループ固有のセットの結合および剪定されたソースリストの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）ソースリストエントリは、ソース-addressをソースSのアドレスに設定し、ソースアドレスマスクレンは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 may 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メッセージで使用されます。ソースから指定されたグループに送信された最短のパスツリーを介してトラフィックを受信することに関心（またはその欠如）を表明します。各ソースアドレスについて、エントリは、グループ固有のセットの結合および剪定されたソースリストの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）ソースリストエントリは、ソースSのアドレスにソースアドレスを設定し、ソースアドレスマスクレンはIPアドレスの全長に設定され、エンコードされたWCとRPTビットの両方が設定されています - Source-Addressがクリアされました。
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 a (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）結合を組み合わせて、A（s、g、rpt）の結合エントリは、（*、g）エントリが（s、g、rpt）エントリによって提供される情報をカバーするため、冗長です。
o The same applies for a (*,G) Prunes and (S,G,rpt) Prunes.
o 同じことが（*、g）プルーンと（s、g、rpt）プルーンにも当てはまります。
o The combination of a (*,G) Prune and a (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 A（*、g）Pruneとa（s、g、rpt）結合の組み合わせも生成されません。（s、g、rpt）結合は、ルーターが共有ツリー上のグループのすべてのトラフィックを受信している場合にのみ送信され、特定のソースの変更を示したいと考えています。a（*、g）プルーンは、ルーターが共有ツリートラフィックを受信したくないことを示しているため、（s、g、rpt）結合は無意味になります。
o As Join/Prune messages are targeted to a single PIM neighbor, including both a (S,G) Join and a (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メッセージは、A（s、g）JoinとA（s、g、rpt）の両方を含む単一のPIM隣人を対象としているため、通常は同じメッセージに囲まれています。（s、g）結合は、送信者が最短のパスツリーの特定のソースを受け取ることを望んでいることを隣人に通知します。したがって、ルーターが共有ツリーでそれを受け取りたくないと言うのは不要です。ただし、このエントリの組み合わせには有効な解釈があります。下流のルーターは、最も短いパスツリーのソースの受信を開始したら、特定のソースの転送を開始するように上流に指示する必要がある場合があります。
o The combination of a (S,G) Prune and a (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 a（s、g）pruneとa（s、g、rpt）の結合の組み合わせは、ルーターによって使用される可能性があります。最短パスと共有ツリーのRPF隣人が一般的であること。ただし、スパースモードPIMは、共有ツリーに明示的に切り替えるメカニズムを提供しません。
The rules are summarized in the tables 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) || | | | | | |
+----------++------+-------+-----------+-----------+-------+-------+
+---------------++--------------+----------------+------------+
| ||Join (*,*,RP) | Prune (*,*,RP) | all others |
+---------------++--------------+----------------+------------+
|Join (*,*,RP) ||- | no | yes |
+---------------++--------------+----------------+------------+
|Prune (*,*,RP) ||no | - | yes |
+---------------++--------------+----------------+------------+
|all others ||yes | yes | see above |
+---------------++--------------+----------------+------------+
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.
特定の隣人の結合/プルーンを構築するとき、ルーターは、できるだけ隣人に伝えるために必要な多くの情報をメッセージに含めるようにする必要があります。これは、情報保留中の送信がある情報があるマルチキャストグループごとに、およびすべての関連するソースリストエントリを含む各セット内に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.
n（s、g、rpt）のプルーンエントリのみが最大サイズの結合/プルーンメッセージに適合しますが、ルーターにはn（s、g、rpt）プルーネが追加されている場合、ルーターは最初のものを含めることを選択する必要があります。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.
アサートメッセージは、リンク上のルーター間のフォワーダーの競合を解決するために使用されます。ルーターが通常、ルーターがそのパケットを転送するインターフェイスにマルチキャストデータパケットを受信すると送信されます。アサートメッセージは、別のルーターからのアサートメッセージに応じて送信される場合があります。
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.
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 Encoded-Unicast-Address in Section 4.9.1.
ルーターが転送競合を解決したいと希望するソースアドレスソースアドレス。ソースアドレスは、（*、g）アサートに対してゼロに設定できます（以下を参照）。このアドレスの形式は、セクション4.9.1のエンコードされたUnicast-Addressに記載されています。
R RPT-bit is a 1-bit value. The RPT-bit is set to 1 for Assert(*,G) messages and 0 for Assert(S,G) messages.
r rpt-bitは1ビット値です。rpt-bitは、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 RPT-bit is set to 0, the Metric-Preference is set to MRIB.pref(S) and the Metric is set to MRIB.metric(S).
アサート（s、g）ソース固有のアサートは、最も短いパスツリーに特定のソースを転送するルーターによって送信されます（SPTBITは真）。（s、g）グループGにグループGに設定されたグループAddressフィールドとSource-AddressフィールドがソースSに設定されています。RPTビットは0に設定されています。）およびメトリックは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 RPT-bit is set to 1, the Metric-Preference is set to MRIB.pref(RP(G)), and the Metric is set to MRIB.metric(RP(G)).
アサート（*、g）グループ固有のアサートは、共有ツリーの競合の下でグループとソースのデータを転送するルーターによって送信されます。（*、g）Asserts Group-AddressフィールドはグループGに設定されています。データトリガーされたアサートの場合、ソースアドレスフィールドは、アサートをトリガーし、ゼロに設定するデータパケットのIPソースアドレスに設定できます。さもないと。rpt-bitは1に設定され、メトリックプレーションはmrib.pref（rp（g））に設定され、メトリックはmrib.metric（rp（g））に設定されます。
PIM-SM maintains the following timers, as discussed in Section 4.1. 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.
PIM-SMは、セクション4.1で説明したように、次のタイマーを維持します。すべてのタイマーはカウントダウンタイマーです。それらは値に設定され、ゼロにカウントダウンされます。その時点で、通常、アクションをトリガーします。もちろん、絶対有効期限が保存され、リアルタイムクロックと比較されるカウントアップタイマーと同じくらい簡単に実装できますが、この仕様の言語は、それらがゼロにカウントされることを前提としています。
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 active RP (RP):
Active RP（RP）ごとに：
(*,*,RP) Join Expiry Timer: ET(*,*,RP,I)
(*,*,RP) Prune-Pending Timer: PPT(*,*,RP,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,G) Join Expiry Timer: ET(S,G,I)
（S、G）Expiry Timer：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 active RP (RP):
Active RP（RP）ごとに：
(*,*,RP) Upstream Join Timer: JT(*,*,RP)
Per Group (G):
グループごと（g）：
(*,G) Upstream Join Timer: JT(*,G)
Per Source (S):
ソースごとに：
(S,G) Upstream Join Timer: JT(S,G)
（S、G）上流の結合タイマー：JT（S、G）
(S,G) Keepalive Timer: KAT(S,G)
（S、G）KeepAlive Timer：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:
DRSまたは関連するアサート受賞者のみ：
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)
+-------------------------------+--------------+----------------------+
| 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))
タイマー名：ハロータイマー（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).
System Power-Upでは、タイマーがRand（0、Triggered_hello_delay）に初期化され、同期を防ぎます。新しいまたは再起動した隣人が検出されると、Rand（0、triggered_hello_delay）内に応答するhelloが送信されます。
Timer Name: Neighbor Liveness Timer (NLT(N,I))
タイマー名：Neighbor Livension 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(*,*,RP,I), 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 |
+----------------+----------------+------------------------------------+
See details of JT(*,G) for the Holdtime that is included in Join/Prune Messages.
Join/Pruneメッセージに含まれる保留タイムについては、JT（*、g）の詳細を参照してください。
Timer Names: Prune-Pending Timer (PPT(*,*,RP,I), 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 |
| | EffectiveOverride_ | to override the |
| | Interval(I) | join or prune |
+--------------------------+---------------------+---------------------+
Note that both the Effective_Propagation_Delay(I) and the Effective_Override_Interval(I) are interface-specific values that may change when Hello messages are received (see Section 4.3.3).
effection_propagation_delay（i）とeffection_override_interval（i）の両方が、ハローメッセージを受信すると変更される可能性のあるインターフェイス固有の値であることに注意してください（セクション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.
歴史的な理由で、アサートメッセージにはホールドタイムフィールドがないことに注意してください。したがって、デフォルト値からアサート時間を変更することは推奨されません。
Timer Names: Upstream Join Timer (JT(*,*,RP), 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-holdtimeで以前のJoin/Prune-Feriodでルーターを更新し続ける必要があります適応するルーター。
The holdtime specified in a Join/Prune message should be set to (3.5 * t_periodic).
Join/Pruneメッセージで指定された保留タイムは、（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は、上流インターフェイスのeffection_override_intervalに依存します。これは、ハローメッセージが受信されると変更される場合があります。
t_suppressed depends on the Suppression State of the upstream interface (Section 4.3.3) and becomes zero when suppression is disabled.
T_Suppressは、上流インターフェイスの抑制状態（セクション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 t_override; this value is defined in the section on Upstream Join Timers.
上流のオーバーライドタイマーは、T_OVERRIDEにのみ設定されます。この値は、上流の結合タイマーのセクションで定義されています。
Timer Name: Keepalive Timer (KAT(S,G))
タイマー名：KeepAlive Timer（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では、KeepAlive期間は少なくともRegister_Suppression_timeでなければならず、RPは次のNull-Registerが到着する前に（S、G）状態をタイムアウトする場合があります。したがって、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 are 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の半分未満であることを確認する必要があります。
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].
値128〜250は、[9]で定義されているように、IESG承認に基づいてIANAによってPIMに割り当てられるように指定されます。
Values 251 through 255 are designated for Private Use, as defined in [9].
値251〜255は、[9]で定義されているように、私的使用のために指定されています。
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, including a description of how to use IPsec to secure the protocol. The reader is referred to [15] and [16] for further discussion of PIM-SM and multicast security. The IPsec authentication header [8] MAY be used to provide data integrity protection and groupwise data origin authentication of PIM protocol messages. Authentication of PIM messages can protect against unwanted behaviors caused by unauthorized or altered PIM messages.
このセクションでは、PIM-SMプロトコルに関連するさまざまなセキュリティ上の懸念について説明します。これには、IPSECを使用してプロトコルを保護する方法の説明が含まれます。読者は、PIM-SMおよびマルチキャストセキュリティのさらなる議論のために[15]および[16]に紹介されます。IPSEC認証ヘッダー[8]を使用して、PIMプロトコルメッセージのデータ整合性保護とグループワイズデータ起源認証を提供することができます。PIMメッセージの認証は、不正または変更されたPIMメッセージによって引き起こされる不要な動作から保護できます。
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.
考えられる損傷の程度は、受け入れられている偽造メッセージのタイプに依存します。次に、Forged Link-Local（Join/Prune、Hello、Assert）やForged Unicast（Register and Register-Stop）メッセージを含む、可能な偽造の影響を検討します。
Join/Prune, Hello, and Assert messages are all sent to the link-local ALL_PIM_ROUTERS multicast addresses 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.
結合/プルーン、こんにちは、およびアサートメッセージはすべてリンクローカルAll_Pim_Routersマルチキャストアドレスに送信されるため、準拠したルーターによって転送されません。このタイプの偽造メッセージは、LANがローカルホストによって送信された場合、または侵害されたまたは非準拠したルーターによって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. 偽造された結合/プルーンメッセージにより、マルチキャストトラフィックは、正当なリクエスターがないリンクに配信され、そのリンクに帯域幅を無駄にする可能性があります。マルチアクセスLANでの偽造された休暇メッセージは、一般に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. ハローメッセージを偽造することにより、不正なルーターは、LAN上の指定されたルーターとして選択される可能性があります。LAN上の指定されたルーターは（アサートがない場合）、地元のメンバーに代わってそのLANにトラフィックを転送する責任があります。指定されたルーターは、LANのホストが発信するパケットをRPに登録することを担当しています。したがって、地元のホストがマルチキャストトラフィックを送信および受信する能力は、偽造されたハローメッセージによって損なわれる可能性があります。
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にアサートメッセージを偽造することにより、攻撃者は合法的な指定されたフォワーダーが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 consider the effect of a forgery of each of these messages next.
登録メッセージとレジスタストップメッセージは、通常のIP転送を使用して、中間ルーターによって目的地に転送されます。Data Origin Authenticationがなければ、ネットワーク内のどこにでもある攻撃者は、レジスタまたはレジスタストップメッセージを偽造できる場合があります。次に、これらの各メッセージの偽造の効果を考慮します。
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. レジスタストップメッセージを偽造することにより、攻撃者は正当な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, using AH. 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メッセージは、中間ルーターによって変更されず、意図したレシーバーでのみ検査する必要があります。したがって、これらのメッセージは、AHを使用してエンドツーエンドで認証できます。これらのメッセージは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メッセージを受け入れる隣人のセットを制限するオプションを提供する必要があります。IPアドレスの静的構成またはIPSECセキュリティアソシエーションのいずれかを使用できます。さらに、PIMルーターは、まだ有効なHelloメッセージを受け取っていないルーターからプロトコルメッセージを受け入れてはなりません。
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に送信してはなりません。同様に、指定されたルーターは、IPソースアドレスがローカルドメインの有効なRPアドレスではないレジスタストップパケットを受け入れてはなりません。
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がレジスタにカプセル化されたパケットを受け入れるソースアドレスの範囲を制限できるようにするメカニズムを提供する必要があります。
All options that restrict the range of addresses from which packets are accepted MUST default to allowing all packets.
パケットが受け入れられるアドレスの範囲を制限するすべてのオプションは、すべてのパケットを許可するためにデフォルトする必要があります。
The IPsec [8] transport mode using the Authentication Header (AH) is the recommended method to prevent the above attacks against PIM. The specific AH authentication algorithm and parameters, including the choice of authentication algorithm and the choice of key, are configured by the network administrator. When IPsec authentication is used, a PIM router should reject (drop without processing) any unauthorized PIM protocol messages.
認証ヘッダー（AH）を使用したIPSEC [8]トランスポートモードは、PIMに対する上記の攻撃を防ぐための推奨方法です。認証アルゴリズムの選択とキーの選択を含む特定のAH認証アルゴリズムとパラメーターは、ネットワーク管理者によって構成されます。IPSEC認証を使用する場合、PIMルーターは不正なPIMプロトコルメッセージを拒否（処理せずにドロップ）する必要があります。
To use IPsec, the administrator of a PIM network configures each PIM router with one or more security associations (SAs) and associated Security Parameter Indexes (SPIs) that are used by senders to authenticate PIM protocol messages and are used by receivers to authenticate received PIM protocol messages. This document does not describe protocols for establishing SAs. It assumes that manual configuration of SAs is performed, but it does not preclude the use of a negotiation protocol such as the Internet Key Exchange [14] to establish SAs.
IPSECを使用するには、PIMネットワークの管理者が各PIMルーターを1つ以上のセキュリティアソシエーション（SAS）と関連するセキュリティパラメーターインデックス（SPI）で構成します。プロトコルメッセージ。このドキュメントでは、SASを確立するためのプロトコルについては説明していません。SASの手動構成が実行されると想定していますが、SASを確立するためにインターネットキーエクスチェンジ[14]などのネゴシエーションプロトコルの使用を排除しません。
IPsec [8] provides protection against replayed unicast and multicast messages. The anti-replay option for IPsec SHOULD be enabled on all SAs.
IPSEC [8]は、再生されたユニキャストおよびマルチキャストメッセージに対する保護を提供します。IPSECのアンチレプレイオプションは、すべてのSAで有効にする必要があります。
The following sections describe the SAs required to protect PIM protocol messages.
次のセクションでは、PIMプロトコルメッセージを保護するために必要なSASについて説明します。
The network administrator defines an SA and SPI that are to be used to authenticate all link-local PIM protocol messages (Hello, Join/Prune, and Assert) on each link in a PIM domain.
ネットワーク管理者は、PIMドメインの各リンクのすべてのリンクローカルPIMプロトコルメッセージ（Hello、Join/Prune、Assert）を認証するために使用するSAとSPIを定義します。
IPsec [8] allows (but does not require) different Security Policy Databases (SPD) for each router interface. If available, it may be desirable to configure the Security Policy Database at a PIM router such that all incoming and outgoing Join/Prune, Assert, and Hello packets use a different SA for each incoming or outgoing interface.
IPsec can also be used to provide data origin authentication and data integrity protection for the Register and Register-Stop unicast messages.
IPSECを使用して、レジスタおよびレジスタストップユニキャストメッセージのデータ起源認証とデータの整合性保護を提供することもできます。
The Security Policy Database at every PIM router is configured to select an SA to use when sending PIM Register packets to each rendezvous point.
すべてのPIMルーターのセキュリティポリシーデータベースは、各ランデブーポイントにPIMレジスタパケットを送信するときに使用するSAを選択するように構成されています。
In the most general mode of operation, the Security Policy Database at each DR is configured to select a unique SA and SPI for traffic sent to each RP. This allows each DR to have a different authentication algorithm and key to talk to the RP. However, this creates a daunting key management and distribution problem for the network administrator. Therefore, it may be preferable in PIM domains where all Designated Routers are under a single administrative control that the same authentication algorithm parameters (including the key) be used for all Registered packets in a domain, regardless of who are the RP and the DR.
最も一般的な動作モードでは、各DRのセキュリティポリシーデータベースが、各RPに送信されるトラフィック用に一意のSAとSPIを選択するように構成されています。これにより、各DRが異なる認証アルゴリズムとキーを持つことができ、RPと通信できます。ただし、これにより、ネットワーク管理者にとって困難な主要な管理と流通の問題が生じます。したがって、指定されたすべてのルーターが単一の管理制御下にあるPIMドメインでは、同じ認証アルゴリズムパラメーター（キーを含む）をドメイン内のすべての登録パケットに使用して、RPとDRに関係なく使用することが望ましい場合があります。
In this "single shared key" mode of operation, the network administrator must choose an SPI for each DR that will be used to send it PIM protocol packets. The Security Policy Database at every DR is configured to select an SA (including the authentication algorithm, authentication parameters, and this SPI) when sending Register messages to this RP.
この「シングル共有キー」操作モードでは、ネットワーク管理者は、PIMプロトコルパケットを送信するために使用される各DRのSPIを選択する必要があります。すべてのDRのセキュリティポリシーデータベースは、このRPにレジスタメッセージを送信するときに、SA（認証アルゴリズム、認証パラメーター、およびこのSPIを含む）を選択するように構成されています。
By using a single authentication algorithm and associated parameters, the key distribution problem is simplified. Note, however, that this method has the property that, in order to change the authentication method or authentication key used, all routers in the domain must be updated.
単一の認証アルゴリズムと関連するパラメーターを使用することにより、重要な分布問題が簡素化されます。ただし、この方法には、使用される認証方法または認証キーを変更するために、ドメイン内のすべてのルーターを更新する必要があるプロパティがあることに注意してください。
Similarly, the Security Policy Database at each Rendezvous Point should be configured to choose an SA to use when sending Register-Stop messages. Because Register-Stop messages are unicast to the destination DR, a different SA and a potentially unique SPI are required for each DR.
同様に、各ランデブーポイントのセキュリティポリシーデータベースは、レジスタストップメッセージを送信するときに使用するSAを選択するように構成する必要があります。レジスタストップメッセージは宛先DRにユニカストであるため、DRごとに異なるSAと潜在的にユニークなSPIが必要です。
In order to simplify the management problem, it may be acceptable to use the same authentication algorithm and authentication parameters, regardless of the sending RP and regardless of the destination DR. Although a unique SA is needed for each DR, the same authentication algorithm and authentication algorithm parameters (secret key) can be shared by all DRs and by all RPs.
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 data false traffic. Authenticating PIM protocol traffic prevents some, but not all, of these attacks. Three of the possible attacks include:
誤ったPIMプロトコルメッセージを生成したり、データの誤ったトラフィックを生成したりすることで、PIMに対するサービス拒否攻撃が多数あります。PIMプロトコルトラフィックを認証することで、これらの攻撃のすべてではありませんが、一部の攻撃を防ぎます。可能な攻撃の3つは次のとおりです。
- 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.
- 多くの異なるグループアドレスにパケットを迅速に送信することは、それ自体でサービス拒否攻撃になる可能性があります。これにより、DR、RP、およびルーターがDRとRPの間にロードされ、多くの登録抑制パケットが発生します。
- 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.
- 結合メッセージを鍛造すると、マルチキャストツリーがセットアップされる可能性があります。多数の鍛造結合は、ルーターリソースを消費し、サービスの拒否をもたらすことができます。
- Forging a (*,*,RP) join presents a possibility for a denial-of-service attack by causing all traffic in the domain to flow to the PMBR issuing the join. (*,*,RP) behavior is included here primarily for backwards compatibility with prior revisions of the spec. However, the implementation of (*,*,RP) and PMBR is optional. When using (*,*,RP), the security concerns should be carefully considered.
- 鍛造a（*、*、rp）Joinは、ドメイン内のすべてのトラフィックがPMBRに流れて結合を発行することにより、サービス拒否攻撃の可能性を提示します。（*、*、rp）動作は、主にスペックの以前の改訂と後方互換性のために含まれています。ただし、（*、*、RP）およびPMBRの実装はオプションです。（*、*、rp）を使用する場合、セキュリティの懸念を慎重に検討する必要があります。
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は、デボラ・エストリン、ディノ・ファリナッチ、アーメド・ヘルミー、デビッド・ターラー、スティーブ・ディーリング、ヴァン・ジェイコブソン、C・リュー、プネート・シャルマ、ライミング・ウェイからのアイデア、コメント、訂正など、大勢の人々によって長年にわたって設計されました。、トム・プサテリ、トニー・バラルディ、スコット・ブリム、ジョン・クロウクロフト、ポール・フランシス、ジョエル・ハルパーン、ホルスト・ホーデル、ポリー・ファン、スティーブン・オストロフスキー、リクシア・チャン、ギリッシュ・チャンドランメノン、ブライアン・ハーバーマン、ハル・サンディック、マイク、マリー・クンプ、パブリン・ラドスラボフ、マイ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 Limorice Companyに感謝します。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[2] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、B。、およびA. Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC 3376、2002年10月。
[3] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[3] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
[4] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[4] Deering、S.、Fenner、W。、およびB. Haberman、「IPv6のマルチキャストリスナーディスカバリー（MLD）」、RFC 2710、1999年10月。
[5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[5]
[6] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4507, August 2006.
[6] Holbrook、H。およびB. Cain、「IP用のソース固有のマルチキャスト」、RFC 4507、2006年8月。
[7] IANA, "Address Family Numbers", <http://www.iana.org/assignments/address-family-numbers>.
[7] IANA、「家族番号をアドレス」、<http://www.iana.org/assignments/address-family-numbers>。
[8] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[8] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[9] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[10] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[10] Bates、T.、Rekhter、Y.、Chandra、R。、およびD. Katz、「BGP-4のマルチプロトコル拡張」、RFC 2858、2000年6月。
[11] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap Router (BSR) Mechanism for PIM Sparse Mode", Work in Progress, May 2006.
[11] Bhaskar、N.、Gall、A.、Lingard、J。、およびS. Venaas、「Bootstrapルーター（BSR）PIMスパースモードのメカニズム」、2006年5月、進行中の作業。
[12] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[12] Black、D。、「差別化されたサービスとトンネル」、RFC 2983、2000年10月。
[13] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bi-directional Protocol Independent Multicast", Work in Progress, October 2005.
[13] Handley、M.、Kouvelas、I.、Speakman、T。、およびL. Vicisano、「Bi-Directional Protocol Independent Multicast」、2005年10月の作業。
[14] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[14] Kaufman、C。、「Internet Key Exchange（IKEV2）プロトコル」、RFC 4306、2005年12月。
[15] Savola, P., Lehtonen, R., and D. Meyer, "Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements", RFC 4609, August 2006.
[15] Savola、P.、Lehtonen、R。、およびD. Meyer、「プロトコル独立マルチキャスト - スパースモード（PIM -SM）マルチキャストルーティングセキュリティの問題と機能強化」、RFC 4609、2006年8月。
[16] Savola, P. and J. Lingard, "Last-hop Threats to Protocol Independent Multicast (PIM)", Work in Progress, January 2005.
[16] Savola、P。and J. Lingard、「プロトコル独立マルチキャスト（PIM）に対する最終ホップの脅威」、2005年1月、進行中の作業。
[17] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004.
[17] Savola、P。およびB. Haberman、「IPv6マルチキャストアドレスにRendezvous Point（RP）アドレスを埋め込む」、RFC 3956、2004年11月。
[18] Thaler, D., "Interoperability Rules for Multicast Routing Protocols", RFC 2715, October 1999.
[18] Thaler、D。、「マルチキャストルーティングプロトコルの相互運用性ルール」、RFC 2715、1999年10月。
In some cases, PIM-SM domains will interconnect with non-PIM multicast domains. In these cases, the border routers of the PIM domain speak PIM-SM on some interfaces and speak other multicast routing protocols on other interfaces. Such routers are termed PIM Multicast Border Routers (PMBRs). In general, RFC 2715 [18] provides rules for interoperability between different multicast routing protocols. In this appendix, we specify how PMBRs differ from regular PIM-SM routers.
場合によっては、PIM-SMドメインは非PIMマルチキャストドメインと相互接続されます。これらの場合、PIMドメインのボーダールーターはいくつかのインターフェイスでPIM-SMを話し、他のインターフェイスで他のマルチキャストルーティングプロトコルを話します。このようなルーターは、PIMマルチキャストボーダールーター（PMBRS）と呼ばれます。一般に、RFC 2715 [18]は、異なるマルチキャストルーティングプロトコル間の相互運用性のルールを提供します。この付録では、PMBRが通常のPIM-SMルーターとどのように異なるかを指定します。
From the point of view of PIM-SM, a PMBR has two tasks:
PIM-SMの観点から、PMBRには2つのタスクがあります。
o To ensure that traffic from sources outside the PIM-SM domain reaches receivers inside the domain.
o PIM-SMドメインの外側のソースからのトラフィックがドメイン内の受信機に到達するようにします。
o To ensure that traffic from sources inside the PIM-SM domain reaches receivers outside the domain.
o
We note that multiple PIM-SM domains are sometimes connected together using protocols such as Multicast Source Discovery Protocol (MSDP), which provides information about active external sources, but does not follow RFC 2715. In such cases, the domains are not connected via PMBRs because Join(S,G) messages traverse the border between domains. A PMBR is required when no PIM messages can traverse the border.
複数のPIM-SMドメインが、アクティブな外部ソースに関する情報を提供するマルチキャストソースディスカバリープロトコル（MSDP）などのプロトコルを使用して一緒に接続されることがあることに注意してください。結合（s、g）メッセージは、ドメイン間の境界線を横断するためです。PIMメッセージが境界線を通過できない場合は、PMBRが必要です。
A PMBR needs to ensure that traffic from multicast sources external to the PIM-SM domain reaches receivers inside the domain. The PMBR will follow the rules in RFC 2715, such that traffic from external sources reaches the PMBR itself.
According to RFC 2715, the PIM-SM component of the PMBR will receive an (S,G) Creation event when data from an (S,G) data packet from an external source first reaches the PMBR. If RPF_interface(S) is an interface in the PIM-SM domain, the packet cannot be originated into the PIM domain at this router, and the PIM-SM component of the PMBR will not process the packet. Otherwise, the PMBR will then act exactly as if it were the DR for this source (see Section 4.4.1), with the following modifications:
RFC 2715によると、PMBRのPIM-SMコンポーネントは、外部ソースからの（S、G）データパケットからのデータが最初にPMBRに到達すると、（s、g）作成イベントを受け取ります。RPF_INTERFACEがPIM-SMドメインのインターフェイスである場合、このルーターのPIMドメインにパケットを作成することはできず、PMBRのPIM-SMコンポーネントはパケットを処理しません。それ以外の場合、PMBRはこのソースのDRであるかのように正確に動作します（セクション4.4.1を参照）。
o The Border-bit is set in all PIM Register messages sent for these sources.
o ボーダービットは、これらのソースに送信されるすべてのPIMレジスタメッセージに設定されています。
o DirectlyConnected(S) is treated as being TRUE for these sources.
o 直接接続は、これらのソースに当てはまると扱われます。
o The PIM-SM forwarding rule "iif == RPF_interface(S)" is relaxed to be TRUE if iif is any interface that is not part of the PIM-SM component of the PMBR (see Section 4.2).
o IIFがPMBRのPIM-SMコンポーネントの一部ではないインターフェイスである場合、PIM-SM転送ルール「IIF == rpf_interface（s）」は真実になるようにリラックスしています（セクション4.2を参照）。
A PMBR needs to ensure that traffic from sources inside the PIM-SM domain reaches receivers outside the domain. Using terminology from RFC 2715, there are two possible scenarios for this:
PMBRは、PIM-SMドメイン内のソースからのトラフィックがドメインの外側の受信機に到達するようにする必要があります。RFC 2715の用語を使用して、これには2つの可能なシナリオがあります。
o Another component of the PMBR is a wildcard receiver. In this case, the PIM-SM component of the PMBR must ensure that traffic from all internal sources reaches the PMBR until it is informed otherwise.
o PMBRのもう1つのコンポーネントは、ワイルドカードレシーバーです。この場合、PMBRのPIM-SMコンポーネントは、すべての内部ソースからのトラフィックがPMBRに到達することを確認する必要があります。
Note that certain profiles of PIM-SM (e.g., PIM-SSM, PIM-SM with Embedded RP) cannot interoperate with a neighboring wildcard receiver domain.
PIM-SMの特定のプロファイル（たとえば、PIM-SSM、埋め込まれたRPを備えたPIM-SM）は、隣接するワイルドカードレシーバードメインと相互運用できないことに注意してください。
o No other component of the PMBR is a wildcard receiver. In this case the PMBR will receive explicit information as to which groups or (source,group) pairs the external domains wish to receive.
o PMBRの他のコンポーネントは、ワイルドカードレシーバーではありません。この場合、PMBRは、外部ドメインが受信したいグループまたは（ソース、グループ）のペアに関する明示的な情報を受け取ります。
In the former case, the PMBR will need to send a Join(*,*,RP) to all the active RPs in the PIM-SM domain. It may also send a Join(*,*,RP) to all the candidate RPs in the PIM-SM domain. This will cause all traffic in the domain to reach the PMBR. The PMBR may then act as if it were a DR with directly connected receivers and trigger the transition to a shortest path tree (see Section 4.2.1).
前者の場合、PMBRはPIM-SMドメインのすべてのアクティブなRPSに結合（*、*、RP）を送信する必要があります。また、PIM-SMドメインのすべての候補RPSに結合（*、*、RP）を送信する場合があります。これにより、ドメイン内のすべてのトラフィックがPMBRに到達します。その後、PMBRは、直接接続されたレシーバーを備えたDRであるかのように動作し、最短のパスツリーへの移行をトリガーします（セクション4.2.1を参照）。
In the latter case, the PMBR will not need to send Join(*,*,RP) messages. However, the PMBR will still need to act as a DR with directly connected receivers on behalf of the external receivers in terms of being able to switch to the shortest-path tree for internally-reached sources.
後者の場合、PMBRはJoin（*、*、RP）メッセージを送信する必要はありません。ただし、PMBRは、内部が到達したソースのために最短パスツリーに切り替えることができるという点で、外部レシーバーに代わって直接接続されたレシーバーを持つDRとして行動する必要があります。
According to RFC 2715, the PIM-SM component of the PMBR may receive a number of alerts generated by events in the external routing components. To implement the above behavior, one reasonable way to map these alerts into PIM-SM state is as follows:
RFC 2715によると、PMBRのPIM-SMコンポーネントは、外部ルーティングコンポーネントのイベントによって生成される多くのアラートを受け取る場合があります。上記の動作を実装するには、これらのアラートをPIM-SM状態にマッピングする合理的な方法の1つは次のとおりです。
o When a PIM-SM component receives an (S,G) Prune alert, it sets local_receiver_include(S,G,I) to FALSE for the discard interface.
o PIM-SMコンポーネントが（s、g）pruneアラートを受信すると、discardインターフェイスに対してlocal_receiver_include（s、g、i）をfalseに設定します。
o When a PIM-SM component receives a (*,G) Prune alert, it sets local_receiver_include(*,G,I) to FALSE for the discard interface.
o PIM-SMコンポーネントが（*、g）Pruneアラートを受信すると、discardインターフェイスに対してlocal_receiver_include（*、g、i）をfalseに設定します。
o When a PIM-SM component receives an (S,G) Join alert, it sets local_receiver_include(S,G,I) to TRUE for the discard interface.
o PIM-SMコンポーネントが（s、g）結合アラートを受信すると、discardインターフェイスの場合はlocal_receiver_include（s、g、i）を真に設定します。
o When a PIM-SM component receives a (*,G) Join alert, it sets local_receiver_include(*,G,I) to TRUE for the discard interface.
o PIM-SMコンポーネントがアラートの結合を受信すると、discardインターフェイスに対してlocal_receiver_include（*、g、i）を真に設定します。
o When a PIM-SM component receives a (*,*) Join alert, it sets DownstreamJPState(*,*,RP,I) to Join state on the discard interface for all RPs in the PIM-SM domain.
o PIM-SMコンポーネントがAlertを受信すると、Alertの結合が受信されると、PIM-SMドメインのすべてのRPSの破棄インターフェイスの状態（*、*、RP、I）を下に設定します。
o When a PIM-SM component receives a (*,*) Prune alert, it sets DownstreamJPState(*,*,RP,I) to NoInfo state on the discard interface for all RPs in the PIM-SM domain.
o PIM-SMコンポーネントが（*、*）プルーンアラートを受信すると、PIM-SMドメインのすべてのRPSの破棄インターフェイスで下流（*、*、*、RP、i）をnoInfo状態に設定します。
We refer above to the discard interface because the macros and state machines are interface specific, but we need to have PIM state that is not associated with any actual PIM-SM interface. Implementers are free to implement this in any reasonable manner.
マクロと状態のマシンはインターフェイス固有であるため、廃棄インターフェイスを上記で参照していますが、実際のPIM-SMインターフェイスに関連付けられていないPIM状態が必要です。実装者は、これを合理的な方法で自由に実装できます。
Note that these state changes will then cause additional PIM-SM state machine transitions in the normal way.
これらの状態の変更により、通常の方法で追加のPIM-SM状態マシン遷移が発生することに注意してください。
These rules are, however, not sufficient to allow pruning off the (*,*,RP) tree. Some additional rules provide guidance as to one way this may be done:
ただし、これらのルールは、（*、*、RP）ツリーを剪定するのに十分ではありません。いくつかの追加のルールは、これが行われる1つの方法に関するガイダンスを提供します。
o If the PMBR has joined on the (*,*,RP) tree, then it should set DownstreamJPState(*,G,I) to JOIN on the discard interface for all active groups.
o PMBRが（*、*、rp）ツリーに結合した場合、すべてのアクティブグループの破棄インターフェイスに結合するために、下流（*、g、i）を下に設定する必要があります。
o If the router receives a (S,G) prune alert, it will need to set DownstreamJPState(S,G,rpt,I) to PRUNE on the discard interface.
o ルーターが（s、g）プルーンアラートを受信した場合、廃棄インターフェイスを剪定するには、下線Jpstate（s、g、rpt、i）を設定する必要があります。
o If the router receives a (*,G) prune alert, it will need to set DownstreamJPState(S,G,rpt,I) to PRUNE on the discard interface for all active sources sending to G.
o ルーターが（*、g）プルーンアラートを受信した場合、Gに送信するすべてのアクティブソースの破棄インターフェイスを剪定するには、下流jpstate（s、g、rpt、i）を設定する必要があります。
The rationale for this is that there is no way in PIM-SM to prune traffic off the (*,*,RP) tree, except by Joining the (*,G) tree and then pruning each source individually.
これの理論的根拠は、（*、*、rp）ツリーからトラフィックをプルンする方法はないということです。
Address_List. . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Assert(*,G) . . . . . . . . . . . . . . . . . . . . . . . . . .27,128
Assert(S,G) . . . . . . . . . . . . . . . . . . . . . . . . . .27,128
AssertCancel(*,G) . . . . . . . . . . . . . . . . . . . . . . . 97,99
AssertCancel(S,G) . . . . . . . . . . . . . . . . . . . . . .80,90,99
AssertTimer(*,G,I). . . . . . . . . . . . . . . . . . . .16,24,91,132
AssertTimer(S,G,I). . . . . . . . . . . . . . . . . . . .18,24,84,132
AssertTrackingDesired(*,G,I). . . . . . . . . . . . . . . . .93,94,96
AssertTrackingDesired(S,G,I). . . . . . . . . . . . . . . 85,86,87,89
AssertWinner(*,G,I) . . . . . . . . . . . . . . . .16,22,24,93,97,100
AssertWinner(S,G,I) . . . . . . . . . . . . . .18,22,24,86,90,100,100
AssertWinnerMetric(*,G,I) . . . . . . . . . . . . . . . . . 16,97,101
AssertWinnerMetric(S,G,I) . . . . . . . . . . . . . . . . . 18,90,101
assert_metric . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Assert_Override_Interval. . . . . . . . . . . . . . . . . . 90,97,132
Assert_Time . . . . . . . . . . . . . . . . . . . . . . . . 90,97,132
AT(*,G,I) . . . . . . . . . . . . . . . . . . . . . .16,24,91,129,132
AT(S,G,I) . . . . . . . . . . . . . . . . . . . . . .18,24,84,129,132
CheckSwitchToSpt(S,G) . . . . . . . . . . . . . . . . . . . . . 27,28
CouldAssert(*,G,I). . . . . . . . . . . . . . . . . . .92,93,94,95,98
CouldAssert(S,G,I). . . . . . . . . . . . . . . . . 84,86,87,88,89,98
CouldRegister(S,G). . . . . . . . . . . . . . . . . . . . . . . 39,41
Default_Hello_Holdtime. . . . . . . . . . . . . . . . . . . . . . 33
DirectlyConnected(S). . . . . . . . . . . . . . . . . 27,27,29,41,143
DownstreamJPState(*,*,RP,I) . . . . . . . . . . . . . . . . . .23,145
DownstreamJPState(*,G,I). . . . . . . . . . . . . . . . . . . . . 23
DownstreamJPState(S,G,I). . . . . . . . . . . . . . . . . . . . 23,40
DownstreamJPState(S,G,rpt,I). . . . . . . . . . . . . . . . . . . 23
DR(I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
dr_is_better(a,b,I) . . . . . . . . . . . . . . . . . . . . . . 33,33
DR_Priority . . . . . . . . . . . . . . . . . . . . . . . . .31,32,33
Effective_Override_Interval(I). . . . . . . . . . . . . . .36,114,132
Effective_Propagation_Delay(I). . . . . . . . . . . . . . . . .35,132
ET(*,*,RP,I). . . . . . . . . . . . . . . . . . . . . . 15,46,128,131
ET(*,G,I) . . . . . . . . . . . . . . . . . . . . . . . 16,50,128,131
ET(S,G,I) . . . . . . . . . . . . . . . . . . . . . . . 18,53,129,131
ET(S,G,rpt,I) . . . . . . . . . . . . . . . . . . . .20,57,59,129,131
GenID . . . . . . . . . . . . . . . . . 15,17,19,31,64,68,70,73,85,93
Hash_Function . . . . . . . . . . . . . . . . . . . . . . . . .12,105
Hello_Holdtime. . . . . . . . . . . . . . . . . . . . . . . . .33,131
Hello_Period. . . . . . . . . . . . . . . . . . . . . . . . . .31,130
HT(I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31,130
IGMP. . . . . . . . . . . . . . . . . . . . . . . . 6,8,17,23,101,105
immediate_olist(*,*,RP) . . . . . . . . . . . . . . . . . . . . 22,64
immediate_olist(*,G). . . . . . . . . . . . . . . . . . . . . . 22,68
immediate_olist(S,G). . . . . . . . . . . . . . . . . . . . .22,40,73
infinite_assert_metric(). . . . . . . . . . . . . . . . . . . . . 99
inherited_olist(S,G). . . . . . . . . . . . . . 22,27,40,43,73,86,108
inherited_olist(S,G,rpt). . . . . . . . . . . . . . 22,27,29,76,79,81
I_Am_Assert_Loser(*,G,I). . . . . . . . . . . . . . . . . . . . . 24
I_Am_Assert_Loser(S,G,I). . . . . . . . . . . . . . . . . . . . . 24
I_am_DR(I). . . . . . . . . . . . . . . . . . . . . . .22,33,41,86,93
I_am_RP(G). . . . . . . . . . . . . . . . . . . . . . . . . . . 43,44
J/P_Holdtime. . . . . . . . . . . . .47,51,55,59,65,69,74,121,131,133
J/P_Override_Interval(I). . . . . . . . . . . . . 48,51,55,59,121,132
JoinDesired(*,*,RP) . . . . . . . . . . . . . . . . . . . . . . 64,79
JoinDesired(*,G). . . . . . . . . . . . . . . . . . . .17,68,79,86,97
JoinDesired(S,G). . . . . . . . . . . . . . . . . . 19,29,73,86,88,90
joins(*,*,RP(G)). . . . . . . . . . . . . . . . . . . . . . . . . 22
joins(*,*,RP) . . . . . . . . . . . . . . . . . . . . . . 22,23,86,93
joins(*,G). . . . . . . . . . . . . . . . . . . . . . . . 22,23,86,93
joins(S,G). . . . . . . . . . . . . . . . . . . . . . . . . .22,23,86
JT(*,*,RP). . . . . . . . . . . . . . . . . . . . . . . 15,62,129,133
JT(*,G) . . . . . . . . . . . . . . . . . . . . . . . . 16,67,129,133
JT(S,G) . . . . . . . . . . . . . . . . . . . . . . . . 18,71,129,133
KAT(S,G). . . . . . . . . . . . . . .18,26,27,28,41,43,73,108,129,134
KeepaliveTimer(S,G) . . . . . . . 18,26,27,27,28,41,43,73,108,129,134
Keepalive_Period. . . . . . . . . . . . . . . . . . . . . . . .27,134
lan_delay_enabled(I). . . . . . . . . . . . . . . . . . . . . . 35,36
LAN_Prune_Delay . . . . . . . . . . . . . . . . . . . . . . . . . 31
local_receiver_exclude(S,G,I) . . . . . . . . . . . . . . . . . . 23
local_receiver_include(*,G,I) . . . . . . . . . . . . . . . 23,93,144
local_receiver_include(S,G,I) . . . . . . . . . . . . . . . . . 23,86
local_receiver_include(S,G,I).. . . . . . . . . . . . . . . . . . 144
lost_assert(*,G). . . . . . . . . . . . . . . . . . . . . . .22,24,86
lost_assert(*,G,I). . . . . . . . . . . . . . . . . . . . . 22,24,100
lost_assert(S,G). . . . . . . . . . . . . . . . . . . . . . . . 22,24
lost_assert(S,G,I). . . . . . . . . . . . . . . . . . . . . 22,24,100
lost_assert(S,G,rpt). . . . . . . . . . . . . . . . . . . . . . . 24
lost_assert(S,G,rpt,I). . . . . . . . . . . . . . . . . . . . .24,100
MBGP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6,7
MFIB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6,13
MLD . . . . . . . . . . . . . . . . . . . . . . . . 6,8,17,23,101,105
MRIB. . . . . . . . . . . . . .6,7,11,15,19,25,62,66,66,75,98,103,128
MRIB.next_hop(host) . . . . . . . . . . . . . . . . . . . 24,25,62,64
my_assert_metric(*,G,I) . . . . . . . . . . . . . . . . . . . . . 94
my_assert_metric(S,G,I) . . . . . . . . . . . . . . . . . 85,89,92,98
NBR(Interface,IP_address) . . . . . . . . . . . . . . .25,37,62,64,66
NLT(N,I). . . . . . . . . . . . . . . . . . . . . . . . 14,33,128,131
OT(S,G,rpt) . . . . . . . . . . . . . . . . . . . . . . 20,77,129,134
Override_Interval(I). . . . . . . . . . . . . 14,31,34,36,114,130,132
packet_arrives_on_rp_tunnel(pkt). . . . . . . . . . . . . . . . . 43
pim_exclude(S,G). . . . . . . . . . . . . . . . . . . . . 22,22,28,86
pim_include(*,G). . . . . . . . . . . . . . . . . . 17,22,22,28,86,93
pim_include(S,G). . . . . . . . . . . . . . . . . . . .19,22,22,28,86
PPT(*,*,RP,I) . . . . . . . . . . . . . . . . . . . . . 15,46,128,132
PPT(*,G,I). . . . . . . . . . . . . . . . . . . . . . . 16,50,129,132
PPT(S,G,I). . . . . . . . . . . . . . . . . . . . . . . 18,53,129,132
PPT(S,G,rpt,I). . . . . . . . . . . . . . . . . . . .20,57,59,129,132
Propagation_Delay(I). . . . . . . . . . . . . . . . . . 31,35,130,132
Propagation_delay_default . . . . . . . . . . . . . . . . . . .35,130
PruneDesired(S,G,rpt) . . . . . . . . . . . . . . . . . . 79,80,88,90
prunes(S,G,rpt) . . . . . . . . . . . . . . . . . . . . . . .22,23,86
Register-Stop(*,G). . . . . . . . . . . . . . . . . . . . . . . . 42
Register-Stop(S,G). . . . . . . . . . . . . . . . . . . . . . . . 43
Register-StopTimer(S,G) . . . . . . . . . . . . . . . . 38,39,129,135
Register_Probe_Time . . . . . . . . . . . . . . . . . . . . 39,44,135
Register_Suppression_Time . . . . . . . . . . . . . . . . . 39,44,135
RP(G) . . . . . . . . . . . . 5,22,24,40,43,49,68,77,86,93,99,102,128
RPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
RPF'(*,G) . . . . . . . . . . . . . . . . 24,29,67,68,70,76,79,97,101
RPF'(S,G) . . . . . . . . . . . . . . . . . . . 25,29,71,76,79,90,101
RPF'(S,G,rpt) . . . . . . . . . . . . . . . . . . . . . .24,76,79,102
RPF_interface . . . . . . . . . . . . . . . . . . . . . . . . . . 93
RPF_interface(host) . . . . . .24,27,29,41,68,69,74,86,93,100,108,143
RPTJoinDesired(G) . . . . . . . . . . . . . . . . . . . . . .79,81,93
rpt_assert_metric(G,I). . . . . . . . . . . . . . . . . . . .96,97,99
RST(S,G). . . . . . . . . . . . . . . . . . . . . . . . 38,39,129,135
SPTbit(S,G) . . . . . . . 19,27,29,43,53,74,76,79,86,86,89,90,100,108
spt_assert_metric(S,I). . . . . . . . . . . . . . . . . . . 90,98,100
SSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10,106
Suppression_Enabled(I). . . . . . . . . . . . . . . . . . . . .36,133
SwitchToSptDesired(S,G) . . . . . . . . . . . . . . . . . . .28,28,43
TIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6,13,26
Triggered_Hello_Delay . . . . . . . . . . . . . . . . . . . 31,32,130
t_joinsuppress. . . . . . . . . . . . . . . . . . . . .64,65,68,69,74
t_override. . . . . . . . . . . . . . . . . . . . 64,68,73,78,133,134
t_override_default. . . . . . . . . . . . . . . . . . . . . . .36,130
t_periodic. . . . . . . . . . . . . . . . . . . . . . . .64,68,73,133
t_suppressed. . . . . . . . . . . . . . . . . . . .36,65,69,73,74,133
Update_SPTbit(S,G,iif). . . . . . . . . . . . . . . . . . . . . 27,29
UpstreamJPState(S,G). . . . . . . . . . . . . . . . . . . . . .27,108
Authors' Addresses
著者のアドレス
Bill Fenner AT&T Labs - Research 1 River Oaks Place San Jose, CA 95134
ビル・フェナーAT＆Tラボ - リサーチ1リバーオークスプレイスサンノゼ、カリフォルニア95134
EMail: fenner@research.att.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 Arastra, Inc. P.O. Box 10905 Palo Alto, CA 94303
Hugh Holbrook Arastra、Inc。P.O.Box 10905 Palo Alto、CA 94303
EMail: holbrook@arastra.com
Isidor Kouvelas Cisco Systems 170 W. Tasman Drive San Jose, CA 95134
Isidor Kouvelas Cisco Systems 170 W. Tasman Drive San Jose、CA 95134
EMail: kouvelas@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。