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)
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).
著作権（C）インターネット協会（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.
希薄モード（PIM-SM） - このドキュメントは、プロトコル独立マルチキャストを指定します。 PIM-SMは、基礎となるユニキャストルーティング情報ベース、または別個のマルチキャスト対応ルーティング情報ベースを使用することができるマルチキャストルーティングプロトコルです。これは、グループ当たりランデブーポイント（RP）をルート一方向共有ツリーを構築し、そして必要に応じてソースあたり最短パス木を作成します。
This document obsoletes RFC 2362, an Experimental version of PIM-SM.
この文書はRFC 2362、PIM-SMの実験バージョンを廃止します。
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の両方を元々RFC 2117で指定されたが、RFC 2362で修正されました。この文書は、PIM-SMは、以前に指定された方法で識別された欠陥の数を修正するために、およびIETF標準化過程の上にPIM-SMをもたらすために、廃止された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.
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" 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.
ランデブーポイント（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ルータを有していてもよいです。これらのルータの単一のもの、DRは、PIM-SMプロトコルに対して直接接続されたホストに代わって行動します。単一DRは、単純な選択プロセスを使用してインターフェイス（LANまたはその他）ごとに選出されます。
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はどこ/参加プルーンメッセージを送信することを決定するために使用されます。 MRIBの二次関数は、宛先アドレスのルーティングメトリックを提供することです。これらのメトリックは、送信側とのAssertメッセージを処理するときに使用されています。
RPF Neighbor RPF stands for "Reverse Path Forwarding". The RPF Neighbor of a router with respect to an address is the neighbor that the MRIB indicates should be used to forward packets to that address. In the case of a PIM-SM multicast group, the RPF neighbor is the router that a Join message for that group would be directed to, in the absence of modifying Assert state.
RPF隣人RPFは、「リバースパス転送」の略です。アドレスに対するルータの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.
TIBツリー情報ベース。これは、PIMを受信することにより作成されたPIMルータの状態のコレクションです/プルーンのメッセージ、PIMアサートメッセージ、およびインターネットグループ管理プロトコル（IGMP）またはローカルホストからのマルチキャストリスナ発見（MLD）の情報に参加します。それは本質的にそのルータでは、すべてのマルチキャスト配信ツリーの状態を格納します。
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.
再起動を検出するために使用られたGenID生成識別子。
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.
（+）Bは二組、AとBの和集合であります
A (-) B is the elements of set A that are not in set B.
（ - ）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参加/プルーンメッセージが送信されるべき次のホップネイバーを決定するために使用されます。データは、参加メッセージの逆の経路に沿って流れます。従って、データパケットは、いくつかのサブネットに到達するためにかかる次のホップを指定するユニキャストRIBとは対照的に、MRIBは、逆パス情報を与え、マルチキャストデータパケットがその原点サブネットからに取る経路を示しますMRIBを持つルータ。
Like all multicast routing protocols that implement the service model from RFC 1112 [3], PIM-SM must be able to route data packets from sources to receivers without either the sources or receivers knowing a priori of the existence of the others. This is essentially done in three phases, although as senders and receivers may come and go at any time, all three phases may occur simultaneously.
RFC 1112からサービスモデルを実装するすべてのマルチキャストルーティングプロトコルのように、[3]、PIM-SMは、他人の存在のアプリオリに知ることソースまたは受信機のいずれかせずにソースから受信機までの経路データパケットにできなければなりません。送信側と受信側はいつでも行ったり来たりする可能性があるため、すべての3つのフェーズが同時に発生する可能性がありますが、これは基本的に、3つのフェーズで行われます。
In phase one, a multicast receiver expresses its interest in receiving traffic destined for a multicast group. Typically, it does this using IGMP [2] or MLD [4], but other mechanisms might also serve this purpose. One of the receiver's local routers is elected as the Designated Router (DR) for that subnet. On receiving the receiver's expression of interest, the DR then sends a PIM Join message towards the RP for that multicast group. This Join message is known as a (*,G) Join because it joins group G for all sources to that group. The (*,G) Join travels hop-by-hop towards the RP for the group, and in each router it passes through, multicast tree state for group G is instantiated. Eventually, the (*,G) Join either reaches the RP or reaches a router that already has (*,G) Join state for that group. When many receivers join the group, their Join messages converge on the RP and form a distribution tree for group G that is rooted at the RP. This is known as the RP Tree (RPT), and is also known as the shared tree because it is shared by all sources sending to that group. Join messages are resent periodically so long as the receiver remains in the group. When all receivers on a leaf-network leave the group, the DR will send a PIM (*,G) Prune message towards the RP for that multicast group. However, if the Prune message is not sent for any reason, the state will eventually time out.
フェーズ1で、マルチキャスト受信側は、マルチキャストグループ宛のトラフィックの受信に関心を表現します。典型的には、この[2]またはMLD [4] IGMPを使用しないが、他のメカニズムもまた、この目的を果たすかもしれません。受信機のローカルルータの1つは、そのサブネットの代表ルータ（DR）として選出されます。興味の受信者の表現を受信すると、DRは、PIMは、そのマルチキャストグループのRPに向けてJoinメッセージを送信します。それは、そのグループのすべてのソースのグループGに加入するので、この参加メッセージは、（*、G）として知られている参加。 （*、G）は、ホップバイホップグループのためのRPに向かって、各ルータにそれが通過進行は、グループGのマルチキャストツリー状態がインスタンス化され参加します。最終的には、（*、G）は、どちらかがRPに達するか、すでに持っているルータ（*、G）、そのグループの状態を参加に達する参加します。多くの受信機がグループに参加すると、彼らの参加メッセージがRPに収束し、RPをルートとされ、グループGの配布ツリーを形成します。これは、RPツリー（RPT）として知られており、それはそのグループに送信するすべてのソースによって共有されているため、共有ツリーとして知られています。メッセージに参加していれば、受信機がグループに残るよう、定期的に再送されます。リーフ・ネットワーク上のすべての受信機がグループを離れたとき、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 Registerパケットとして知られています。
At the end of phase one, multicast traffic is flowing encapsulated to the RP, and then natively over the RP tree to the multicast receivers.
、フェーズ1の終わりに、マルチキャストトラフィックはRPにカプセル化され、その後、ネイティブマルチキャストレシーバーへのRP木の上に流れています。
Register-encapsulation of data packets is inefficient for two reasons:
登録カプセル化データパケットの2つの理由のために非効率的です：
o Encapsulation and decapsulation may be relatively expensive operations for a router to perform, depending on whether or not the router has appropriate hardware for these tasks.
Oカプセル化とカプセル化解除は、ルータがこれらのタスクのための適切なハードウェアを持っているかどうかに応じて、実行するためのルータのための比較的高価な操作かもしれません。
o Traveling all the way to the RP, and then back down the shared tree may result in the packets traveling a relatively long distance to reach receivers that are close to the sender. For some applications, this increased latency or bandwidth consumption is undesirable.
共有ツリーの下、当時のRPへのすべての道を旅し、oを送信者に近い受信機に到達するために、比較的長い距離を移動するパケットをもたらすことができます。一部のアプリケーションでは、この待ち時間の増加または帯域幅の消費は望ましくありません。
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、G）ソース特有を開始し、この参加メッセージは、ホップバイホップSに向かって走行するS.向かっ参加経路に沿ったルータで（S、G）マルチキャストツリーの状態をインスタンス化します。これらのパケットは、ソースSから来る場合には（S、G）マルチキャストツリー状態が唯一のグループGのためのパケットを転送するために使用される最終的参加メッセージは、Sのサブネットまたは既に（S、G）マルチキャストツリー状態を有するルータに到達し、その後、パケットSからRPに向かって（S、G）ツリーの状態を以下の流れ始めます。これらのデータパケットはまた、RPに向かう経路に沿って（*、G）ステートを持つルータに到達することができます。彼らがしなければ、彼らはこの時点でRPツリー上にショートカットすることができます。
While the RP is in the process of joining the source-specific tree for S, the data packets will continue being encapsulated to the RP. When packets from S also start to arrive natively at the RP, the RP will be receiving two copies of each of these packets. At this point, the RP starts to discard the encapsulated copy of these packets, and it sends a Register-Stop message back to S's DR to prevent the DR from unnecessarily encapsulating the packets.
RPはSのソース固有のツリーを結合する過程にある間に、データパケットはRPにカプセル化され続けます。 SからのパケットもRPにネイティブに到達するために起動すると、RPは、これらのパケットのそれぞれの2つのコピーを受信します。この時点で、RPは、これらのパケットのカプセル化されたコピーを破棄し始め、それが不必要にパケットをカプセル化からDRを防ぐために、バックSのDRに登録-Stopメッセージを送信します。
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の終わりには、トラフィックはRPに、共有ツリーに沿ってそこから受信機にソース特有の木に沿ってSからネイティブに流れるであろう。 2本の木が交差する場合は、トラフィックは、RPツリーにソース特有の木から転送するため、RPを経由して、長い回り道を取って回避することができます。
Note that a sender may start sending before or after a receiver joins the group, and thus phase two may happen before the shared tree to the receiver is built.
受信機がグループに参加する前または後に、送信者が送信を開始することができ、したがって、受信機への共有ツリーが構築される前に、第二段階が起こるかもしれないことに注意してください。
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、G）これは最終的にS.へのパスに沿ったルータの状態をインスタンス化する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から1：この時点では、受信機（又は受信機の上流のルータ）は、データの2つのコピーを受信します。最初のトラフィックはSPTから到着し始めたとき、DRまたは上流のルータは、RPツリーを介して到着SからGのパケットをドロップし始めます。また、RPに向かって（S、G）プルーンメッセージを送信します。これは（S、G、RPT）プルーンとして知られています。プルーンメッセージは、G用のSからのトラフィックがこの方向に転送されるべきでないことを示しているRPに向かって経路に沿って状態をインスタンス化する、ホップバイホップを移動します。それはRPか、まだ他の受信機のためにSからのトラフィックを必要とするルータに到達するまで、プルーンが伝播されます。
By now, the receiver will be receiving traffic from S along the shortest-path tree between the receiver and S. In addition, the RP is receiving the traffic from S, but this traffic is no longer reaching the receiver along the RP tree. As far as the receiver is concerned, this is the final distribution tree.
今、受信機はまた、受信機とSとの間の最短パス木に沿ってSからトラフィックを受信することにより、RPがSからのトラフィックを受信していないが、このトラフィックはもはやRPツリーに沿って受信機に到達します。限り受信機に関しては、これは、最終的な配信ツリーです。
IGMPv3 permits a receiver to join a group and specify that it only wants to receive traffic for a group if that traffic comes from a particular source. If a receiver does this, and no other receiver on the LAN requires all the traffic for the group, then the DR may omit performing a (*,G) join to set up the shared tree, and instead issue a source-specific (S,G) join only.
IGMPv3がグループに参加し、そのトラフィックが特定のソースから来ている場合にのみグループのトラフィックを受信したいことを指定するための受信機を可能にします。受信機はこれを行い、そしてLAN上の他の受信機は、グループのすべてのトラフィックを必要とせず、その後、DRは（*、G）を実行省略してもよい場合は、共有ツリーを設定し、その代わりにソース固有の（Sを発行する参加します、Gは）のみ参加します。
The range of multicast addresses from 232.0.0.0 to 232.255.255.255 is currently set aside for source-specific multicast in IPv4. For groups in this range, receivers should only issue source-specific IGMPv3 joins. If a PIM router receives a non-source-specific join for a group in this range, it should ignore it, 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は（*、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.
彼らはRPに到達する方法について、一貫性のないMRIBエントリーを持っているので、O LAN上の2つの以上のルータが発行することができる（*、G）は、LAN上の別のアップストリームルータに参加します。 RPツリー上の両方のパスは、LAN上で表示されるすべての共有ツリーのトラフィックの2つのコピーを引き起こし、設定されます。
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上の異なるアップストリームルータに参加Sからのすべてのトラフィックの2つのコピーは、LAN上に表示します。
o A router on the LAN may issue a (*,G) Join to one upstream router on the LAN, and another router on the LAN may issue an (S,G) Join to a different upstream router on the same LAN. Traffic from S may reach the LAN over both the RPT and the SPT. If the receiver behind the downstream (*,G) router doesn't issue an (S,G,rpt) prune, then this condition would persist.
O LAN上のルータが（*、G）を発行する（S、G）は、同じLAN上の異なるアップストリームルータに参加を発行することができる1つのアップストリーム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上に表示されたときに代わりに、これらのルータは、このことを気づくと、単一フォワーダを選出します。この選挙は、（S、G）状態を持っている上流のルータを支持して問題を解決するPIMアサートメッセージを用いて行われます。どちらかまたは両方のルータは（S、G）状態を持っている場合は、問題はRP木、またはソース固有の樹木にソースへの最良のメトリックのためのRPへの最適なメトリックを持つルータを支持して解決されます。
These Assert messages are also received by the downstream routers on the LAN, and these cause subsequent Join messages to be sent to the upstream router that won the Assert.
これらのAssertメッセージもLAN上の下流のルータによって受信され、これらはアサートを獲得した上流のルータに送信されるように、後続のJoinメッセージを引き起こします。
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ドメイン内のルータは、単純な選挙プロセスをブートストラップルータに選出されます。 RPは定期的に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セット順序保存ハッシュ関数（RP-設定変更された場合、変更を最小限に抑える1）を使用してにグループアドレスをハッシュします。結果の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）選挙とメッセージを送信し、こんにちは処理するためのルールを指定します。
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.
ソース固有マルチキャスト、PIM-SSMをサポートするために必要なPIMのサブセットO、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:
私たちは4つのセクションにTIB状態を分割します：
(*,*,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.のためのRPツリーを維持して（*、G）ステート州
(S,G) state State that maintains a source-specific tree for source S and group G.
（S、G）ステート状態は、ソースSとグループGのソース固有のツリーを維持します
(S,G,rpt) state State that maintains source-specific information about source S on the RP tree for G. For example, if a source is being received on the source-specific tree, it will normally have been pruned off the RP tree. This prune state is (S,G,rpt) state.
（S、G、RPT）ソースは、ソース特有ツリー上で受信されている場合、たとえば、G.ためRPツリー上のソースSに関するソース固有の情報を保持する状態状態が、それは通常RPをオフに剪定されているであろう木。このプルーン状態は（S、G、RPT）の状態です。
The state that should be kept is described below. Of course, implementations will only maintain state when it is relevant to forwarding operations; for example, the "NoInfo" state might be assumed from the lack of other state information rather than being held explicitly.
維持されるべき状態は以下の通りです。それはフォワーディング業務に関連しているときもちろん、実装が唯一の状態を維持します。例えば、「NoInfo」状態が他の状態情報の不足から、想定される可能性があるのではなく、明示的に開催されています。
A router holds the following non-group-specific state:
ルータは、次の非グループ固有の状態を保持します。
For each interface:
各インタフェースの場合：
o Effective Override Interval
O有効オーバーライド間隔
o Effective Propagation Delay
Oの有効伝搬遅延
o Suppression state: One of {"Enable", "Disable"}
O抑制状態：{「有効」、「無効」}の一つ
Neighbor State:
近隣の状態：
For each neighbor:
各隣人のために：
o Information from neighbor's Hello
隣人のHelloからO情報
o Neighbor's GenID.
近隣の宋の。
o Neighbor Liveness Timer (NLT)
O隣接ライブネスタイマ（NLT）
Designated Router (DR) State:
指定ルータ（DR）状態：
o Designated Router's IP Address
OルーターのIPアドレスを指定
o DR's DR Priority
O DRのDR優先順位
The Effective Override Interval, the Effective Propagation Delay and the Interface suppression state are described in Section 4.3.3. Designated Router state is described in Section 4.3.
有効なオーバーライド間隔、効果的な伝播遅延時間とインターフェイスの抑制状態は、セクション4.3.3で説明されています。指定ルータの状態は、セクション4.3に記載されています。
For every RP, a router keeps the following state:
すべてのRPについて、ルータは次の状態を保持します。
(*,*,RP) state: For each interface:
（*、*、RP）状態：各インタフェースの場合：
PIM (*,*,RP) Join/Prune State:
PIM（*、*、RP）/プルーンの状態に参加：
o State: One of {"NoInfo" (NI), "Join" (J), "Prune-
Pending" (PP)}
o Prune-Pending Timer (PPT)
Oプルーン・ペンディングタイマ（PPT）
o Join/Prune Expiry Timer (ET)
O参加/プルーン有効期限タイマ（ET）
Not interface specific:
特定のインタフェースではありません。
Upstream (*,*,RP) Join/Prune State:
上流（*、*、RP）/プルーンの状態に参加：
o State: One of {"NotJoined(*,*,RP)",
"Joined(*,*,RP)"}
o Upstream Join/Prune Timer (JT)
O上流には、/プルーンタイマー（JT）に参加します
o Last RPF Neighbor towards RP that was used
使用されたRPに向けた最後のRPFネイバーO
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.
RPに向けた最後のRPF隣人が原因MRIBが変化した場合、その後、RPへのRPF隣人が変化する可能性が保存されています。それがそうするならば、我々は新しいをトリガーする必要が古い上流隣接に新しい上流隣接し、プルーン（*、*、RP）に（*、*、RP）に参加。ルータがRPに向かった上流の隣人がリブートしていることをHelloメッセージに変えられたGenIDを通して検出された場合同様に、それは（*、*、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）/プルーンの状態に参加：
o State: One of {"NoInfo" (NI), "Join" (J), "Prune-
Pending" (PP)}
o Prune-Pending Timer (PPT)
Oプルーン・ペンディングタイマ（PPT）
o Join/Prune Expiry Timer (ET)
O参加/プルーン有効期限タイマ（ET）
(*,G) Assert Winner State
（*、G）のAssert勝者状態
o State: One of {"NoInfo" (NI), "I lost Assert" (L),
"I won Assert" (W)}
o Assert Timer (AT)
Oアサートタイマー（AT）
o Assert winner's IP Address (AssertWinner)
Oアサート勝者のIPアドレス（AssertWinner）
o Assert winner's Assert Metric (AssertWinnerMetric)
Oアサート勝者のアサートメートル（AssertWinnerMetric）
Not interface specific:
特定のインタフェースではありません。
Upstream (*,G) Join/Prune State:
上流（*、G）/プルーンの状態に参加：
o State: One of {"NotJoined(*,G)", "Joined(*,G)"}
O状態：の一つ{ "NotJoined（*、G）"、 "参加（*、G）"}
o Upstream Join/Prune Timer (JT)
O上流には、/プルーンタイマー（JT）に参加します
o Last RP Used
O最終RPが使用されます
o Last RPF Neighbor towards RP that was used
使用されたRPに向けた最後のRPFネイバーO
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など）ローカルメンバシップメカニズムの結果です。これは、このルータがそのインタフェース上DRでない場合は、このルータが（*、G）を獲得しない限り、実装は必要に応じて、それらがDRになるか、勝者をアサートする場合には、この状態を維持することができるが、このグループのために、このインターフェイス上でアサート維持する必要はありません。私たちは、可能であれば、それは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、*）に参加するかどうかを決定する際に使用される（セクション4.5.6で定義された）JoinDesired（*、G）マクロにあります上流送信する必要があります。
(*,G) Assert Winner state is the result of sending or receiving (*,G) Assert messages on this interface. It is specified in Section 4.6.2.
（*、G）が勝者の状態が（*、G）は、このインターフェイス上でメッセージをアサート送信または受信の結果でアサート。これは、4.6.2項で規定されています。
The upstream (*,G) Join/Prune State reflects the state of the upstream (*,G) state machine described in Section 4.5.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の変化グループのために再構築されなければならない、なぜならRP-セットの変更（セクション4.7）場合に格納しなければなりません。
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.
RPに向けた最後のRPF隣人が原因MRIBが変化した場合、その後、RPへのRPF隣人が変化する可能性が保存されています。それがそうするならば、我々はトリガするために必要な新しい新しい上流隣接する（*、G）と昔の上流の隣人へのプルーン（*、G）が参加。同様に、ルータが参加（*、G）を送信することによって、HelloメッセージRPに向かって上流隣接が再起動したこと、それが再インスタンス化する状態に変化られたGenIDを通して検出した場合。これらのメカニズムは、セクション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）/プルーンの状態に参加：
o State: One of {"NoInfo" (NI), "Join" (J), "Prune-
Pending" (PP)}
o Prune-Pending Timer (PPT)
Oプルーン・ペンディングタイマ（PPT）
o Join/Prune Expiry Timer (ET)
O参加/プルーン有効期限タイマ（ET）
(S,G) Assert Winner State
（S、G）をアサート受賞状態
o State: One of {"NoInfo" (NI), "I lost Assert" (L),
"I won Assert" (W)}
o Assert Timer (AT)
Oアサートタイマー（AT）
o Assert winner's IP Address (AssertWinner)
Oアサート勝者のIPアドレス（AssertWinner）
o Assert winner's Assert Metric (AssertWinnerMetric)
Oアサート勝者のアサートメートル（AssertWinnerMetric）
Not interface specific:
特定のインタフェースではありません。
Upstream (S,G) Join/Prune State:
上流（S、G）/プルーンの状態に参加：
o State: One of {"NotJoined(S,G)", "Joined(S,G)"}
O状態：{ "NotJoined（S、G）"、 "（S、G）参加"}の一つ
o Upstream (S,G) Join/Prune Timer (JT)
アップストリーム（S、G）O /プルーンタイマー（JT）に参加
o Last RPF Neighbor towards S that was used
使用されたSに向けた最後のRPFネイバーO
o SPTbit (indicates (S,G) state is active)
O SPTbit（示し（S、G）状態がアクティブです）
o (S,G) Keepalive Timer (KAT)
O（S、G）キープアライブタイマー（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 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.
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の矛盾が解決された後に、この状態は結果の状態です。このルータは、このルータは（S、G）は、このグループのために、このインターフェイス上でアサートを獲得していない限り、そのインターフェイス上の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に発信インターフェイスリストを計算するマクロによって使用され、参加するかどうかを決定する際に使用されるJoinDesired（S、G）マクロ（セクション4.5.7で定義された）に（S、G）されています上流送信する必要があります。
(S,G) Assert Winner state is the result of sending or receiving (S,G) Assert messages on this interface. It is specified in Section 4.6.1.
（S、G）受賞状態が送信またはこのインターフェイス上でメッセージをアサート（S、G）を受信した結果であるアサート。これは、4.6.1項で規定されています。
The upstream (S,G) Join/Prune State reflects the state of the upstream (S,G) state machine described in Section 4.5.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）Joinメッセージを周期送出するように、上流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）をトリガする必要があります。ルータがSに向かって上流隣接が再起動したことをHelloメッセージに変更られたGenIDを通して検出された場合も同様に、それは参加（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）SPTbitがTRUEである場合に転送状態がGにSからパケットを転送するために使用され、両方の（*、G）および（S、G）転送状態に使用されます。
The (S,G) Keepalive Timer is updated by data being forwarded using this (S,G) forwarding state. It is used to keep (S,G) state alive in the absence of explicit (S,G) Joins. Amongst other things, this is necessary for the so-called "turnaround rules" -- when the RP uses (S,G) joins to stop encapsulation, and then (S,G) prunes to prevent traffic from unnecessarily reaching the RP.
（S、G）キープアライブタイマがこの（S、G）転送状態を使用して転送されるデータによって更新されます。 （S、G）明示の非存在下で生きている状態（S、G）参加を維持するために使用されます。 RPが使用する（S、G）はカプセル化を停止するために参加したときに、不必要に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.
キープアライブタイマーの期限が切れるとRPで、PMBR値をクリアする必要があります。
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 Prune-Pending Timer (PPT)
Oプルーン・ペンディングタイマ（PPT）
o Join/Prune Expiry Timer (ET)
O参加/プルーン有効期限タイマ（ET）
Not interface specific:
特定のインタフェースではありません。
Upstream (S,G,rpt) Join/Prune State:
上流（S、G、RPT）/プルーンの状態に参加：
o State: One of {"RPTNotJoined(G)",
"NotPruned(S,G,rpt)", "Pruned(S,G,rpt)"}
o 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.
ローカル・メンバーシップは、（例えばIGMPv3のような）ローカル・ソース特有の会員機構の結果、そのインターフェイス上で実行され、（*、G）ステートを含めるがあるが、この特定のソースを除外すべきであることを指定します。ここに保存されたよう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.5.8で指定された（*、G）メッセージに参加するプルーン（S、G、RPT）メッセージを追加するためのセクション4.1.6において、ルールにおける発信インターフェイスリストを計算するマクロによって使用されます。
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.
最も重要なマクロは、関連する状態のための発信インターフェイスリスト（または「OLIST」）を定義するものです。それは、関連するタイプの状態から直接構築されている場合OLISTは、「即時」することができます。例えば、immediate_olist（S、G）は、ルータのみであった場合に構築されるであろうOLIST（S、G）ステートなし（*、G）または（S、G、RPT）の状態です。これとは対照的に、「継承」OLISTは、他のタイプの状態を継承します。例えば、引き継いでいる_olist（S、G）は、ソース固有およびグループ固有の状態の両方を使用して、GにSからパケットを転送するための関連しOLISTあります。
There is no immediate_olist(S,G,rpt) as (S,G,rpt) state is negative state; it removes interfaces in the (*,G) olist from the olist that is actually used to forward traffic. The inherited_olist(S,G,rpt) is therefore the olist that would be used for a packet from S to G forwarding on the RP tree. It is a strict subset of (immediate_olist(*,*,RP) (+) immediate_olist(*,G)).
（S、G、RPT）状態が負の状態であるように何immediate_olist（S、G、RPT）がありません。実際にトラフィックを転送するために使用されるOLISTから（*、G）OLISTのインターフェイスを除去します。引き継いでいる_olist（S、G、RPT）は、従ってRPツリーに転送SからGへのパケットのために使用されるであろうOLISTあります。これは、（immediate_olist（*、*、RP）（+）immediate_olist（*、G））の厳密なサブセットです。
Generally speaking, the inherited olists are used for forwarding, and the immediate_olists are used to make decisions about state maintenance.
一般的に言って、継承されたolistsは転送のために使用され、immediate_olistsは、状態の維持に関する決定を行うために使用されています。
immediate_olist(*,*,RP) = joins(*,*,RP)
immediate_olist（*、*、RP）=（*、*、RP）加入
immediate_olist(*,G) = joins(*,G) (+) pim_include(*,G) (-) lost_assert(*,G)
immediate_olist（*、G）=ジョイン（*、G）（+）pim_include（*、G）（ - ）lost_assert（*、G）
immediate_olist(S,G) = joins(S,G) (+) pim_include(S,G) (-) lost_assert(S,G)
immediate_olist（S、G）=参加する（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) )
引き継いでいる_olist（S、G、RPT）=（（*、*、RP（G）に参加）（+）ジョイン（*、G）（ - ）プルーン（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)
引き継いでいる_olist（S、G）=引き継いでいる_olist（S、G、RPT）（+）が参加（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（*、G）= {すべてのインタフェースIように：（（I_am_DR（I）AND lost_assert（*、G、I）が== FALSE）OR AssertWinner（*、G、I）==私）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_include（S、G）= {すべてのインタフェースIになるように：（（I_am_DR（I）AND lost_assert（S、G、I）== FALSE）OR AssertWinner（S、G、I）==私）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) }
pim_exclude（S、G）= {すべてのインタフェースIように：（（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.
IGMP / MLDモジュールまたは他のローカルメンバーシップ機構はインターフェイス上のローカルメンバーは、私はG.「local_receiver_include（*、GとSによって特異的に送信されたトラフィックを受信することを望んでいると判断した場合句「local_receiver_include（S、G、I）が」真でありますIGMP / MLDモジュールまたは他のローカルメンバーシップ機構はインターフェイス上のローカルメンバーは、私は（おそらく）源の特定のセットからのトラフィックを除くGに送信されたすべてのトラフィックを受信することを望んでいると判断した場合、I）」も同様です。 local_receiver_includeは、（*、G、I）は 『真のですが、地元のメンバーのいずれもSからトラフィックを受信することを望んでいない「場合local_receiver_exclude（S、G、I）が真です』
The set "joins(*,*,RP)" is the set of all interfaces on which the router has received (*,*,RP) Joins:
セット「ジョインは、（*、*、RP）」ルータが受信したすべてのインターフェイスのセットである（*、*、RP）は、ジョイン：
joins(*,*,RP) = { all interfaces I such that DownstreamJPState(*,*,RP,I) is either Join or Prune-Pending }
ジョイン（*、*、RP）= {すべてのインタフェースIようDownstreamJPStateは（*、*、RP、I）であることのいずれかで参加又はプルーン保留}
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 }
（*、G）加入= {すべてのインタフェースIようDownstreamJPState（*、G、I）がいずれかの参加又はプルーン保留されていることを}
DownstreamJPState(*,G,I) is the state of the finite state machine in Section 4.5.2.
DownstreamJPState（*、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 }
（S、G）加入= {すべてのインタフェースIようDownstreamJPState（S、Gは、I）であることのいずれかで参加又はプルーン保留}
DownstreamJPState(S,G,I) is the state of the finite state machine in Section 4.5.3.
DownstreamJPState（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.
セット "プルーン（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 }
プルーン（S、G、RPT）= {DownstreamJPState（S、Gは、RPTは、I）は、そのようなすべてのインターフェースであるIことプルーンまたはPruneTmp}
DownstreamJPState(S,G,rpt,I) is the state of the finite state machine in Section 4.5.4.
DownstreamJPState（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）アサートを失っています。マクロlost_assert（*、G、I）は、セクション4.6.5で定義されています。
lost_assert(*,G) = { all interfaces I such that lost_assert(*,G,I) == TRUE }
lost_assert（*、G）= {すべてのインタフェースはIようlost_assert（*、G、I）== TRUE}
The set "lost_assert(S,G,rpt)" is the set of all interfaces on which the router has received (*,G) joins but has lost an (S,G) assert. The macro lost_assert(S,G,rpt,I) is defined in Section 4.6.5.
セット「lost_assert（S、G、RPT）」は、ルータが受信したすべてのインターフェイスのセット（*、G）が加入されているが（S、G）アサートを失っています。マクロlost_assert（S、G、RPTは、I）は、セクション4.6.5で定義されています。
lost_assert(S,G,rpt) = { all interfaces I such that lost_assert(S,G,rpt,I) == TRUE }
lost_assert（S、G、RPT）= {すべてのインタフェースIようlost_assert（S、G、RPT、I）== TRUE}
The set "lost_assert(S,G)" is the set of all interfaces on which the router has received (S,G) joins but has lost an (S,G) assert. The macro lost_assert(S,G,I) is defined in Section 4.6.5.
セット「lost_assert（S、G）」は、ルータが受信したすべてのインタフェースのセット（S、G）が加入されているが、（S、G）アサートを失っています。マクロlost_assert（S、G、I）は、セクション4.6.5で定義されています。
lost_assert(S,G) = { all interfaces I such that lost_assert(S,G,I) == TRUE }
lost_assert（S、G）= {すべてのインタフェースはIよう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.
次の擬似コードマクロ定義はまた、仕様の多くの場所で使用されています。 PIM-アサートが隣人の通常の選択をオーバーライドしている場合を除き基本的には、RPFは、」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) ) ) } }
隣接RPF '（*、G）{（）I_Am_Assert_Loser（*、G、RPF_interface（RP（G）））であれば{AssertWinnerを返す（G、*、RPF_interface（RP（G）））}他{（RPF_interface（NBRを返します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 '（S、G、RPT）{IF（I_Am_Assert_Loser（S、G、RPF_interface（RP（G））））{戻りAssertWinner（S、Gは、RPF_interface（RP（G）））}他{RPFを返します' （*、G）}}隣接RPF '（S、G）{IF（I_Am_Assert_Loser（S、G、RPF_interface（S）））{AssertWinnerを返す（S、G、RPF_interface（S））}他{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）に参加アクティブ状態を持っている場合は、私たちは '（S、G、RPT）をRPFからのパケットを受け入れ、定期的な参加（*、G）メッセージにプルーン（S、G、RPT）を追加する必要があること我々は（セクション4.5.8を参照）RPF '（*、G）に送ります。
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によって示されるように機能MRIB.next_hop（S）は、ホストSに向かって次のホップPIMネイバーのアドレスを返します。 Sが直接的に隣接している場合、MRIB.next_hop（S）はNULLを返します。 G用RPでは、MRIB.next_hop（RP（G））はNULLを返します。
The function NBR( I, A ) uses information gathered through PIM Hello messages to map the IP address A of a directly connected PIM neighbor router on interface I to the primary IP address of the same router (Section 4.3.4). The primary IP address of a neighbor is the address that it uses as the source of its PIM Hello messages. Note that a neighbor's IP address may be non-unique within the PIM neighbor database due to scope issues. The address must, however, be unique amongst the addresses of all the PIM neighbors on a specific interface.
機能NBR（I、A）は、同じルータ（4.3.4項）のプライマリIPアドレスへのインタフェースIに直接接続されているPIMネイバールータのIPアドレスAをマッピングするためにPIM Helloメッセージを通じて収集した情報を使用しています。隣人のプライマリIPアドレスは、そのPIM Helloメッセージの送信元として使用するアドレスです。ネイバーのIPアドレスは、スコープの問題に起因するPIMネイバーデータベース内の非一意であることに注意してください。アドレスは、しかし、特定のインターフェイス上のすべての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の（S、G）のために（セクション4.6.1で）アサート状態マシンは "私は敗者をアサートしています" 状態である場合にI_Am_Assert_Loser（S、G、I）が真です。
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のために（セクション4.6.2で）アサートステートマシン（*、G）は "私は敗者をアサートしています" 状態にある場合I_Am_Assert_Loserは（*、Gは、I）が真です。
The PIM-SM packet forwarding rules are defined below in pseudocode.
PIM-SMパケット転送ルールは、擬似コードで以下に定義されます。
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それはデカプセル化インターフェースであるRPを除いて、RPにパケットをルーティングするために使用される示すインタフェース（MRIBはS. RPF_interface（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.
第二に、我々は今、SPTにRPツリーから切り替えたのでSPTbitが設定されるべきかどうかを確認します。
Next, we check to see whether the packet should be accepted based on TIB state and the interface that the packet arrived on.
次に、我々はパケットがTIB状態とパケットが到着したインターフェイスに基づいて受け入れられるべきであるかどうかを確認します。
If the packet should be forwarded using (S,G) state, we then build an outgoing interface list for the packet. If this list is not empty, then we restart the (S,G) state Keepalive Timer.
パケットが（S、G）状態を使用して転送する必要がある場合、我々はその後、パケットの発信インターフェイスリストを構築します。このリストが空でない場合は、我々は（S、G）状態キープアライブタイマーを再起動します。
If the packet should be forwarded using (*,*,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（DirectlyConnected（S）== TRUE AND IIF == RPF_interface（S））{設定KeepaliveTimer（S、G）Keepalive_Period位注：：レジスタ状態遷移又はUpstreamJPState（IIFインターフェース上のGに対するSからデータを受信しますS、G）は＃遷移＃KeepaliveTimerを再起動の結果として起こるかもしれない、そしてここで扱われなければなりません。 }
if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined AND inherited_olist(S,G) != NULL ) { set KeepaliveTimer(S,G) to Keepalive_Period }
場合（IIF == RPF_interface（S）AND UpstreamJPState（S、G）==参加し、引き継いでいる_olist（S、G）！= NULL）{Keepalive_PeriodにKeepaliveTimer（S、G）を設定}
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 } }
IF（IIF == RPF_interface（S）AND SPTbit（S、G）== TRUE）{oiflist =引き継いでいる_olist（S、G）}そうであれば（IIF == RPF_interface（RP（G））AND SPTbit（S、G） == FALSE）{oiflist =引き継いでいる_olistは（S、G、RPT）CheckSwitchToSpt（S、G）}他{＃注：RPFチェックがアサートFSMの遷移がアサート（S、G）＃またはアサートする（引き起こす可能性が＃失敗しました*、G）メッセージは、インターフェイスIIFを送出します。 ＃詳細については、セクション4.6を参照してください。 （TRUE AND IIF SPTbit（S、G）==が（S、G）引き継いでいる_olistにある）場合（SPTbit（S、G）は== FALSE AND IIFは引き継いでいる_olistであれば他{IIFにアサート（S、G）を送信} （S、G、RPT）} {IIFにアサート（*、G）を送信}
oiflist = oiflist (-) iif forward packet on all interfaces in oiflist
oiflist = oiflist（ - ）oiflist内のすべてのインターフェイス上でIIF転送パケット
This pseudocode employs several "macro" definitions:
この擬似コードは、いくつかの「マクロ」の定義を採用しています。
DirectlyConnected(S) is TRUE if the source S is on any subnet that is directly connected to this router (or for packets originating on this router).
ソースSは、直接ルータ（またはこのルータに発信パケット用）に接続されている任意のサブネット上にある場合DirectlyConnected（S）がTRUEです。
inherited_olist(S,G) and inherited_olist(S,G,rpt) are defined in Section 4.1.
引き継いでいる_olist（S、G）と引き継いでいる_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.
基本的に、引き継いでいる_olist（S、G）が（S、G）状態に転送されるパケットのための発信インターフェイスリスト等、アサート状態（*、*、RP）状態、（*、G）を考慮し、あります
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.
引き継いでいる_olist（S、G、RPT）を、（S、G、RPT）状態をプルーニング考慮し、アサート等（*、*、RP）に転送されるパケットまたは（*、G）ステートのための発信インターフェイスリストであります
Update_SPTbit(S,G,iif) is defined in Section 4.2.2.
Update_SPTbit（S、G、IIF）は、セクション4.2.2で定義されています。
CheckSwitchToSpt(S,G) is defined in Section 4.2.1.
CheckSwitchToSpt（S、G）は、セクション4.2.1で定義されています。
UpstreamJPState(S,G) is the state of the finite state machine in Section 4.5.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 } }
（！ - ）pim_exclude（S、G）（+）pim_include（S、G）= NULL）AND SwitchToSptDesired（S、G）（pim_include（*、G）（）{＃注CheckSwitchToSpt（S、G）{場合は無効：KATを再起動するとKeepaliveTimer Keepalive_Periodに（S、G）}}設定SPTスイッチもたらします
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）は、実装が定義されているポリシー関数です。 「無限の閾値」ポリシーは、すべての時間をfalseを返す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ツリーから切り替えるときに上流（S、G）状態の間、確立されている間にデータが（*、*、RP）/（*、G）ステートを上流による到着したとき、移行期間がありますその時間のルータは（*、*、RP）/（*、G）状態に転送するために継続すべきです。これは、アップストリーム（S、G）状態が確立される前に終了したプルーン（S、G、RPT）を送信することに起因する一時的なブラックホールを防止します。
Thus, when a packet arrives, the (S,G) SPTbit is updated as follows:
パケットが到着したときに次のようにこのようにして、（S、G）SPTbitが更新されます。
void Update_SPTbit(S,G,iif) { if ( iif == RPF_interface(S) AND JoinDesired(S,G) == TRUE AND ( DirectlyConnected(S) == TRUE OR RPF_interface(S) != RPF_interface(RP(G)) OR inherited_olist(S,G,rpt) == NULL OR ( ( RPF'(S,G) == RPF'(*,G) ) AND ( RPF'(S,G) != NULL ) ) OR ( I_Am_Assert_Loser(S,G,iif) ) { Set SPTbit(S,G) to TRUE } }
空Update_SPTbit（S、G、IIF）{場合（IIF == RPF_interface（S）AND TRUE JoinDesired（S、G）== AND（DirectlyConnected（S）== TRUE OR RPF_interface（S）！= RPF_interface（RP（G ））OR引き継いでいる_olist（S、G、RPT）== NULL OR（（RPF '（S、G）== RPF'（*、G））AND（RPF '（S、G）！= NULL））OR（ I_Am_Assert_Loser（S、G、IIF））{trueに設定SPTbit（S、G）}}
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).
また、ルータ（セクション4.6.1を参照）は、それがRPF_interface（S）上にアサート（S、G）を受信したときのように、他の場合にはTRUEにSPTbit（S、G）を設定することができます。
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.
JoinDesired（S、G）は、セクション4.5.7で定義されており、我々は適切な（S、G）上流の参加（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の正しいアップストリームインターフェイスに到着した場合は、適切な（S、G）は状態に参加し、持っている場合は、次の条件の1つ以上が当てはまる場合は基本的に、Update_SPTbitはSPTbitを設定します：
1. The source is directly connected, in which case the switch to the SPT is a no-op.
1.ソースが直接SPTへのスイッチは何もしません、その場合、接続されています。
2. The RPF interface to S is different from the RPF interface to the RP. The packet arrived on RPF_interface(S), and so the SPT must have been completed.
2. SへのRPFインターフェイスはRPへのRPFインターフェイスは異なっています。パケットはRPF_interface（S）に到着し、そのSPTが完了している必要があります。
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）が異なる場合には、我々は示しアサート（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.
JoinDesired（S、G）がFALSEになったときSPTbitは（S、G）上流の状態マシンでクリアされる（セクション4.5.7参照）。
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ルータを有することができます。これらのルータの単一のもの、DRは、PIM-SMプロトコルに対して直接接続されたホストに代わって行動します。 LANおよびポイントツーポイントインターフェイスとの間の区別が時々ぼかすことができ、ルータは、マルチキャストホスト機能を有することができるので、PIM-SM仕様は、二つを区別しないからです。したがって、DRの選出は、すべてのインターフェイス、LANまたはそれ以外で発生します。
DR election is performed using Hello messages. Hello messages are also the way that option negotiation takes place in PIM, so that additional functionality can be enabled, or parameters tuned.
DRの選出は、Helloメッセージを使用して行われます。 helloメッセージは、追加機能が有効、またはパラメータを調整することができるように、オプションのネゴシエーションは、PIMで行われること方法です。
PIM Hello messages are sent periodically on each PIM-enabled interface. They allow a router to learn about the neighboring PIM routers on each interface. Hello messages are also the mechanism used to elect a 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).
ハローメッセージは、物理的なポイントツーポイントリンクを含む、すべてのアクティブなインターフェイス上で送信され、そして（「224.0.0.13」のIPv4および「FF02 :: D」IPv6のための「ALL-PIM-ルータのグループアドレスにマルチキャストされなければなりません）。
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がインターフェイスまたはルータ最初の始まりで有効になっている場合は、そのインターフェイスのhelloタイマーが0とTriggered_Hello_Delay間のランダムな値に設定されています。複数のルータが同時に電源が入っている場合、これはHelloメッセージの同期化を防ぐことができます。最初の無作為化間隔の後、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.
彼らが最初にそのルータからHelloメッセージを聞いたことがない限り、隣人が参加/プルーンを受け入れるか、またはルータからのメッセージを主張しないことに注意してください。したがって、ルータが参加/プルーンを送信するか、それはまだ現在設定されているIPアドレスを持つHelloメッセージを送信していない、それはすぐにhelloタイマーを待たずに、関連のHelloメッセージを送らなければなりませんしたインターフェイス上でメッセージをアサートする必要がある場合期限切れになるように、参加/プルーンまたはアサートメッセージが続きます。
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オプションにはDR優先順位が明示的にそのインターフェイスに設定されていない場合でも、すべての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ビット値を含みます。新しいられたGenIDでHelloメッセージがネイバーから受信した場合、その隣人についての古いこんにちは情報は破棄され、新しい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プルーン遅延オプションは、マルチアクセスLAN上で送信されるすべてのHelloメッセージに含まれるべきです。このオプションは、プルーン、保留中の設定に影響を与えるPROPAGATION_DELAYとOverride_Intervalのデフォルト以外の値を使用するようにルータの機能をアドバタイズし、上流参加、およびタイマーをオーバーライドします（4.10節で定義されています）。
The Address List Option advertises all the secondary addresses associated with the source interface of the router originating the message. The option MUST be included in all Hello messages if there are secondary addresses associated with the source interface and MAY be omitted if no secondary addresses exist.
アドレス一覧のオプションは、メッセージを発信するルータの送信元インターフェイスに関連付けられているすべてのセカンダリアドレスをアドバタイズします。オプションでは、送信元インターフェイスに関連付けられているセカンダリアドレスがある場合は、すべてのHelloメッセージに含まれなければならないと何のセカンダリアドレスが存在しない場合は省略されるかもしれません。
To allow new or rebooting routers to learn of PIM neighbors quickly, when a Hello message is received from a new neighbor, or a Hello message with a new GenID is received from an existing neighbor, a new Hello message should be sent on this interface after a randomized delay between 0 and Triggered_Hello_Delay. This triggered message need not change the timing of the scheduled periodic message. If a router needs to send a Join/Prune to the new neighbor or send an Assert message in response to an Assert message from the new neighbor before this randomized delay has expired, then it MUST immediately send the relevant Hello message without waiting for the Hello Timer to expire, followed by the Join/Prune or Assert message. If it does not do this, then the new neighbor will discard the Join/Prune or Assert message.
Helloメッセージは、既存のネイバーから受信された新しい隣人、または新規られたGenIDとHelloメッセージから受信したときに、新規または再起動するルータが迅速PIMネイバーの学ぶことができるようにするには、新しいHelloメッセージがこのインタフェースの後に送られるべきです0とTriggered_Hello_Delay間無作為化遅延。このトリガーメッセージは、スケジュール定期的なメッセージのタイミングを変更する必要はありません。ルータが参加/この無作為化遅延が経過する前に、それはすぐにこんにちはを待たずに、関連のHelloメッセージを送らなければなりません新しいネイバーにプルーニングしたり、新しい隣人からのAssertメッセージに応答してアサートメッセージを送信を送信する必要がある場合有効期限が切れるようにタイマー、参加/プルーンが続いたり、メッセージをアサートします。それはこれをしない場合、新しい隣人は参加/プルーンを破棄するか、メッセージをアサートします。
Before an interface goes down or changes primary IP address, a Hello message with a zero HoldTime should be sent immediately (with the old IP address if the IP address changed). This will cause PIM neighbors to remove this neighbor (or its old IP address) immediately. After an interface has changed its IP address, it MUST send a Hello message with its new IP address. If an interface changes one of its secondary IP addresses, a Hello message with an updated Address_List option and a non-zero HoldTime should be sent immediately. This will cause PIM neighbors to update this neighbor's list of secondary addresses immediately.
インターフェイスがダウンしたり、変更のプライマリIPアドレス行く前に（IPアドレスが変更された場合、古いIPアドレスを使用して）、ゼロたHoldTimeとHelloメッセージを直ちに送信する必要があります。これは、PIMネイバーはすぐにこの隣人（またはその古いIPアドレス）を削除します。インターフェイスは、そのIPアドレスを変更した後は、その新しいIPアドレスでHelloメッセージを送らなければなりません。インターフェースは、そのセカンダリIPアドレスのいずれかを変更した場合、更新ADDRESS_LISTオプションと非ゼロのHoldTimeとHelloメッセージを直ちに送信する必要があります。これは、PIMネイバーがすぐにセカンダリアドレスのこの隣人のリストを更新するようになります。
When a PIM Hello message is received on interface I, the following information about the sending neighbor is recorded:
PIM Helloメッセージが、私はインターフェイス上で受信されると、送信隣人について、以下の情報が記録されます。
neighbor.interface The interface on which the Hello message arrived.
Helloメッセージが到着したインターフェイスをneighbor.interface。
neighbor.primary_ip_address The IP address that the PIM neighbor used as the source address of the Hello message.
neighbor.primary_ip_address PIMネイバーがHelloメッセージの送信元アドレスとして使用するIPアドレス。
neighbor.genid The Generation ID of the PIM neighbor.
neighbor.genid PIMネイバーの生成ID。
neighbor.dr_priority The DR Priority field of the PIM neighbor, if it is present in the Hello message.
neighbor.dr_priority PIMネイバーのDR Priorityフィールド、それはHelloメッセージに存在している場合。
neighbor.dr_priority_present A flag indicating if the DR Priority field was present in the Hello message.
DRプライオリティフィールドは、Helloメッセージに存在したかどうかを示すフラグをneighbor.dr_priority_present。
neighbor.timeout A timer value to time out the neighbor state when it becomes stale, also known as the Neighbor Liveness Timer.
また、近隣ライブネスタイマーとして知られ、それは古くなった隣人の状態アウト時にタイマー値、neighbor.timeout。
The Neighbor Liveness Timer (NLT(N,I)) is reset to
Hello_Holdtime (from the Hello Holdtime option) whenever a
Hello message is received containing a Holdtime option, or to
Default_Hello_Holdtime if the Hello message does not contain
the Holdtime option.
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 }
ホストDR（I）{DR =私インターフェイス上の各隣接するためのI {IF（dr_is_better（隣人、DR、I）== TRUE）{DR =隣接}}戻りDR}
The function used for comparing DR "metrics" on interface I is:
インタフェースIにDR「メトリクス」を比較するために使用する関数は次のようになります。
bool dr_is_better(a,b,I) { if( there is a neighbor n on I for which n.dr_priority_present is false ) { return a.primary_ip_address > b.primary_ip_address } else { return ( a.dr_priority > b.dr_priority ) OR ( a.dr_priority == b.dr_priority AND a.primary_ip_address > b.primary_ip_address ) } }
ブールdr_is_better（A、B、I）{{戻りa.primary_ip_address> b.primary_ip_address}他{リターン（a.dr_priority> b.dr_priority）（n.dr_priority_presentが偽されたIに隣接nが存在する）場合、または（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 }
BOOL I_am_DR（I）{DR（I）を返す==私}
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ビットの符号なしの数であり、数値的により大きな優先順位を常に好ましいです。 PIM Helloメッセージは、ときネイバータイムアウトする場合、またはルータ自身のDR優先順位の変更を受信したときのインターフェイスの現在の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選挙を行うことができないことに注意してください。これは、非準拠の動作です。 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:
DR選挙のために記録された情報に加えて、以下の隣あたりの情報は、LANプルーン遅延こんにちはオプションから取得されます。
neighbor.lan_prune_delay_present A flag indicating if the LAN Prune Delay option was present in the Hello message.
LANプルーンDelayオプションは、Helloメッセージに存在したかどうかを示すフラグをneighbor.lan_prune_delay_present。
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.
それはHelloメッセージに存在する場合LANプルーン遅延オプションでTビットの値を格納するフラグneighbor.tracking_support。これは、メッセージ抑制に参加し無効にする隣人の能力を示します。
neighbor.propagation_delay The Propagation Delay field of the LAN Prune Delay option (if present) in the Hello message.
HelloメッセージにおけるLANプルーンDelayオプション（存在する場合）の伝播遅延フィールドをneighbor.propagation_delay。
neighbor.override_interval The Override_Interval field of the LAN Prune Delay option (if present) in the Hello message.
HelloメッセージにおけるLANプルーンDelayオプション（存在する場合）のOverride_Intervalフィールドneighbor.override_interval。
The additional state described above is deleted along with the DR neighbor state when the neighbor timeout expires.
近隣タイムアウトが満了すると、上述の追加の状態は、DR隣人状態と共に削除されます。
Just like the DR_Priority option, the information provided in the LAN Prune Delay option is not used unless all neighbors on a link advertise the option. The function below computes this state:
リンク上のすべてのネイバーがオプションを宣伝しない限り、ちょうどDR_Priorityオプションと同様に、LANプルーンDelayオプションで提供される情報は使用されません。以下の関数は、この状態を計算します。
bool lan_delay_enabled(I) { for each neighbor on interface I { if ( neighbor.lan_prune_delay_present == false ) { return false } } return true }
BOOL lan_delay_enabled（I）{Iは{場合（neighbor.lan_prune_delay_presentは==偽）{falseを返すインターフェイス上の各隣接ため}} 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プルーンDelayオプションでルータによって挿入された伝搬遅延はリンク上で予想されるメッセージの伝播遅延を発現し、システム管理者が設定する必要があります。彼らはインターフェイスを剪定する前に、参加オーバーライド・メッセージを待機する時間を把握するために、上流ルータによって使用されます。
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:
リンク上のすべてのルータがデフォルトと異なる伝搬遅延を交渉する立場にある場合は、各隣接によってアドバタイズたものから最大値が選択されています。インタフェースのEffective_Propagation_Delayを計算するための関数がIであります：
time_interval Effective_Propagation_Delay(I) { if ( lan_delay_enabled(I) == false ) { return Propagation_delay_default } delay = Propagation_Delay(I) for each neighbor on interface I { if ( neighbor.propagation_delay > delay ) { delay = neighbor.propagation_delay } } return delay }
TIME_INTERVAL Effective_Propagation_Delay（I）{IF（lan_delay_enabled（I）== false）を返す{Propagation_delay_default}遅延= PROPAGATION_DELAYインタフェースI {IF（neighbor.propagation_delay>遅延）{遅延= neighbor.propagation_delay}}戻りの各隣人のため（I）遅延}
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.
複数のダウンストリームルータがマルチアクセスリンクを共有する場合、オーバーライドメッセージの同期化を避けるために、このようなメッセージの送信は、時間の小さなランダム量だけ遅延されます。ランダム化の期間は、リンク上のPIMルータ人口の大きさを表している必要があります。各ルータはLANプルーンDelayオプションのオーバーライドIntervalフィールドの必要なランダム化の量のその見解を表現しています。
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 }
TIME_INTERVAL Effective_Override_Interval（I）{IF（lan_delay_enabled（I）==偽）{戻りt_override_default}遅延= Override_Intervalインターフェイス上の各隣人のため（I）I {IF（neighbor.override_interval>遅延）{遅延= neighbor.override_interval}}リターン遅延}
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プルーン遅延こんにちはオプションで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 }
BOOL Suppression_Enabled（I）{IF（lan_delay_enabled（I）== false）を{Iは{場合（neighbor.tracking_supportは==偽）{trueを返す}} falseを返すインターフェイス上の各隣接ため} trueを返します}
Note that the setting of Suppression_Enabled(I) affects the value of t_suppressed (see Section 4.10).
（4.10節を参照）Suppression_Enabled（I）の設定がt_suppressedの値に影響することに注意してください。
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メッセージの中に運ばれます。ルータのソースインターフェイスのプライマリアドレスは、アドレス一覧のHelloオプションの中にリストされてはなりません。
In addition to the information recorded for the DR Election, the following per neighbor information is obtained from the Address List Hello option:
DR選挙のために記録された情報に加えて、以下の隣あたりの情報は、アドレス一覧のHelloオプションから取得されます。
neighbor.secondary_address_list The list of secondary addresses used by the PIM neighbor on the interface through which the Hello message was transmitted.
neighbor.secondary_address_list Helloメッセージが送信された介してインターフェイス上のPIMネイバーによって使用される二次アドレスのリスト。
When processing a received PIM Hello message containing an Address List Hello option, the list of secondary addresses in the message completely replaces any previously associated secondary addresses for that neighbor. If a received PIM Hello message does not contain an Address List Hello option, then all secondary addresses associated with the neighbor must be deleted. If a received PIM Hello message contains an Address List Hello option that includes the primary address of the sending router in the list of secondary addresses (although this is not expected), then the addresses listed in the message, excluding the primary address, are used to update the associated secondary addresses for that neighbor.
アドレス一覧のHelloオプションを含む受信PIM Helloメッセージを処理するとき、メッセージ中の二次アドレスのリストは、完全にその隣人のために以前に関連付けられているセカンダリアドレスを置き換えます。受信PIM Helloメッセージは、アドレス一覧のHelloオプションが含まれていない場合は、ネイバーに関連付けられたすべてのセカンダリアドレスを削除する必要があります。受信PIM Helloメッセージは、アドレス一覧のHello（これが期待されていないが）、二次アドレスのリストにある送信ルータのプライマリアドレスを含んオプションが含まれている場合は、そのメッセージに記載されているアドレスは、プライマリアドレスを除いて、使用されていますその隣人のための関連するセカンダリアドレスを更新します。
All the advertised secondary addresses in received Hello messages must be checked against those previously advertised by all other PIM neighbors on that interface. If there is a conflict and the same secondary address was previously advertised by another neighbor, then only the most recently received mapping MUST be maintained, and an error message SHOULD be logged to the administrator in a rate-limited manner.
こんにちは、受信したメッセージのすべての広告を出してセカンダリアドレスは、以前にそのインターフェイス上の他のすべてのPIMネイバーによってアドバタイズたものと照合しなければなりません。衝突と同一の二次アドレスがある場合は、以前に別の隣人によってアドバタイズした後、唯一の最も最近に受信されたマッピングを維持しなければならない、エラーメッセージがレート制限された方法で管理者にログインする必要があります。
Within one Address List Hello option, all the addresses MUST be of the same address family. It is not permitted to mix IPv4 and IPv6 addresses within the same message. In addition, the address family of the fields in the message SHOULD be the same as the IP source and destination addresses of the packet header.
1本のアドレス一覧こんにちはオプションの中で、すべてのアドレスが同じアドレスファミリーのものでなければなりません。同じメッセージ内のIPv4アドレスとIPv6アドレスを混在することは許されません。加えて、メッセージ内のフィールドのアドレスファミリーは、パケットヘッダのIP送信元アドレスと宛先アドレスと同じでなければなりません。
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.
それは最近登録 - ストップそのためのメッセージ（S、G）または（*、Gを受けない限り、LAN又はポイントツーポイントリンク上の指定ルータ（DR）は、関連するグループのためのRPにローカルソースからマルチキャストパケットをカプセル化）RPから。 DRは、RPからRegister-Stopメッセージを受信すると、それはこの状態を維持するために登録するストップタイマーを開始します。登録ストップタイマーの期限が切れる直前に、DRはRPがDRで登録ストップ情報を更新できるようにするためにRPにヌル登録メッセージを送信します。登録ストップタイマーが実際に有効期限が切れた場合、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すべき能力を持っています。以下のステートマシンは、登録機能を実装するために使用されます。明細書の目的のために、我々は、追加または（S、G）OLISTから除去されるレジスタトンネルインタフェースとしてRPにパケットをカプセル化するメカニズムを表します。セクション4.2で指定されたトンネルインターフェースは、通常のパケット転送ルールに関与します。
If register state is maintained, it is maintained only for directly connected sources and is per-(S,G). There are four states in the DR's per-(S,G) Register state machine:
レジスタ状態が維持される場合、それが直接接続されたソースに対してのみ維持され、（S、G）パーです。 DRのパー（S、G）ステートマシンを登録するには4つの状態があります。
Join (J) The register tunnel is "joined" (the join is actually implicit, but the DR acts as if the RP has joined the DR on the tunnel interface).
参加（J）レジスタトンネルは、（参加実際には暗黙的であるが、DRはRPトンネルインターフェイス上DRに参加しているかのように作用する）「接合」されます。
Prune (P) The register tunnel is "pruned" (this occurs when a Register-Stop is received).
（登録ストップを受信したときにこれが起こる）プルーン（P）レジスタトンネルは「剪定」されます。
Join-Pending (JP) The register tunnel is pruned but the DR is contemplating adding it back.
ジョイン・ペンディングレジスタトンネルがプルーニングされているが、DRに戻ってそれを追加検討している（JP）。
NoInfo (NI) No information. This is the initial state, and the state when the router is not the DR.
NoInfo（NI）情報なし。ルータがDRでないとき、これは初期状態、および状態です。
In addition, a Register-Stop Timer (RST) is kept if the state machine is not in the NoInfo state.
ステートマシンがNoInfo状態にされていない場合も、登録ストップタイマー（RST）が保たれています。
Figure 1: Per-(S,G) register state machine at a DR in tabular form
図1：パー（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）から一様に選択された値マイナス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.
(**) 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）はimmediate_olist（S、G）と引き継いでいる_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）のカプセル化対象と登録 - トンネルの仮想インターフェースです。 DownstreamJPState（S、G、VI）は、トンネルインターフェースがimmediate_olist（S、G）と引き継いでいる_olist（S、G）から除去させる、NoInfo状態に設定されています。 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状態に設定され、DownstreamJPState（S、G、VI_new）の状態に参加するように設定されています。 DownstreamJPState（S、G、VI_old）は全て（S、G）のためのNoInfoある場合、VI_oldを削除することができます。
Note that we cannot simply change the encapsulation target of VI_old because not all groups using that encapsulation tunnel will have moved to the same new RP.
そのカプセル化トンネルを使用していないすべてのグループが同じ新しいRPに移動しますので、我々は単にVI_oldのカプセル化目標を変更することはできません。
CouldRegister(S,G)
CouldRegister（S、G）
The macro "CouldRegister" in the state machine is defined as:
ステート・マシン内のマクロ「CouldRegisterは」のように定義されます。
bool CouldRegister(S,G) { return ( I_am_DR( RPF_interface(S) ) AND KeepaliveTimer(S,G) is running AND DirectlyConnected(S) == TRUE ) }
BOOL CouldRegister（S、G）{リターン（I_am_DR（RPF_interface（S））AND KeepaliveTimer（S、G）が実行され、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）は、レジスタ状態機械でCouldRegister（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は、トンネルの有効なMTUを決定するためにRPへのパスMTU探索を実行することができます。小さなMTUのフラグメンテーションは、外側IPヘッダおよびアカウントへPIMレジスタヘッダのオーバーヘッドの両方を取るべきです。マルチキャストパケットはレジスタトンネル内に途中で断片化されている場合、各フラグメントは、それがIP、PIM、および内側IPヘッダが含まれているように、個別にカプセル化されます。
In IPv6, the DR MUST perform Path MTU discovery, and an ICMP Packet Too Big message MUST be sent by the encapsulating DR if it receives a packet that will not fit in the effective MTU of the tunnel. If the MTU between the DR and the RP results in the effective tunnel MTU being smaller than 1280 (the IPv6 minimum MTU), the DR MUST send Fragmentation Required messages with an MTU value of 1280 and MUST fragment its PIM register messages as required, using an IPv6 fragmentation header between the outer IPv6 header and the PIM Register header.
IPv6では、DRは、パスMTU探索を実行しなければなりません、そして、それはトンネルの有効なMTUに収まらないパケットを受信した場合、ICMPパケット過大メッセージをカプセル化するDRによって送信されなければなりません。 DR及び有効なトンネルMTU 1280よりも小さい（IPv6の最小MTU）でRPの結果との間の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はすべてゼロに設定され、送信元アドレスを登録-Stopメッセージを送信することがあります。これは、RegisterメッセージをRPに（*、G）ステートに対して一致する場合、RFC 2362でのアクションの通常の過程であり、それは「このグループのすべてのソースをカプセル化ストップ」を意味するものとして定義されていました。しかし、そのような登録・停止（*、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は、それを受信した場合は、1つを受け入れることができるはずです。
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）は、すべてのためにレジスタストップ（S、G）（S、G）NoInfo状態にない状態レジスタマシンとして扱われるべきです。登録・停止（*、G）が受信された後にルータがアクティブになるソースに登録するストップ（*、G）を適用してはなりません。
When an RP receives a Register message, the course of action is decided according to the following pseudocode:
RPはRegisterメッセージを受信すると、アクションのコースは、以下の擬似コードに応じて決定されます。
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は、すなわち、DRのアドレスカプセル化ヘッダのIPソースアドレスです。
I_am_RP(G) is true if the group-to-RP mapping indicates that this router is the RP for the group.
グループ対RPマッピングはこのルータがグループのRPであることを示す場合I_am_RP（G）が真です。
Note (*): This may block traffic from S for Register_Suppression_Time if the DR learned about a new group-to-RP mapping before the RP did. However, this doesn't matter unless we figure out some way for the RP also to accept (*,G) joins when it doesn't yet realize that it is about to become the RP for G. This will all get sorted out once the RP learns the new group-to-rp mapping. We decided to do nothing about this and just accept the fact that PIM may suffer interrupted (*,G) connectivity following an RP change.
注（*）：DRがしたRP前に、新しいグループ-RPマッピングについて学んだ場合、これはRegister_Suppression_TimeのためのSからのトラフィックをブロックすることがあります。我々はまた、（*、G）を受け入れRPためのいくつかの方法を把握しない限り、それはまだすべてを一度整理れますG.このためRPになろうとしていることを認識していないときは、この結合は重要ではありません。 RPは、新しいグループ-RPマッピングを学習します。我々はこのことについて何もしないことを決定し、ちょうどPIMは、RPの変化を以下の中断（*、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.
注（+）：実装は、この特殊なケースにするために、このパスは、通常のパケット転送パスに再び参加することを手配しないことをお勧めします。 「IIFインターフェイス上のGに対するSからデータを受信すると、」セクション4.2の擬似コードが実行されなければならないから適切な行動の全て。
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.
パケットは適切なトンネルインタフェースに到着し、RPがSPTに切り替えることを望む又はSPTbitが既に設定されている場合KeepaliveTimer（S、G）がRPで再開されます。これは引き継いでいる_olist（S、G）がNULLでない場合参加トリガするために上流（S、G）ステートマシンを引き起こし得ます。
An RP should preserve (S,G) state that was created in response to a Register message for at least ( 3 * Register_Suppression_Time ); otherwise, the RP may stop joining (S,G) before the DR for S has restarted sending registers. Traffic would then be interrupted until the Register-Stop Timer expires at the DR.
RPは、少なくとも（3 * Register_Suppression_Time）用の登録メッセージに応答して作成された（S、G）状態を維持すべきです。そうでない場合、RPは、レジスタを送信する再起動したSのためのDRの前に（S、G）を接合停止してもよいです。登録・停止Timerが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参加/プルーンメッセージは、グループのリストと、各グループのメンバーと剪定ソースのリストから成ります。受信した参加/プルーンメッセージを処理するときに、グループの各メンバーまたはプルーニング源を効果的に個々に考えられ、以下の状態機械の一つ以上に適用されます。その上流隣接アドレスフィールドアドレスこのルータに参加/プルーンのメッセージ、（*、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.
それが知られているPIMネイバーから来る場合一般的には、PIMに参加/プルーンのメッセージは、処理のために受理されなければなりません。 PIMルータはPIM Helloメッセージを通じてPIMネイバーについて聞きます。ルータが特定の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 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.
（インターフェイスは、ルータがプルーン情報（S、G、RPT）も存在する場合を除いて、このインターフェイスからRPによって処理される任意のグループ宛てのパケットを転送するようになります（*、*、RP）参加状態、有する（J）に参加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.
有効な参加（*、*、RP）を受信したときにExpiryTimer（ET）このタイマーが再起動されます。 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.
有効なプルーン（*、*、RP）が受信されると、プルーン、保留タイマー（PPT）このタイマーが設定されています。プルーン-保留タイマーの有効期限は、このRPのためNoInfoに戻すためのインタフェースの状態を引き起こします。
Figure 2: Downstream per-interface (*,*,RP) state machine in tabular form
図2：表形式の下流インターフェイス単位（*、*、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.
遷移イベントは、受信したインターフェイス上でこのルータのプライマリIPアドレスを対象とJoinまたはプルーニング受け暗示「プルーン（*、*、RP）を受信」「（*、*、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.
ポイントツーポイントリンク上のアンナンバードインターフェイスでは、ルータのアドレスは、それがそのインターフェイスを介して送信されるHelloメッセージのために選択した送信元アドレスと同じでなければなりません。しかし、ポイントツーポイントリンク上で、我々はまた、後方互換性のPIMのためにも受け入れられているすべてゼロの上流隣接アドレスフィールドに/プルーンのメッセージに参加することをお勧めします。
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.
参加（*、*、RP）Aを受信（*、*、RP）に参加私はI.上のルータのプライマリIPアドレスに設定し、その上流隣接アドレスを持つインターフェイスで受信されます
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.
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）状態の場合には、あまりにも長い間、我々は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.
参加（*、*、RP）Aを受信（*、*、RP）に参加私はI.上のルータのプライマリIPアドレスに設定し、その上流隣接アドレスを持つインターフェイスで受信されます
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.
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.
受信プルーン（*、*、RP）Aプルーン（*、*、RP）は、私はI.上のルータのプライマリIPアドレスに設定し、その上流隣接アドレスを持つインターフェイスで受信されます
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.
Expiry Timer Expires The Expiry 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.
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.
参加（*、*、RP）Aを受信（*、*、RP）に参加私はI.上のルータのプライマリIPアドレスに設定し、その上流隣接アドレスを持つインターフェイスで受信されます
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.
Expiry Timer Expires The Expiry 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.
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.
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.
ルータはプルーンの結果としてインターフェイスに転送を停止したときにアクション「PruneEchoを送る（*、*、RP）は、」トリガされます。 PruneEchoは（*、*、RP）単に上流隣接アドレスフィールドに自身のアドレスをLAN上の上流のルータによって送られたプルーン（*、*、RP）メッセージです。その目的は、別のルータによって上書きされているはずプルーンは、LAN上でローカルに失われた場合、その後、PruneEchoを受信してオーバーライドが発生する原因となることができるように、追加の信頼性を追加することです。 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）Joinを受信すると、それは最初のメッセージ内のRPがRP（G）（RPが誰であるかのルータのアイデアを）一致するかどうかを確認しなければなりません。メッセージ内のRPがRP（G）、（*、G）参加に一致しない場合は黙って落とさなければなりません。 （例えば、同じグループ固有の設定では（S、G、RPT）または（S、G）、などの他のソースリストのエントリは、まだ処理されなければならないことに注意してください。）ルータは何のRP情報を持っていない場合（例えば、最近はしていませんそれは、*（G参加受け入れることを選択）とRP（G）としてメッセージにRPを扱うことができ、）BSRメッセージを受け取りました。メッセージ内のRPがRP（G）と一致しない場合でも、受信プルーン（*、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.
（4.5.4項を参照してください）インタフェースは（*、G）は、ルータは（S、G、RPT）プルーンの情報もある場合を除いて、このインターフェイスからG宛のパケットを転送するようになります状態を、参加している（J）に参加またはルータがこのインターフェイスでアサートを失いました。
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.
有効なプルーン（*、G）を受信したとき、プルーン、保留タイマー（PPT）このタイマーが設定されています。プルーン・保留タイマの満了は、このグループのNoInfoに戻す界面状態を引き起こします。
Figure 3: Downstream per-interface (*,G) state machine in tabular form
図3：表形式の下流インターフェイス単位（*、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.
遷移イベントは、「（*、G）が参加受信」と「プルーン（*、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.
ポイントツーポイントリンク上のアンナンバードインターフェイスでは、ルータのアドレスは、それがそのインターフェイスを介して送信されるHelloメッセージのために選択した送信元アドレスと同じでなければなりません。しかし、ポイントツーポイントリンク上で、我々はまた、後方互換性の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.
参加受信（*、G）Aは、（*、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.
Transitions from Join State
参加状態からの遷移
When in Join state, the following events may trigger a transition:
中には、国家に参加すると、次のイベントは、遷移を引き起こすことがあります。
Receive Join(*,G) A Join(*,G) is received on interface I with its Upstream Neighbor Address set to the router's primary IP address on I.
参加受信（*、G）Aは、（*、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.
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.
受信プルーン（*、G）Aプルーン（*、G）が、私はI.上のルータのプライマリIPアドレスに設定し、その上流隣接アドレスを持つインターフェイスで受信されます
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.
Expiry Timer Expires The Expiry Timer for the (*,G) downstream state machine on interface I expires.
有効期限タイマーIが満了するインターフェイスに（*、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.
参加受信（*、G）Aは、（*、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.
Expiry Timer Expires The Expiry Timer for the (*,G) downstream state machine on interface I expires.
有効期限タイマーIが満了するインターフェイスに（*、G）下流のステートマシンの有効期限タイマーが期限切れ。
The (*,G) downstream state machine on interface I transitions
to the NoInfo state.
Prune-Pending Timer Expires The Prune-Pending Timer for the (*,G) downstream state machine on interface I expires.
プルーン保留タイマーIが満了するインターフェイスに（*、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.
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.
ルータはプルーンの結果としてインタフェースに転送停止時アクション「PruneEcho（*、G）を送る」がトリガされます。 PruneEcho（*、G）は、単に上流隣接アドレスフィールドに自身のアドレスとLAN上の上流のルータによって送信されたプルーン（*、G）メッセージです。その目的は、別のルータによって上書きされているはずプルーンは、LAN上でローカルに失われた場合、その後、PruneEchoを受信してオーバーライドが発生する原因となることができるように、追加の信頼性を追加することです。 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.
NoInfo（NI）インタフェースには（S、G）の状態に参加していないとNO（S、G）タイマが動作していません。
Join (J) The interface has (S,G) Join state, which will cause the router to forward packets from S destined for G from this interface if the (S,G) state is active (the SPTbit is set) except if the router lost an assert on this interface.
参加（J）インターフェースが（S、G）状態がアクティブである場合、ルータは、このインターフェイスからG宛Sからパケットを転送します（S、G）参加状態は、（SPTbitが設定されている）を有している場合を除きルータは、このインターフェイスでアサートを失いました。
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.
有効な参加（S、G）を受信したときに有効期限タイマ（ET）このタイマーが設定されています。有効期限タイマーの有効期限は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.
有効なプルーン（S、G）を受信したときプルーンペンディングタイマ（PPT）このタイマは設定されています。プルーン-保留タイマーの有効期限は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.
遷移イベントは、「（S、G）に参加受信」し、受信したインターフェイス上でこのルータのプライマリIPアドレスを対象とJoinまたはプルーニング受け暗示「プルーン（S、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.
ポイントツーポイントリンク上のアンナンバードインターフェイスでは、ルータのアドレスは、それがそのインターフェイスを介して送信されるHelloメッセージのために選択した送信元アドレスと同じでなければなりません。しかし、ポイントツーポイントリンク上で、我々はまた、後方互換性の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.
（S、G）A参加（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.
Transitions from Join State
参加状態からの遷移
When in Join state, the following events may trigger a transition:
中には、国家に参加すると、次のイベントは、遷移を引き起こすことがあります。
Receive Join(S,G) A Join(S,G) is received on interface I with its Upstream Neighbor Address set to the router's primary IP address on I.
（S、G）A参加（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.
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.
受信プルーン（S、G）プルーン（S、G）が、私はI.上のルータのプライマリIPアドレスに設定し、その上流隣接アドレスを持つインターフェイスで受信されます
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.
Expiry Timer Expires The Expiry Timer for the (S,G) downstream state machine on interface I expires.
有効期限タイマーIが満了するインターフェイス上で（S、G）下流のステートマシンの有効期限タイマーが期限切れ。
The (S,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(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.
（S、G）A参加（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.
Expiry Timer Expires The Expiry Timer for the (S,G) downstream state machine on interface I expires.
有効期限タイマーIが満了するインターフェイス上で（S、G）下流のステートマシンの有効期限タイマーが期限切れ。
The (S,G) downstream state machine on interface I transitions
to the NoInfo state.
Prune-Pending Timer Expires The Prune-Pending Timer for the (S,G) downstream state machine on interface I expires.
プルーン保留タイマーIが満了するインターフェイスで（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.
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.
ルータはプルーンの結果としてインタフェースに転送停止時アクション「PruneEcho（S、G）を送る」がトリガされます。 PruneEcho（S、G）は、単に上流隣接アドレスフィールドに自身のアドレスとLAN上の上流のルータによって送信されたプルーン（S、G）メッセージです。その目的は、別のルータによって上書きされているはずプルーンは、LAN上でローカルに失われた場合、その後、PruneEchoを受信してオーバーライドが発生する原因となることができるように、追加の信頼性を追加することです。 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）インタフェースには（S、G、RPT）プルーン状態と、実行中の（S、G、RPT）タイマーを有していません。
Prune (P) The interface has (S,G,rpt) Prune state, which will cause the router not to forward packets from S destined for G from this interface even though the interface has active (*,G) Join state.
プルーン（P）インタフェースはインタフェースは（*、G）状態が参加し、アクティブ持っているにもかかわらず、このインターフェイスからG宛てSからのパケットを転送しないルータが発生します（S、G、RPT）プルーンの状態を、持っています。
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.
プルーン係属-TMP（PP「）この状態は、Pと同一である過渡状態である」はPPの状態ではなく、Pの状態に関連付けられていることを除い。転送のために、PPは」正確PP状態のように振る舞います。
In addition, there are two timers:
また、2つのタイマがあります。
Expiry Timer (ET) This timer is set when a valid Prune(S,G,rpt) is received. Expiry of the Expiry Timer causes this state machine to revert to NoInfo state.
有効なプルーン（S、G、RPT）を受信したときに有効期限タイマ（ET）このタイマーが設定されています。有効期限タイマーの有効期限は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.
有効なプルーン（S、G、RPT）を受信したときプルーンペンディングタイマ（PPT）このタイマは設定されています。プルーン-保留タイマーの有効期限は、この状態マシンが状態を剪定するために移動させます。
Figure 5: Downstream per-interface (S,G,rpt) state machine in tabular form
図5：表形式の下流あたりインタフェース（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.
遷移イベントは、「（S、G、RPT）を参加受信」、「（*、G）参加受信」「プルーン（S、G、RPT）を受信」、および入会受信暗示やプルーンがこのルータのプライマリ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 PIM Join/Prune messages with an upstream neighbor address field of all zeros are also accepted.
ポイントツーポイントリンク上のアンナンバードインターフェイスでは、ルータのアドレスは、それがそのインターフェイスを介して送信されるHelloメッセージのために選択した送信元アドレスと同じでなければなりません。しかし、ポイントツーポイントリンク上で、我々はまた、PIMも受け入れられているすべてゼロの上流隣接アドレスフィールドに/プルーンのメッセージに参加することをお勧めします。
Transitions from NoInfo State
NoInfo状態からの遷移
When in NoInfo (NI) state, the following event may trigger a transition:
NoInfoで（NI）状態、次のイベントが遷移をトリガすることができます。
Receive Prune(S,G,rpt) A Prune(S,G,rpt) is received on interface I with its Upstream Neighbor Address set to the router's primary IP address on I.
プルーン（S、G、RPT）を受信プルーン（S、G、RPTは）私はI.上のルータのプライマリIPアドレスに設定し、その上流隣接アドレスを持つインターフェイスで受信されます
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:
プルーン・保留（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.
参加受信（*、G）Aは、（*、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.
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.
（S、G、RPT）A参加（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.
プルーン保留タイマーIが満了するインターフェイスで（S、G、RPT）下流ステートマシンのプルーン・保留タイマー期限切れ。
The (S,G,rpt) downstream state machine on interface I
transitions to the Prune state.
Transitions from Prune State
プルーンの状態からの遷移
When in Prune (P) state, the following events may trigger a transition:
プルーンに（P）状態で、次のイベントが遷移をトリガすることができます。
Receive Join(*,G) A Join(*,G) is received on interface I with its Upstream Neighbor Address set to the router's primary IP address on I.
参加受信（*、G）Aは、（*、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.
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.
（S、G、RPT）A参加（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.
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.
プルーン（S、G、RPT）を受信プルーン（S、G、RPTは）私はI.上のルータのプライマリIPアドレスに設定し、その上流隣接アドレスを持つインターフェイスで受信されます
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.
Expiry Timer Expires The Expiry Timer for the (S,G,rpt) downstream state machine on interface I expires.
有効期限タイマーIが満了するインターフェイス上で（S、G、RPT）下流のステートマシンの有効期限タイマーが期限切れ。
The (S,G,rpt) downstream state machine on interface I
transitions to the NoInfo state.
Transitions from Prune-Pending-Tmp State
プルーン保留-TMPの状態からの遷移
When in Prune-Pending-Tmp (PP') state and processing a compound Join/Prune message, the following events may trigger a transition:
プルーン保留-TMP（PP '）状態と化合物処理/プルーンメッセージに参加すると、次のイベントが遷移をトリガすることができます。
Receive Prune(S,G,rpt) The compound Join/Prune message contains a Prune(S,G,rpt).
プルーン（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.
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.
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).
プルーン（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.
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.
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）下流のステートマシンには影響を与えません。ルータが（*、*、RP）に参加起源とプルーン（S、G、RPT）を使用して、それをオフソースを剪定している場合は、それが明示的に参加使用して再加入する必要があり、再びそのソースを受信する（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）を見れば、ほとんどすぐに参加（*、*、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.
MRIBの変更はRPへのネクストホップが変更されたことを示すためにあればまた、ルータは古いネクストホップからオフ剪定すべきであり、新しい次のホップの方に参加します。
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）は、それはRP、NBR（RPF_interface（RP）、MRIBに向けて上流の次のホップへの参加（*、*、RP）の送信をトリガするために使用されて保持されます。 NEXT_HOP（RP））。
Figure 6: Upstream (*,*,RP) state machine in tabular form
図6：表形式の上流（*、*、RP）状態マシン
+-------------------++-------------------------------------------------+
| || 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 }
BOOL JoinDesired（*、*、RP）{immediate_olist（*、*、RP）であればそうでない！= NULLリターンTRUEは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.
JoinDesiredは（*、*、RP）ルータが受信したとき（*、*、RP）真である任意のダウンストリームインターフェイスから参加します。 JoinDesiredが真であるが、ルータの送信参加（*、*、RP）メッセージの上流インタフェースに参加（*、*、RP）を送信する別のルータによって抑制することができることに留意されたいです。
Transitions from NotJoined State
NotJoined状態からの遷移
When the upstream (*,*,RP) state machine is in NotJoined state, the following event may trigger a state transition:
上流（*、*、RP）状態マシンはNotJoined状態にある場合、次のイベントは、状態遷移をトリガすることができます。
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.
少なくとも1つのインタフェースがJoinDesired（*、*、RP）を製造する、（*、*、RP）immediate_olistになるようJoinDesired（*、*、RP）が（*、*、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.
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.
JoinDesiredは（*、*、RP）（*、*、RP）はfalse下流状態となるJoinDesired（*、*、RP）がFalseになる作り、（*、*、RP）がインターフェイスがimmediate_olistにないよう変更されています。
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).
Join Timer Expires The Join Timer (JT) expires, indicating time to send a Join(*,*,RP)
タイマーは、時間を示すことに参加送信するために満了するタイマー（JT）が参加期限切れに参加（*、*、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.
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.
RPF_interface（RP）が共有メディアである場合、このイベントはのみ関連しMRIB.next_hop（RP）に（*、*、RP）に参加を参照してください。このルータは、NBR（RPF_interface（RP）、MRIB.next_hop（RP））に（RP）（*、*、RP）に参加を送るRPF_interfaceに別のルータを見ています。これは、このルータが参加し、独自のを抑制する原因となります。
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がt_suppressedの最小値と、このイベントをトリガ/プルーンに参加したメッセージからのHoldTimeとします。参加タイマーがt_joinsuppress秒未満で期限が切れるように設定されている場合、それはt_joinsuppress秒後に期限切れになるように、それをリセットします。参加タイマーが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）が共有メディアである場合、このイベントはのみ関連しMRIB.next_hop（RP）にプルーン（*、*、RP）を参照してください。このルータはRPF_interface上の別のルータを（RP）NBR（RPF_interface（RP）、MRIB.next_hop（RP））にプルーン（*、*、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.
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.
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.
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を見れば最終的に、ほとんどすぐにそれが上流の隣人が状態を失ったことを知っている、参加（*、G）を送信することにより、状態をリフレッシュするために準備する必要があり、正しい上流隣接変化（4.3節を参照してください） 。
If a (*,G) Assert occurs on the upstream interface, and this changes this router's idea of the upstream neighbor, it should be prepared to ensure that the Assert winner is aware of downstream routers by sending a Join(*,G) almost immediately.
（*、G）アサートがアップストリームインターフェイス上で発生し、これが上流の隣人のこのルータのアイデアを変更した場合、それがアサート勝者が参加（*、G）を送信することにより、下流のルータを認識していることを確認するために準備する必要があり、ほとんどすぐに。
In addition, if the MRIB changes to indicate that the next hop towards the RP has changed, and either the upstream interface changes or there is no Assert winner on the upstream interface, the router should prune off from the old next hop and join towards the new next hop.
また、MRIBの変更はRPへのネクストホップが変更されたことを示しており、いずれかのアップストリームインターフェイスの変更またはアップストリームインターフェイスにはアサート勝者が存在しないためにあれば、ルータは古いネクストホップからオフ剪定に向かって参加する必要があります新しい次のホップ。
The upstream (*,G) state machine only contains two states:
上流（*、G）ステートマシンは、2つの状態しか含まれています。
Not Joined The downstream state machines indicate that the router does not need to join the RP tree for this group.
参加していない下流のステートマシンは、ルータがこのグループのRPツリーに参加する必要がないことを示しています。
Joined The downstream state machines indicate that the router should join the RP tree for this group.
下流のステートマシンは、ルータがこのグループのRPツリーに参加する必要があることを示し入社。
In addition, one timer JT(*,G) is kept that is used to trigger the sending of a Join(*,G) to the upstream next hop towards the RP, RPF'(*,G).
さらに、1つのタイマJT（*、G）は、それが（*、G） 'RPF、RPに向かって上流の次のホップに参加（*、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 }
BOOL JoinDesired（*、G）{場合（immediate_olist（*、G）！= NULL OR（JoinDesired（*、*、RP（G））AND AssertWinner（*、G、RPF_interface（RP（G）））！= NULL ））} FALSEを返す他にTRUEを返します
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.
ルータは共有ツリーの状態を使用してGのためのトラフィックを転送させるような状態を転送したときJoinDesired（*、G）が真です。 JoinDesiredが真であるが、ルータの送信参加（*、G）メッセージの上流インタフェースに参加（*、G）を送信する別のルータによって抑制することができることに留意されたいです。
Transitions from NotJoined State
NotJoined状態からの遷移
When the upstream (*,G) state machine is in NotJoined state, the following event may trigger a state transition:
上流（*、G）ステートマシンはNotJoined状態にある場合、次のイベントは、状態遷移をトリガすることができます。
JoinDesired(*,G) becomes True The macro JoinDesired(*,G) becomes True, e.g., because the downstream state for (*,G) has changed so that at least one interface is in immediate_olist(*,G).
JoinDesiredは（*、G）は、少なくとも1つのインターフェースがimmediate_olist（*、G）となるようにするための下流の状態（*、G）が変更されたため、マクロJoinDesired（*、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.
Transitions from Joined State
接合状態からの遷移
When the upstream (*,G) state machine is in Joined state, the following events may trigger state transitions:
上流（*、G）ステートマシンは、接合状態にあるときに、次のイベントは、状態遷移をトリガすることができます。
JoinDesired(*,G) becomes False The macro JoinDesired(*,G) becomes False, e.g., because the downstream state for (*,G) has changed so no interface is in immediate_olist(*,G).
JoinDesired（*、G）がマクロJoinDesired（*、G）が偽となる偽となり、例えば、（*、G）のためのダウンストリーム状態ためにはインターフェースが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).
Join Timer Expires The Join Timer (JT) expires, indicating time to send a Join(*,G)
参加（*、G）を送信する時間を示すタイマタイマー（JT）が経過に参加期限参加
Send Join(*,G) to the appropriate upstream neighbor, which is
RPF'(*,G). Restart the Join Timer (JT) to expire after
t_periodic seconds.
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））が共有メディアである場合、このイベントにのみ関連している（G、*） "RPFに（G、*）に参加を参照してください。このルータはRPFに参加（*、G）を送るRPF_interface（RP（G））上の別のルータを見ている '（*、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がt_suppressedの最小値と、このイベントをトリガ/プルーンに参加したメッセージからのHoldTimeとします。参加タイマーがt_joinsuppress秒未満で期限が切れるように設定されている場合、それはt_joinsuppress秒後に期限切れになるように、それをリセットします。参加タイマーがt_joinsuppress秒以上で有効期限が切れるように設定されている場合、それは変わらないまま。
See Prune(*,G) to RPF'(*,G) This event is only relevant if RPF_interface(RP(G)) is a shared medium. This router sees another router on RPF_interface(RP(G)) send a Prune(*,G) to RPF'(*,G). As this router is in Joined state, it must override the Prune after a short random interval.
RPF_interface（RP（G））が共有メディアであるかどうかを確認プルーンRPFに（*、G） '（*、G）は、このイベントにのみ関係します。このルータはRPF_interface（RP（G））上の別のルータを見て（*、G）「RPFにプルーン（*、G）を送ります。このルータが参加状態にあるとして、それは短いランダムな間隔の後にプルーンをオーバーライドする必要があります。
The upstream (*,G) state machine remains in Joined state. If
the Join Timer is set to expire in more than t_override
seconds, reset it so that it expires after t_override seconds.
If the Join Timer is set to expire in less than t_override
seconds, leave it unchanged.
RPF'(*,G) changes due to an Assert The current next hop towards the RP changes due to an Assert(*,G) on the RPF_interface(RP(G)).
RPF '（*、G）によりRPF_interfaceにアサート（*、G）（RP（G））にアサートRP変化に向かって現在の次のホップによる変化。
The upstream (*,G) state machine remains in Joined state. If
the Join Timer is set to expire in more than t_override
seconds, reset it so that it expires after t_override seconds.
If the Join Timer is set to expire in less than t_override
seconds, leave it unchanged.
RPF'(*,G) changes not due to an Assert An event occurred that caused the next hop towards the RP for G to change. This may be caused by a change in the MRIB routing database or the group-to-RP mapping. Note that this transition does not occur if an Assert is active and the upstream interface does not change.
RPF '（*、G）イベントをアサートによるものではない変更はGが変化するためにRPに向けて次のホップを引き起こしたこと起こりました。これはMRIBルーティングデータベースまたはグループ対RPマッピングの変化によって引き起こされ得ます。アサートがアクティブであり、アップストリームインターフェイスが変更されない場合は、この遷移が発生しないことに留意されたいです。
The upstream (*,G) state machine remains in Joined state.
Send Join(*,G) to the new upstream neighbor, which is the new
value of RPF'(*,G). Send Prune(*,G) to the old upstream
neighbor, which is the old value of RPF'(*,G). Use the new
value of RP(G) in the Prune(*,G) message or all zeros if RP(G)
becomes unknown (old value of RP(G) may be used instead to
improve behavior in routers implementing older versions of
this spec). Set the Join Timer (JT) to expire after
t_periodic seconds.
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）が変化する '（*、G）られたGenIDはRPFあるルータの世代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.
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に向けた正しい上流の隣人にプルーン（S、G）、プルーン（S、G、RPT）、またはプルーン（*、G）を見れば、参加（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.
（S、G）アサートがアップストリームインターフェイス上で発生し、これが上流の隣人のこのルータのアイデアを変更した場合、アサート勝者が参加（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
図8：表形式の上流（S、G）ステートマシン
+-------------------+--------------------------------------------------+
| | Event |
| Prev State +-------------------------+------------------------+
| | JoinDesired(S,G) | JoinDesired(S,G) |
| | ->True | ->False |
+-------------------+-------------------------+------------------------+
| NotJoined (NJ) | -> J state | - |
| | Send Join(S,G); | |
| | Set Join Timer to | |
| | t_periodic | |
+-------------------+-------------------------+------------------------+
| Joined (J) | - | -> NJ state |
| | | Send Prune(S,G); |
| | | Set SPTbit(S,G) to |
| | | FALSE; Cancel Join |
| | | Timer |
+-------------------+-------------------------+------------------------+
In addition, we have the following transitions, which occur within the Joined state:
また、当社は、接合状態内で発生し、次の遷移を、持っています：
+----------------------------------------------------------------------+
| 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 ) ) }
BOOL JoinDesired（S、G）{リターン（immediate_olist（S、G）！= NULL OR（KeepaliveTimer（S、G）が実行され、引き継いでいる_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.
ルータは、それがソースツリーの状態を使用してGのためのトラフィックを転送させるような状態を転送したときJoinDesired（S、G）が真です。ソースツリーの状態がいずれかのアクティブソース固有参加状態、または（S、G）キープアライブタイマー及びアクティブ非ソース固有の状態の結果であり得ます。 JoinDesiredが真であるが、ルータの送信参加（S、G）メッセージの上流インタフェースに参加する（S、G）を送信する別のルータによって抑制することができることに留意されたいです。
Transitions from NotJoined State
NotJoined状態からの遷移
When the upstream (S,G) state machine is in NotJoined state, the following event may trigger a state transition:
アップストリーム（S、G）ステートマシンはNotJoined状態にある場合、次のイベントは、状態遷移をトリガすることができます。
JoinDesired(S,G) becomes True The macro JoinDesired(S,G) becomes True, e.g., because the downstream state for (S,G) has changed so that at least one interface is in inherited_olist(S,G).
JoinDesired（S、G）は、少なくとも1つのインターフェースが引き継いでいる_olist（S、G）となるように（S、G）のためのダウンストリーム状態が変更されたため、マクロJoinDesired（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.
Transitions from Joined State
接合状態からの遷移
When the upstream (S,G) state machine is in Joined state, the following events may trigger state transitions:
アップストリーム（S、G）ステートマシンは、接合状態にあるときに、次のイベントは、状態遷移をトリガすることができます。
JoinDesired(S,G) becomes False The macro JoinDesired(S,G) becomes False, e.g., because the downstream state for (S,G) has changed so no interface is in inherited_olist(S,G).
JoinDesired（S、G）が（S、G）のためのダウンストリーム状態がないインターフェースを引き継いでいる_olist（S、G）になっていないので、変更されたため、マクロJoinDesired（S、G）は、例えば、偽になる偽となります。
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.
Join Timer Expires The Join Timer (JT) expires, indicating time to send a Join(S,G)
タイマが満了参加、時間を示すこと参加（S、G）を送信する満了タイマー（JT）に参加
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.
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（S）が共有メディアである場合、このイベントにのみ関連している（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が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.
参加タイマーがt_joinsuppress秒未満で期限が切れるように設定されている場合、それはt_joinsuppress秒後に期限切れになるように、それをリセットします。参加タイマーがt_joinsuppress秒以上で有効期限が切れるように設定されている場合、それは変わらないまま。
See Prune(S,G) to RPF'(S,G) This event is only relevant if RPF_interface(S) is a shared medium. This router sees another router on RPF_interface(S) send a Prune(S,G) to RPF'(S,G). As this router is in Joined state, it must override the Prune after a short random interval.
RPF_interface（S）が共有メディアであるかどうかを確認プルーンRPFに（S、G） '（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.
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（S）が共有メディアである場合、このイベントはのみ関連しRPFへのプルーン（S、G、RPT） '（S、G）を参照してください。このルータはRPFにRPF_interface上の別のルータ（S）プルーン（S、G、RPT）を送る '（S、G）を見ています。上流のルータがRFC-2362準拠のPIMルータである場合には、プルーン（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.
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（S）が共有メディアであるかどうかを確認プルーンRPFに（*、G） '（S、G）このイベントはのみ有効です。このルータはRPF_interface（S）プルーンRPFに（*、G） '（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.
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.
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.
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）が変化する '（S、G）られたGenIDはRPFあるルータの世代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,rpt) Joins and Prunes are (S,G) Joins or Prunes sent on the RP tree with the RPT bit set, either to modify the results of (*,G) Joins, or to override the behavior of other upstream LAN peers. The next section describes the rules for sending triggered messages. This section describes the rules for including a Prune(S,G,rpt) message with a Join(*,G).
（S、G、RPT）は、ジョインとプルーンは（S、G）結合やRPTビットが設定されたRPツリー上で送信されたプルーン、されているか（*、G）の結果を修正する結合、または他の動作を無効にしますLANピアの上流。次のセクションでは、トリガメッセージを送信するためのルールを説明しています。このセクションでは、参加（*、G）とプルーン（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:
ルータが（*、G）に参加送信しようとしたとき、それはプルーン（S、G、RPT）内を含めるかどうかを決定するために、それは状態を持っているそれぞれの（S、G）のために、以下の擬似コードを使用する必要があります化合物は、join / pruneメッセージを：
if( SPTbit(S,G) == TRUE ) { # Note: If receiving (S,G) on the SPT, we only prune off the # shared tree if the RPF neighbors differ. if( RPF'(*,G) != RPF'(S,G) ) { add Prune(S,G,rpt) to compound message } } else if ( inherited_olist(S,G,rpt) == NULL ) { # Note: all (*,G) olist interfaces received RPT prunes for (S,G). add Prune(S,G,rpt) to compound message } else if ( RPF'(*,G) != RPF'(S,G,rpt) { # Note: we joined the shared tree, but there was an (S,G) assert # and the source tree RPF neighbor is different. add Prune(S,G,rpt) to compound message }
（SPTbit（S、G）== TRUE）{＃注場合：SPTに（S、G）を受信した場合RPF隣人が異なる場合、我々は、共有ツリー位オフ剪定します。 IF（RPF '（*、G）！= RPF'（S、G））{メッセージを配合するプルーン（S、G、RPT）を追加}}そうでなければ{（引き継いでいる_olist（S、G、RPT）== NULL）場合＃注：すべての（*、G）OLISTインターフェイスは（S、G）のためにRPTのプルーンを受けました。 （RPF場合、他}メッセージを配合することプルーン（S、G、RPT）を追加（S、G、RPT）{＃（注） '（*、G）= RPF！'：私たちは共有ツリーに参加しましたが、（Sがありました、G）は＃をアサートし、ソースツリーRPFネイバーは異なる。メッセージを配合するプルーン（S、G、RPT）を追加します}
Note that Join(S,G,rpt) is normally sent not as a periodic message, but only as a triggered message.
（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）のためのステートマシンは（S、G）がある（*、G）または（*、*、RP）ルータの状態に加入パー必要とされるメッセージをトリガーし、およびルータまたは任意のその上流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つの状態があります。どちらも（*、G）や（*、*、RP（G））このルータの状態に加入があるときの状態の一つがあります。 （*、G）または（*、*、RP（G））は、ルータの状態に加入がある場合、ステートマシンは、他の2つの状態のいずれかでなければなりません。三つの状態は以下のとおりです。
Pruned(S,G,rpt) (*,G) or (*,*,RP(G)) Joined, but (S,G,rpt) pruned
（S、G、RPT）（*、G）または（*、*、RP（G））プルーニングメンバーが、（S、G、RPT）プルーニング
NotPruned(S,G,rpt) (*,G) or (*,*,RP(G)) Joined, and (S,G,rpt) not pruned
（S、G、RPT）（*、G）または（*、*、RP（G））参加NotPruned、及び（S、G、RPT）プルーニングされていません
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）Joinメッセージをトリガオーバーライドがあります。
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.
さらに、我々はすべてのプルーンのオーバーライド動作のために使用されているNotPruned（S、G、RPT）状態の中、次の遷移を、持っています。
+----------------------------------------------------------------------+
| In NotPruned(S,G,rpt) State |
+----------+--------------+--------------+--------------+--------------+
|Override | See Prune | See Join | See Prune | RPF' |
|Timer | (S,G,rpt) to | (S,G,rpt) to | (S,G) to | (S,G,rpt) -> |
|expires | RPF' | RPF' | RPF' | RPF' (*,G) |
| | (S,G,rpt) | (S,G,rpt) | (S,G,rpt) | |
+----------+--------------+--------------+--------------+--------------+
|Send Join | OT = min(OT, | Cancel OT | OT = min(OT, | OT = min(OT, |
|(S,G,rpt);| t_override) | | t_override) | t_override) |
|Leave OT | | | | |
|unset | | | | |
+----------+--------------+--------------+--------------+--------------+
Note that the min function in the above state machine considers a non-running timer to have an infinite value (e.g., min(not-running, t_override) = t_override).
上記状態マシンでMIN関数は無限大の値（例えば、分（未実行、t_override）= t_override）を有するように、非ランニング・タイマを考慮することに注意してください。
This state machine uses the following macros:
このステートマシンは、次のマクロを使用しています：
bool RPTJoinDesired(G) { return (JoinDesired(*,G) OR JoinDesired(*,*,RP(G))) }
BOOL RPTJoinDesired（G）{リターン（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.
ルータは、それはどちらか（*、G）または（*、*、RP）共有ツリーの状態を使用してGのためのトラフィックを転送させるような状態を転送したとき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)) ))) }
BOOL PruneDesired（S、G、RPT）{リターン（RPTJoinDesired（G）AND（引き継いでいる_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).
RPTJoinDesired（G）が真である場合PruneDesired（S、G、RPT）は、唯一の真であることができます。 RPTJoinDesired（G）が真である場合、ルータはアクティブ（S、G）転送状態が、RPFを有する場合、Sは上で転送、またはされるであろう全く発信インターフェイスが存在しない場合、その後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.
このイベントは "剪定ない" 状態でのみ関連し（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）を参加見ています。私たちは、タイマーが実行されているオーバーライド「NotPruned」状態と（S、G、RPT）にいるならば、我々はRPF '（S、Gに私たち自身の参加（S、G、RPT）を送信するためにトリガされているので、これはあります、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.
このイベントは、 "NotPruned" 状態でのみ関連しRPFへのプルーン（S、G、RPT） '（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.
ルータが正しい上流の隣人であるRPF '（S、G、RPT）、に他の誰かからプルーン（S、G、RPT）を見ています。私たちは「NotPruned」の状態であれば、我々はG宛てSからトラフィックを受信し、トラフィックがRPF '（S、G、RPT）によって供給されていることをしていきたいと思います。したがって、我々はプルーンをオーバーライドする必要があります。
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.
アクションは、無作為プルーン・オーバーライド間隔にt_overrideを（S、G、RPT）オーバーライドタイマーを設定することです。オーバーライドタイマーがすでに実行されている場合はそうすることが、より低い値に設定するならばしかし、我々は唯一のタイマーを設定します。誰もが他の参加送信した場合には、この期間の終わりに、我々はそうするでしょう。
See Prune(S,G) to RPF'(S,G,rpt) This event is only relevant in the "NotPruned" state.
参照プルーンRPFに（S、G） '（S、G、RPT）このイベントは、 "NotPruned" 状態でのみ有効です。
This transition and action are the same as the above transition and action, except that the Prune does not have the RPT bit set. This transition is necessary to be compatible with routers implemented from RFC2362 that don't maintain separate (S,G) and (S,G,rpt) state.
この遷移とアクションは、プルーンがRPTビットが設定されていないことを除いて、上記遷移および動作と同じです。この遷移は、別個の（S、G）および（S、G、RPT）状態を維持していないRFC2362から実施ルータと互換性があることが必要です。
The (S,G,rpt) prune Override Timer expires This event is only relevant in the "NotPruned" state.
（S、G、RPT）プルーンオーバーライドタイマこのイベントは、「NotPruned」状態でのみ関連し満了します。
When the Override Timer expires, we must send a Join(S,G,rpt) to RPF'(S,G,rpt) to override the Prune message that caused the timer to be running. We only send this if RPF'(S,G,rpt) equals RPF'(*,G); if this were not the case, then the Join might be sent to a router that does not have (*,G) 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).
オーバーライドタイマーの期限が切れると、私たちは、タイマーが実行されている原因とプルーンのメッセージをオーバーライドするためにRPF '（S、G、RPT）に参加（S、G、RPT）を送信する必要があります。 RPF（*、G） '（S、G、RPT）はRPF等しい' 場合我々はこれだけを送信します。これが当てはまらなかった場合、その後、持っていないルータ（*、G）または（*、*、RP（G））参加状態、及びその行動が明確に定義されていないでしょうに送信される可能性があります参加します。 RPF（*、G） '（S、G、RPT）はRPFと同じではない' 場合、それはこの問題が発生した場合、ルータはAssertCancel（S、G）を、送信されます、しかしS.の転送を停止することができますその後、RPF（下記参照）（*、G） '（S、G、RPT）はRPFに等しくなるように' 原因となります。
RPF'(S,G,rpt) changes to become equal to RPF'(*,G) This event is only relevant in the "NotPruned" state.
RPF '（S、G、RPT）変更RPFと等しくなるように'（*、G）このイベントは、 "NotPruned" 状態でのみ有効です。
RPF'(S,G,rpt) can only be different from RPF'(*,G) if an (S,G) Assert has happened, which means that traffic from S is arriving on the SPT, and so Prune(S,G,rpt) will have been sent to RPF'(*,G). When RPF'(S,G,rpt) changes to become equal to RPF'(*,G), we need to trigger a Join(S,G,rpt) to RPF'(*,G) to cause that router to start forwarding S again.
RPF、S（SからのトラフィックがプルーンをSPTに到着し、そうしていることを意味します（S、G）アサートが発生した場合には（*、G）、 '（S、G、RPT）が唯一のRPFと異なる場合があります' G、RPT）はRPF '（*、G）に送られてきたでしょう。 RPF '（S、G、RPT）の変化RPFと等しくなるための'（*、G）が、我々はそのルータを開始させるためにRPF '（*、G）に（S、G、RPT）を参加トリガーする必要がある場合再びSを転送します。
The action is to set the (S,G,rpt) Override Timer to the randomized prune-override interval t_override. However, if the timer is already running, we only set the timer if doing so would set it to a lower value. At the end of this interval, if 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のトラフィックを受信したいが、Sからのトラフィックを受信したくない。これは、剪定された状態に移行するようにルータを引き起こしG.宛て。
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).
ルータはNotPruned状態で以前にあった場合、アクションは、RPFにプルーン（S、G、RPT） '（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）の状態、およびPruneDesired（S、G、RPT）FALSEに変更している場合は、このルータは、もはや（G）真RPTJoinDesiredていない可能性があるため、またはそれが今で受信したいです再びSからのトラフィック。それはかつてのであれば、この移行は起こるべきではありませんが、その代わりに「RPTJoinDesired（G） - > FALSE」の移行が起こるはず。従って、この遷移は、 " - > FALSE AND RPTJoinDesired（G）== TRUE PruneDesired（S、G、RPT）" と解釈されるべきです。
The action is to send a Join(S,G,rpt) to RPF'(S,G,rpt).
アクションは '（S、G、RPT）RPFに参加（S、G、RPT）を送信することです。
RPTJoinDesired(G)->FALSE This event is relevant in the "Pruned" and "NotPruned" states.
RPTJoinDesired（G）は - > FALSEこのイベントは、「剪定」と「NotPruned」の状態で関連しています。
The router no longer wishes to receive any traffic destined for G on the RP Tree. This causes a transition to the RPTNotJoined(G) state, and the Override Timer is canceled if it was running. Any further actions are handled by the appropriate upstream state machine for (*,G) or (*,*,RP).
ルータは、もはやRP木の上にG宛てのトラフィックを受信することを希望しません。これはRPTNotJoined（G）状態への遷移を引き起こし、それが実行中であった場合は上書きタイマーはキャンセルされます。さらなるアクションは（*、G）または（*、*、RP）のために適切な上流の状態機械によって処理されます。
inherited_olist(S,G,rpt) becomes non-NULL This transition is only relevant in the RPTNotJoined(G) state.
引き継いでいる_olist（S、G、RPT）は、非NULLこの遷移はRPTNotJoined（G）状態にのみ関連してなります。
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.
ルータは、（必要に応じて（*、G）または（*、*、RP）上流の状態機械によって処理される）RPツリーに参加し、これは、この状態マシンでイベントをトリガしないS.からのトラフィックを受信したいが、ましたNotPruned（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）メッセージが記載されています。抜け目のない読者は、それがトリガプルーン（S、G、RPT）メッセージのことが可能である一方、周期プルーン（S、G、RPT）メッセージのみ、（G、*）参加を含むPIM参加/プルーンメッセージで送信されることに留意されたいですルータは何も（*、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.
我々は最初の受信を注意（S、Gをキャンセルない自身が参加（*、G）を受信し、一方、そのインターフェイス上で状態をプルーニング（S、G、RPT）をキャンセルしない単独で（*、*、RP）参加、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.
この結論は、その転送を防止する（S、G）に（*、*、RP）状態、プルーン（S、G、RPT）を使用しなければならないです。
We also note that for historical reasons there is no Assert(*,*,RP) message, so any forwarding contention is resolved using Assert(*,G) messages.
我々はまた、歴史的な理由のためにそこにはアサート（*、*、RP）メッセージではありませんので、任意の転送の競合が（*、G）メッセージのAssertを使用して解決されることに注意してください。
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.
（*、G）、（*、*、RP）の間のすべての複雑な優先ルールを指定する必要があり、（S、G、RPT）を回避するために、我々は単に*（オフ（S、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.
ルータが（*、G）状態がインスタンス化（*、*、RP）状態で受信され、まだ持っていない場合、それはまだ（プルーンを上書きするためにSをトリガ参加（S、G、RPT）を送信する必要があるかもしれません、それは、そのアップストリームインタフェースにRPF '（*、G）に向け見ることG、RPT）。したがって、JoinDesired（*、G）が偽であるがJoinDesired（*、*、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.
最後に、我々はLAN上の上流のルータがすでに持っているとき、最適化されていない場合があることに注意してください（*、G）に参加し、（S、G、RPT）既存の下流のルータによって引き起こされる状態を剪定。この時点では新しいが異なる下流ルータから上流のルータに送信される（*、*、RP）に参加した場合、これは（S、G、RPT）上流のルータの状態を剪定を上書きしません。オーバーライドは、元の下流ルータがプルーン（S、G、RPT）を再送信する次の時間まで起こらないであろう。この場合は、（*、*、RP）状態は一般的に非常に長く住んで、そしてので、新しいPMBRへのトラフィックを得ることにのわずかな遅れが重要でないように見えるよう、最適化する価値は考慮されませんでした。
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ネイバーについて聞きます。ルータは、特定のIP送信元アドレスからのAssertメッセージを受信し、その送信元アドレスからPIM Helloメッセージを見ていない場合、アサートメッセージはさらに処理することなく廃棄されるべきです。隣人からのHelloメッセージは、IPSec認証ヘッダ（AH）を使用して認証された場合に加えて、その隣人からのすべてのAssertメッセージものIPsec AHを使用して認証されなければならない、（セクション6.3を参照）。
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のための状態機械をアサート3つの状態があり、図10に示されています。
NoInfo (NI) This router has no (S,G) assert state on interface I.
NoInfo（NI）このルータがない（S、G）界面I.上の状態を主張しています
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).
私は一方で、このルータは（S、G）獲得した受賞（W）をアサートそれはそれは私のためにDRであるかどうかにかかわらず、インターフェースIのうち、G宛てSからのトラフィックを転送するために、今責任があるインタフェースI.上で主張していますルータは、それはまた、特にS（およびG）を参照してくださいメンバーシップのリクエストをした私のローカルホストに代わって私にトラフィックを転送する責任があり、アサート勝者です。
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）このルータは失ってしまった（S、G）は、インタフェースI.上で主張することは、インタフェースI.上にG宛てSからのパケットを転送してはならない、それは私にDRであれば、それはもはや責任があるアサート敗者です私は、特に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.
また、アウト時に使用アサート敗者にアサートし、アサート勝者にアサート再送するようにされてアサートタイマー（AT）もあります。
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）よりも悪いメトリックを有するものです。 （S、G、I）my_assert_metricが無限大である場合にはアサートが劣るとみなされることはありません。
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）= SPTbit（S、G）== TRUE AND（RPF_interface（S）！= I）AND（中I（（（*、*、RP（G）を合流）（+）は、（加入します*、G）（ - ）プルーン（S、G、RPT））（+）（pim_include（*、G）（ - ）pim_exclude（S、G））（ - ）lost_assert（*、G）（+）ジョイン（ 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.
CouldAssert（S、G、I）が（S、G）アサート情報を考慮していなかった場合に引き継いでいる_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）=（Iはで（（（*、*、RP（G）に参加）（+）ジョイン（*、G）（ - ）プルーン（S、G、RPT））（+）（ pim_include（*、G）（ - ）pim_exclude（S、G））（ - ）lost_assert（*、G）（+）参加する（S、G）））OR（local_receiver_include（S、G、I）== TRUEと（I_am_DR（I）OR（AssertWinner（S、G、I）==私）））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.
ルータがI.にアサートに興味があることを引き起こすかもしれないIで受信した（*、G）に参加し、地元の会員情報についてAssertTrackingDesiredアカウントの最初の3行
The 4th line accounts for (S,G) join information received on I that might cause the router to be interested in asserts on I.
第四行は、ルータがI.にアサートに興味があることを引き起こすかもしれないIで受信した情報を結合する（S、G）を占め、
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）、我々はそれが（S、G、I）lost_assertを使用しているのでpim_include（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行は、ルータが適切な隣人に参加し、プルーンを送信するために、アップストリームインターフェイス上でのassert情報を追跡しなければならないという事実を占めています。
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).
== TRUEアサートはRPTビットと（S、G）のために受信されRPTbitで劣るアサートを受信クリアしCouldAssert（S、G、I）それは私たち自身のアサートメトリックに劣るクリア。クリアRPTビットはアサートの送信者が（S、G）は、このインターフェイス上の転送状態を有していたことを示しています。アサートは、私たちのメトリックに劣っているなら、私たちはまた、（S、G）転送状態（すなわち、CouldAssert（S、G、I）== TRUE）（S、G）をアサートビート（*、G）をアサートしている必要があります、と私たちはアサート勝者でなければなりません。私たちは、状態「私は勝者をアサートしています」とA1（下）アクションを実行するために移行します。
Receive Assert with RPTbit set AND CouldAssert(S,G,I)==TRUE An assert is received for (S,G) on I with the RPT bit set (it'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セットとCouldAssert（S、G、I）== TRUEアサートはRPTビットセット（それは（*、G）のassertだ）とIに（S、G）のために受信されるとアサートを受信します。 CouldAssert（S、G、I）は、我々は、このインターフェイス上で（S、G）転送状態を持っている場合にのみTRUEであるので、我々はアサート勝者でなければなりません。私たちは、状態「私は勝者をアサートしています」と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）のデータパケットは、私がインターフェイスに到着し、CouldAssert（S、G、I）== TRUEアン（S、G）のデータパケットは、私たちの（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).
*（I、S、G）をクリアし、AssertTrackingDesired RPTビットで許容アサートを受信== TRUE我々は（S、G）に興味を表明し、いずれかの私たちは（S、G）持っているダウンストリームインターフェイスであるため、または（ 、G）転送状態、またはI Sのアップストリームインタフェースであり、我々は（S、G）転送状態を有するからです。受信アサートが私たち自身よりも優れたメトリックを持っているので、私たちはアサートを獲得していません。私たちは、「私は敗者をアサートしています」とA6（下）アクションを実行するように移行します。
Transitions from "I am Assert Winner" State
国家「私は勝者をアサートしています」からの遷移
When in "I am Assert Winner" state, the following events trigger transitions:
状態「私がアサート受賞しています」と、次のイベントが遷移をトリガ：
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）をアサートまたは（*、G）は、私たち自身より悪いメトリックを持つSに言及主張受け取る劣るアサートを受信します。誰アサートを送ったことは誤りであり、そして私たちは（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）または（S、G、RPT）ステートマシンの遷移を引き起こす可能性がJoinDesired（S、G）とPruneDesired（S、G、RPT）の値に影響を与えることができることに留意されたいです。
CouldAssert(S,G,I) -> FALSE Our (S,G) forwarding state or RPF interface changed so as to make CouldAssert(S,G,I) become false. We can no longer perform the actions of the assert winner, and so we transition to NoInfo state and perform Actions A4 (below). This includes sending a "canceling assert" with an infinite metric.
CouldAssert（S、G、I） - > FALSE私たちの（S、G）転送状態またはCouldAssert（S、G、I）が偽になるとなるように変更さRPFインターフェイス。私たちは、もはやアサート勝者のアクションを実行することはできません、と私たちはNoInfo状態に遷移し、アクション（下）A4を行います。これは、無限のメトリックで「キャンセルアサート」を送信することを含みます。
Transitions from "I am Assert Loser" State
国家「私は敗者をアサートしています」からの遷移
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.
私たちは、この（S、G）（メトリックは勝者の前のメトリックよりも悪いかもしれないが）のために私たち自身のメトリックよりも優れている現在のアサート勝者からアサートを受ける現在の受賞者からの明確なRPTbitで許容アサートを受信します。我々は敗者状態のままにし、以下のアクション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.
劣っアサートまたはアサートが現在の受賞者からキャンセルの受信我々は（勝者のメトリックが悪化したか、それがアサートされるので、キャンセルので、一般的に）このグループのために私たち自身のメトリックよりも悪化している現在のアサート勝者からアサートを受けます。我々は、（S、G）は情報をアサートし、通常のPIMは/動作するプルーンメカニズムに参加できるように削除、NoInfo状態に遷移します。通常、我々は最終的にアサートを再し、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）をアサートタイマが満了する期限。我々は、（S、G）情報（以下アクションA5）をアサートを削除し、NoInfo状態に遷移します。
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).
現在ウィナーズられたGenID変更またはNLTが満了し、現在の勝者に関連付けられた近隣ライブネスタイマーを期限切れになるか、私たちはそれが以前に報告されたものとは異なるられたGenIDを報告し、現在の勝者からHelloメッセージを受信します。これは、現在の勝者のインタフェースやルータがダウンした（と戻って来たかもしれない）ことを示している、と私たちは、それはもはや、それは勝者だった知っていると仮定してはなりません。我々は、この（S、G）情報（以下アクションA5）をアサートを削除し、NoInfo状態に遷移します。
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）がインターフェイスでアサートすることを私はもはや私たちに関心のあるように、私たちの転送状態は変わっていません。我々は、（S、G）は情報をアサート削除、NoInfo状態に遷移します。
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.
私のメトリックは今（S、G）のための私のアサートメトリックは、我々が現在アサート勝者のために保存されているメトリックよりも優れているように変更されたアサート勝者のメトリックmy_assert_metric（S、G、I）よりも良好となります。基礎となるメトリックの変更をルーティングするときに発生する可能性があります、またはCouldAssert（S、G、I）が真となったとき。例えば、SPTbit（S、G）が真となります。我々は、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）は、私はSのためのRPFインターフェイスであるために使用されるインタフェースであることインタフェースを停止し、今ではありません。我々は、この（S、G）状態（以下アクションA5）をアサートを削除し、NoInfo状態に遷移します。
Receive Join(S,G) on Interface I We receive a Join(S,G) that has the Upstream Neighbor Address field set to my primary IP address on interface I. The action is to transition to NoInfo state, delete this (S,G) assert state (Actions A5 below), and allow the normal PIM Join/Prune mechanisms to operate. If whoever sent the Join was in error, then the normal assert mechanism will eventually re-apply, and we will lose the assert again. However, whoever sent the assert may know that the previous assert winner has died, and so we may end up being the new forwarder.
インタフェースIの（S、G）が参加レシーブ我々は（Sのインタフェースアクションはこれを削除し、NoInfo状態に遷移することであるI.上で私のプライマリIPアドレスに設定上流隣接アドレスフィールドを持っている（S、G）が参加受け取り、 G）状態（アクション以下A5）をアサートし、通常のPIMが動作するように/プルーン機構に参加可能。誰でも参加を送ってもエラーにあった場合は、通常のアサートメカニズムは、最終的に再適用されます、そして我々は再びアサートを失うことになります。しかし、誰が以前アサート勝者が亡くなったことを知っている可能性がありアサートを送った、と私たちは新しいフォワーダになってしまうことがあります。
(S,G) Assert State machine Actions
（S、G）アサートステートマシンのアクション
A1: Send Assert(S,G). Set Assert Timer to (Assert_Time - Assert_Override_Interval). Store self as AssertWinner(S,G,I). Store spt_assert_metric(S,I) as AssertWinnerMetric(S,G,I).
A1：アサート（S、G）を送信します。 （ - Assert_Override_Interval Assert_Time）にアサートタイマーを設定します。 AssertWinner（S、G、I）としてストアセルフ。ストアspt_assert_metric（S、I）AssertWinnerMetric（S、G、I）など。
A2: Store new assert winner as AssertWinner(S,G,I) and assert winner metric as AssertWinnerMetric(S,G,I). Set Assert Timer to Assert_Time.
A2：ストア新しいアサートAssertWinner（S、G、I）として勝者とAssertWinnerMetric（S、G、I）として勝者メトリックを主張しています。 Assert_Timeにアサートタイマーを設定します。
A3: Send Assert(S,G). Set Assert Timer to (Assert_Time - Assert_Override_Interval).
A3：アサート（S、G）を送信します。 （ - Assert_Override_Interval Assert_Time）にアサートタイマーを設定します。
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）を送信します。 （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：主張削除情報（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）として勝者とAssertWinnerMetric（S、G、I）として勝者メトリックを主張しています。 Assert_Timeにアサートタイマーを設定します。 （私はあるRPF_interface（S））AND（真UpstreamJPState（S、G）==）がTRUEにSPTbit（S、G）を設定した場合。
Note that some of these actions may cause the value of JoinDesired(S,G), PruneDesired(S,G,rpt), or RPF'(S,G) to change, which could cause further transitions in other state machines.
他のステートマシンにさらに遷移を引き起こす可能性があり、変更するために、これらのアクションのいくつかはJoinDesired（S、G）、PruneDesired（S、G、RPT）の値を引き起こすことがあります、またはRPF '（S、G）。
The (*,G) Assert state machine for interface I is shown in Figure 11. There are three states:
（*、G）界面Iのための状態機械をアサート3つの状態があり、図11に示されています。
NoInfo (NI) This router has no (*,G) assert state on interface I.
NoInfo（NI）は、このルータは、インタフェースI.には（*、G）アサート状態を有していません
I am Assert Winner (W) This router has won 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.
私は "（W）このルータは、（*、G）を獲得したことが、今、私はそれが（S、G）持っているトラフィックを除いて、インタフェース上にG宛てのトラフィックを転送する責任があるインタフェースI.上で主張アサート受賞しています私は敗者」状態をアサートしています。かかわらず、それは私のためにDRであるかどうかの、それはまた、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.
私はそれは私が「持っている（S、G）されているソースからのトラフィックを除いてインターフェースI上にGのためにパケットを転送してはならない。このルータは（*、G）が失われた敗者（L）をアサートインタフェースI.上で主張しています勝者」状態をアサートしています。それはDRであるならば、それはもはやI.上のローカルホストからグループGのメンバーシップ要求を処理する責任がありません
In addition, there is also an Assert Timer (AT) that is used to time out asserts on the assert losers and to resend asserts on the assert winner.
また、アウト時に使用アサート敗者にアサートし、アサート勝者にアサート再送するようにされてアサートタイマー（AT）もあります。
When an Assert message is received with a source address other than zero, a PIM implementation must first match it against the possible events in the (S,G) assert state machine and process any transitions and actions, before considering whether the Assert message matches against the (*,G) assert state machine.
アサートメッセージがゼロ以外のソースアドレスで受信されると、PIMの実装では、最初のアサートメッセージは反対一致するかどうかを検討する前に、状態機械をアサートし、任意の遷移とアクションを処理する（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）は、関連するSのための状態機械をアサートしない限り、遷移がアサート・メッセージを受信した結果として、（*、G）ステートマシンで発生することができないことに留意することが重要であり、G「はNoInfo」状態であります（S、G）ステートマシンはメッセージを処理した後。また、NO TRANSITIONは、そのメッセージが（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）がアサート・メッセージが到着したときに、状態マシンはNoInfo状態であり、メッセージが「W」のいずれかに移行する（S、G）ステートマシンを引き起こすアサートまたは「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」状態であり、メッセージにアサートメトリックは、（I、S、G）を（S my_assert_metricより悪い場合、 G）ステートマシンはNoInfo状態に遷移するアサート。 （*、G）ステートマシンをアサートがNoInfo状態であった場合、このような場合には、このメッセージが既に（S遷移を引き起こしたので、それが「W」の状態遷移になるが、これはそうではないように見えるかもしれません、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）=（I中（参加する（*、*、RP（G））（+）が参加する（*、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.
CouldAssert（*、G、I）は、我々が持っている（*、*、RP（G））または（*、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）= CouldAssert（*、G、I）OR（local_receiver_include（*、G、I）==（I_am_DR（I）OR AssertWinner（*、G、I）TRUEと==私）） 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）アサートが私たちの行動に影響を与える可能性があります上の任意のインターフェイスに当てはまります。
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）"（*、G、I）AssertTrackingDesiredを参照するためにステートマシンテーブルで使用されています。
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セットとCouldAssert（*、G、I）で劣るアサートを受信== TRUEアン劣る（*、G）アサートがインタフェースI.もしCouldAssertにGのために受信される（*、G、I）TRUEで、その後、私は私たちですダウンストリームインターフェイス、そして私たちは、このインターフェイス上で（*、G）転送状態を持っているので、我々はアサート勝者でなければなりません。私たちは、状態「私は勝者をアサートしています」と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宛のデータパケットは、私がインターフェイスに到着し、G宛てCouldAssert（*、G、I）== TRUEデータパケットは、私たちの（*、G）発信インターフェイスリストにあるダウンストリームインターフェイスに到着しました。したがって、我々は、我々は、このためのフォワーダ（*、G）であるべき、と私たちは状態「私は勝者をアサートしています」とA1（下）アクションを実行するために移行すると考えています。
Receive Acceptable Assert with RPT bit set AND AssertTrackingDesired(*,G,I)==TRUE We're interested in (*,G) Asserts, either because I is a downstream interface for which we have (*,G) forwarding state, or because I is the upstream interface for RP(G) and we have (*,G) forwarding state. We get a (*,G) Assert that has a better metric than our own, so we do not win the Assert. We transition to "I am Assert Loser" and perform Actions A2 (below).
、RPTビットセットとAssertTrackingDesired（*、G、I）で許容アサートを受信== TRUE我々は（*、G）に興味を表明し、いずれかの私たちは（*、G）転送状態を持っているため、ダウンストリームインターフェイスであるため、または私はRPのためのアップストリームインターフェイス（G）であり、我々は（*、G）転送状態を持っているので。私たちはより良いメトリック私たち自身よりも持っている（*、G）アサートを取得するので、私たちはアサートを獲得していません。私たちは、「私は敗者をアサートしています」とA2（下記）アクションを実行するように移行します。
Transitions from "I am Assert Winner" State
国家「私は勝者をアサートしています」からの遷移
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）アサートを受け劣るアサートを受信します。誰がアサートが失われた送信され、私たちは（*、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）アサートを受け取る優先アサートを受信します。私たちは、状態「私は敗者をアサートしています」とA2（下記）アクションを実行するように移行します。
When in "I am Assert Winner" state, the following events trigger transitions:
状態「私がアサート受賞しています」と、次のイベントが遷移をトリガ：
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).
CouldAssert（*、G、I） - > FALSE私たちの（*、G）転送状態またはCouldAssert（*、G、I）が偽になるとなるように変更さRPFインターフェイス。私たちは、もはやアサート勝者のアクションを実行することはできません、と私たちはNoInfo状態に遷移し、アクション（下）A4を行います。
Transitions from "I am Assert Loser" State
国家「私は敗者をアサートしています」からの遷移
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.
私たちが受け取るRPTbitセットで優先アサートを受信（*、G）は、それが現在のアサート勝者のそれよりも優れて主張しています。我々は敗者状態のままにし、以下のアクションA2を行います。
Receive Acceptable Assert from Current Winner with RPTbit set We receive a (*,G) assert from the current assert winner that is better than our own metric for this group (although the metric may be worse than the winner's previous metric). We stay in Loser state and perform Actions A2 below.
私たちは、（*、G）が（メトリックは勝者の前のメトリックよりも悪いかもしれないが）、このグループのために私たち自身のメトリックよりも優れている現在のアサート勝者からの主張を受けるRPTbitセットで現在の受賞者から許容アサートを受けます。我々は敗者状態のままにし、以下のアクション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).
現在ウィナーズられたGenID変更またはNLTが満了し、現在の勝者に関連付けられた近隣ライブネスタイマーを期限切れになるか、私たちはそれが以前に報告されたものとは異なるられたGenIDを報告し、現在の勝者からHelloメッセージを受信します。これは、現在の勝者のインタフェースやルータがダウンした（と戻って来たかもしれない）ことを示している、と私たちは、それはもはや、それは勝者だった知っていると仮定してはなりません。我々は、（*、G）アサート情報（アクションA5）を削除、NoInfo状態に遷移します。
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.
私のメトリックがアサート勝者のメトリックマイルーティングメトリック、rpt_assert_metric（G、I）よりも良くなる、（*、G）のためになるように、今、私のアサートメトリックを変更した私たちは、現在のアサート勝者のために保存されているメトリックよりも優れています。私たちは、NoInfo状態に移行し、（*、G）は状態（アクションA5）をアサートし、通常のPIMが動作するように/プルーンのメカニズムに参加できるように、これを削除します。通常、我々は最終的にアサートを再とGのためのデータパケットが再び流れ始めた時に獲得します。
RPF_interface(RP(G)) stops being interface I Interface I used to be the RPF interface for RP(G), and now it is not. We transition to NoInfo state and delete this (*,G) assert state (Actions A5).
RPF_interface（RP（G））は私は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.
（*、*、RP（G））インターフェイス上で、私は我々が受け取る（*、G）に参加受信または参加しよう（*、G）または参加（*、*、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：アサート（*、G）を送信します。 （ - Assert_Override_Interval Assert_Time）にアサートタイマーを設定します。 AssertWinner（*、G、I）としてストアセルフ。店舗rpt_assert_metric AssertWinnerMetricとして（G、I）（*、G、I）。
A2: Store new assert winner as AssertWinner(*,G,I) and assert winner metric as AssertWinnerMetric(*,G,I). Set Assert Timer to Assert_Time.
A2：ストアAssertWinnerなどの新しいアサート勝者（*、G、I）AssertWinnerMetricとしてメトリックと主張勝者（*、G、I）。 Assert_Timeにアサートタイマーを設定します。
A3: Send Assert(*,G) Set Assert Timer to (Assert_Time - Assert_Override_Interval).
A3：（Assert_Time - Assert_Override_Interval）にアサート（*、G）の設定アサートタイマーを送信します。
A4: Send AssertCancel(*,G). Delete assert info (AssertWinner(*,G,I) and AssertWinnerMetric(*,G,I) will then return their default values).
A4：AssertCancel（*、G）を送信します。 （AssertWinner（*、G、I）とAssertWinnerMetric（*、G、I）はその後、それらのデフォルト値を返します）の情報をアサート削除します。
A5: Delete assert info (AssertWinner(*,G,I) and AssertWinnerMetric(*,G,I) will then return their default values).
A5：削除（AssertWinner（*、Gは、I）とAssertWinnerMetric（*、G、I）は、その後、それらのデフォルト値を返します）の情報を主張。
Note that some of these actions may cause the value of JoinDesired(*,G) or RPF'(*,G)) to change, which could cause further transitions in other state machines.
これらのアクションのいくつかはJoinDesired（*、G）またはRPF '（*、G））の値が他のステートマシンの更なる遷移を引き起こす可能性があり、変化させることがあります。
Assert metrics are defined as:
アサートメトリックは、以下のように定義されています。
struct assert_metric {
rpt_bit_flag;
metric_preference;
route_metric;
ip_address;
};
When comparing assert_metrics, the rpt_bit_flag, metric_preference, and route_metric 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_preference、及び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_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() } }
assert_metric my_assert_metric（S、G、I）{IF（CouldAssert（S、G、I）== TRUE）{spt_assert_metric返す（S、I）}もしそうでなければ（CouldAssert（*、G、I）== TRUE）{リターンrpt_assert_metric他（G、I）}は{}}）（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:
我々は、アクティブ（S、G）転送状態に基づいてアサートを送信している場合spt_assert_metric（S、I）は、我々が使用アサートメトリックを与えます：
assert_metric spt_assert_metric(S,I) { return {0,MRIB.pref(S),MRIB.metric(S),my_ip_address(I)} }
assert_metric spt_assert_metric（S、I）{リターン{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:
我々は唯一の（*、G）転送状態に基づいてアサートを送信している場合rpt_assert_metric（G、I）は、我々が使用アサートメトリックを与えます：
assert_metric rpt_assert_metric(G,I) { return {1,MRIB.pref(RP(G)),MRIB.metric(RP(G)),my_ip_address(I)} }
assert_metric rpt_assert_metric（G、I）{リターン{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は（）私たちはアサートを送信する必要がありますが、どちらかの（S、G）または（*、G）転送状態と一致しないアサートメトリックを与えます：
assert_metric infinite_assert_metric() { return {1,infinity,infinity,0} }
assert_metric infinite_assert_metric（）{リターン{1、無限大、無限大、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.
AssertCancel（S、G）は、そのソースとして名S RPTビットが設定された無限のメトリックアサートあります。
An AssertCancel(*,G) is an infinite metric assert with the RPT bit set and the source set to zero.
AssertCancel（*、G）をRPTビットセットとゼロに設定ソースと無限メトリックアサートあります。
AssertCancel messages are simply an optimization. The original Assert timeout mechanism will allow a subnet to eventually become consistent; the AssertCancel mechanism simply causes faster convergence. No special processing is required for an AssertCancel message, since it is simply an Assert message from the current winner.
AssertCancelメッセージは単純に最適化されています。オリジナルのアサートタイムアウトメカニズムは、サブネットは、最終的に一貫性になることができます。 AssertCancelメカニズムは、単により速い収束が発生します。それは単に現在の勝者からのAssertメッセージであるため、特別な処理は、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:
マクロlost_assert（S、G、RPT、I）、lost_assert（S、G、I）、及びlost_assert（*、G、I）は、セクション4.1のOLIST計算に使用され、のように定義されます。
bool lost_assert(S,G,rpt,I) { if ( RPF_interface(RP(G)) == I OR ( RPF_interface(S) == I AND SPTbit(S,G) == TRUE ) ) { return FALSE } else { return ( AssertWinner(S,G,I) != NULL AND AssertWinner(S,G,I) != me ) } }
BOOL lost_assert（S、G、RPT、I）{IF（RPF_interface（RP（G））== I OR（RPF_interface（S）== I AND SPTbit（S、G）== TRUE））を{}そうでなければFALSEを返します{リターン（AssertWinner（S、G、I）！= NULL AND AssertWinner（S、G、I）！=私）}}
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) ) } }
ブールlost_assert（S、G、I）{IF（RPF_interface（S）== I）{FALSEを返す}他{リターン（AssertWinner（S、G、I）！= NULL AND AssertWinner（S、G、I）！=私AND（AssertWinnerMetric（S、G、I）は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.
注意：用語を正しくルータは（S、G）状態が参加している移行期を処理するために必要とされる「AssertWinnerMetric（S、G、I）が（私はS）spt_assert_metricよりも優れている」、まだ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 ) } }
ブールlost_assert（*、G、I）{場合（RPF_interface（RP（G））== I）{FALSEを返す}他{リターン（AssertWinner（*、G、I）！= NULL AND AssertWinner（*、G、I ）！=私）}}
AssertWinner(S,G,I) is the IP source address of the Assert(S,G) packet that won an Assert.
AssertWinner（S、G、I）がアサートを獲得したのAssert（S、G）パケットのIP送信元アドレスです。
AssertWinner(*,G,I) is the IP source address of the Assert(*,G) packet that won an Assert.
AssertWinner（*、G、I）のAssertを獲得したアサート（*、G）パケットのIP送信元アドレスです。
AssertWinnerMetric(S,G,I) is the Assert metric of the Assert(S,G) packet that won an Assert.
AssertWinnerMetric（S、G、I）がアサートを獲得アサート（S、G）パケットのアサートメトリックです。
AssertWinnerMetric(*,G,I) is the Assert metric of the Assert(*,G) packet that won an Assert.
AssertWinnerMetric（*、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）デフォルト値はNULLとNoInfo状態で無限にAssertWinnerMetric（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.動作下流隣人（* G）に参加し、適切なRPF」隣接、アサートプロセスによって修正され、すなわち、RPF隣人に（S、G）定期的なJoinメッセージを送信します。 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.動作：（*、G）のためのアサート勝者はIGMP / MLD部材の代わりに（*、G）のための局所DRとして働きます。
Rationale: This is required to allow a single router to merge PIM
and IGMP/MLD joins and leaves. Without this, overrides don't
work.
3. Behavior: The assert winner for (S,G) acts as the local DR for (S,G) on behalf of IGMPv3 members.
3.動作：（S、G）のためのアサート勝者は、IGMPv3メンバーの代わりに（S、G）のための局所DRとして働きます。
Rationale: Same rationale as for item 2.
理論的根拠：項目2の場合と同じ原理。
4. Behavior: (S,G) and (*,G) prune overrides are sent to the RPF' neighbor and not to the regular RPF neighbor.
4.行動：（S、G）および（*、G）プルーンオーバーライドは、RPF」隣人にしていない通常のRPFネイバーに送信されます。
Rationale: Same rationale as for item 1.
理論的根拠：項目1の場合と同じ原理。
5. Behavior: An (S,G,rpt) prune override is not sent (at all) if RPF'(S,G,rpt) != RPF'(*,G).
5.行動：RPF '！（S、G、RPT）= RPF'（*、G）場合には（S、G、RPT）プルーンオーバーライドは（すべてで）送信されません。
Rationale: This avoids keeping state alive on the (S,G) tree when
only (*,G) downstream members are left. Also, it avoids sending
(S,G,rpt) joins to a router that is not on the (*,G) tree. This
behavior might be confusing although this specification does
indicate that such a join should be dropped.
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.行動：参加（*、G）または（*、*、RP（G））そのインターフェイス上のプライマリIPアドレスをある上流隣接アドレスとは、（*、G）Joinを受信キャンセルアサート敗者アサートタイマー及び全て（S、G）は、化合物/プルーンメッセージを参加に対応するプルーン（S、G、RPT）を持っていないタイマメッセージをアサートします。
Rationale: Same rationale as for item 6.
理論的根拠：項目6の場合と同じ原理。
8. Behavior: An assert winner for (*,G) or (S,G) sends a canceling assert when it is about to stop forwarding on a (*,G) or an (S,G) entry. This behavior does not apply to (S,G,rpt).
8.動作：（*、G）に転送または（S、G）エントリを停止しようとしている場合のアサート勝者（*、G）または（S、G）はキャンセルアサートを送信します。この動作は、（S、G、RPT）には適用されません。
Rationale: This allows switching back to the shared tree after
the last SPT router on the LAN leaves. Doing this prevents
downstream routers on the shared tree from keeping SPT state
alive.
9. Behavior: Resend the assert messages before timing out an assert. (This behavior is optional.)
9.行動：アサートをタイムアウトするまでのassertメッセージを再送信します。 （この動作はオプションです。）
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に（S、G、RPT） '（*、G）が参加トリガする必要があります。
Rationale: This allows switching back to the RPT after the last
SPT member leaves.
For correct operation, every PIM router within a PIM domain must be able to map a particular multicast group address to the same RP. If this is not the case, then black holes may appear, where some receivers in the domain cannot receive some groups. A domain in this context is a contiguous set of routers that all implement PIM and are configured to operate within a common boundary.
正しい動作のためには、PIMドメイン内のすべてのPIMルータが同じRPに特定のマルチキャストグループアドレスをマッピングすることができなければなりません。そうでない場合、次いで、ブラックホールは、ドメイン内のいくつかの受信機がいくつかのグループを受信することができない場合、表示されてもよいです。この文脈でのドメインは、すべてのPIMを実装し、共通の境界内で動作するように設定されているルータの連続したセットです。
A notable exception to this is where a PIM domain is broken up into multiple administrative scope regions; these are regions where a border has been configured so that a range of multicast groups will not be forwarded across that border. For more information on Administratively Scoped IP Multicast, see RFC 2365. The modified criteria for admin-scoped regions are that the region is convex with respect to forwarding based on the MRIB, and that all PIM routers within the scope region map scoped groups to the same RP within that region.
PIMドメインが複数の管理範囲の領域に分割される場合、これに注目すべき例外です。これらは、マルチキャストグループの範囲はその境界を横切って転送されないように境界が設定されている領域です。管理スコープのIPマルチキャストの詳細については、RFC管理スコープ領域についての修正基準2365は、領域はMRIBに基づいて転送に対して凸状であること、参照、および範囲領域マップ内のすべてのPIMルータは、にグループをスコープことその領域内の同じRP。
This specification does not mandate the use of a single mechanism to provide routers with the information to perform the group-to-RP mapping. Currently four mechanisms are possible, and all four have associated problems:
この仕様は、グループ・ツー・RPマッピングを実行するための情報を、ルータを提供するために、単一のメカニズムの使用を強制しません。現在、4つの機構が可能であり、4つのすべての関連する問題があります。
Static Configuration A PIM router MUST support the static configuration of group-to-RP mappings. Such a mechanism is not robust to failures, but does at least provide a basic interoperability mechanism.
静的構成A PIMルータは、グループ-RPマッピングの静的な構成をサポートしなければなりません。このようなメカニズムは、障害に対して堅牢ではありませんが、少なくとも基本的な相互運用性のメカニズムを提供しません。
Embedded-RP Embedded-RP defines an address allocation policy in which the address of the Rendezvous Point (RP) is encoded in an IPv6 multicast group address [17].
組み込みRP埋め込み-RPは、ランデブーポイント（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.
シスコのAuto-RP Auto-RPは中央の場所からグループ-RPマッピングを発表するPIMデンスモードマルチキャストグループを使用しています。 PIM denseモードは、PIMスパースモードと並行して実行されていない、とだけPIMスパースモードバージョン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への立候補を報告し、その後、ドメイン全体の氾濫メカニズムは、ドメイン全体のRPのBSRの選択したセットを配布しています。 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.
運用上のPIMドメイン内のすべてのルータから到達可能であるよう構成された任意のRPアドレスは、学んだことを保証し、または宣伝する必要があります。
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:
上記のメカニズムのいずれかを使用して、PIMルータは、一つ以上の可能なグループ範囲ツーRPマッピングを受け取ります。各マッピングは、マルチキャストグループ（グループとマスクとして表される）と、そのようなグループがマッピングすべきRPの範囲を指定します。各マッピングは、関連する優先度を有していてもよいです。同一のマルチキャストグループに一致する可能性のあるすべてのそれらの複数のマッピングを、受信することが可能です。これはBSRと一般的なケースです。次のようにグループ-RPマッピングを実行するためのアルゴリズムは次のとおりです。
2. From this list of matching RPs, find the one with highest priority. Eliminate any RPs from the list that have lower priorities.
マッチングのRPのこのリスト2.、最も優先度の高いものを見つけます。下の優先順位を持つリストから任意のRPを排除します。
4. If multiple RPs are in the list, use the PIM hash function to choose one.
4.複数のRPは、いずれかを選択するPIMハッシュ関数を使用して、リストにある場合。
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.
二つ以上のグループ範囲ツー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
このアルゴリズムは、それがDRを知らないするグループのためのパケット又はIGMP / MLDメンバーシップ指示を受信すると、例えば、特定のグループのためのRPを決定する必要がDRによって呼び出され
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.
RP。これは、パケットが該当する（S、G）または（*、G）エントリが存在しないいる受信されたとき（*、*、RP）状態を有する任意のルータによって呼び出されます。さらに、マッピング関数は（*、G）または（*、*、RP）/プルーンメッセージを参加を受信するすべてのルータによって呼び出されます。
Note that if the set of possible group-range-to-RP mappings changes, each router will need to check whether any existing groups are affected. This may, for example, cause a DR or acting DR to re-join a group, or cause it to restart register encapsulation to the new RP.
可能なグループ範囲-RPマッピングの変更のセットならば、各ルータは、既存のグループが影響を受けているかどうかを確認する必要があることに注意してください。これは、例えば、DRや演技DRが再グループに参加させ、またはそれが新しいRPにカプセル化を登録し、再起動する場合があります。
Implementation note: the bootstrap mechanism described in RFC 2362 omitted step 1 above. However, of the implementations we are aware of, approximately half performed step 1 anyway. Note that implementations of BSR that omit step 1 will not correctly interoperate with implementations of this specification when used with the BSR mechanism described in [11].
実装注：上記の手順1を省略RFC 2362に記載されたブートストラップ機構。しかし、私たちが知っているの実装で、約半分とにかくステップ1を行いました。 [11]に記載のBSR機構を使用した場合、ステップ1を省略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.
ハッシュ関数は、グループレンジツーRPマッピング（このセットは、全て同じ最長のマスク長と同じ最高優先度を有する）のマッチングセットからのRPのいずれかのグループをマッピングするために、ドメイン内のすべてのルータによって使用されます。このアルゴリズムは、入力として、グループアドレス、およびマッピングからの候補RPのアドレスを取得し、使用するために、出力1つのRPアドレスとして提供します。
The protocol requires that all routers hash to the same RP within a domain (except for transients). The following hash function must be used in each router:
プロトコルは、すべてのルータが（トランジェントを除く）ドメイン内の同じRPにハッシュことが必要です。以下のハッシュ関数は、各ルータで使用する必要があります。
1. For RP addresses in the matching group-range-to-RP mappings, compute a value:
マッチンググループレンジツーRPマッピングにおけるRPアドレスについて1は、値を計算します。
Value(G,M,C(i))= (1103515245 * ((1103515245 * (G&M)+12345) XOR C(i)) + 12345) mod 2^31
値（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.
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の以外のアドレスファミリーのため、32ビットのC（i）とGとして使用するダイジェスト第1実RPまたはグループアドレスから導出されなければなりません。このようなダイジェストメソッドは、PIMドメイン全体で一貫して使用する必要があります。 IPv6アドレスのために、我々は、IPv4互換アドレスの等価IPv4アドレスを使用して、排他的または他のすべてのIPv6アドレスのアドレスの各32ビット・セグメントのをお勧めします。たとえば、IPv6アドレス3FFEのダイジェスト：B00：C18：1 :: 10は、^は排他的論理和演算を表す^ 0x0c180001 ^ 0x00000000の^ 0x00000010 0x3ffe0b00、として計算されます。
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プロトコルを用いて実現することができます。現在232.0.0.0/8 IPv4およびFF3xにおけるマルチキャストアドレスの範囲、IPv6の:: / 32は、SSMのために予約され、及びセマンティクスの選択は、データパケットおよびPIMメッセージの両方にマルチキャストグループアドレスによって決定されます。
The following rules override the normal PIM-SM behavior for a multicast address G in the SSM range:
以下の規則はSSM範囲内のマルチキャストアドレスGの通常のPIM-SMの動作をオーバーライドします。
o A router MUST NOT send a (*,G) Join/Prune message for any reason.
Oルータが何らかの理由で（*、G）参加/プルーンのメッセージを送ってはいけません。
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アドレスを宛先とするすべてのパケットのためにRegisterメッセージを送ってはいけません。
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つのルールがSSM宛先アドレスのメッセージを（*、G）を送信し、（S、G、RPT）参加/プルーン、または登録することができる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アドレス宛のパケットを含む任意のRegisterメッセージに登録-Stopメッセージで応答する必要があります。
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)
ダウンストリーム（S、G）ステートマシンO（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メッセージ、近隣探索、およびDRの選出（4.3節）
o Packet forwarding rules (Section 4.2)
Oパケット転送ルール（4.2節）
A PIM-SSM-only router does not need to implement the following protocol elements:
PIM-SSM-のみのルータは、次のプロトコル要素を実装する必要はありません。
o Register state machine (Section 4.4)
Oステート・マシンを登録します（4.4節）
o (*,G), (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ブートストラップRP選挙（4.7節）
o Keepalive Timer
Oキープアライブタイマー
o SPTbit (Section 4.2.2)
SPTbit O（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:
キープアライブタイマーは、常に実行しているとして扱われるべきである、と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 }
（IIF == RPF_interface（S）と上流Upstate社（S、G）==メンバー）もしあれば他{（S、G）OLISTを継承=リストを}（IIFは引き継いでいる_olist（S、G）である）{（アサートを送信IIFにS、G）}
oiflist = oiflist (-) iif forward packet on all interfaces in oiflist
oiflist = oiflist（ - ）oiflist内のすべてのインターフェイス上でIIF転送パケット
This is nothing more than the reduction of the normal PIM-SM forwarding rule, with all (S,G,rpt) and (*,G) clauses replaced with NULL.
これは、すべての（S、G、RPT）とNULLに置き換え（*、G）の句と通常のPIM-SMの転送ルールの削減以外の何物でも、ありません。
This section describes the details of the packet formats for PIM control messages.
このセクションでは、PIM制御メッセージのパケットフォーマットの詳細について説明します。
All PIM control messages have IP protocol number 103.
すべてのPIMコントロールメッセージは、IPプロトコル番号103を持っています。
PIM messages are either unicast (e.g., Registers and Register-Stop) or multicast with TTL 1 to the 'ALL-PIM-ROUTERS' group (e.g., Join/Prune, Asserts, 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メッセージは、ユニキャスト（例えば、レジスタ、レジスタ・停止）または「ALL-PIM-ルータのグループ（例えば、/プルーンに参加し、アサートなど）にTTL 1とマルチキャストのいずれかです。ユニキャストメッセージに使用される送信元アドレスは、ドメイン全体の到達可能なアドレスです。マルチキャストメッセージのために使用されるソースアドレスは、メッセージが送信されているインターフェイスのリンクローカルアドレスです。
The IPv4 'ALL-PIM-ROUTERS' group is '224.0.0.13'. The IPv6 'ALL-PIM-ROUTERS' group is 'ff02::d'.
IPv4の 'ALL-PIM-ルータのグループは、 '224.0.0.13' です。 IPv6の「ALL-PIM-ルータのグループは、 '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版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チェックサム、Registerメッセージの「マルチキャストデータパケット」セクションを除く全体PIMメッセージの1の補数和の、すなわち、16ビットの1の補数です。チェックサムを計算するために、チェックサムフィールドがゼロにされます。パケットの長さは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.
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版またはタイプフィールドで受信される、またはメッセージの宛先は、上記の表に対応しない場合、メッセージは破棄されなければならない、およびエラーメッセージが速度制限のようにして管理者にログインする必要がある場合。
Encoded-Unicast Address
エンコードされたユニキャストアドレス
An Encoded-Unicast address takes the following format:
エンコードされたユニキャストアドレスは次の形式を取ります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type | Unicast Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
Addr Family The PIM address family of the 'Unicast Address' field of this address.
ADDR家族このアドレスの「ユニキャストアドレス」欄の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.
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] idirectional 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.
管理範囲[Z]一つはグループ範囲は、管理スコープゾーンであることを示します。これが唯一のブートストラップルータのメカニズム[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つのビットの数です。グループアドレスと組み合わされたとき、それがグループの範囲が記載されています。これは、指定されたアドレスファミリとエンコードタイプのためのビットのアドレスの長さ以下です。メッセージが単一のグループのために送られている場合、マスクの長さは、指定されたアドレスファミリとエンコードタイプ（IPv6のネイティブ符号化するための、例えば、IPv4のネイティブ符号化のための32、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スパースビットは、PIM-SMのために1に設定された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).
WC（またはワイルドカード）Wビットは、PIM加入/プルーンメッセージ（セクション4.9.5.1を参照）と共に使用するための1ビットの値です。
R The RPT (or Rendezvous Point Tree) bit is a 1-bit value for use with PIM Join/Prune messages (see Section 4.9.5.1). If the WC bit is 1, the RPT bit MUST be 1.
Rザ・RPT（またはランデブーポイントツリー）ビットは、PIM参加/プルーンのメッセージ（セクション4.9.5.1を参照）で使用するための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ビットであるレンマスク。値は、ソースアドレスと組み合わされ、ソースサブネットを記述するマスクとして左寄せ連続する1つのビットの数です。マスク長は、指定されたアドレスファミリとエンコードタイプのためのビットのマスク長（ネイティブ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.
次OptionValue分野で与えられたオプションの種類でoptionType。
OptionLength The length of the OptionValue field in bytes.
バイト単位でOptionValueフィールドの長さOptionLength。
OptionValue A variable length field, carrying the value of the option.
オプションの値を運んで、可変長フィールドをOptionValue。
The Option fields may contain the following values:
オプションフィールドには、次の値が含まれる場合があります。
o OptionType 1: Holdtime
1でoptionType O：ホールドタイム
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メッセージでリンクを追いつい避けるために、ダイヤルオンデマンドリンクを使用することができます。
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」に設定ホールドタイム値を持つメッセージは、（4.3.1項を参照）を下るまたはIPアドレスを変更する程度のインターフェイス上のルータによって送信されます。これらは、効果的にお別れのメッセージであり、受信ルータはすぐに送信者のネイバー情報をタイムアウトする必要があります。
o OptionType 2: LAN Prune Delay
OでoptionType 2：LANプルーン遅延
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| Propagation_Delay | Override_Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The LAN Prune Delay option is used to tune the prune propagation delay on multi-access LANs. The T bit specifies the ability of the sending router to disable 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プルーンDelayオプションは、マルチアクセスLANのプルーンの伝播遅延を調整するために使用されます。 Tビットは、抑制に参加し無効にするには、送信ルータの能力を指定します。 PROPAGATION_DELAYとOverride_Intervalは、ミリ秒単位の時間間隔です。インターフェイス上のLANプルーンDelayオプションを発信するルータは、私がPROPAGATION_DELAY（I）の設定された値とOverride_Interval（I）の値にOverride_Intervalフィールドの値にPROPAGATION_DELAYフィールドを設定します。受信ルータ上で、フィールドの値を調整するためにEffective_Override_Interval（I）及びその派生タイマ値の値を使用しています。 4.3.3は、これらの値は、ルータの動作に影響を与える方法を説明します。
o OptionType 3 to 16: reserved to be defined in future versions of this document.
3〜16でoptionType 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優先順位は、32ビットの符号なしの数であり、セクション4.3.2に記載されているようにDR選挙において考慮されるべきです。
o OptionType 20: Generation ID
OでoptionType 20：ジェネレーションID
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 20 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Generation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Generation ID is a random 32-bit value for the interface on which the Hello message is sent. The Generation ID is regenerated whenever PIM forwarding is started or restarted on the interface.
世代IDは、Helloメッセージが送信されたインターフェイスのためのランダム32ビット値です。 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.
アドレス一覧のHelloオプションの内容は、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].
65000経由のオプションタイプ17は、IANAによって割り当てられます。 [9]で定義されるようにオプションタイプ65001〜65535は、プライベート使用のために予約されています。
Unknown options MUST be ignored and MUST NOT prevent a neighbor relationship from being formed. The "Holdtime" option MUST be implemented; the "DR Priority" and "Generation ID" options SHOULD be implemented. The "Address List" option MUST be implemented for IPv6.
不明なオプションは無視されなければならないと形成されることから、ネイバー関係を妨げてはなりません。 「ホールドタイム」オプションを実装する必要があります。 「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-ツリー上で送信する必要があるとき登録メッセージはDRまたはRPにPMBRによって送信されます。 IPソースアドレスがDR、RPのアドレスに送信先アドレスのアドレスに設定されています。 PIMパケットのIP TTLは、システムの正常なユニキャストTTLです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B|N| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Multicast data packet .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Type, Reserved, Checksum Described in Section 4.9. Note that in order to reduce encapsulation overhead, the checksum for Registers is done only on the first 8 bytes of the packet, including the PIM header and the next 4 bytes, excluding the data packet portion. For interoperability reasons, a message carrying a checksum calculated over the entire PIM Register message should also be accepted. When calculating the checksum, the IPv6 pseudoheader "Upper-Layer Packet Length" is set to 8.
PIMバージョン、タイプは、予約済み、チェックサムは、4.9節で説明します。データパケットの部分を除いた、カプセル化オーバヘッドを削減するために、レジスタのチェックサムのみPIMヘッダと次の4つのバイトを含むパケットの最初の8バイトで行われることに留意されたいです。相互運用性の理由から、全体のPIM Registerメッセージの上に計算されたチェックサムを運ぶメッセージも受け入れられるべきです。チェックサムを計算する場合、のIPv6擬似ヘッダ「上位層パケット長は」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である場合、ルータは直接接続されたクラウド内のソースのPMBRである場合、それは0にBビットを設定し、それは1にBビットをセットします。
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ザ・ヌル・レジスタのビット。そのローカル登録-抑制タイマーの期限切れ前にRPを探査されるDRによって1に設定します。それ以外の場合は0に設定します。
Reserved2 Transmitted as zero, ignored on receipt.
Reserved2は、領収書の上で無視、ゼロとして送信します。
Multicast data packet The original packet sent by the source. This packet must be of the same address family as the encapsulating PIM packet, e.g., an IPv6 data packet must be encapsulated in an IPv6 PIM packet. Note that the TTL of the original packet is decremented before encapsulation, just like any other packet that is forwarded. In addition, the RP decrements the TTL after decapsulating, before forwarding the packet down the shared tree.
マルチキャストデータは、ソースによって送信された元のパケットをパケット。このパケットがカプセル化PIMパケットと同じアドレスファミリーである必要があり、例えば、IPv6データパケットは、IPv6 PIMパケットにカプセル化されなければなりません。元のパケットのTTLがちょうど転送され、他のパケットと同様に、カプセル化の前に減算されることに注意してください。また、RPは、共有ツリーの下のパケットを転送する前に、カプセル化解除後のTTLを減少します。
For (S,G) Null-Registers, the Multicast data packet portion
contains a dummy IP header with S as the source address, 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.
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.
ヘッダチェックサムフィールドが非ゼロである場合（S、G）ヌルレジスタを受信すると、受信者は、チェックサムをチェックし、不正なチェックサムを有するヌルレジスタを破棄すべきです。受信者は、任意の個々のフィールドの値をチェックするべきではありません。正しいIPヘッダチェックサムは十分です。ヘッダチェックサムフィールドがゼロの場合、受信者はチェックサムをチェックしてはなりません。
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では、実装がソースグループに加えて、以下の表に従って値を持つダミーPIMヘッダに続くダミーIPヘッダを生成します。他の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.
ダミーPIMヘッダが存在する場合、IPv6の（S、G）ヌルレジスタを受信すると、受信者は、チェックサムをチェックし、不正なチェックサムを有するヌルレジスタを破棄すべきです。
A Register-Stop is unicast from the RP to the sender of the Register message. The IP source address is the address to which the register was addressed. The IP destination address is the source address of the register message.
登録・停止は、Registerメッセージの送信者に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で説明します。登録ストップ用マスクLENフィールドは、完全なアドレス長が含まれていることに注意してください* 8（例えば、IPv4のネイティブ符号化のための32）と、メッセージは、単一のグループのために送られている場合。
Source Address The host address of the source from the multicast data packet in the register. The format for this address is given in the Encoded-Unicast address in Section 4.9.1. A special wild card value consisting of an address field of all zeros can be used to indicate any source.
ソースは、レジスタ内のマルチキャストデータパケットから送信元のホストアドレス。このアドレスの形式は、セクション4.9.1でエンコードされたユニキャストアドレスに与えられています。すべてゼロのアドレスフィールドからなる特殊なワイルドカード値は、任意のソースを示すために使用することができます。
A Join/Prune message is sent by routers towards upstream sources and RPs. Joins are sent to build shared trees (RP trees) or source trees (SPT). Prunes are sent to prune source trees when members leave groups as well as sources that do not use the shared tree.
参加/プルーンメッセージがアップストリームソースとの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.
PIMバージョン、タイプは、予約済み、チェックサムは、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.
ユニキャスト上流隣接には、メッセージのターゲットである上流ネイバーのアドレス。このアドレスの形式は、セクション4.9.1でエンコードされたユニキャストアドレスに与えられています。 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.
ホールドタイムレシーバは秒で、生きて参加/プルーンの状態を維持しなければならない時間の量。ホールドタイムが「0xFFFFの」に設定されている場合、このメッセージの受信側は/プルーンメッセージを参加キャンセル適切によってキャンセルされるまでの状態を保持する、またはローカルポリシーに従ってタイムアウトしなければなりません。これは、定期的な参加/プルーンのメッセージでリンクを追いつい避けるために、ダイヤルオンデマンドリンクを使用することができます。
Note that the HoldTime must be larger than the
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はこのリストには、送信側のルータが参加/プルーンメッセージが送信されているインターフェイス上で受信した場合のマルチキャストデータグラムを転送します特定のグループのためのソースが含まれています。
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はこのリストには、送信側のルータが参加/プルーンメッセージが送信されているインターフェイス上で受信したときからのマルチキャストデータグラムを転送したくない特定のグループのためのソースが含まれています。
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つまたは複数のグループセットで構成されている参加。各セットには、二つのソースリスト、参加ソースと剪定ソースが含まれています。このセクションでは、参加/プルーンメッセージで存在することができるグループセットとソースリストのエントリの異なるタイプを記述する。
There are two valid group set types:
2つの有効なグループセットの種類があります。
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.
'、グループアドレスフィールドにマルチキャストアドレス範囲の開始とマルチキャストグループアドレス（すなわちのマスク長フィールド内のマルチキャストアドレス範囲のプレフィックス長：ワイルドカードグループセットのワイルドカードグループセットは、全マルチキャスト範囲で表され、 IPv6のFF00 :: / 8 '）IPv4またはのための' 224.0.0.0/4' 。それぞれ/プルーンのメッセージは最大で1つのワイルドカードグループセットに含まれているべきで参加します。各ワイルドカードグループセットは、いずれかの参加またはプルーニングリスト内の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) 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のアドレスに設定ソース・アドレスは、送信元アドレスマスク - レンはIPアドレスの完全な長さに設定されている、とソースのWCとRPTビットの両方1に設定-address。
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.
グループ固有のセットAグループ固有の設定は、グループアドレスフィールドに有効なIPマルチキャストアドレスおよびマルチキャストグループアドレスのマスク長フィールドでIPアドレスの完全な長さで表されます。各参加/プルーンのメッセージは、同じ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に向けて送信/プルーンメッセージに参加します。これは、ランデブーポイントの共有ツリーをグループに送信されたトラフィックの受信に関心（またはその欠如）を表します。唯一のグループ固有のセットの両方の参加およびプルーニングリスト内の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.
(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に向けて送信/プルーンメッセージに参加します。これは、このグループに指定されたソースによって送信され、共有ツリーを通過するトラフィックを受信することに関心（またはその欠如）を表します。各送信元アドレスのために、エントリが両方ではなく、グループ固有のセットのメンバーと剪定ソースリストの一方のみに存在してもよいです。
(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) 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）ソース・リスト・エントリは、指定した送信元に向けて送信/プルーンメッセージに参加して使用されます。これは、指定されたグループのソースによって送信された最短経路ツリーを介してトラフィックを受信することに関心（またはその欠如）を表します。各送信元アドレスのために、エントリが両方ではなく、グループ固有のセットのメンバーと剪定ソースリストの一方のみに存在してもよいです。
(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.
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.
（*、G）エントリが（S、G、RPT）エントリによって提供される情報をカバーするように（*、G）に参加し、（S、G、RPT）同じメッセージ内のエントリに参加を組み合わせるoを冗長です。
o The same applies for a (*,G) Prunes and (S,G,rpt) Prunes.
同じことが（*、G）プルーン及び（S、G、RPT）プルーンに適用され、O。
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（*、G）プルーン及び（S、G、RPT）参加の組み合わせも発生しません。 （S、G、RPT）は、ルータが共有ツリー上のグループのすべてのトラフィックを受信している場合にのみ送信されジョイン、それが特定のソースの変更を指示することを望みます。 （*、G）プルーンは、ルータはもはや共有ツリーのトラフィックを受信したいことを示していないので、（S、G、RPT）が参加し意味がありません。
o As Join/Prune messages are targeted to a single PIM neighbor, including both 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などが同じメッセージにプルーンメッセージが（S、G）に参加し、（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（S、G）プルーン及び（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）結合Sourceリストエントリを含むグループセットとの例外があります。グループセットは共有ツリー上の指定したグループのすべてのトラフィックの受信にルータの関心を表現し、そしてそれは、ルータが受信したくないすべてのソースの（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.
アサートメッセージは、リンク上のルータ間のフォワーダの競合を解決するために使用されます。ルータは、ルータが正常にそのパケットを転送しているだろうしたインターフェイス上のマルチキャストデータパケットを受信したときに送信されます。アサートメッセージも別のルータからのAssertメッセージに応答して送信することができます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Metric Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Type, Reserved, Checksum Described in Section 4.9.
PIMバージョン、タイプは、予約済み、チェックサムは、4.9節で説明します。
Group Address The group address for which the router wishes to resolve the forwarding conflict. This is an Encoded-Group address, as specified in Section 4.9.1.
グループでは、ルータが転送の競合を解決することを希望するグループアドレス。セクション4.9.1で指定されたように、これは、エンコード・グループアドレスです。
Source Address Source address for which the router wishes to resolve the forwarding conflict. The source address MAY be set to zero for (*,G) asserts (see below). The format for this address is given in Encoded-Unicast-Address in Section 4.9.1.
ルータが転送競合を解決することを望むの送信元アドレスを送信元アドレス。送信元アドレスは、（*、G）がゼロに設定されてもよい（下記参照）をアサートします。このアドレスの形式は、セクション4.9.1でエンコードされたユニキャスト・アドレスに与えられています。
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ビットは、1ビットの値です。 RPTビットはアサート（S、G）メッセージにアサート（*、G）メッセージのための1と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がTRUEである）最短パス木の特定のソースを転送するルータによって送信されます。 （S、G）は、グループGおよびSザRPTビットは0に設定されているソースに設定ソースアドレスフィールドに設定されたグループアドレスフィールドがアサートメトリック好ましくはMRIB.pref（Sに設定されています）とメトリックはMRIB.metric（S）に設定されています。
Assert(*,G) Group-specific asserts are sent by routers forwarding data for the group and source(s) under contention on the shared tree. (*,G) asserts have the Group-Address field set to the group G. For data-triggered Asserts, the Source-Address field MAY be set to the IP source address of the data packet that triggered the Assert and is set to zero otherwise. The 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）グループ固有のアサートは、共有ツリー上の競合下でグループ及びソース（S）のデータを転送するルータによって送信されます。 （*、G）は、データ・トリガアサート、ソース・アドレス・フィールドはアサートをトリガーし、ゼロに設定されているデータパケットの送信元IPアドレスに設定されるかもしれについてグループGに設定し、グループアドレスフィールドを持って主張しますそうでなければ。 RPTビットが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.
4.1節で述べたようにPIM-SMは、次のタイマーを維持します。すべてのタイマーはカウントダウンタイマーです。彼らは、値に設定され、それらは、典型的にはアクションをトリガその時点でゼロにカウントダウンされます。もちろん、彼らは同じように簡単に絶対有効期限の時間は、リアルタイムクロックに対して保存され、比較され、カウントアップタイマー、として実装されますが、この仕様では、言語は、彼らがゼロに下向きに数えることを前提としてすることができます。
Global Timers
グローバル営業時間
Per interface (I):
インターフェイスごとに（I）：
Hello Timer: HT(I)
こんにちはタイマー：HT（I）
Per neighbor (N):
隣人（N）あたり：
Neighbor Liveness Timer: NLT(N,I)
近隣ライブネスタイマー：NLT（N、I）
Per active RP (RP):
あたりのアクティブRP（RP）：
(*,*,RP) Join Expiry Timer: ET(*,*,RP,I)
（*、*、RP）が有効期限タイマーに参加：ET（*、*、RP、I）
(*,*,RP) Prune-Pending Timer: PPT(*,*,RP,I)
（*、*、RP）プルーン-保留タイマー：PPT（*、*、RP、I）
Per Group (G):
グループごと（G）：
(*,G) Join Expiry Timer: ET(*,G,I) (*,G) Prune-Pending Timer: PPT(*,G,I)
（*、G）が有効期限タイマーに参加：ET（*、G、I）（*、G）プルーン-保留タイマー：PPT（*、G、I）
(*,G) Assert Timer: AT(*,G,I)
（*、G）アサートタイマー：AT（*、G、I）
Per Source (S):
パーソース（S）：
(S,G) Join Expiry Timer: ET(S,G,I)
（S、G）参加期限タイマー：ET（S、G、I）
(S,G) Prune-Pending Timer: PPT(S,G,I)
（S、G）プルーン保留タイマー：PPT（S、G、I）
(S,G) Assert Timer: AT(S,G,I)
（S、G）アサートタイマー：AT（S、G、I）
(S,G,rpt) Prune Expiry Timer: ET(S,G,rpt,I)
（S、G、RPT）プルーン期限タイマー：ET（S、G、RPT、I）
(S,G,rpt) Prune-Pending Timer: PPT(S,G,rpt,I)
（S、G、RPT）プルーン保留タイマー：PPT（S、G、RPT、I）
Per active RP (RP):
あたりのアクティブRP（RP）：
(*,*,RP) Upstream Join Timer: JT(*,*,RP)
（*、*、RP）上流はタイマーに参加：JT（*、*、RP）
Per Group (G):
グループごと（G）：
(*,G) Upstream Join Timer: JT(*,G)
（*、G）上流のタイマーに参加：JT（*、G）
Per Source (S):
パーソース（S）：
(S,G) Upstream Join Timer: JT(S,G)
JT（S、G）：（S、G）上流タイマに参加します
(S,G) Keepalive Timer: KAT(S,G)
（S、G）キープアライブタイマー：KAT（S、G）
(S,G,rpt) Upstream Override Timer: OT(S,G,rpt)
（S、G、RPT）上流オーバーライドタイマ：OT（S、G、RPT）
At the DRs or relevant Assert Winners only:
DRまたは関連するアサート受賞者だけでは：
Per Source,Group pair (S,G):
ソースごと、グループのペア（S、G）：
Register-Stop Timer: RST(S,G)
登録ストップタイマー：RST（S、G）
When timers are started or restarted, they are set to default values. This section summarizes those default values.
タイマーが起動または再起動されると、それらはデフォルト値に設定されています。ここでは、これらのデフォルト値をまとめたもの。
Note that protocol events or configuration may change the default value of a timer on a specific interface. When timers are initialized in this document, the value specific to the interface in context must be used.
プロトコルイベントや設定は、特定のインターフェイス上のタイマーのデフォルト値を変更することがあります。タイマーが本書で初期化されている場合は、コンテキストのインターフェイスに特定の値を使用する必要があります。
Some of the timers listed below (Prune-Pending, Upstream Join, Upstream Override) can be set to values that depend on the settings of the Propagation_Delay and Override_Interval of the corresponding interface. The default values for these are given below.
下記タイマーの一部は、対応するインターフェースのPROPAGATION_DELAYとOverride_Intervalの設定に依存する値に設定することができる（プルーン-保留は、アップストリームは、アップストリームオーバーライドに参加します）。これらのデフォルト値は以下の通りです。
Variable Name: Propagation_Delay(I)
変数名：PROPAGATION_DELAY（I）
+-------------------------------+--------------+----------------------+
| Value Name | Value | Explanation |
+-------------------------------+--------------+----------------------+
| Propagation_delay_default | 0.5 secs | Expected |
| | | propagation delay |
| | | over the local |
| | | link. |
+-------------------------------+--------------+----------------------+
The default value of the Propagation_delay_default is chosen to be relatively large to provide compatibility with older PIM implementations.
Propagation_delay_defaultのデフォルト値は古いPIM実装との互換性を提供するために比較的大きくなるように選択されます。
Variable Name: Override_Interval(I)
変数名：Override_Interval（I）
+--------------------------+-----------------+-------------------------+
| Value Name | Value | Explanation |
+--------------------------+-----------------+-------------------------+
| t_override_default | 2.5 secs | Default delay |
| | | interval over |
| | | which to randomize |
| | | when scheduling a |
| | | delayed Join |
| | | message. |
+--------------------------+-----------------+-------------------------+
Timer Name: Hello Timer (HT(I))
タイマー名前：こんにちはタイマー（HT（I））
+---------------------+--------+---------------------------------------+
|Value Name | Value | Explanation |
+---------------------+--------+---------------------------------------+
|Hello_Period | 30 secs| Periodic interval for Hello messages. |
+---------------------+--------+---------------------------------------+
|Triggered_Hello_Delay| 5 secs | Randomized interval for initial Hello |
| | | message on bootup or triggered Hello |
| | | message to a rebooting neighbor. |
+---------------------+--------+---------------------------------------+
At system power-up, the timer is initialized to rand(0, Triggered_Hello_Delay) to prevent synchronization. When a new or rebooting neighbor is detected, a responding Hello is sent within rand(0, Triggered_Hello_Delay).
システムのパワーアップ時に、タイマが同期化を防ぐためのrand（0、Triggered_Hello_Delay）に初期化されます。新規または再起動ネイバーが検出されると、応答こんにちはは、ランド（0、Triggered_Hello_Delay）内で送信されます。
Timer Name: Neighbor Liveness Timer (NLT(N,I))
タイマー名：隣人ライブネスタイマー（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.
こんにちは、メッセージでのホールドタイムは105秒のデフォルト値を与える、（3.5 * Hello_Period）に設定する必要があります。
Timer Names: Expiry Timer (ET(*,*,RP,I), ET(*,G,I), ET(S,G,I), ET(S,G,rpt,I))
H名称：タイマ満了（ET（*、*、RP、I）、（*、G、I）、（S、G、I）、（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.
参加に含まれているホールドタイムのためのJT（*、G）の詳細/プルーンのメッセージを参照してください。
Timer Names: Prune-Pending Timer (PPT(*,*,RP,I), PPT(*,G,I), PPT(S,G,I), PPT(S,G,rpt,I))
タイマー名：プルーン-保留タイマー（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).
Effective_Propagation_Delay（I）及びEffective_Override_Interval（I）の両方が（セクション4.3.3を参照）Helloメッセージを受信したときに変更することができるインタフェース固有の値であることに注意してください。
Timer Names: Assert Timer (AT(*,G,I), AT(S,G,I))
タイマー名：アサートタイマー（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))
タイマー名：上流は、タイマー（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のアカウントに設定された帯域幅のようなものを取るように設定し、接続されたネットワークまたはリンクのためのマルチキャストルートエントリの平均数を予想（例えば、期間は低速リンクのため、またはの中心にあるルータに長くなりすることができますエントリのより大きな数を持つことを期待ネットワーク）。参加/プルーン期間は動作中に変更された場合、これらの変更は比較的まれにしか行われるべきである、とルータは、上流を可能にするために、少なくとも/プルーン-ホールドタイム参加のために、以前の参加/プルーン期間でリフレッシュし続けなければなりません適応するルータ。
The holdtime specified in a Join/Prune message should be set to (3.5 * t_periodic).
参加/プルーンのメッセージで指定されたホールドタイムは（3.5 * t_periodic）に設定する必要があります。
t_override depends on the Effective_Override_Interval of the upstream interface, which may change when Hello messages are received.
t_overrideは、Helloメッセージを受信したときに変更することができる上流インタフェースのEffective_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_suppressed上流インタフェース（4.3.3）の抑制状態に依存して抑制が無効になっているときにはゼロとなります。
Timer Name: Upstream Override Timer (OT(S,G,rpt))
タイマ名：上流タイマー（OT（S、G、RPT））をオーバーライド
+---------------+--------------------------+---------------------------+
| Value Name | Value | Explanation |
+---------------+--------------------------+---------------------------+
| t_override | see Upstream Join Timer | see Upstream Join Timer |
+---------------+--------------------------+---------------------------+
The upstream Override Timer is only ever set to t_override; this value is defined in the section on Upstream Join Timers.
上流のオーバーライドタイマーがしかt_overrideに設定されています。この値は、上流のセクションで定義されているタイマーに参加。
Timer Name: Keepalive Timer (KAT(S,G))
タイマ名：キープアライブタイマー（KAT（S、G））
+-----------------------+-----------------------+----------------------+
| Value Name | Value | Explanation |
+-----------------------+-----------------------+----------------------+
| Keepalive_Period | Default: 210 secs | Period after last |
| | | (S,G) data packet |
| | | during which (S,G) |
| | | Join state will be |
| | | maintained even in |
| | | the absence of |
| | | (S,G) Join |
| | | messages. |
+-----------------------+-----------------------+----------------------+
| RP_Keepalive_Period | ( 3 * Register_ | As |
| | Suppression_Time ) | Keepalive_Period, |
| | + Register_ | but at the RP when |
| | Probe_Time | a Register-Stop is |
| | | sent. |
+-----------------------+-----------------------+----------------------+
The normal keepalive period for the KAT(S,G) defaults to 210 seconds. However, at the RP, the keepalive period must be at least the Register_Suppression_Time, or the RP may time out the (S,G) state before the next Null-Register arrives. Thus, the KAT(S,G) is set to max(Keepalive_Period, RP_Keepalive_Period) when a Register-Stop is sent.
210秒KAT（S、G）のデフォルトの通常のキープアライブ期間。しかしながら、RPで、キープアライブ期間が少なくともRegister_Suppression_Timeなければならない、または次のヌル・レジスタが到着する前にRPは（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].
127までの値0は、IANAによって割り当てられたアドレスファミリ番号と同じ意味を持つように指定されている[7]。
Values 128 through 250 are designated to be assigned for PIM by the IANA based upon IESG Approval, as defined in [9].
250を介して128の値は、[9]で定義されるように、IESGの承認に基づいて、IANAによってPIMのために割り当てられるように指定されています。
Values 251 through 255 are designated for Private Use, as defined in [9].
で定義されている255までの値251は、私的使用のために指定されている[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].)
65000までの値17は、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.
このセクションでは、プロトコルを保護するためにIPsecを使用する方法の説明を含むPIM-SMプロトコルに関連する様々な可能性のあるセキュリティの問題について説明します。読者は、PIM-SMおよびマルチキャストセキュリティのさらなる議論については[15]及び[16]と呼ばれます。 IPsec認証ヘッダ[8] PIMプロトコルメッセージのデータ保全性保護およびGroupWiseデータ発信元認証を提供するために使用され得ます。 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.
損傷の程度は受け入れられた偽造メッセージの種類によって異なります。私たちは、次の鍛造リンクローカル（/プルーン、こんにちは、とアサートへの参加）と鍛造ユニキャスト（とレジスタ・ストップ）メッセージを含む可能偽造の影響を考慮する。
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に到達することができます。
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. Aはプルーンのメッセージは、マルチキャストトラフィックが潜在的にそのリンク上の帯域幅を浪費し、正当な要求者が存在しないリンクに配信されることがあります/参加鍛造しました。いずれかが合法的に上流のルータは、LANへのデータの転送を停止する前に、LAN上のルータが参加して休暇をオーバーライドします参加しているため、マルチアクセスLAN上の偽造Leaveメッセージは、一般的にPIMの重要な攻撃ではありません。
2. By forging a Hello message, an unauthorized router can cause itself to be elected as the designated router on a LAN. The designated router on a LAN is (in the absence of asserts) responsible for forwarding traffic to that LAN on behalf of any local members. The designated router is also responsible for register-encapsulating to the RP any packets that are originated by hosts on the LAN. Thus, the ability of local hosts to send and receive multicast traffic may be compromised by a forged Hello message.
2. Helloメッセージを鍛造することにより、不正なルータは自身がLAN上の指定ルータとして選出されることがあります。 LAN上の指定ルータは（が存在しない場合にアサート）任意のローカルメンバーに代わってそのLANにトラフィックを転送する責任があります。指定されたルータは、レジスタ封入RPにLAN上のホストから発信されているすべてのパケットをする責任があります。このように、マルチキャストトラフィックを送受信するローカルホストの能力は、偽造Helloメッセージによって損なわれる可能性があります。
3. By forging an Assert message on a multi-access LAN, an attacker could cause the legitimate designated forwarder to stop forwarding traffic to the LAN. Such a forgery would prevent any hosts downstream of that LAN from receiving traffic.
3.マルチアクセスLAN上のAssertメッセージを鍛造することにより、攻撃者は正当な指定フォワーダがLANへのトラフィックの転送を停止する可能性があります。このような偽造は、トラフィックを受信しているLANの下流の任意のホストを防止するであろう。
Register messages and Register-Stop messages are forwarded by intermediate routers to their destination using normal IP forwarding. Without data origin authentication, an attacker who is located anywhere in the network may be able to forge a Register or Register-Stop message. We consider the effect of a forgery of each of these messages next.
メッセージを登録し、登録-STOPメッセージは、通常のIP転送を使用して、その先に中間ルータによって転送されます。データ発信元認証、登録を偽造または登録-Stopメッセージをすることができるかもしれネットワーク内の任意の場所に位置して攻撃者はなし。私たちは、次のようなメッセージのそれぞれの偽造の影響を考慮してください。
1. By forging a Register message, an attacker can cause the RP to inject forged traffic onto the shared multicast tree.
1. Registerメッセージを鍛造することにより、攻撃者は共有マルチキャストツリー上に偽造トラフィックを注入するために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.登録停止メッセージを鍛造により、攻撃者は、RPにパケットを登録から正当DRを防止することができます。これは、マルチキャストパケットを送信してから、その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.
上記の二つのPIMメッセージは、中間ルータによって変更されないとのみ意図され、受信機により検査される必要があります。したがって、これらのメッセージは、AHを使用して、エンドツーエンドを認証することができます。これらのメッセージは、PIM-SSMのために必要とされていないとして登録への攻撃と登録-STOPメッセージは、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ルータは、それが/プルーン、アサート、および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プロトコルメッセージを認証するために送信者によって使用され、受信PIMを認証するための受信機で使用される1つのまたは複数のセキュリティアソシエーション（SA）と関連するセキュリティパラメータインデックス（SPIの）で、各PIMルータを設定しますプロトコルメッセージ。この文書では、SAを確立するためのプロトコルを説明していません。これは、SAの手動設定が行われていることを前提としていますが、それは、SAを確立するために、このようなインターネット鍵交換などネゴシエーションプロトコル[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プロトコルメッセージを保護するために必要なSAを記述する。
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プロトコルメッセージを認証するために使用されることを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は、[8]ことができます（ただし、必須ではありません）、各ルータインターフェイスごとに異なるセキュリティポリシーデータベース（SPD）を。利用可能ならば、それはPIMルータでのセキュリティポリシーデータベースを構成することが望ましいようにすべての着信および/プルーン、アサートに参加し、helloパケットがそれぞれ着信または発信インターフェイスのために別のSAを使用して、発信。
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 Registerパケットを送信するときに使用する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に話をするために、異なる認証アルゴリズムとキーを持つことができます。しかし、これは、ネットワーク管理者のための困難な鍵の管理と配布問題を作成します。したがって、それはすべての指定ルータに関係なくRPとDRている人の、（キーを含む）は、同じ認証アルゴリズムパラメータは、ドメインに登録されたすべてのパケットのために使用され、単一の管理制御下にあるPIMドメインに好ましいかもしれません。
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に登録メッセージを送信するとき（認証アルゴリズム、認証パラメータ、およびこのSPIを含む）SAを選択するように構成されています。
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へのユニキャストであるため、異なるSAおよび潜在的にユニークなSPIは、各DRのために必要とされます。
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.
管理問題を簡単にするために、関係なく送信RPのかかわらず先DRの、同じ認証アルゴリズムと認証パラメータを使用することが許容されることができます。一意のSAを各DRのために必要とされているが、同じ認証アルゴリズムと認証アルゴリズムパラメータ（秘密鍵）は、すべてのDRによって、すべてのRPで共有することができます。
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.
- Joinメッセージを偽造することは、マルチキャストツリーが設定を取得することがあります。鍛造の大多数は、ルータのリソースを消費し、サービス拒否が発生することができます結合します。
- 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.
- （*、*、RP）に参加を鍛造することは参加発行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.劉、Puneetシャルマ、黎明魏からのアイデア、コメント、修正を含め、人々の大規模なグループで長年にわたり設計されました、トムPusateri、トニー・Ballardie、スコット・ブリム、ジョンクロウクロフト、ポール・フランシス、ジョエル・ハルパーン、ホルストHodel、ポリー黄、スティーブンOstrowski、Lixiaチャン、Girish Chandranmenon、ブライアンハーバーマン、ハルSandick、マイク・Mroz、ギャリーKump、Pavlin Radoslavov、マイクデイヴィソン、ジェームズ黄、クリストファー・トーマス・ブラウン、ジェームスリンガード。
Thanks are due to the American Licorice Company, for its obscure but possibly essential role in the creation of this document.
おかげで、この文書の作成におけるその曖昧しかし、おそらく重要な役割のために、アメリカの甘草会社によるものです。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[2]カイン、B.、デアリング、S.、Kouvelas、I.、フェナー、B.、およびA. Thyagarajan、 "インターネットグループ管理プロトコル、バージョン3"、RFC 3376、2002年10月。
[3] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[3]デアリング、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]デアリング、S.、フェナー、W.、およびB.ハーバーマン、 "マルチキャストリスナ発見IPv6の（MLD）"、RFC 2710、1999年10月。
[5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[5]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[6] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4507, August 2006.
[6]ホルブルック、H.、およびB.カイン、 "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]ケント、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]ベイツ、T.、Rekhter、Y.、チャンドラ、R.、およびD.カッツ、 "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.、ガル、A.、リンガード、J.、およびS. Venaas、 "PIMスパースモードのためのブートストラップルータ（BSR）メカニズム"、進歩、2006年5月に働いています。
[12] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[12]ブラック、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]ハンドレー、M.、Kouvelas、I.、スピークマン、T.、およびL. Vicisano、 "双方向プロトコル独立マルチキャスト"、進歩、2005年10月に働いています。
[14] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[14]カウフマン、C.、 "インターネットキーエクスチェンジ（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.マイヤー、 "プロトコル独立マルチキャスト - スパースモード（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.およびJ.リンガード、 "プロトコル独立マルチキャスト（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.ハーバーマン、 "IPv6マルチキャストアドレスでのランデブーポイント（RP）アドレスを埋め込み"、RFC 3956、2004年11月。
[18] Thaler, D., "Interoperability Rules for Multicast Routing Protocols", RFC 2715, October 1999.
[18]ターラー、D.、RFC 2715、1999年10月 "マルチキャストルーティングプロトコルの相互運用性の規則"。
Appendix A. PIM Multicast Border Router Behavior
付録A. PIMマルチキャスト境界ルータの動作
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]異なるマルチキャストルーティングプロトコル間の相互運用性のためのルールを提供します。この付録では、我々はPMBRsは、通常の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.
PIM-SMドメインの外部ソースからのトラフィックは、ドメイン内の受信機に到達することを確実にするために、O。
o To ensure that traffic from sources inside the PIM-SM domain reaches receivers outside the domain.
PIM-SMドメイン内のソースからのトラフィックは、ドメイン外の受信機に到達することを確実にするために、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）などのプロトコルを用いて互いに接続されているが、このような場合にはRFC 2715に従っていないことに注意して、ドメインはPMBRsを介して接続されていません参加するために（S、G）メッセージは、ドメイン間の境界を横切ります。何のPIMメッセージが国境を通過することはできませんときPMBRが必要です。
A.1. Sources External to the PIM-SM Domain
A.1。 PIM-SMドメインにソース外部
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.
PMBRはPIM-SMドメインの外部のマルチキャスト送信元からのトラフィックは、ドメイン内の受信機に到達することを確認する必要があります。 PMBRは、外部ソースからのトラフィックがPMBR自体に到達するように、RFC 2715のルールに従います。
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（S）は、PIM-SMドメインのインターフェイスである場合、パケットはこのルータにPIMドメインに由来することができず、PMBRのPIM-SMコンポーネントは、パケットを処理しません。それは、このソースのDRであるかのようにそれ以外の場合は、PMBRは、以下のように変更して、（4.4.1項を参照）を正確に動作します：
o The Border-bit is set in all PIM Register messages sent for these sources.
Oボーダービットは、これらのソースのために送信されたすべてのPIM Registerメッセージに設定されています。
o DirectlyConnected(S) is treated as being TRUE for these sources.
O DirectlyConnected（S）は、これらのソースのTRUEであるとして扱われます。
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 PIM-SM転送ルール「IIF == RPF_interface（S）」IIFはPMBRのPIM-SMコンポーネントの一部ではない任意のインタフェースがある場合TRUEことが緩和される（セクション4.2参照）。
A.2. Sources Internal to the PIM-SM Domain
A.2。 PIM-SMドメインへの内部要因
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の別の成分は、ワイルドカードの受信機です。この場合には、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.
（埋め込みRPと例えば、PIM-SSM、PIM-SM）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ドメイン内のすべてのアクティブのRPに参加（*、*、RP）を送信する必要があります。また、PIM-SMドメイン内のすべての候補RPに（*、*、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は（*、*、RP）Joinメッセージを送信する必要はありません。しかし、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の状態にこれらのアラートをマッピングする一つの合理的な方法は以下のとおりです。
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.
PIM-SM成分は（S、G）プルーンアラートを受信すると、O、それは廃棄インターフェイスのFALSEにlocal_receiver_include（S、G、I）を設定します。
o When a PIM-SM component receives a (*,G) Prune alert, it sets local_receiver_include(*,G,I) to FALSE for the discard interface.
PIM-SM成分は（*、G）プルーンアラートを受信すると、O、それは廃棄インターフェイスのFALSEにlocal_receiver_include（*、G、I）を設定します。
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.
PIM-SM成分は（S、G）警告を参加を受信すると、O、それは廃棄インターフェイスについてTRUEと（S、G、I）local_receiver_includeを設定します。
o When a PIM-SM component receives a (*,G) Join alert, it sets local_receiver_include(*,G,I) to TRUE for the discard interface.
PIM-SM成分は（*、G）参加通知を受信すると、O、それは廃棄インターフェイスのTRUEに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.
PIM-SMコンポーネントは、（*、*）アラートをJoinを受信すると、O、それはPIM-SMドメイン内のすべてのRPのための廃棄インターフェイス上の状態に参加するDownstreamJPState（*、*、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.
PIM-SMコンポーネントは、（*、*）プルーンのアラートを受信すると、O、それはPIM-SMドメイン内のすべてのRPのための廃棄インターフェイス上NoInfo状態にDownstreamJPState（*、*、RP、I）を設定します。
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）の木を剪定オフ可能にするのに十分なしかし、ではありません。いくつかの追加ルールはこれを実行することができる一つの方法に関して、ガイダンスを提供します。
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.
PMBRは（*、*、RP）ツリーに参加した場合、O、それはすべてのアクティブなグループのための廃棄インターフェイスに参加するDownstreamJPState（*、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.
ルータは（S、G）プルーンのアラートを受信した場合、O、それは廃棄インターフェースでプルーニングするDownstreamJPState（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.
ルータが（*、G）プルーンのアラートを受信した場合、O、それはすべてのアクティブなソースがG.に送信するための廃棄インターフェイスでプルーニングするDownstreamJPState（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.
この理論的根拠は、（*、G）ツリーに参加した後、個々のソースをプルーニングする以外、（*、*、RP）ツリーオフトラフィックをプルーニングするPIM-SMに方法がないことです。
Appendix B. Index
付録B.インデックス
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リバーオークス置き、サンノゼ、CA 95134
EMail: fenner@research.att.com
メールアドレス：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
メールアドレス：M.Handley@cs.ucl.ac.uk
Hugh Holbrook Arastra, Inc. P.O. Box 10905 Palo Alto, CA 94303
ヒュー・ホルブルックArastra、株式会社私書箱ボックス10905パロアルト、CA 94303
EMail: holbrook@arastra.com
メールアドレス：holbrook@arastra.com
Isidor Kouvelas Cisco Systems 170 W. Tasman Drive San Jose, CA 95134
イジドールKouvelasシスコシステムズ170 W.タスマン・ドライブサンノゼ、CA 95134
EMail: kouvelas@cisco.com
メールアドレス：kouvelas@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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）によって提供されます。