Network Working Group A. Adams
Request for Comments: 3973 NextHop Technologies
Category: Experimental J. Nicholas
ITT A/CD
W. Siadak
NextHop Technologies
January 2005
Protocol Independent Multicast - Dense Mode (PIM-DM):
Protocol Specification (Revised)
Status of This Memo
このメモのステータス
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document specifies Protocol Independent Multicast - Dense Mode (PIM-DM). PIM-DM is a multicast routing protocol that uses the underlying unicast routing information base to flood multicast datagrams to all multicast routers. Prune messages are used to prevent future messages from propagating to routers without group membership information.
稠密モード（PIM-DM） - このドキュメントは、プロトコル独立マルチキャストを指定します。 PIM-DMは、すべてのマルチキャストルータにマルチキャストデータグラムをフラッディングする基礎となるユニキャストルーティング情報ベースを使用するマルチキャストルーティングプロトコルです。プルーンのメッセージは、グループメンバーシップ情報なしでルータに伝播するから今後のメッセージを防止するために使用されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Pseudocode Notation . . . . . . . . . . . . . . . . . . 5
3. PIM-DM Protocol Overview . . . . . . . . . . . . . . . . . . . 5
4. Protocol Specification . . . . . . . . . . . . . . . . . . . . 6
4.1. PIM Protocol State . . . . . . . . . . . . . . . . . . . 7
4.1.1. General Purpose State . . . . . . . . . . . . . 7
4.1.2. (S,G) State . . . . . . . . . . . . . . . . . . 8
4.1.3. State Summarization Macros . . . . . . . . . . . 8
4.2. Data Packet Forwarding Rules . . . . . . . . . . . . . . 10
4.3. Hello Messages . . . . . . . . . . . . . . . . . . . . . 11
4.3.1. Sending Hello Messages . . . . . . . . . . . . . 11
4.3.2. Receiving Hello Messages . . . . . . . . . . . . 11
4.3.3. Hello Message Hold Time . . . . . . . . . . . . 12
4.3.4. Handling Router Failures . . . . . . . . . . . . 12
4.3.5. Reducing Prune Propagation Delay on LANs . . . . 13
4.4. PIM-DM Prune, Join, and Graft Messages . . . . . . . . . 13
4.4.1. Upstream Prune, Join, and Graft Messages . . . . 14
4.4.1.1. Transitions from the Forwarding
(F) State . . . . . . . . . . . . . . 17
4.4.1.2. Transitions from the Pruned
(P) State . . . . . . . . . . . . . . 18
4.4.1.3. Transitions from the AckPending
(AP) State . . . . . . . . . . . . . . 19
4.4.2. Downstream Prune, Join, and Graft Messages . . . 21
4.4.2.1. Transitions from the NoInfo State . . 23
4.4.2.2. Transitions from the PrunePending
(PP) State . . . . . . . . . . . . . . 24
4.4.2.3. Transitions from the Prune
(P) State . . . . . . . . . . . . . . 25
4.5. State Refresh . . . . . . . . . . . . . . . . . . . . . 26
4.5.1. Forwarding of State Refresh Messages . . . . . . 26
4.5.2. State Refresh Message Origination . . . . . . . 28
4.5.2.1. Transitions from the NotOriginator
(NO) State . . . . . . . . . . . . . . 29
4.5.2.2. Transitions from the Originator
(O) State . . . . . . . . . . . . . . 29
4.6. PIM Assert Messages . . . . . . . . . . . . . . . . . . 30
4.6.1. Assert Metrics . . . . . . . . . . . . . . . . . 30
4.6.2. AssertCancel Messages . . . . . . . . . . . . . 31
4.6.3. Assert State Macros . . . . . . . . . . . . . . 32
4.6.4. (S,G) Assert Message State Machine . . . . . . . 32
4.6.4.1. Transitions from NoInfo State . . . . 34
4.6.4.2. Transitions from Winner State . . . . 35
4.6.4.3. Transitions from Loser State . . . . . 36
4.6.5. Rationale for Assert Rules . . . . . . . . . . . 38
4.7. PIM Packet Formats . . . . . . . . . . . . . . . . . . . 38
4.7.1. PIM Header . . . . . . . . . . . . . . . . . . . 38
4.7.2. Encoded Unicast Address . . . . . . . . . . . . 39
4.7.3. Encoded Group Address . . . . . . . . . . . . . 40
4.7.4. Encoded Source Address . . . . . . . . . . . . . 41
4.7.5. Hello Message Format . . . . . . . . . . . . . . 42
4.7.5.1. Hello Hold Time Option . . . . . . . . 43
4.7.5.2. LAN Prune Delay Option . . . . . . . . 43
4.7.5.3. Generation ID Option . . . . . . . . . 44
4.7.5.4. State Refresh Capable Option . . . . . 44
4.7.6. Join/Prune Message Format . . . . . . . . . . . 45
4.7.7. Assert Message Format . . . . . . . . . . . . . 47
4.7.8. Graft Message Format . . . . . . . . . . . . . . 48
4.7.9. Graft Ack Message Format . . . . . . . . . . . . 48
4.7.10. State Refresh Message Format . . . . . . . . . . 48
4.8. PIM-DM Timers . . . . . . . . . . . . . . . . . . . . . 50
5. Protocol Interaction Considerations . . . . . . . . . . . . . 53
5.1. PIM-SM Interactions . . . . . . . . . . . . . . . . . . 53
5.2. IGMP Interactions . . . . . . . . . . . . . . . . . . . 54
5.3. Source Specific Multicast (SSM) Interactions . . . . . . 54
5.4. Multicast Group Scope Boundary Interactions . . . . . . 54
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54
6.1. PIM Address Family . . . . . . . . . . . . . . . . . . . 54
6.2. PIM Hello Options . . . . . . . . . . . . . . . . . . . 55
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 55
7.1. Attacks Based on Forged Messages . . . . . . . . . . . . 55
7.2. Non-cryptographic Authentication Mechanisms . . . . . . 56
7.3. Authentication Using IPsec . . . . . . . . . . . . . . . 56
7.4. Denial of Service Attacks . . . . . . . . . . . . . . . 58
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 58
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58
9.1. Normative References . . . . . . . . . . . . . . . . . . 58
9.2. Informative References . . . . . . . . . . . . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 61
This specification defines a multicast routing algorithm for multicast groups that are densely distributed across a network. This protocol does not have a topology discovery mechanism often used by a unicast routing protocol. It employs the same packet formats sparse mode PIM (PIM-SM) uses. This protocol is called PIM - Dense Mode. The foundation of this design was largely built on Deering's early work on IP multicast routing [12].
この仕様は、密にネットワーク全体に分散されているマルチキャストグループのためのマルチキャスト・ルーティング・アルゴリズムを定義します。このプロトコルは、多くの場合、ユニキャストルーティングプロトコルによって使用されるトポロジ検出メカニズムを持っていません。これは、スパースモードPIM（PIM-SM）を使用するのと同じパケット・フォーマットを使用します。稠密モード - このプロトコルはPIMと呼ばれています。この設計の基礎は、主にIPマルチキャストルーティング[12]のデアリングの初期の作品の上に建てられました。
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 [11] and indicate requirement levels for compliant PIM-DM implementations.
キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHALL"、 "SHOULD"、 "ないもの"、 "推奨" "ない（SHOULD NOT）"、 "MAY"、 "OPTIONAL" は解釈されるべきですRFC 2119に記載されているように[11]とは、コンプライアントPIM-DM実装の要求レベルを示します。
Multicast Routing Information Base (MRIB) This is the multicast topology table, which is typically derived from the unicast routing table, or from routing protocols such as MBGP that carry multicast-specific topology information. PIM-DM uses the MRIB to make decisions regarding RPF interfaces.
マルチキャストルーティング情報ベース（MRIB）これは、典型的には、ユニキャストルーティングテーブルから、またはマルチキャスト固有のトポロジ情報を運ぶようMBGPなどのルーティングプロトコルに由来するマルチキャストトポロジーテーブルです。 PIM-DMは、RPFインターフェイスに関する意思決定を行うためにMRIBを使用しています。
Tree Information Base (TIB) This is the collection of state maintained by a PIM router and created by receiving PIM messages and IGMP information from local hosts. It essentially stores the state of all multicast distribution trees at that router.
ツリー情報ベース（TIB）これは、PIMメッセージとローカルホストからIGMP情報を受信することにより、PIMルータによって維持され、作成された状態のコレクションです。それは本質的にそのルータでは、すべてのマルチキャスト配信ツリーの状態を格納します。
Reverse Path Forwarding (RPF) RPF is a multicast forwarding mode in which a data packet is accepted for forwarding only if it is received on an interface used to reach the source in unicast.
逆方向パス転送（RPF）RPFは、データ・パケットは、それがユニキャストで送信元に到達するために使用されるインターフェイスで受信された場合にのみ転送するために受け入れられたマルチキャスト転送モードです。
Upstream Interface Interface toward the source of the datagram. Also known as the RPF Interface.
データグラムのソースに向けてアップストリームインターフェイスのインターフェイス。また、RPFインターフェイスとして知られています。
Downstream Interface All interfaces that are not the upstream interface, including the router itself.
ルータ自体を含むアップストリームインタフェースないダウンストリームインターフェイスすべてのインターフェイス、。
(S,G) Pair Source S and destination group G associated with an IP packet.
（S、G）ペアのソースSと宛先グループGは、IPパケットに関連付けられています。
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 are the elements of set A that are not in set B.
（ - ）BセットBにはない集合Aの要素であります
NULL is the empty set or list.
NULLは空のセットまたはリストです。
Note that operations MUST be conducted in the order specified. This is due to the fact that (-) is not a true difference operator, because B is not necessarily a subset of A. That is, A (+) B (-) C = A (-) C (+) B is not a true statement unless C is a subset of both A and B.
動作が指定された順序で行われなければならないことに留意されたいです。あるC（+）B（ - ）Bは、必ずしもであるAの部分集合ではないので、真の差分演算子ではなく、A（+）B - （ - ）C = A（）これは事実でありますではない真の文Cは、AとBの両方のサブセットでない限り、
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-DM behavior. It is intended as an introduction to how PIM-DM works and is NOT definitive. For the definitive specification, see Section 4, Protocol Specification.
このセクションでは、PIM-DMの動作の概要を説明します。それはどのようにPIM-DMの作品への紹介を目的と決定的ではありません。決定的な仕様に関しては、第4章、プロトコル仕様を参照してください。
PIM-DM assumes that when a source starts sending, all downstream systems want to receive multicast datagrams. Initially, multicast datagrams are flooded to all areas of the network. PIM-DM uses RPF to prevent looping of multicast datagrams while flooding. If some areas of the network do not have group members, PIM-DM will prune off the forwarding branch by instantiating prune state.
PIM-DMは、ソースが送信を開始すると、すべての下流のシステムは、マルチキャストデータグラムを受信することを想定しています。最初は、マルチキャストデータグラムは、ネットワークのすべての領域にフラッディングされます。 PIM-DMは、氾濫しながら、マルチキャストデータグラムのループを防ぐために、RPFを使用しています。ネットワークの一部の地域は、グループのメンバーを持っていない場合は、PIM-DMは、プルーン状態をインスタンス化することによって、転送枝を剪定します。
Prune state has a finite lifetime. When that lifetime expires, data will again be forwarded down the previously pruned branch.
プルーン状態は有限の寿命を有します。その寿命が切れると、データは再び以前剪定枝を下に転送されます。
Prune state is associated with an (S,G) pair. When a new member for a group G appears in a pruned area, a router can "graft" toward the source S for the group, thereby turning the pruned branch back into a forwarding branch.
プルーン状態は（S、G）組に関連付けられています。グループGのための新たな部材プルーニング領域に表示されたとき、ルータは、それによって転送ブランチに戻し剪定枝のグループのソースSに向かって「グラフト」旋回することができます。
The broadcast of datagrams followed by pruning of unwanted branches is often referred to as a flood and prune cycle and is typical of dense mode protocols.
不要な枝の剪定に続くデータグラムの放送は、多くの場合、洪水やプルーンサイクルと呼ばれ、稠密モードプロトコルの典型です。
To minimize repeated flooding of datagrams and subsequent pruning associated with a particular (S,G) pair, PIM-DM uses a state refresh message. This message is sent by the router(s) directly connected to the source and is propagated throughout the network. When received by a router on its RPF interface, the state refresh message causes an existing prune state to be refreshed.
データグラムの繰り返し洪水、特に（S、G）組に関連付けられた後続の剪定を最小限にするために、PIM-DMは、状態更新メッセージを使用します。このメッセージは、ルータ（複数可）を直接ソースに接続され、ネットワーク全体に伝播することによって送信されます。そのRPFインターフェイスで、ルータが受信した場合には、ステートリフレッシュメッセージは、既存のプルーン状態が更新されます。
Compared with multicast routing protocols with built-in topology discovery mechanisms (e.g., DVMRP [13]), PIM-DM has a simplified design and is not hard-wired into a specific topology discovery protocol. However, this simplification does incur more overhead by causing flooding and pruning to occur on some links that could be avoided if sufficient topology information were available; i.e., to decide whether an interface leads to any downstream members of a particular group. Additional overhead is chosen in favor of the simplification and flexibility gained by not depending on a specific topology discovery protocol.
内蔵トポロジ発見メカニズム（例えば、DVMRP [13]）とマルチキャストルーティングプロトコルと比較して、PIM-DMは、簡略化された設計を有しており、特定のトポロジ発見プロトコルにハードワイヤードされていません。しかし、この単純化は、洪水を引き起こし、十分なトポロジ情報が入手可能であれば避けることができ、いくつかのリンク上で発生する剪定することで、よりオーバーヘッドが発生しません。即ち、インタフェースは、特定のグループの任意の下流のメンバーをもたらすかどうかを決定します。追加のオーバーヘッドは、特定のトポロジディスカバリプロトコルに依存しないことによって得られる簡素化と柔軟性に有利に選択されています。
PIM-DM differs from PIM-SM in two essential ways: 1) There are no periodic joins transmitted, only explicitly triggered prunes and grafts. 2) There is no Rendezvous Point (RP). This is particularly important in networks that cannot tolerate a single point of failure. (An RP is the root of a shared multicast distribution tree. For more details, see [4]).
PIM-DMは、2つの重要な方法でPIM-SMとは異なり：1）は、定期的に送信されないジョインがあり、明示的にのみプルーンおよびグラフトを引き起こしました。 2）何のランデブーポイント（RP）はありません。これは、単一障害点を容認することはできませんネットワークにおいて特に重要です。 （RPは、共有マルチキャスト配信ツリーのルートである。詳細については、[4]を参照します）。
The specification of PIM-DM is broken into several parts:
PIM-DMの仕様は、いくつかの部分に分割されます。
* Section 4.1 details the protocol state stored. * Section 4.2 specifies the data packet forwarding rules. * Section 4.3 specifies generation and processing of Hello messages. * Section 4.4 specifies the Join, Prune, and Graft generation and processing rules. * Section 4.5 specifies the State Refresh generation and forwarding rules. * Section 4.6 specifies the Assert generation and processing rules. * Section 4.7 gives details on PIM-DM Packet Formats. * Section 4.8 summarizes PIM-DM timers and their defaults.
*セクション4.1の詳細プロトコル状態が保存されました。 *セクション4.2は、データパケットの転送ルールを指定します。 *セクション4.3は、Helloメッセージの生成および処理を指定します。 *セクション4.4は参加し、プルーン、および移植片の生成と処理規則を指定します。 * 4.5節は、ステートリフレッシュ生成および転送ルールを指定します。 * 4.6節はアサート生成と処理規則を指定します。 *セクション4.7はPIM-DMのパケットフォーマットの詳細を提供します。 *セクション4.8はPIM-DMのタイマーとそのデフォルト値をまとめたもの。
This section specifies all the protocol states that a PIM-DM implementation should maintain to function correctly. We term this state the Tree Information Base or TIB, as it holds the state of all the multicast distribution trees at this router. In this specification, we define PIM-DM 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-DMの実装が正しく機能するために維持する必要があり、すべてのプロトコル状態を指定します。それはこのルータでは、すべてのマルチキャスト配信ツリーの状態を保持していると私たちは、この状態ツリー情報ベースまたはTIBを名づけます。この仕様では、我々は、TIBの面でPIM-DMメカニズムを定義します。しかし、唯一の非常に単純な実装では、実際にこのような状態の面でパケット転送の操作を実装します。ほとんどの実装では、TIBの関連する状態が変化したときに、その後更新されるマルチキャスト転送テーブルを構築するために、この状態を使用します。
Unlike PIM-SM, PIM-DM does not maintain a keepalive timer associated with each (S,G) route. Within PIM-DM, route and state information associated with an (S,G) entry MUST be maintained as long as any timer associated with that (S,G) entry is active. When no timer associated with an (S,G) entry is active, all information concerning that (S,G) route may be discarded.
PIM-SMとは異なり、PIM-DMは、それぞれ（S、G）ルートに関連付けられたキープアライブタイマーを維持しません。 PIM-DM、ルート及び（S、G）エントリに関連付けられた状態情報内にあれば、その（S、G）エントリに関連付けられた任意のタイマがアクティブであるように維持しなければなりません。 （S、G）エントリに関連付けられたタイマがアクティブでない場合、その（S、G）ルートに関するすべての情報は破棄されてもよいです。
Although we precisely specify the state to be kept, this does not mean that an implementation of PIM-DM has 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-DM implementation is free to hold whatever internal state it requires and will still be conformant with this specification as long as it results in the same externally visible protocol behavior as an abstract router that holds the following state.
我々は正確に維持することが状態を指定しますが、これは、PIM-DMの実装は、この形式で状態を保持するために持っていることを意味するものではありません。これは実際にルータの動作を指定するために必要とされる抽象状態の定義、です。 PIM-DMの実装は、それが必要とし、まだであれば、次の状態を保持する抽象ルータと同じ外部から見えるプロトコルの動作になり、この仕様に準拠される内部どんな状態を保持して自由です。
A router stores the following non-group-specific state:
ルータは、次の非グループ固有の状態を格納します。
For each interface: Hello Timer (HT) State Refresh Capable LAN Delay Enabled Propagation Delay (PD) Override Interval (OI)
各インタフェースについて：こんにちはタイマー（HT）ステートリフレッシュできるLAN遅延は伝搬遅延（PD）を有効間隔（OI）をオーバーライドします
Neighbor State: For each neighbor: Information from neighbor's Hello Neighbor's Gen ID. Neighbor's LAN Prune Delay Neighbor's Override Interval Neighbor's State Refresh Capability Neighbor Liveness Timer (NLT)
近隣州：各隣人のために：隣人のHello隣人の世代IDからの情報。近隣のLANプルーンディレイ近隣のオーバーライド間隔近隣の国家リフレッシュ機能近隣ライブネスタイマー（NLT）
For every source/group pair (S,G), a router stores the following state:
すべてのソース/グループペア（S、G）のために、ルータは、次の状態を記憶します。
(S,G) state: For each interface: Local Membership: State: One of {"NoInfo", "Include"}
（S、G）状態：ローカル・メンバーシップ：状態：各インタフェースについての一{ "NoInfo"、 "含みます"}
PIM (S,G) Prune State:
State: One of {"NoInfo" (NI), "Pruned" (P), "PrunePending"
(PP)}
Prune Pending Timer (PPT)
Prune Timer (PT)
(S,G) Assert Winner State: State: One of {"NoInfo" (NI), "I lost Assert" (L), "I won Assert" (W)} Assert Timer (AT) Assert winner's IP Address Assert winner's Assert Metric
受賞者のIPアドレスのAssertの勝者のアサートタイマー（AT）{（W） "私はアサートを獲得した"、（L） "私はアサートを失った"、 "NoInfo"（NI）}の一つアサート：状態：（S、G）受賞状態をアサートメトリックをアサート
Upstream interface-specific: Graft/Prune State: State: One of {"NoInfo" (NI), "Pruned" (P), "Forwarding" (F), "AckPending" (AP) } GraftRetry Timer (GRT) Override Timer (OT) Prune Limit Timer (PLT)
上流インタフェース特有：グラフト/プルーン状態：状態：{ "NoInfo"（NI）、 "プルーニング"（P）、 "転送"（F）、 "AckPending"（AP）}の一つGraftRetryタイマ（GRT）オーバーライドタイマ（OT）プルーン制限タイマ（PLT）
Originator State: Source Active Timer (SAT) State Refresh Timer (SRT)
発信元の状態：ソースアクティブタイマー（SAT）の状態リフレッシュタイマ（SRT）
Using the state defined above, the following "macros" are defined and will be used in the descriptions of the state machines and pseudocode in the following sections.
上記で定義された状態を使用して、以下の「マクロ」に定義されており、以下の各項のステートマシンと擬似コードの記述に使用されます。
The most important macros are those defining the outgoing interface list (or "olist") for the relevant state.
最も重要なマクロは、関連する状態のための発信インターフェイスリスト（または「OLIST」）を定義したものです。
immediate_olist(S,G) = pim_nbrs (-) prunes(S,G) (+) (pim_include(*,G) (-) pim_exclude(S,G) ) (+) pim_include(S,G) (-) lost_assert(S,G) (-) boundary(G)
immediate_olist（S、G）= pim_nbrs（ - ）プルーン（S、G）（+）（pim_include（*、G）（ - ）pim_exclude（S、G））（+）pim_include（S、G）（ - ）lost_assert （S、G）（ - ）境界（G）
olist(S,G) = immediate_olist(S,G) (-) RPF_interface(S)
OLIST（S、G）= immediate_olist（S、G）（ - ）RPF_interface（S）
The macros pim_include(*,G) and pim_include(S,G) indicate the interfaces to which traffic might or might not be forwarded because of hosts that are local members on those interfaces.
マクロpim_include（*、G）とpim_include（S、G）は、トラフィックまたはので、これらのインターフェイスのローカルメンバーであるホストから転送されない場合がありますするインターフェイスを示します。
pim_include(*,G) = {all interfaces I such that: local_receiver_include(*,G,I)} pim_include(S,G) = {all interfaces I such that: local_receiver_include(S,G,I)} pim_exclude(S,G) = {all interfaces I such that: local_receiver_exclude(S,G,I)}
pim_include（*、G）= {すべてのインタフェースIように：local_receiver_include（*、G、I）} pim_include（S、G）= {すべてのインタフェースIように：local_receiver_include（S、G、I）} pim_exclude（S、 G）= {すべてのインターフェイスIは、その：local_receiver_exclude（S、G、I）}
The macro RPF_interface(S) returns the RPF interface for source S. That is to say, it returns the interface used to reach S as indicated by the MRIB.
マクロRPF_interface（S）は、MRIBによって示されるようにSに到達するために使用されるインターフェースを返し、と言うことであるソースSのためのRPFインタフェースを返します。
The macro local_receiver_include(S,G,I) is true if the IGMP module or other local membership mechanism ([1], [2], [3], [6]) has determined that there are local members on interface I that seek to receive traffic sent specifically by S to G.
IGMPモジュールまたは他のローカルメンバーシップ機構（[1]、[2]、[3]、[6]）を決定した場合、マクロlocal_receiver_include（S、G、I）を求めるIインターフェース上のローカルメンバがあることは事実でありますG.にSにより特異的に送信されるトラフィックを受信します
The macro local_receiver_include(*,G,I) is true if the IGMP module or other local membership mechanism has determined that there are local members on interface I that seek to receive all traffic sent to G. Note that this determination is expected to account for membership joins initiated on or by the router.
IGMPモジュールまたは他のローカルメンバーシップ機構がローカルメンバーインターフェイスであると判断した場合にマクロlocal_receiver_include（*、G、I）が真であるI Gに送信されたすべてのトラフィックを受信しようと、この決意を説明するために期待されていることに注意してくださいメンバーシップは、上またはルータによって開始ジョイン。
The macro local_receiver_exclude(S,G,I) is true if local_receiver_include(*,G,I) is true but none of the local members seek to receive traffic from S.
local_receiver_include（*、G、I）が真であるが、ローカルメンバーのいずれもSからトラフィックを受信しようとしない場合、マクロlocal_receiver_exclude（S、G、I）が真であります
The set pim_nbrs is the set of all interfaces on which the router has at least one active PIM neighbor.
セットpim_nbrsルータは少なくとも1つの活性PIMネイバーを有しているすべてのインタフェースのセットです。
The set prunes(S,G) is the set of all interfaces on which the router has received Prune(S,G) messages:
セットプルーン（S、G）ルータがプルーン（S、G）メッセージを受信したすべてのインタフェースのセットです。
prunes(S,G) = {all interfaces I such that DownstreamPState(S,G,I) is in Pruned state}
プルーン（S、G）= {DownstreamPState（S、G、I）が剪定状態であることを私はそのようなすべてのインタフェース}
The set lost_assert(S,G) is the set of all interfaces on which the router has lost an (S,G) Assert.
セットlost_assert（S、G）は、ルータは（S、G）をアサートを失ったすべてのインターフェイスのセットです。
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}
boundary(G) = {all interfaces I with an administratively scoped boundary for group G}
境界（G）= {グループGのための管理用スコープの境界を持つすべてのインタフェースI}
The following pseudocode macro definitions are also used in many places in the specification. Basically RPF' is the RPF neighbor toward a source unless a PIM-DM Assert has overridden the normal choice of neighbor.
次の擬似コードマクロ定義はまた、仕様の多くの場所で使用されています。 PIM-DMアサートが隣人の通常の選択を上書きしていない限り、基本的には」RPFは、送信元に向けたRPF隣人です。
neighbor RPF'(S,G) { if ( I_Am_Assert_loser(S, G, RPF_interface(S) )) { return AssertWinner(S, G, RPF_interface(S) ) } else { return MRIB.next_hop( S ) } }
隣接RPF '（S、G）{場合（I_Am_Assert_loser（S、Gは、RPF_interface（S）））{他} AssertWinner（S、G、RPF_interface（S））を返す{戻りMRIB.next_hop（S）}}
The macro I_Am_Assert_loser(S, G, I) is true if the Assert state machine (in Section 4.6) for (S,G) on interface I is in the "I am Assert Loser" state.
界面Iに（S、G）のために（セクション4.6で）アサート状態マシンが「私は敗者をアサートアム」状態である場合、マクロI_Am_Assert_loser（S、G、I）が真です。
The PIM-DM packet forwarding rules are defined below in pseudocode.
PIM-DMパケット転送ルールは、擬似コードで以下に定義されます。
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). RPF_interface(S) is the interface the MRIB indicates would be used to route packets to S.
IIFは、パケットの着信インターフェイスです。 Sは、パケットの送信元アドレスです。 Gはパケット（グループアドレス）の宛先アドレスです。 RPF_interface（S）はMRIBをSにパケットをルーティングするために使用される示すインタフェースであります
First, an RPF check MUST be performed to determine whether the packet should be accepted based on TIB state and the interface on which that the packet arrived. Packets that fail the RPF check MUST NOT be forwarded, and the router will conduct an assert process for the (S,G) pair specified in the packet. Packets for which a route to the source cannot be found MUST be discarded.
まず、RPFチェックはパケットがTIB状態及びパケットが到着したことをしたインターフェイスに基づいて受け入れられるかどうかを決定するために実行されなければなりません。 RPFチェックに失敗したパケットは、転送されてはならない、とルータは、パケットに指定された（S、G）ペアのアサートプロセスを実施します。ソースへのルートが見つからないパケットは捨てなければなりません。
If the RPF check has been passed, an outgoing interface list is constructed for the packet. If this list is not empty, then the packet MUST be forwarded to all listed interfaces. If the list is empty, then the router will conduct a prune process for the (S,G) pair specified in the packet.
RPFチェックを通過した場合には、発信インターフェイスリストは、パケットのために構成されています。このリストが空でない場合、パケットはすべてのリストされたインターフェイスに転送されなければなりません。リストが空である場合、ルータはパケットに指定された（S、G）ペアのためのプルーン処理を実施します。
Upon receipt of a data packet from S addressed to G on interface iif:
Sからデータパケットを受信するインタフェースIIFにG宛：
if (iif == RPF_interface(S) AND UpstreamPState(S,G) != Pruned) { oiflist = olist(S,G) } else { oiflist = NULL } forward packet on all interfaces in oiflist
IF（IIF == RPF_interface（S）AND UpstreamPState（S、G）！=プルーニング）{oiflist = OLIST（S、G）} oiflist内のすべてのインターフェイス上の他{oiflist = NULL}転送パケット
This pseudocode employs the following "macro" definition:
この擬似コードは、以下の「マクロ」の定義を採用しています。
UpstreamPState(S,G) is the state of the Upstream(S,G) state machine in Section 4.4.1.
UpstreamPState（S、G）は、セクション4.4.1の上流（S、G）ステートマシンの状態です。
This section describes the generation and processing of Hello messages.
このセクションでは、Helloメッセージの生成および処理を説明します。
PIM-DM uses Hello messages to detect other PIM routers. Hello messages are sent periodically on each PIM enabled interface. Hello messages are multicast to the ALL-PIM-ROUTERS group. When PIM is enabled on an interface or when a router first starts, the Hello Timer (HT) MUST be set to random value between 0 and Triggered_Hello_Delay. This prevents synchronization of Hello messages if multiple routers are powered on simultaneously.
PIM-DMは、他のPIMルータを検出するために、Helloメッセージを使用しています。 helloメッセージは、各PIM対応インターフェイス上で定期的に送信されます。 helloメッセージは、ALL-PIM-ROUTERSグループにマルチキャストされています。 PIMがインターフェイスとき、またはルータが最初に起動で有効になっている場合に、ハロータイマ（HT）は0とTriggered_Hello_Delay間のランダムな値に設定しなければなりません。複数のルータが同時に電源が入っている場合、これはHelloメッセージの同期化を防ぐことができます。
After the initial Hello message, a Hello message MUST be sent every Hello_Period. A single Hello timer MAY be used to trigger sending Hello messages on all active interfaces. The Hello Timer SHOULD NOT be reset except when it expires.
初期こんにちはメッセージの後、Helloメッセージは、すべてのHello_Periodを送らなければなりません。単一Helloタイマーこんにちは、すべてのアクティブインターフェイス上でメッセージを送信するトリガするために使用されるかもしれません。こんにちはタイマーは、それが期限切れになったときを除いてリセットされるべきでありません。
When a Hello message is received, the receiving router SHALL record the receiving interface, the sender, and any information contained in recognized options. This information is retained for a number of seconds in the Hold Time field of the Hello Message. If a new Hello message is received from a particular neighbor N, the Neighbor Liveness Timer (NLT(N,I)) MUST be reset to the newly received Hello Holdtime. If a Hello message is received from a new neighbor, the receiving router SHOULD send its own Hello message after a random delay between 0 and Triggered_Hello_Delay.
Helloメッセージを受信すると、受信ルータは、受信インタフェース、送信者、および認識オプションに含まれるすべての情報を記録しなければなりません。この情報は、ハローメッセージのホールド時間フィールドの秒数のために保持されます。新しいHelloメッセージが特定の隣人N、近隣ライブネスタイマーから受信した場合（NLT（N、I））は、新たに受信されたこんにちはホールドタイムをリセットする必要があります。 Helloメッセージは、新しいネイバーから受信した場合、受信側ルータが0とTriggered_Hello_Delay間のランダム遅延の後に、自身のHelloメッセージを送るべきです。
The Hold Time in the Hello Message should be set to a value that can reasonably be expected to keep the Hello active until a new Hello message is received. On most links, this will be 3.5 times the value of Hello_Period.
こんにちは、メッセージでの保持時間は、合理的に新しいHelloメッセージが受信されるまでアクティブのHelloを維持することが期待される値に設定する必要があります。ほとんどのリンクでは、これはHello_Periodの3.5倍の値になります。
If the Hold Time is set to '0xffff', the receiving router MUST NOT time out that Hello message. This feature might be used for on-demand links to avoid keeping the link up with periodic Hello messages.
ホールド時間が「0xffffの」に設定されている場合は、受信ルータは、Helloメッセージをタイムアウトしてはなりません。この機能は、定期的にHelloメッセージでリンクを追いつい避けるために、オンデマンドリンクに使用される可能性があります。
If a Hold Time of '0' is received, the corresponding neighbor state expires immediately. When a PIM router takes an interface down or changes IP address, a Hello message with a zero Hold Time SHOULD be sent immediately (with the old IP address if the IP address is changed) to cause any PIM neighbors to remove the old information immediately.
「0」のホールド時間を受信した場合、対応するネイバー状態がすぐに期限切れになります。 PIMルータがインターフェイスをダウン取るか、IPアドレスを変更した場合（IPアドレスが変更された場合、古いIPアドレスを使用して）、ゼロホールド時間を持つHelloメッセージはすぐに古い情報を削除するために、任意のPIMネイバーを引き起こすために、すぐに送ってください。
If a Hello message is received from an active neighbor with a different Generation ID (GenID), the neighbor has restarted and may not contain the correct (S,G) state. A Hello message SHOULD be sent after a random delay between 0 and Triggered_Hello_Delay (see 4.8) before any other messages are sent. If the neighbor is downstream, the router MAY replay the last State Refresh message for any (S,G) pairs for which it is the Assert Winner indicating Prune and Assert status to the downstream router. These State Refresh messages SHOULD be sent out immediately after the Hello message. If the neighbor is the upstream neighbor for an (S,G) entry, the router MAY cancel its Prune Limit Timer to permit sending a prune and reestablishing a Pruned state in the upstream router.
Helloメッセージは、異なる世代ID（られたGenID）とアクティブネイバーから受信した場合、ネイバーは再起動し、正しい（S、G）ステートを含有していてもよいです。他のメッセージが送信される前に、Helloメッセージには、（4.8を参照）を0とTriggered_Hello_Delay間のランダム遅延の後に送ってください。ネイバーが下流側にある場合、ルータは、ダウンストリームルータにプルーンとアサート状態を示すアサート受賞されている任意の（S、G）ペアの最後の状態更新メッセージを再生してもよい（MAY）。これらのステートリフレッシュメッセージは、Helloメッセージの直後に送信されるべきです。ネイバーが（S、G）エントリの上流隣接である場合、ルータはプルーンを送信し、アップストリームルータに剪定状態を再構築可能にするために、そのプルーン制限タイマーを取り消すことができます。
Upon startup, a router MAY use any State Refresh messages received within Hello_Period of its first Hello message on an interface to establish state information. The State Refresh source will be the RPF'(S), and Prune status for all interfaces will be set according to the Prune Indicator bit in the State Refresh message. If the Prune Indicator is set, the router SHOULD set the PruneLimitTimer to Prune_Holdtime and set the PruneTimer on all downstream interfaces to the State Refresh's Interval times two. The router SHOULD then propagate the State Refresh as described in Section 4.5.1.
起動時に、ルータは、状態情報を確立するためのインタフェース上で、その最初のHelloメッセージのHello_Period内に受信任意のステートリフレッシュメッセージを使用するかもしれません。ステートリフレッシュ源はRPF '（S）になり、すべてのインタフェースのプルーン状態は、状態更新メッセージでプルーンインジケータビットに従って設定されます。プルーン区分が設定されている場合、ルータはPrune_HoldtimeにPruneLimitTimerを設定し、ステートリフレッシュの間隔の2倍にすべてのダウンストリームインターフェイス上PruneTimerを設定する必要があります。 4.5.1項で説明したように、ルータは、ステートリフレッシュを伝播すべきです。
If all routers on a LAN support the LAN Prune Delay option, then the PIM routers on that LAN will use the values received to adjust their J/P_Override_Interval on that interface and the interface is LAN Delay Enabled. Briefly, to avoid synchronization of Prune Override (Join) messages when multiple downstream routers share a multi-access link, sending of these messages is delayed by a small random amount of time. The period of randomization is configurable and has a default value of 3 seconds.
LAN上のすべてのルータがLANプルーンDelayオプションをサポートしている場合、そのLAN上のPIMルータは、値がそのインターフェイス上で彼らのJ / P_Override_Intervalを調整するために、受信されたとのインタフェースはLANディレイが有効になって使用されます。複数のダウンストリームルータが時間の小さなランダムな量だけ遅延され、これらのメッセージの送信、マルチアクセスリンクを共有するとき簡単に言えば、プルーンオーバーライド（参加）メッセージの同期化を避けるために。ランダム化の期間が設定可能であり、3秒のデフォルト値を持っています。
Each router on the LAN expresses its view of the amount of randomization necessary in the Override Interval field of the LAN Prune Delay option. When all routers on a LAN use the LAN Prune Delay Option, all routers on the LAN MUST set their Override_Interval to the largest Override value on the LAN.
LAN上の各ルータはLANプルーンDelayオプションのオーバーライドIntervalフィールドの必要なランダム化の量のその見解を表現しています。 LAN上のすべてのルータがLANプルーン遅延オプションを使用すると、LAN上のすべてのルータは、LAN上で最大のオーバーライド値へのOverride_Intervalを設定しなければなりません。
The LAN 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. When all routers on a link use the LAN Prune Delay Option, all routers on the LAN MUST set Propagation Delay to the largest LAN Delay on the LAN.
LANプルーンDelayオプションでルータによって挿入されたLANの遅延はリンク上で予想されるメッセージの伝播遅延を発現し、システム管理者が設定すべきである（SHOULD）。リンク上のすべてのルータがLANプルーン遅延オプションを使用すると、LAN上のすべてのルータは、LAN上の最大のLANディレイへの伝播遅延を設定しなければなりません。
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 and triggered messages to be sent later than intended. Setting this LAN Prune 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の実装は、そのルータ内のスケジューリングや処理遅延を許可するには、この遅延のために許可された値に下限を強制すべきです。このような遅延は、受信したメッセージが後で処理され、意図したよりも後に送信されるメッセージをトリガする可能性があります。下流ルータが上流の隣人が転送を停止する前に、隣人のプルーンメッセージを上書きすることはできませんので、低すぎる値は、一時的な転送の停止をもたらすことができるし、このLANプルーン遅延の設定。
This section describes the generation and processing of PIM-DM Join, Prune, and Graft messages. Prune messages are sent toward the upstream neighbor for S to indicate that traffic from S addressed to group G is not desired. In the case of downstream routers A and B, where A wishes to continue receiving data and B does not, A will send a Join in response to B's Prune to override the Prune. This is the only situation in PIM-DM in which a Join message is used. Finally, a Graft message is used to re-join a previously pruned branch to the delivery tree.
このセクションでは、PIM-DMの生成および処理は、プルーン、グラフトJoinメッセージを説明します。プルーンメッセージは、SからトラフィックはグループG宛てことを示すために、Sのための上流ネイバーに向けて送信される望ましくありません。 Aがデータを受信し続けることを望むとBはない下流のルータAおよびBの場合には、Aは、プルーンをオーバーライドするBのプルーンに応答して参加し送信します。これは、Joinメッセージが使用されるPIM-DMで唯一の状況です。最後に、グラフトメッセージが配信ツリーに以前に剪定枝を再結合するために使用されます。
The Upstream(S,G) state machine for sending Prune, Graft, and Join messages is given below. There are three states.
プルーン、グラフトを送信するためのアップストリーム（S、G）ステートマシン、及び参加メッセージを以下に示します。 3つの状態があります。
Forwarding (F) This is the starting state of the Upsteam(S,G) state machine. The state machine is in this state if it just started or if oiflist(S,G) != NULL.
（F）を転送これは、アップストリーム（SG）、ステートマシンの開始状態です。ステートマシンは、それだけで開始された場合、この状態にあるか、オフセットがあれば（IS）！= NULL。
Pruned (P) The set, olist(S,G), is empty. The router will not forward data from S addressed to group G.
剪定（P）セット、OLIST（S、G）は、空です。ルータはグループG宛Sからデータを転送しません。
AckPending (AP) The router was in the Pruned(P) state, but a transition has occurred in the Downstream(S,G) state machine for one of this (S,G) entry's outgoing interfaces, indicating that traffic from S addressed to G should again be forwarded. A Graft message has been sent to RPF'(S), but a Graft Ack message has not yet been received.
（AP）をAckPendingルータは、プルーニング（P）状態であったが、遷移がSからのトラフィックが宛てことを示し、この（S、G）エントリの発信インターフェイスのいずれかのダウンストリーム（S、G）ステートマシンで発生しましたGは再び転送する必要があります。グラフトメッセージは、（S） 'RPFに送信されてきたが、グラフトAckメッセージがまだ受信されていません。
In addition, there are three state-machine-specific timers:
また、3ステート・マシン固有のタイマーがあります。
GraftRetry Timer (GRT(S,G)) This timer is set when a Graft is sent upstream. If a corresponding GraftAck is not received before the timer expires, then another Graft is sent, and the GraftRetry Timer is reset. The timer is stopped when a Graft Ack message is received. This timer is normally set to Graft_Retry_Period (see 4.8).
移植片は上流送信されたときGraftRetryタイマ（GRT（S、G））このタイマは設定されています。タイマーが切れる前に、対応するGraftAckが受信されない場合は、別の移植片が送信され、GraftRetryタイマーがリセットされます。グラフトAckメッセージを受信したときにタイマーを停止しています。このタイマは、通常Graft_Retry_Period（4.8を参照）に設定されています。
Override Timer (OT(S,G)) This timer is set when a Prune(S,G) is received on the upstream interface where olist(S,G) != NULL. When the timer expires, a Join(S,G) message is sent on the upstream interface. This timer is normally set to t_override (see 4.8).
プルーン（S、G）はOLIST（S、G）！= NULLアップストリームインターフェイスで受信されたときにタイマ（OT（S、Gに））オーバーライドこのタイマは設定されています。タイマが満了した場合、参加（S、G）メッセージがアップストリームインターフェイス上で送信されます。このタイマーは通常、（4.8を参照）t_overrideに設定されています。
Prune Limit Timer (PLT(S,G)) This timer is used to rate-limit Prunes on a LAN. It is only used when the Upstream(S,G) state machine is in the Pruned state. A Prune cannot be sent if this timer is running. This timer is normally set to t_limit (see 4.8).
プルーン制限タイマ（PLT（S、G））このタイマは、LAN上のプルーン制限レートするために使用されます。アップストリーム（S、G）ステートマシンプルーニング状態にあるときにのみ使用されます。このタイマーが実行されている場合プルーンを送信することはできません。このタイマーは通常、（4.8を参照）t_limitに設定されています。
+-------------+ +-------------+
| | olist == NULL | |
| Forward |----------------------->| Pruned |
| | | |
+-------------+ +-------------+
^ | ^ |
| | | |
| |RPF`(S) Changes olist == NULL| |
| | | |
| | +-------------+ | |
| +-------->| |----------+ |
| | AckPending | |
+-------------| |<-------------+
Rcv GraftAck OR +-------------+ olist != NULL
Rcv State Refresh
With (P==0) OR
S Directly Connect
Figure 1: Upstream Interface State Machine
図1：アップストリームインターフェイスステートマシン
In tabular form, the state machine is defined as follows:
次のように表形式で、状態マシンに定義されます。
+-------------------------------+--------------------------------------+
| | Previous State |
| +------------+------------+------------+
| Event | Forwarding | Pruned | AckPending |
+-------------------------------+------------+------------+------------+
| Data packet arrives on | ->P Send | ->P Send | N/A |
| RPF_Interface(S) AND | Prune(S,G) | Prune(S,G) | |
| olist(S,G) == NULL AND |Set PLT(S,G)|Set PLT(S,G)| |
| PLT(S,G) not running | | | |
+-------------------------------+------------+------------+------------+
| State Refresh(S,G) received | ->F Set | ->P Reset |->AP Set |
| from RPF`(S) AND | OT(S,G) | PLT(S,G) | OT(S,G) |
| Prune Indicator == 1 | | | |
+-------------------------------+------------+------------+------------+
| State Refresh(S,G) received | ->F | ->P Send |->F Cancel |
| from RPF`(S) AND | | Prune(S,G) | GRT(S,G) |
| Prune Indicator == 0 AND | |Set PLT(S,G)| |
| PLT(S,G) not running | | | |
+-------------------------------+------------+------------+------------+
+-------------------------------+--------------------------------------+
| | Previous State |
+ +------------+------------+------------+
| Event | Forwarding | Pruned | AckPending |
+-------------------------------+------------+------------+------------+
| See Join(S,G) to RPF'(S) | ->F Cancel | ->P |->AP Cancel |
| | OT(S,G) | | OT(S,G) |
+-------------------------------+------------+------------+------------+
| See Prune(S,G) | ->F Set | ->P |->AP Set |
| | OT(S,G) | | OT(S,G) |
+-------------------------------+------------+------------+------------+
| OT(S,G) Expires | ->F Send | N/A |->AP Send |
| | Join(S,G) | | Join(S,G) |
+-------------------------------+------------+------------+------------+
| olist(S,G)->NULL | ->P Send | N/A |->P Send |
| | Prune(S,G) | | Prune(S,G) |
| |Set PLT(S,G)| |Set PLT(S,G)|
| | | | Cancel |
| | | | GRT(S,G) |
+-------------------------------+------------+------------+------------+
| olist(S,G)->non-NULL | N/A | ->AP Send | N/A |
| | | Graft(S,G) | |
| | |Set GRT(S,G)| |
+-------------------------------+------------+------------+------------+
| RPF'(S) Changes AND | ->AP Send | ->AP Send |->AP Send |
| olist(S,G) != NULL | Graft(S,G) | Graft(S,G) | Graft(S,G) |
| |Set GRT(S,G)|Set GRT(S,G)|Set GRT(S,G)|
+-------------------------------+------------+------------+------------+
| RPF'(S) Changes AND | ->P | ->P Cancel |->P Cancel |
| olist(S,G) == NULL | | PLT(S,G) | GRT(S,G) |
+-------------------------------+------------+------------+------------+
| S becomes directly connected | ->F | ->P |->F Cancel |
| | | | GRT(S,G) |
+-------------------------------+------------+------------+------------+
| GRT(S,G) Expires | N/A | N/A |->AP Send |
| | | | Graft(S,G) |
| | | |Set GRT(S,G)|
+-------------------------------+------------+------------+------------+
| Receive GraftAck(S,G) from | ->F | ->P |->F Cancel |
| RPF'(S) | | | GRT(S,G) |
+-------------------------------+------------+------------+------------+
The transition event "RcvGraftAck(S,G)" implies receiving a Graft Ack message targeted to this router's address on the incoming interface for the (S,G) entry. If the destination address is not correct, the state transitions in this state machine must not occur.
遷移イベント「RcvGraftAck（S、G）」は（S、G）エントリの着信インターフェイス上でこのルータのアドレスを標的とするグラフトACKメッセージを受信暗示します。宛先アドレスが正しくない場合は、この状態マシンの状態遷移が発生してはいけません。
When the Upstream(S,G) state machine is in the Forwarding (F) state, the following events may trigger a transition:
アップストリーム（S、G）ステートマシンは、転送（F）状態にある場合、以下のイベントが遷移をトリガすることができます。
Data Packet arrives on RPF_Interface(S) AND olist(S,G) == NULL AND S NOT directly connected The Upstream(S,G) state machine MUST transition to the Pruned (P) state, send a Prune(S,G) to RPF'(S), and set PLT(S,G) to t_limit seconds.
データパケットがプルーン（S、G）を送信し、剪定（P）状態に移行しなければならないNULL == RPF_Interface（S）AND OLIST（S、G）に到着し、直接アップストリーム（S、G）ステートマシンを接続しませんわRPF '（S）に、秒をt_limitに設定PLT（S、G）。
State Refresh(S,G) Received from RPF'(S) The Upstream(S,G) state machine remains in a Forwarding state. If the received State Refresh has the Prune Indicator bit set to one, this router must override the upstream router's Prune state after a short random interval. If OT(S,G) is not running and the Prune Indicator bit equals one, the router MUST set OT(S,G) to t_override seconds.
ステートリフレッシュRPFから受信した（S、G） '（S）上流（S、G）ステートマシンは、フォワーディング状態で残っています。受信状態のリフレッシュプルーンインジケータビット1に設定されている場合は、このルータは、短いランダムな間隔の後、上流のルータのプルーンの状態をオーバーライドする必要があります。 OT（S、G）が実行されていないとプルーンインジケータビットが1に等しい場合、ルータは秒をt_overrideするOT（S、G）を設定しなければなりません。
See Join(S,G) to RPF'(S) 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). If the OT(S,G) is running, then it means that the router had scheduled a Join to override a previously received Prune. Another router has responded more quickly with a Join, so the local router SHOULD cancel its OT(S,G), if it is running. The Upstream(S,G) state machine remains in the Forwarding (F) state.
RPF_interface（S）が共有メディアである場合、このイベントにのみ関連している（S）「RPFに（S、G）に参加を参照してください。このルータはRPF_interface（S）上の別のルータを見RPF '（S、G）に参加（S、G）を送ります。 OT（S、G）が実行されている場合、それは、ルータが以前に受信したプルーンを上書きするために参加を予定していたことを意味します。別のルータが参加して、より迅速に対応しているので、それが実行されている場合、ローカルルータは、そのOT（S、G）をキャンセルすべきです。アップストリーム（S、G）ステートマシンは、転送（F）状態のままです。
See Prune(S,G) AND S NOT directly connected 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). As this router is in Forwarding state, it must override the Prune after a short random interval. If OT(S,G) is not running, the router MUST set OT(S,G) to t_override seconds. The Upstream(S,G) state machine remains in Forwarding (F) state.
RPF_interface（S）が共有メディアである場合にはプルーン（S、G）AND S直接このイベントを接続されていないが、唯一の関連性がある参照してください。このルータはRPF_interface（S）上の別のルータを見プルーン（S、G）を送ります。このルータがフォワーディング状態にあるとして、それは短いランダムな間隔の後にプルーンをオーバーライドする必要があります。 OT（S、G）が実行されていない場合、ルータは秒をt_overrideするOT（S、G）を設定しなければなりません。アップストリーム（S、G）ステートマシンは、転送（F）状態のままです。
OT(S,G) Expires AND S NOT directly connected The OverrideTimer (OT(S,G)) expires. The router MUST send a Join(S,G) to RPF'(S) to override a previously detected prune. The Upstream(S,G) state machine remains in the Forwarding (F) state.
OT（S、G）は、有効期限及びS直接OverrideTimer（OT（S、G））が期限切れに接続されていません。ルータは、以前に検出されたプルーンを上書きするRPF '（S）への参加（S、G）を送信しなければなりません。アップストリーム（S、G）ステートマシンは、転送（F）状態のままです。
olist(S,G) -> NULL AND S NOT directly connected The Upstream(S,G) state machine MUST transition to the Pruned (P) state, send a Prune(S,G) to RPF'(S), and set PLT(S,G) to t_limit seconds.
OLIST（S、G） - > NULL直接アップストリーム（S、G）ステートマシンを接続NOT S RPFにプルーン（S、G）を送信し、剪定（P）状態に移行しなければならない '（S）、および組秒をt_limitするPLT（S、G）。
RPF'(S) Changes AND olist(S,G) is non-NULL AND S NOT directly connected Unicast routing or Assert state causes RPF'(S) to change, including changes to RPF_Interface(S). The Upstream(S,G) state machine MUST transition to the AckPending (AP) state, unicast a Graft to the new RPF'(S), and set the GraftRetry Timer (GRT(S,G)) to Graft_Retry_Period.
RPFは、 '（S）の変更およびOLIST（S、G）NULLで直接ユニキャストルーティングを接続または状態がRPFせるアサートしないS'（S）がRPF_Interface（S）への変更を含めて、変更します。アップストリーム（S、G）ステートマシンはAckPending（AP）状態、ユニキャスト（S） '新しいRPFに移植への移行、およびGraft_Retry_PeriodにGraftRetryタイマ（GRT（S、G））を設定しなければなりません。
RPF'(S) Changes AND olist(S,G) is NULL Unicast routing or Assert state causes RPF'(S) to change, including changes to RPF_Interface(S). The Upstream(S,G) state machine MUST transition to the Pruned (P) state.
RPF '（S）の変更およびOLIST（S、G）はNULLユニキャストルーティング、または状態がRPFせるアサート'（S）RPF_Interface（S）への変更を含めて、変更します。アップストリーム（S、G）ステートマシンは、剪定（P）状態に移行しなければなりません。
When the Upstream(S,G) state machine is in the Pruned (P) state, the following events may trigger a transition:
アップストリーム（S、G）ステートマシンは、剪定（P）状態である場合、次のイベントが遷移をトリガすることができます。
Data arrives on RPF_interface(S) AND PLT(S,G) not running AND S NOT directly connected Either another router on the LAN desires traffic from S addressed to G or a previous Prune was lost. To prevent generating a Prune(S,G) in response to every data packet, the PruneLimit Timer (PLT(S,G)) is used. Once the PLT(S,G) expires, the router needs to send another prune in response to a data packet not received directly from the source. A Prune(S,G) MUST be sent to RPF'(S), and the PLT(S,G) MUST be set to t_limit.
データはRPF_interface（S）に到着し、PLT（S、G）が動作していないと直接接続されていないSのいずれかをLAN上の他のルータがSからのトラフィックがG宛または前のプルーンが失われたことを望みます。すべてのデータ・パケットに応答してプルーン（S、G）を生成防ぐために、PruneLimitタイマ（PLT（S、G））が使用されます。 PLT（S、G）が満了すると、ルータは、ソースから直接受信されなかったデータパケットに応答して別のプルーンを送信する必要があります。プルーン（S、G）は、（S） 'RPFに送信する必要があり、及びPLT（S、G）はt_limitに設定する必要があります。
State Refresh(S,G) Received from RPF'(S) The Upstream(S,G) state machine remains in a Pruned state. If the State Refresh has its Prune Indicator bit set to zero and PLT(S,G) is not running, a Prune(S,G) MUST be sent to RPF'(S), and the PLT(S,G) MUST be set to t_limit. If the State Refresh has its Prune Indicator bit set to one, the router MUST reset PLT(S,G) to t_limit.
ステートリフレッシュ（S、G）が上流（S、G）ステート・マシンは、剪定された状態のままでRPF '（S）から受け取りました。ステートリフレッシュがプルーンインジケータビットはゼロに設定されている及びPLT（S、G）が実行されていない場合、プルーン（S、G）は、（S） 'RPFに送信する必要があり、及びPLT（S、G）がなければなりませんt_limitに設定します。ステートリフレッシュはそのプルーンインジケータビット1に設定されている場合、ルータはt_limitにPLT（S、G）をリセットする必要があります。
See Prune(S,G) to RPF'(S) A Prune(S,G) is seen on RPF_interface(S) to RPF'(S). The Upstream(S,G) state machine stays in the Pruned (P) state. The router MAY reset its PLT(S,G) to the value in the Holdtime field of the received message if it is greater than the current value of the PLT(S,G).
参照プルーンRPFに（S、G）（S） '（S）Aプルーン（S、G）は、RPFにRPF_interface（S）に見られます'。アップストリーム（S、G）ステートマシンは、剪定（P）状態に留まります。それはPLT（S、G）の現在の値よりも大きい場合、ルータは、受信したメッセージのホールドタイムフィールドの値へのPLT（S、G）をリセットすることができます。
olist(S,G)->non-NULL AND S NOT directly connected The set of interfaces defined by the olist(S,G) macro becomes non-empty, indicating that traffic from S addressed to group G must be forwarded. The Upstream(S,G) state machine MUST cancel PLT(S,G), transition to the AckPending (AP) state and unicast a
OLIST（S、G） - >非NULL直接Sからのトラフィックが転送されなければならないグループG宛てことを示す、OLIST（S、G）マクロが空になることによって定義されたインタフェースのセットを接続されたじゃありません。アップストリーム（S、G）ステートマシンは、PLT（S、G）AckPending（AP）に、遷移状態及びユニキャストAをキャンセルする必要があります
Graft message to RPF'(S). The Graft Retry Timer (GRT(S,G)) MUST be set to Graft_Retry_Period.
RPFへのグラフトメッセージ '（S）。グラフトリトライタイマ（GRT（S、G））がGraft_Retry_Periodに設定しなければなりません。
RPF'(S) Changes AND olist(S,G) == non-NULL AND S NOT directly connected Unicast routing or Assert state causes RPF'(S) to change, including changes to RPF_Interface(S). The Upstream(S,G) state machine MUST cancel PLT(S,G), transition to the AckPending (AP) state, send a Graft unicast to the new RPF'(S), and set the GraftRetry Timer (GRT(S,G)) to Graft_Retry_Period.
RPF '（S）の変更およびOLIST（S、G）は== NULL以外直接ユニキャストルーティングを接続または状態がRPFせるアサートしないS'（S）RPF_Interface（S）への変更を含めて、変更します。アップストリーム（S、G）ステートマシンは、AckPending（AP）状態への遷移、（S） '新しいRPFにグラフトユニキャストを送信する（S、G）PLTを取り消し、そしてGraftRetryタイマ（GRT（Sを設定しなければなりませんGraft_Retry_PeriodへG））。
RPF'(S) Changes AND olist(S,G) == NULL AND S NOT directly connected Unicast routing or Assert state causes RPF'(S) to change, including changes to RPF_Interface(S). The Upstream(S,G) state machine stays in the Pruned (P) state and MUST cancel the PLT(S,G) timer.
RPF '（S）の変更およびOLIST（S、G）== NULL直接ユニキャストルーティングを接続または状態がRPFせるアサートしないS' は（S）RPF_Interface（S）への変更を含めて、変更します。アップストリーム（S、G）ステートマシンは、剪定（P）状態に留まり、PLT（S、G）タイマーをキャンセルしなければなりません。
S becomes directly connected Unicast routing changed so that S is directly connected. The Upstream(S,G) state machine remains in the Pruned (P) state.
Sは、直接接続されたユニキャストルーティングようsが直接接続されている変更となります。アップストリーム（S、G）ステートマシンは、剪定（P）状態のままです。
When the Upstream(S,G) state machine is in the AckPending (AP) state, the following events may trigger a transition:
アップストリーム（S、G）ステートマシンはAckPending（AP）状態にある場合、以下のイベントが遷移をトリガすることができます。
State Refresh(S,G) Received from RPF'(S) with Prune Indicator == 1 The Upstream(S,G) state machine remains in an AckPending state. The router must override the upstream router's Prune state after a short random interval. If OT(S,G) is not running and the Prune Indicator bit equals one, the router MUST set OT(S,G) to t_override seconds.
プルーンインジケータ== 1状態更新（S、G）「RPFから受信した（S）は、アップストリーム（S、G）ステートマシンはAckPending状態のままです。ルータは、短いランダムな間隔の後、上流のルータのプルーンの状態をオーバーライドする必要があります。 OT（S、G）が実行されていないとプルーンインジケータビットが1に等しい場合、ルータは秒をt_overrideするOT（S、G）を設定しなければなりません。
State Refresh(S,G) Received from RPF'(S) with Prune Indicator == 0 The router MUST cancel its GraftRetry Timer (GRT(S,G)) and transition to the Forwarding (F) state.
プルーンインジケータ== 0キャンセルしなければならないルータと状態更新RPFから受信した（S、G）」（S）そのGraftRetryタイマ（GRT（S、G））および転送（F）状態に遷移。
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). If the OT(S,G) is running, then it means that the router had scheduled a Join to override a previously received Prune. Another router has responded more quickly with a Join, so the local router SHOULD cancel its OT(S,G), if it is running. The Upstream(S,G) state machine remains in the AckPending (AP) state.
RPF_interface（S）が共有メディアである場合、このイベントにのみ関連している（S、G）「RPFに（S、G）に参加を参照してください。このルータはRPF_interface（S）上の別のルータを見RPF '（S、G）に参加（S、G）を送ります。 OT（S、G）が実行されている場合、それは、ルータが以前に受信したプルーンを上書きするために参加を予定していたことを意味します。別のルータが参加して、より迅速に対応しているので、それが実行されている場合、ローカルルータは、そのOT（S、G）をキャンセルすべきです。アップストリーム（S、G）ステートマシンはAckPending（AP）状態のままです。
See Prune(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). As this router is in AckPending (AP) state, it must override the Prune after a short random interval. If OT(S,G) is not running, the router MUST set OT(S,G) to t_override seconds. The Upstream(S,G) state machine remains in AckPending (AP) state.
RPF_interface（S）は、共有媒体であるかどうかプルーン（S、G）このイベントは、関連しています。このルータはRPF_interface（S）上の別のルータを見プルーン（S、G）を送ります。このルータはAckPending（AP）状態にあるとして、それは短いランダムな間隔の後にプルーンをオーバーライドする必要があります。 OT（S、G）が実行されていない場合、ルータは秒をt_overrideするOT（S、G）を設定しなければなりません。アップストリーム（S、G）ステートマシンはAckPending（AP）状態のままです。
OT(S,G) Expires The OverrideTimer (OT(S,G)) expires. The router MUST send a Join(S,G) to RPF'(S). The Upstream(S,G) state machine remains in the AckPending (AP) state.
OT（S、G）はOverrideTimer（OT（S、G））が満了する期限。ルータはRPF '（S）に参加（S、G）を送らなければなりません。アップストリーム（S、G）ステートマシンはAckPending（AP）状態のままです。
olist(S,G) -> NULL The set of interfaces defined by the olist(S,G) macro becomes null, indicating that traffic from S addressed to group G should no longer be forwarded. The Upstream(S,G) state machine MUST transition to the Pruned (P) state. A Prune(S,G) MUST be multicast to the RPF_interface(S), with RPF'(S) named in the upstream neighbor field. The GraftRetry Timer (GRT(S,G)) MUST be cancelled, and PLT(S,G) MUST be set to t_limit seconds.
OLIST（S、G） - > NULL OLIST（S、G）によって定義されたインタフェースのセットマクロは、SからトラフィックGはもはや転送されるべきグループ宛ないことを示し、ゼロになります。アップストリーム（S、G）ステートマシンは、剪定（P）状態に移行しなければなりません。プルーン（S、G）は、上流隣接フィールドで指定されたRPF '（S）と、RPF_interface（S）にマルチキャストされなければなりません。 GraftRetryタイマ（GRT（S、G））が解除されなければならない、及びPLT（S、G）は秒t_limitに設定されなければなりません。
RPF'(S) Changes AND olist(S,G) does not become NULL AND S NOT directly connected Unicast routing or Assert state causes RPF'(S) to change, including changes to RPF_Interface(S). The Upstream(S,G) state machine stays in the AckPending (AP) state. A Graft MUST be unicast to the new RPF'(S) and the GraftRetry Timer (GRT(S,G)) reset to Graft_Retry_Period.
RPF '（S）の変更およびOLIST（S、G）はNULLになっておらず、直接ユニキャストルーティングを接続NOT Sまたは状態がRPFせるアサート'（S）RPF_Interface（S）への変更を含めて、変更します。アップストリーム（S、G）ステートマシンはAckPending（AP）状態に留まります。移植片はGraft_Retry_Periodにリセット新しいRPF '（S）とGraftRetryタイマ（GRT（S、G））にユニキャストされなければなりません。
RPF'(S) Changes AND olist(S,G) == NULL AND S NOT directly connected Unicast routing or Assert state causes RPF'(S) to change, including changes to RPF_Interface(S). The Upstream(S,G) state machine MUST transition to the Pruned (P) state. The GraftRetry Timer (GRT(S,G)) MUST be cancelled.
RPF '（S）の変更およびOLIST（S、G）== NULL直接ユニキャストルーティングを接続または状態がRPFせるアサートしないS' は（S）RPF_Interface（S）への変更を含めて、変更します。アップストリーム（S、G）ステートマシンは、剪定（P）状態に移行しなければなりません。 GraftRetryタイマ（GRT（S、G））が解除されなければなりません。
S becomes directly connected Unicast routing has changed so that S is directly connected. The GraftRetry Timer MUST be cancelled, and the Upstream(S,G) state machine MUST transition to the Forwarding(F) state.
Sは、Sが直接接続されるように、直接接続されたユニキャストルーティングが変更されてなります。 GraftRetryタイマーはキャンセルされなければならない、そして上流（S、G）ステートマシンは、転送（F）状態に移行しなければなりません。
GRT(S,G) Expires The GraftRetry Timer (GRT(S,G)) expires for this (S,G) entry. The Upstream(S,G) state machine stays in the AckPending (AP) state. Another Graft message for (S,G) SHOULD be unicast to RPF'(S) and the GraftRetry Timer (GRT(S,G)) reset to Graft_Retry_Period. It is RECOMMENDED that the router retry a configured number of times before ceasing retries.
GRT（S、G）はGraftRetryタイマ（GRT（S、G））は、この（S、G）エントリの有効期限が切れる期限。アップストリーム（S、G）ステートマシンはAckPending（AP）状態に留まります。 （S、G）のための別のグラフトメッセージがRPF '（S）とGraftRetryタイマ（GRT（S、G））Graft_Retry_Periodにリセットするためにユニキャストされるべきです。ルータが再試行を中止する前に設定された回数を再試行することが推奨されます。
See GraftAck(S,G) from RPF'(S) A GraftAck is received from RPF'(S). The GraftRetry Timer MUST be cancelled, and the Upstream(S,G) state machine MUST transition to the Forwarding(F) state.
RPFからGraftAck（S、G） '（S）A GraftAckは、RPFから受信される'（S）を参照してください。 GraftRetryタイマーはキャンセルされなければならない、そして上流（S、G）ステートマシンは、転送（F）状態に移行しなければなりません。
The Prune(S,G) Downstream state machine for receiving Prune, Join and Graft messages on interface I is given below. This state machine MUST always be in the NoInfo state on the upstream interface. It contains three states.
プルーン（S、G）プルーンを受信するためのダウンストリームステートマシンは、参加およびインターフェイスIにグラフトメッセージを以下に示します。このステートマシンは常にアップストリームインターフェイス上NoInfoの状態でなければなりません。これは3つの状態が含まれています。
NoInfo(NI) The interface has no (S,G) Prune state, and neither the Prune timer (PT(S,G,I)) nor the PrunePending timer ((PPT(S,G,I)) is running.
いいえ情報（IN）インタフェースが実行されている無（S、G）プルーン状態、およびどちらのプルーンタイマー（PT（S、G、I））やプルーン保留タイマー（（PPT（S、G、I））を持っていません。
PrunePending(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 PrunePending state functions exactly like the NoInfo state.
PrunePending（PP）ルータは、ダウンストリームネイバーから、このインターフェイス上でプルーン（S、G）を受信したとプルーンが別の下流のルータによって上書きされるかどうかを確認するために待機しています。転送のために、正確にNoInfo状態のようなPrunePending状態機能。
Pruned(P) The router has received a Prune(S,G) on this interface from a downstream neighbor, and the Prune was not overridden. Data from S addressed to group G is no longer being forwarded on this interface.
剪定（P）ルータは、下流の近隣からこのインターフェイスでプルーン（S、G）を受信した、とプルーンは上書きされませんでした。 Sからのデータは、Gは、もはやこのインターフェイスで転送されているグループ宛。
In addition, there are two timers:
また、2つのタイマがあります。
PrunePending Timer (PPT(S,G,I)) This timer is set when a valid Prune(S,G) is received. Expiry of the PrunePending Timer (PPT(S,G,I)) causes the interface to transition to the Pruned state.
有効なプルーン（S、G）を受信したときPrunePendingタイマ（PPT（S、G、I））このタイマーが設定されています。 PrunePendingタイマ（PPT（S、G、I））の有効期限は、インターフェイスがプルーニング状態に遷移させます。
Prune Timer (PT(S,G,I)) This timer is set when the PrunePending Timer (PT(S,G,I)) expires. Expiry of the Prune Timer (PT(S,G,I)) causes the interface to transition to the NoInfo (NI) state, thereby allowing data from S addressed to group G to be forwarded on the interface.
PrunePendingタイマー（PT（S、G、I））が満了したときプルーンタイマー（PT（S、G、I））このタイマは設定されています。プルーンタイマー（PT（S、G、I））の有効期限は、それによってインターフェイス上で転送されるSからのデータがグループG宛せる、NoInfo（NI）状態に遷移するためのインタフェースを引き起こします。
+-------------+ +-------------+
| | PPT Expires | |
|PrunePending |----------------------->| Pruned |
| | | |
+-------------+ +-------------+
| ^ |
| | |
| |Rcv Prune |
| | |
| | +-------------+ |
| +---------| | |
| | NoInfo |<-------------+
+------------>| | Rcv Join/Graft OR
Rcv Join/Graft OR +-------------+ PT Expires OR
RPF_Interface(S)->I RPF_Interface(S)->I
Figure 2: Downstream Interface State Machine
図2：ダウンストリームインターフェイスのステートマシン
In tabular form, the state machine is as follows:
次のように表形式で、状態機械です。
+-------------------------------+--------------------------------------+
| | Previous State |
+ +------------+------------+------------+
| Event | No Info | PrunePend | Pruned |
+-------------------------------+------------+------------+------------+
| Receive Prune(S,G) |->PP Set |->PP |->P Reset |
| | PPT(S,G,I) | | PT(S,G,I) |
+-------------------------------+------------+------------+------------+
| Receive Join(S,G) |->NI |->NI Cancel |->NI Cancel |
| | | PPT(S,G,I) | PT(S,G,I) |
+-------------------------------+------------+------------+------------+
| Receive Graft(S,G) |->NI Send |->NI Send |->NI Send |
| | GraftAck | GraftAck | GraftAck |
| | | Cancel | Cancel |
| | | PPT(S,G,I) | PT(S,G,I) |
+-------------------------------+------------+------------+------------+
| PPT(S,G) Expires | N/A |->P Set | N/A |
| | | PT(S,G,I) | |
+-------------------------------+------------+------------+------------+
| PT(S,G) Expires | N/A | N/A |->NI |
+-------------------------------+------------+------------+------------+
| RPF_Interface(S) becomes I |->NI |->NI Cancel |->NI Cancel |
| | | PPT(S,G,I) | PT(S,G,I) |
+-------------------------------+------------+------------+------------+
| Send State Refresh(S,G) out I |->NI |->PP |->P Reset |
| | | | PT(S,G,I) |
+-------------------------------+------------+------------+------------+
The transition events "Receive Graft(S,G)", "Receive Prune(S,G)", and "Receive Join(S,G)" denote receiving a Graft, Prune, or Join message in which this router's address on I is contained in the message's upstream neighbor field. If the upstream neighbor field does not match this router's address on I, then these state transitions in this state machine must not occur.
遷移イベントは、「グラフト（S、G）を受信」、および、グラフト、プルーンを受ける意味「（S、G）が参加受信」またはJoinメッセージを「プルーン（S、G）が受信」I上のどのこのルータのアドレスでメッセージの上流隣接フィールドに含まれています。上流隣接フィールドはI上でこのルータのアドレスと一致しない場合は、この状態のマシンでこれらの状態遷移は発生してはいけません。
When the Prune(S,G) Downstream state machine is in the NoInfo (NI) state, the following events may trigger a transition:
プルーン（S、G）ダウンストリーム状態マシンはNoInfo（NI）状態にある場合、以下のイベントが遷移をトリガすることができます。
Receive Prune(S,G) A Prune(S,G) is received on interface I with the upstream neighbor field set to the router's address on I. The Prune(S,G) Downstream state machine on interface I MUST transition to the PrunePending (PP) state. The PrunePending Timer (PPT(S,G,I)) MUST be set to J/P_Override_Interval if the router has more than one neighbor on I. If the router has only one neighbor on interface I, then it SHOULD set the PPT(S,G,I) to zero, effectively transitioning immediately to the Pruned (P) state.
インターフェイス上で受信プルーン（S、G）Aプルーン（S、G）は、私はI.ザプルーン（S、G）上のルータのアドレスに設定上流隣接フィールドとのインターフェイスで受信されたダウンストリームステートマシンIはPrunePendingに遷移しなければなりません（PP）の状態。ルータは、私は、それはPPT（Sを設定するインターフェイスにのみつの隣接している場合、ルータはI.上の複数の隣接している場合PrunePendingタイマ（PPT（S、G、I））はJ / P_Override_Intervalに設定しなければなりません、G、I）をゼロに、効果的に剪定（P）状態に直ちに移行します。
Receive Graft(S,G) A Graft(S,G) is received on the interface I with the upstream neighbor field set to the router's address on I. The Prune(S,G) Downstream state machine on interface I stays in the NoInfo (NI) state. A GraftAck(S,G) MUST be unicast to the originator of the Graft(S,G) message.
私はNoInfoにとどまるインターフェイスにグラフト（S、G）Aグラフト（S、G）私はI.ザ・プルーン（S、G）上のルータのアドレスに設定上流隣接フィールドにインターフェイス上で受信されたダウンストリームステートマシンを受け取ります（NI）状態。 GraftAck（S、G）は、グラフト（S、G）メッセージの発信者にユニキャストされなければなりません。
When the Prune(S,G) downstream state machine is in the PrunePending (PP) state, the following events may trigger a transition.
プルーン（S、G）下流のステートマシンがPrunePending（PP）状態にある場合、以下のイベントが遷移をトリガすることができます。
Receive Join(S,G) A Join(S,G) is received on interface I with the upstream neighbor field set to the router's address on I. The Prune(S,G) Downstream state machine on interface I MUST transition to the NoInfo (NI) state. The PrunePending Timer (PPT(S,G,I)) MUST be cancelled.
インターフェイス上で参加受け取る（S、G）A参加（S、G）は、私はI.ザプルーン（S、G）上のルータのアドレスに設定上流隣接フィールドとのインターフェイスで受信されたダウンストリームステートマシンIはNoInfoに遷移しなければなりません（NI）状態。 PrunePendingタイマ（PPT（S、G、I））が解除されなければなりません。
Receive Graft(S,G) A Graft(S,G) is received on interface I with the upstream neighbor field set to the router's address on I. The Prune(S,G) Downstream state machine on interface I MUST transition to the NoInfo (NI) state and MUST unicast a Graft Ack message to the Graft originator. The PrunePending Timer (PPT(S,G,I)) MUST be cancelled.
インターフェイス上でグラフト（S、G）Aグラフト（S、G）私はI.ザプルーン（S、G）上のルータのアドレスに設定上流隣接フィールドとのインターフェイスで受信されたダウンストリームステートマシンを受信IはNoInfoに遷移しなければなりません（NI）状態とグラフト元にグラフトAckメッセージをユニキャストしなければなりません。 PrunePendingタイマ（PPT（S、G、I））が解除されなければなりません。
PPT(S,G,I) Expires The PrunePending Timer (PPT(S,G,I)) expires, indicating that no neighbors have overridden the previous Prune(S,G) message. The Prune(S,G) Downstream state machine on interface I MUST transition to the Pruned (P) state. The Prune Timer (PT(S,G,I)) is started and MUST be initialized to the received Prune_Hold_Time minus J/P_Override_Interval. A PruneEcho(S,G) MUST be sent on I if I has more than one PIM neighbor. A PruneEcho(S,G) is simply a Prune(S,G) message multicast by the upstream router to a LAN, with itself as the Upstream Neighbor. Its purpose is to add additional reliability so that if a Join that should have overridden the Prune is lost locally on the LAN, the PruneEcho(S,G) may be received and trigger a new Join message. A PruneEcho(S,G) is OPTIONAL on an interface with only one PIM neighbor. In addition, the router MUST evaluate any possible transitions in the Upstream(S,G) state machine.
PPT（S、G、I）がないネイバーが以前プルーン（S、G）メッセージをオーバーライドしていないことを示す、PrunePendingタイマ（PPT（S、G、I））が満了する期限。 Iは、剪定（P）状態に移行しなければならないインターフェイス上プルーン（S、G）下流のステートマシン。プルーンタイマー（PT（S、G、I））が開始され、受信Prune_Hold_TimeマイナスJ / P_Override_Intervalに初期化されなければなりません。私は複数のPIMネイバーを有する場合PruneEcho（S、G）はI上で送信されなければなりません。 PruneEcho（S、G）は、単に上流ネイバーとしてそれ自体で、LANへのアップストリームルータによってマルチキャストプルーン（S、G）メッセージです。 、PruneEcho（S、G）を受信することができるLAN上でローカルに失われたプルーンをオーバーライドしていなければならないことに参加して、新しいJoinメッセージをトリガーする場合ように、その目的は、追加の信頼性を追加することです。 PruneEcho（S、G）は、唯一のPIMネイバーとのインタフェースに任意です。また、ルータは、アップストリーム（S、G）ステートマシンの任意の可能な遷移を評価しなければなりません。
RPF_Interface(S) becomes interface I The upstream interface for S has changed. The Prune(S,G) Downstream state machine on interface I MUST transition to the NoInfo (NI) state. The PrunePending Timer (PPT(S,G,I)) MUST be cancelled.
RPF_Interface（S）は、私はSのアップストリームインタフェースが変更されたインタフェースとなります。 IはNoInfo（NI）状態に移行しなければならないインターフェイス上プルーン（S、G）下流のステートマシン。 PrunePendingタイマ（PPT（S、G、I））が解除されなければなりません。
When the Prune(S,G) Downstream state machine is in the Pruned (P) state, the following events may trigger a transition.
プルーン（S、G）ダウンストリーム状態マシンは剪定（P）状態である場合、次のイベントが遷移をトリガすることができます。
Receive Prune(S,G) A Prune(S,G) is received on the interface I with the upstream neighbor field set to the router's address on I. The Prune(S,G) Downstream state machine on interface I remains in the Pruned (P) state. The Prune Timer (PT(S,G,I)) SHOULD be reset to the holdtime contained in the Prune(S,G) message if it is greater than the current value.
私は剪定に残っインターフェイスで受信プルーン（S、G）Aプルーン（S、G）は、私はI.ザプルーン（S、G）上のルータのアドレスに設定上流隣接フィールドとのインターフェイスで受信されたダウンストリームステートマシン（P）状態。それが現在の値よりも大きい場合プルーンタイマー（PT（S、G、I））は、プルーン（S、G）メッセージに含まれるホールドタイムにリセットされるべきです。
Receive Join(S,G) A Join(S,G) is received on the interface I with the upstream neighbor field set to the router's address on I. The Prune(S,G) downstream state machine on interface I MUST transition to the NoInfo (NI) state. The Prune Timer (PT(S,G,I)) MUST be cancelled. The router MUST evaluate any possible transitions in the Upstream(S,G) state machine.
参加（S、G）Aは（S、G）に参加する受信Iインターフェイス上I.ザプルーン（S、G）川下状態マシン上でルータのアドレスに設定上流隣接フィールドとのインターフェイスで受信されたIは、に移行しなければなりませんNoInfo（NI）状態。プルーンタイマー（PT（S、G、I））が解除されなければなりません。ルータは、アップストリーム（S、G）ステートマシンの任意の可能な遷移を評価しなければなりません。
Receive Graft(S,G) A Graft(S,G) is received on interface I with the upstream neighbor field set to the router's address on I. The Prune(S,G) Downstream state machine on interface I MUST transition to the NoInfo (NI) state and send a Graft Ack back to the Graft's source. The Prune Timer (PT(S,G,I)) MUST be cancelled. The router MUST evaluate any possible transitions in the Upstream(S,G) state machine.
インターフェイス上でグラフト（S、G）Aグラフト（S、G）私はI.ザプルーン（S、G）上のルータのアドレスに設定上流隣接フィールドとのインターフェイスで受信されたダウンストリームステートマシンを受信IはNoInfoに遷移しなければなりません（NI）状態とグラフトのソースにグラフトACKを返送します。プルーンタイマー（PT（S、G、I））が解除されなければなりません。ルータは、アップストリーム（S、G）ステートマシンの任意の可能な遷移を評価しなければなりません。
PT(S,G,I) Expires The Prune Timer (PT(S,G,I)) expires, indicating that it is again time to flood data from S addressed to group G onto interface I. The Prune(S,G) Downstream state machine on interface I MUST transition to the NoInfo (NI) state. The router MUST evaluate any possible transitions in the Upstream(S,G) state machine.
PT（S、G、I）は、再びSからデータをフラッディングする時間であることを示す、プルーンタイマー（PT（S、G、I））が満了する期限インタフェースI.ザプルーン（S、G）にグループG宛てインターフェイスのダウンストリームステートマシンは、IはNoInfo（NI）状態に移行しなければなりません。ルータは、アップストリーム（S、G）ステートマシンの任意の可能な遷移を評価しなければなりません。
RPF_Interface(S) becomes interface I The upstream interface for S has changed. The Prune(S,G) Downstream state machine on interface I MUST transition to the NoInfo (NI) state. The PruneTimer (PT(S,G,I)) MUST be cancelled.
RPF_Interface（S）は、私はSのアップストリームインタフェースが変更されたインタフェースとなります。 IはNoInfo（NI）状態に移行しなければならないインターフェイス上プルーン（S、G）下流のステートマシン。 PruneTimer（PT（S、G、I））が解除されなければなりません。
Send State Refresh(S,G) out interface I The router has refreshed the Prune(S,G) state on interface I. The router MUST reset the Prune Timer (PT(S,G,I)) to the Holdtime from an active Prune received on interface I. The Holdtime used SHOULD be the largest active one but MAY be the most recently received active Prune Holdtime.
送信ルータインターフェイスI.上プルーン（S、G）ステートをリフレッシュしているIステートリフレッシュ（S、G）を界面活性からホールドタイムにプルーンタイマー（PT（S、G、I））をリセットする必要があり、ルータプルーンは、ホールドタイムが最大のアクティブなものでなければならないが、最後にアクティブプルーンホールドタイムを受け取ることができる使用インターフェースI.で受信しました。
This section describes the major portions of the state refresh mechanism.
このセクションでは、状態のリフレッシュ機構の主要な部分を説明しています。
When a State Refresh message, SRM, is received, it is forwarded according to the following pseudo-code.
状態更新メッセージ、SRMは、受信された場合には、次の擬似コードに従って転送されます。
if (iif != RPF_interface(S))
return;
if (RPF'(S) != srcaddr(SRM))
return;
if (StateRefreshRateLimit(S,G) == TRUE)
return;
for each interface I in pim_nbrs {
if (TTL(SRM) == 0 OR (TTL(SRM) - 1) < Threshold(I))
continue; /* Out of TTL, skip this interface */
if (boundary(I,G))
continue; /* This interface is scope boundary, skip it */
if (I == iif)
continue; /* This is the incoming interface, skip it */
if (lost_assert(S,G,I) == TRUE)
continue; /* Let the Assert Winner do State Refresh */
Copy SRM to SRM'; /* Make a copy of SRM to forward */
if (I contained in prunes(S,G)) { set Prune Indicator bit of SRM' to 1;
もし1にSRM」の{設定プルーンインジケータビット（Iはプルーン（S、G）に含まれます）。
if StateRefreshCapable(I) == TRUE set PT(S,G) to largest active holdtime read from a Prune message accepted on I;
Iで受け入れプルーンメッセージから読み取る最大アクティブホールドタイムにStateRefreshCapable（I）== TRUEセットPT（S、G）であれば、
} else { set Prune Indicator bit of SRM' to 0; }
}他{0 SRM」の設定プルーンインジケータビット。 }
set srcaddr(SRM') to my_addr(I);
set TTL of SRM' to TTL(SRM) - 1;
set metric of SRM' to metric of unicast route used to reach S;
set pref of SRM' to preference of unicast route used to reach S;
set mask of SRM' to mask of route used to reach S;
if (AssertState == NoInfo) {
set Assert Override of SRM' to 1;
} else {
set Assert Override of SRM' to 0;
}
transmit SRM' on I; }
私に」SRMを送信します。 }
The pseudocode above employs the following macro definitions.
上記の擬似コードは、以下のマクロ定義を採用します。
Boundary(I,G) is TRUE if an administratively scoped boundary for group G is configured on interface I.
グループGのための管理用スコープの境界が界面I.上に設定されている場合、境界（I、G）がTRUEであります
StateRefreshCapable(I) is TRUE if all neighbors on an interface use the State Refresh option.
インターフェイス上のすべてのネイバーが国家更新]オプションを使用する場合StateRefreshCapable（I）はTRUEです。
StateRefreshRateLimit(S,G) is TRUE if the time elapsed since the last received StateRefresh(S,G) is less than the configured RefreshLimitInterval.
最後に受信StateRefresh（S、G）が構成RefreshLimitInterval未満であるので、時間が経過した場合StateRefreshRateLimit（S、G）がTRUEです。
TTL(SRM) returns the TTL contained in the State Refresh Message, SRM. This is different from the TTL contained in the IP header.
TTL（SRM）は、状態更新メッセージに含まれるTTL、SRMを返します。これは、IPヘッダに含まれるTTLは異なっています。
Threshold(I) returns the minimum TTL that a packet must have before it can be transmitted on interface I.
閾値（I）は、インタフェースI.上で送信する前にパケットを有していなければならない最小のTTLを返します
srcaddr(SRM) returns the source address contained in the network protocol (e.g., IPv4) header of the State Refresh Message, SRM.
SRCADDR（SRM）は、状態更新メッセージ、SRMのネットワークプロトコル（例えば、IPv4）のヘッダに含まれる送信元アドレスを返します。
my_addr(I) returns this node's network (e.g., IPv4) address on interface I.
my_addr（I）は、このノードのネットワークインタフェースI.上で（例えば、IPv4）のアドレスを返します
This section describes the origination of State Refresh messages. These messages are generated periodically by the PIM-DM router directly connected to a source. One Origination(S,G) state machine exists per (S,G) entry in a PIM-DM router.
このセクションでは、ステートリフレッシュメッセージの発信を説明しています。これらのメッセージは、直接ソースに接続されたPIM-DMルータによって定期的に生成されます。一の発信（S、G）ステートマシンは（S、G）PIM-DMルータ内のエントリごとに存在します。
The Origination(S,G) state machine has the following states:
発信（S、G）ステートマシンは、次の状態があります。
NotOriginator(NO) This is the starting state of the Origination(S,G) state machine. While in this state, a router will not originate State Refresh messages for the (S,G) pair.
NotOriginator（NO）これは、発信（S、G）ステートマシンの開始状態です。この状態にある間、ルータは（S、G）ペアの状態更新メッセージを発信しません。
Originator(O) When in this state the router will periodically originate State Refresh messages. Only routers directly connected to S may transition to this state.
この状態で、ルータが定期的にステートリフレッシュメッセージを発信しますオリジネータ（O）。直接Sに接続されている唯一のルータは、この状態に遷移してもよいです。
In addition, there are two state machine specific timers:
さらに、2つのステートマシン固有のタイマーがあります。
State Refresh Timer (SRT(S,G)) This timer controls when State Refresh messages are generated. The timer is initially set when that Origination(S,G) state machine transitions to the O state. It is cancelled when the Origination(S,G) state machine transitions to the NO state. This timer is normally set to StateRefreshInterval (see 4.8).
ステートリフレッシュメッセージが生成されている状態リフレッシュタイマ（SRT（S、G））このタイマーを制御します。タイマーは、最初にO状態のときに発信（S、G）ステートマシン遷移を設定されています。それがキャンセルされたときにNO状態に発信（S、G）ステートマシン遷移します。このタイマは、通常StateRefreshInterval（4.8を参照）に設定されています。
Source Active Timer (SAT(S,G)) This timer is first set when the Origination(S,G) state machine transitions to the O state and is reset on the receipt of every data packet from S addressed to group G. When it expires, the Origination(S,G) state machine transitions to the NO state. This timer is normally set to SourceLifetime (see 4.8).
ときソースアクティブタイマ（SAT（S、G））このタイマが第1の設定とき発信（S、G）ステートマシン遷移O状態にあり、Sからすべてのデータパケットの受信時にリセットされるグループG宛てNO状態に発信（S、G）ステートマシン遷移は、有効期限が切れます。このタイマは、通常SourceLifetime（4.8を参照）に設定されています。
+-------------+ Rcv Directly From S +-------------+
| |----------------------->| |
|NotOriginator| | Originator |
| |<-----------------------| |
+-------------+ SAT Expires OR +-------------+
S NOT Direct Connect
Figure 3: State Refresh State Machine
図3：ステートリフレッシュステートマシン
In tabular form, the state machine is defined as follows:
次のように表形式で、状態マシンに定義されます。
+----------------------------------------------------------------------+
| | Previous State |
| +---------------+-------------------+
| Event | NotOriginator | Originator |
+----------------------------------+---------------+-------------------+
| Receive Data from S AND | ->O | ->O Reset |
| S directly connected | Set SRT(S,G) | SAT(S,G) |
| | Set SAT(S,G) | |
+----------------------------------+---------------+-------------------+
| SRT(S,G) Expires | N/A | ->O Send |
| | | StateRefresh(S,G) |
| | | Reset SRT(S,G) |
+----------------------------------+---------------+-------------------+
| SAT(S,G) Expires | N/A | ->NO Cancel |
| | | SRT(S,G) |
+----------------------------------+---------------+-------------------+
| S no longer directly connected | ->NO | ->NO |
| | | Cancel SRT(S,G) |
| | | Cancel SAT(S,G) |
+----------------------------------+---------------+-------------------+
When the Originating(S,G) state machine is in the NotOriginator (NO) state, the following event may trigger a transition:
発信元（S、G）ステートマシンはNotOriginator（NO）状態にある場合、次のイベントが遷移をトリガすることができます。
Data Packet received from directly connected Source S addressed to group G The router MUST transition to an Originator (O) state, set SAT(S,G) to SourceLifetime, and set SRT(S,G) to StateRefreshInterval. The router SHOULD record the TTL of the packet for use in State Refresh messages.
直接接続されたソースSがSourceLifetimeに発信（O）状態、設定SAT（S、G）に移行し、そしてStateRefreshIntervalにSRT（S、G）を設定しなければならないルータGグループ宛のデータパケットが受信されました。ルータは、ステートリフレッシュメッセージで使用するためのパケットのTTLを記録する必要があります。
When the Originating(S,G) state machine is in the Originator (O) state, the following events may trigger a transition:
発信元（S、G）ステートマシンは、オリジネータ（O）状態にある場合、以下のイベントが遷移をトリガすることができます。
Receive Data Packet from S addressed to G The router remains in the Originator (O) state and MUST reset SAT(S,G) to SourceLifetime. The router SHOULD increase its recorded TTL to match the TTL of the packet, if the packet's TTL is larger than the previously recorded TTL. A router MAY record the TTL based on an implementation specific sampling policy to avoid examining the TTL of every multicast packet it handles.
Sからデータパケットを受信すると、ルータは、発信元（O）状態のままとSourceLifetimeにSAT（S、G）をリセットする必要がありG宛て。ルータは、パケットのTTLは、以前に記録されたTTLよりも大きい場合には、パケットのTTLを一致させるためにその記録TTLを増やす必要があります。ルータは、それが扱うすべてのマルチキャストパケットのTTLを調べる避けるために、実装固有のサンプリング・ポリシーに基づいてTTLを記録することができます。
SRT(S,G) Expires The router remains in the Originator (O) state and MUST reset SRT(S,G) to StateRefreshInterval. The router MUST also generate State Refresh messages for transmission, as described in the State Refresh Forwarding rules (Section 4.5.1), except for the TTL. If the TTL of data packets from S to G are being recorded, then the TTL of each State Refresh message is set to the highest recorded TTL. Otherwise, the TTL is set to the configured State Refresh TTL. Let I denote the interface over which a State Refresh message is being sent. If the Prune(S,G) Downstream state machine is in the Pruned (P) state, then the Prune-Indicator bit MUST be set to 1 in the State Refresh message being sent over I. Otherwise, the Prune-Indicator bit MUST be set to 0.
SRT（S、G）は、ルータが発信（O）状態のままとStateRefreshIntervalにSRT（S、G）をリセットしなければならない期限。 TTLを除いて、ステートリフレッシュ転送ルール（セクション4.5.1）に記載されているように、ルータはまた、送信のために状態更新メッセージを生成しなければなりません。 SからGへのデータパケットのTTLが記録されている場合、各状態更新メッセージのTTLは、最高記録TTLに設定されています。それ以外の場合は、TTLを設定ステートリフレッシュTTLに設定されています。私はステートリフレッシュメッセージが送信されている上のインタフェースを示すものとします。プルーン（S、G）ダウンストリーム状態マシンは剪定（P）状態である場合には、プルーン・インジケータビットは、そうでない場合I.上に送信される状態更新メッセージに1に設定しなければなりません、プルーン・インジケータビットでなければなりません0に設定します。
SAT(S,G) Expires The router MUST cancel the SRT(S,G) timer and transition to the NotOriginator (NO) state.
SAT（S、G）は、ルータがSRT（S、G）NotOriginator（NO）状態にタイマおよび遷移をキャンセルしなければならない期限。
S is no longer directly connected The router MUST transition to the NotOriginator (NO) state and cancel both the SAT(S,G) and SRT(S,G).
Sは、もはや直接ルータがNotOriginator（NO）状態に移行し、SAT（S、G）及びSRT（S、G）の両方をキャンセルする必要があります接続されていません。
Assert metrics are defined as follows:
次のようにアサートメトリックが定義されています。
struct assert_metric {
metric_preference;
route_metric;
ip_address;
};
When assert_metrics are compared, the metric_preference and route_metric field are compared in order, where the first lower value wins. If all fields are equal, the IP address of the router that sourced the Assert message is used as a tie-breaker, with the highest IP address winning.
assert_metricsを比較すると、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 by 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,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、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_addr(I)} }
assert_metric spt_assert_metric（S、I）{リターン{0、MRIB.pref（S）、MRIB.metric（S）、my_addr（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_addr(I) is simply the router's network (e.g., IP) address associated with the local interface I.
MRIB.pref（X）とMRIB.metric（X）はMRIBによって決定されるように、特定の（ユニキャスト）宛先Xまでの経路に関連付けられたルーティング選好とルーティングメトリックです。 my_addr（I）は、単にローカルインタフェースI.に関連付けられているルータのネットワーク（例えば、IP）アドレスであります
infinite_assert_metric() gives the Assert metric we need to send an Assert but doesn't match (S,G) forwarding state:
infinite_assert_metricは（）私たちはアサートを送信する必要があるが、（S、G）転送状態と一致していないアサートメトリックを提供します：
assert_metric infinite_assert_metric() { return {1,infinity,infinity,0} }
assert_metric infinite_assert_metric（）{リターン{1、無限大、無限大、0}}
An AssertCancel(S,G) message is simply an Assert message for (S,G) with infinite metric. The Assert winner sends this message when it changes its upstream interface to this interface. Other routers will see this metric, causing those with forwarding state to send their own Asserts and re-establish an Assert winner.
AssertCancel（S、G）メッセージは、単に無限のメトリックの（S、G）のためのアサート・メッセージです。それは、このインターフェイスにその上流のインタフェースを変更したときにアサート勝者はこのメッセージを送信します。他のルータはアサートとアサート勝者を再確立し、独自のを送信するためにフォワーディング状態にそれらを引き起こし、このメトリックが表示されます。
AssertCancel messages are simply an optimization. The original Assert timeout mechanism will eventually allow a subnet to become consistent; the AssertCancel mechanism simply causes faster convergence. No special processing is required for an AssertCancel message, as it is simply an Assert message from the current winner.
AssertCancelメッセージは単純に最適化されています。オリジナルのアサートタイムアウトメカニズムは、最終的にサブネットが一貫になることができます。 AssertCancelメカニズムは、単により速い収束が発生します。それは単に現在の勝者からアサート・メッセージであるとして特別な処理は、AssertCancelメッセージのために必要とされません。
The macro lost_assert(S,G,I), is used in the olist computations of Section 4.1.3, and is defined as follows:
マクロlost_assert（S、Gは、I）、セクション4.1.3のOLIST計算で使用され、そして以下のように定義されます。
bool lost_assert(S,G,I) { if ( RPF_interface(S) == I ) { return FALSE } else { return (AssertWinner(S,G,I) != me AND (AssertWinnerMetric(S,G,I) is better than spt_assert_metric(S,G,I))) } }
ブールlost_assert（S、G、I）{（RPF_interface（S）== I）{FALSEを返す}他{リターン（AssertWinner（S、G、I）！=私AND（AssertWinnerMetric（S、G、I）である場合spt_assert_metricよりも良好な（S、G、I）））}}
AssertWinner(S,G,I) defaults to NULL, and AssertWinnerMetric(S,G,I) defaults to Infinity when in the NoInfo state.
無限大にNULLにAssertWinner（S、G、I）デフォルト値、及びAssertWinnerMetric（S、G、I）デフォルト場合NoInfo状態です。
The (S,G) Assert state machine for interface I is shown in Figure 4. There are three states:
（S、G）界面Iのための状態機械をアサート3つの状態があり、図4に示されています。
NoInfo (NI) This router has no (S,G) Assert state on interface I.
NoInfo（NI）は、このルータは、インタフェースI.でない（S、G）をアサート状態を有します
I am Assert Winner (W) This router has won an (S,G) Assert on interface I. It is now responsible for forwarding traffic from S destined for G via interface I.
私はそれが今、インタフェースI.経由G宛てSからのトラフィックを転送する責任がある。このルータは（S、G）獲得した受賞（W）をアサートインタフェースI.上でアサートしています
I am Assert Loser (L) This router has lost an (S,G) Assert on interface I. It must not forward packets from S destined for G onto interface I.
私はそれは、インタフェースI.上にG宛てSからのパケットを転送してはならない。このルータは（S、G）が失われた敗者（L）をアサートインタフェースI.上でアサートしています
In addition, an Assert Timer (AT(S,G,I)) is used to time out the Assert state.
加えて、アサートタイマー（AT（S、G、I））がアサート状態タイムアウトに使用されます。
+-------------+ +-------------+
| | Rcv Pref Assert or SR | |
| Winner |----------------------->| Loser |
| | | |
+-------------+ +-------------+
^ | ^ |
| | Rcv Pref Assert or| |
| |AT Expires OR State Refresh| |
| |CouldAssert->FALSE | |
| | | |
| | +-------------+ | |
| +-------->| |----------+ |
| | No Info | |
+-------------| |<-------------+
Rcv Data from dnstrm +-------------+ Rcv Inf Assert from Win OR
OR Rcv Inferior Assert Rcv Inf SR from Winner OR
OR Rcv Inferior SR AT Expires OR
CouldAssert Changes OR
Winner's NLT Expires
Figure 4: Assert State Machine
図4：ステートマシンをアサート
In tabular form, the state machine is defined as follows:
次のように表形式で、状態マシンに定義されます。
+-------------------------------+--------------------------------------+
| | Previous State |
| +------------+------------+------------+
| Event | No Info | Winner | Loser |
+-------------------------------+------------+------------+------------+
| An (S,G) Data packet received | ->W Send | ->W Send | ->L |
| on downstream interface | Assert(S,G)| Assert(S,G)| |
| | Set | Set | |
| | AT(S,G,I) | AT(S,G,I) | |
+-------------------------------+--------------------------------------+
| Receive Inferior (Assert OR | N/A | N/A |->NI Cancel |
| State Refresh) from Assert | | | AT(S,G,I) |
| Winner | | | |
+-------------------------------+--------------------------------------+
| Receive Inferior (Assert OR | ->W Send | ->W Send | ->L |
| State Refresh) from non-Assert| Assert(S,G)| Assert(S,G)| |
| Winner AND CouldAssert==TRUE | Set | Set | |
| | AT(S,G,I) | AT(S,G,I) | |
+-------------------------------+--------------------------------------+
+-------------------------------+--------------------------------------+
| | Previous State |
| +------------+------------+------------+
| Event | No Info | Winner | Loser |
+-------------------------------+------------+------------+------------+
| Receive Preferred Assert OR | ->L Send | ->L Send | ->L Set |
| State Refresh | Prune(S,G) | Prune(S,G) | AT(S,G,I) |
| | Set | Set | |
| | AT(S,G,I) | AT(S,G,I) | |
+-------------------------------+--------------------------------------+
| Send State Refresh | ->NI | ->W Reset | N/A |
| | | AT(S,G,I) | |
+-------------------------------+--------------------------------------+
| AT(S,G) Expires | N/A | ->NI | ->NI |
+-------------------------------+--------------------------------------+
| CouldAssert -> FALSE | ->NI |->NI Cancel |->NI Cancel |
| | | AT(S,G,I) | AT(S,G,I) |
+-------------------------------+--------------------------------------+
| CouldAssert -> TRUE | ->NI | N/A |->NI Cancel |
| | | | AT(S,G,I) |
+-------------------------------+--------------------------------------+
| Winner's NLT(N,I) Expires | N/A | N/A |->NI Cancel |
| | | | AT(S,G,I) |
+-------------------------------+--------------------------------------+
| Receive Prune(S,G), Join(S,G) | ->NI | ->W | ->L Send |
| or Graft(S,G) | | | Assert(S,G)|
+-------------------------------+--------------------------------------+
Terminology: A "preferred assert" is one with a better metric than the current winner. An "inferior assert" is one with a worse metric than my_assert_metric(S,G,I).
用語：「優先アサート」は、現在の勝者より良いメトリックを有するものです。 「劣っアサートが」my_assert_metric（S、G、I）よりも悪いメトリックを有するものです。
The state machine uses the following macro:
ステートマシンは、次のマクロを使用しています：
CouldAssert(S,G,I) = (RPF_interface(S) != I)
CouldAssert（S、G、I）=（RPF_interface（S）！= I）
In the NoInfo state, the following events may trigger transitions:
NoInfo状態では、次のイベントは、トランジションをトリガー可能性があります。
An (S,G) data packet arrives on downstream interface I An (S,G) data packet arrived on a downstream interface. It is optimistically assumed that this router will be the Assert winner for this (S,G). The Assert state machine MUST transition to the "I am Assert Winner" state, send an Assert(S,G) to interface I, store its own address and metric as the Assert Winner, and set the Assert_Timer (AT(S,G,I) to Assert_Time, thereby initiating the Assert negotiation for (S,G).
（S、G）データパケットは、私は（S、G）データパケットがダウンストリームインターフェースに到着下流インタフェースに到着します。楽観このルータは、この（S、G）のためのAssert勝者になることが想定されます。アサート状態マシンは、Assert_Timer（AT（S、Gを、「私はアサート勝者午前」状態に遷移アサート（S、G）は、IのインタフェースのAssert勝者として自身のアドレスと、メトリックを格納するために送信し、設定しなければなりませんI）はAssert_Timeに、それによって（S、G）のためのアサートネゴシエーションを開始します。
Receive Inferior (Assert OR State Refresh) AND CouldAssert(S,G,I)==TRUE An Assert or State Refresh is received for (S,G) that is inferior to our own assert metric on interface I. The Assert state machine MUST transition to the "I am Assert Winner" state, send an Assert(S,G) to interface I, store its own address and metric as the Assert Winner, and set the Assert Timer (AT(S,G,I)) to Assert_Time.
（アサートORステートリフレッシュ）AND CouldAssert（S、G、I）== TRUEアンアサートまたはステートリフレッシュ劣るが、インタフェースI.アサート状態マシンMUSTの上に私たち自身のassertメトリックに劣っている（S、G）のために受信された受信します「私がアサート勝者午前」状態への遷移、アサート（S、G）は、IのインタフェースのAssert勝者として自身のアドレスと、メトリックを格納し、アサートタイマー（AT（S、G、I））とを設定する送信Assert_Time。
Receive Preferred Assert or State Refresh The received Assert or State Refresh has a better metric than this router's, and therefore the Assert state machine MUST transition to the "I am Assert Loser" state and store the Assert Winner's address and metric. If the metric was received in an Assert, the router MUST set the Assert Timer (AT(S,G,I)) to Assert_Time. If the metric was received in a State Refresh, the router MUST set the Assert Timer (AT(S,G,I)) to three times the received State Refresh Interval. If CouldAssert(S,G,I) == TRUE, the router MUST also multicast a Prune(S,G) to the Assert winner with a Prune Hold Time equal to the Assert Timer and evaluate any changes in its Upstream(S,G) state machine.
受信優先アサートまたはステートリフレッシュザ・はアサートまたはステートリフレッシュが良いメトリックこのルータのより持っ受け、そのためのAssert州のマシンは、「私は敗者をアサートしています」状態に遷移し、アサート受賞者のアドレスとメトリックを保存しなければなりません。メトリックがアサートで受信された場合、ルータはAssert_Timeにアサートタイマー（AT（S、G、I））を設定しなければなりません。メトリックは、ステートリフレッシュに受信された場合、ルータは3回受信した状態更新間隔にアサートタイマー（AT（S、G、I））を設定しなければなりません。 CouldAssert（S、G、I）== TRUEの場合、ルータはまた、アサートタイマーに等しい時間を持ち、その上流（S、Gの任意の変化を評価プルーンとアサートの勝者にプルーン（S、G）をマルチキャストしなければなりません）ステートマシン。
When in "I am Assert Winner" state, the following events trigger transitions:
状態「私がアサート受賞しています」と、次のイベントが遷移をトリガ：
An (S,G) data packet arrives on downstream interface I An (S,G) data packet arrived on a downstream interface. The Assert state machine remains in the "I am Assert Winner" state. The router MUST send an Assert(S,G) to interface I and set the Assert Timer (AT(S,G,I) to Assert_Time.
（S、G）データパケットは、私は（S、G）データパケットがダウンストリームインターフェースに到着下流インタフェースに到着します。アサートステートマシンは「私は勝者をアサートしています」状態のまま。ルータはIのインターフェースとAssert_Timeにアサートタイマ（AT（S、G、I）を設定するためにアサート（S、G）を送信しなければなりません。
Receive Inferior Assert or State Refresh An (S,G) Assert is received containing a metric for S that is worse than this router's metric for S. Whoever sent the Assert is in error. The router MUST send an Assert(S,G) to interface I and reset the Assert Timer (AT(S,G,I)) to Assert_Time.
劣っアサートまたはステートリフレッシュアン（S、G）を受信アサートがアサートを送っ誰S.のため、このルータのメトリックよりも悪いSのメトリックを含む受信されたエラーです。ルータはIのインターフェースとAssert_Timeにアサートタイマ（AT（S、G、I））をリセットするためにアサート（S、G）を送信しなければなりません。
Receive Preferred Assert or State Refresh An (S,G) Assert or State Refresh is received that has a better metric than this router's metric for S on interface I. The Assert state machine MUST transition to "I am Assert Loser" state and store the new Assert Winner's address and metric. If the metric was received in an Assert, the router MUST set the Assert Timer (AT(S,G,I)) to Assert_Time. If the metric was received in a State Refresh, the router MUST set the Assert Timer (AT(S,G,I)) to three times the State Refresh Interval. The router MUST also multicast a Prune(S,G) to the Assert winner, with a Prune Hold Time equal to the Assert Timer, and evaluate any changes in its Upstream(S,G) state machine.
受信優先アサートまたはステートリフレッシュアン（S、G）アサートまたはステートリフレッシュがアサート状態マシンが状態「私は敗者をアサートしています」と格納に遷移しなければならない、より良いメトリックインターフェースI.上のSのために、このルータのメトリックよりも持っているが受信されます新しいアサート受賞者のアドレスとメトリック。メトリックがアサートで受信された場合、ルータはAssert_Timeにアサートタイマー（AT（S、G、I））を設定しなければなりません。メトリックは、ステートリフレッシュに受信された場合、ルータは三回国家更新間隔にアサートタイマー（AT（S、G、I））を設定しなければなりません。ルータはまた、アサートタイマーに等しいプルーン保持時間で、アサート勝者にプルーン（S、G）をマルチキャスト、およびその上流（S、G）ステートマシンの任意の変化を評価しなければなりません。
Send State Refresh The router is sending a State Refresh(S,G) message on interface I. The router MUST set the Assert Timer (AT(S,G,I)) to three times the State Refresh Interval contained in the State Refresh(S,G) message.
ステートリフレッシュルータはインターフェイスI.上ステートリフレッシュ（S、G）メッセージを送信しているを送信ステートリフレッシュに含まれている3回国家更新間隔に（（S、G、I）AT）アサートタイマーを設定しなければなりませんルータ（ S、G）メッセージ。
AT(S,G,I) Expires The (S,G) Assert Timer (AT(S,G,I)) expires. The Assert state machine MUST transition to the NoInfo (NI) state.
AT（S、G、I）（S、G）をアサートタイマ（AT（S、G、I））が満了する期限。アサート状態マシンはNoInfo（NI）状態に移行しなければなりません。
CouldAssert(S,G,I) -> FALSE This router's RPF interface changed, making CouldAssert(S,G,I) false. This router can no longer perform the actions of the Assert winner, so the Assert state machine MUST transition to NoInfo (NI) state, send an AssertCancel(S,G) to interface I, cancel the Assert Timer (AT(S,G,I)), and remove itself as the Assert Winner.
CouldAssert（S、G、I） - > FALSEこのルータのRPFインターフェイスはCouldAssert（S、G、I）はfalseを作り、変更しました。 、アサートタイマー（AT（S、Gを、キャンセル、IをインタフェースするAssertCancel（S、G）を送るこのルータは、もはやアサート勝者のアクションを実行することはできませんので、アサート状態マシンはNoInfo（NI）状態に移行しなければなりませんI））、およびアサート受賞として自分自身を削除します。
When in "I am Assert Loser" state, the following transitions can occur:
状態「私は敗者をアサートしています」ときで、次の遷移が発生する可能性があります。
Receive Inferior Assert or State Refresh from Current Winner An Assert or State Refresh is received from the current Assert winner that is worse than this router's metric for S (typically, the winner's metric became worse). The Assert state machine MUST transition to NoInfo (NI) state and cancel AT(S,G,I). The router MUST delete the previous Assert Winner's address and metric and evaluate any possible transitions to its Upstream(S,G) state machine. Usually this router will eventually re-assert and win when data packets from S have started flowing again.
現在の受賞アンアサートから下位アサートまたはステートリフレッシュを受け取るか、ステートリフレッシュがSのために、このルータのメトリック（通常は、勝者のメトリックが悪化した）よりも悪化している現在のアサートを受賞から受信されます。アサート状態マシンはNoInfo（NI）状態に移行し、AT（S、G、I）をキャンセルしなければなりません。ルータは、以前のAssert勝者のアドレスとメトリックを削除し、その上流（S、G）ステートマシンにすべての可能な遷移を評価しなければなりません。通常、このルータは、最終的にアサートを再し、Sからのデータパケットが再び流れ始めた時に獲得します。
Receive Preferred Assert or State Refresh An Assert or State Refresh is received that has a metric better than or equal to that of the current Assert winner. The Assert state machine remains in Loser (L) state. If the metric was received in an Assert, the router MUST set the Assert Timer (AT(S,G,I)) to Assert_Time. If the metric was received in a State Refresh, the router MUST set the Assert Timer (AT(S,G,I)) to three times the received State Refresh Interval. If the metric is better than the current Assert Winner, the router MUST store the address and metric of the new Assert Winner, and if CouldAssert(S,G,I) == TRUE, the router MUST multicast a Prune(S,G) to the new Assert winner.
優先アサートまたはステートリフレッシュアンアサートまたはステートリフレッシュ受信がより良いメトリックまたは現在のAssertの勝者と同等のを持っているが受信されます。アサート状態マシンは敗者（L）状態のままです。メトリックがアサートで受信された場合、ルータはAssert_Timeにアサートタイマー（AT（S、G、I））を設定しなければなりません。メトリックは、ステートリフレッシュに受信された場合、ルータは3回受信した状態更新間隔にアサートタイマー（AT（S、G、I））を設定しなければなりません。メトリックは、現在のAssert勝者よりも優れている場合、ルータはアドレスと新しいのAssert勝者のメトリックを保存しなければなりませんし、== TRUE CouldAssert（S、G、I）場合、ルータは、マルチキャストなければならプルーン（S、G）新しいアサート勝者へ。
AT(S,G,I) Expires The (S,G) Assert Timer (AT(S,G,I)) expires. The Assert state machine MUST transition to NoInfo (NI) state. The router MUST delete the Assert Winner's address and metric. If CouldAssert == TRUE, the router MUST evaluate any possible transitions to its Upstream(S,G) state machine.
AT（S、G、I）（S、G）をアサートタイマ（AT（S、G、I））が満了する期限。アサート状態マシンはNoInfo（NI）状態に移行しなければなりません。ルータがアサート受賞者のアドレスとメトリックを削除しなければなりません。 CouldAssert == TRUEの場合、ルータはその上流（S、G）ステートマシンにすべての可能な遷移を評価しなければなりません。
CouldAssert -> FALSE CouldAssert has become FALSE because interface I has become the RPF interface for S. The Assert state machine MUST transition to NoInfo (NI) state, cancel AT(S,G,I), and delete information concerning the Assert Winner on I.
CouldAssert - 私はS.ザアサート状態機械のRPFインターフェイスとなっているインターフェイスは、NoInfo（NI）状態に遷移AT（S、G、I）をキャンセルし、上でアサート勝者に関する情報を削除しなければならないので> FALSE CouldAssertはFALSEとなっています私。
CouldAssert -> TRUE CouldAssert has become TRUE because interface I used to be the RPF interface for S, and now it is not. The Assert state machine MUST transition to NoInfo (NI) state, cancel AT(S,G,I), and delete information concerning the Assert Winner on I.
CouldAssert - >インタフェースは、私がSのためのRPFインターフェイスであるために使用されるので、TRUE CouldAssertがTRUEになってきた、そして今ではありません。アサート状態マシンは、NoInfo（NI）状態に遷移AT（S、G、I）をキャンセルし、I.上のAssert勝者に関する情報を削除する必要があります
Current Assert Winner's NeighborLiveness Timer Expires The current Assert winner's NeighborLiveness Timer (NLT(N,I)) has expired. The Assert state machine MUST transition to the NoInfo (NI) state, delete the Assert Winner's address and metric, and evaluate any possible transitions to its Upstream(S,G) state machine.
現在のAssert勝者のNeighborLivenessタイマーは、現在のAssertの勝者のNeighborLivenessタイマー（NLT（N、I））が経過した有効期限。アサート状態マシンは、NoInfo（NI）状態に遷移アサート受賞者のアドレスとメトリックを削除し、その上流（S、G）ステートマシンに任意の可能な遷移を評価しなければなりません。
Receive Prune(S,G), Join(S,G), or Graft(S,G) A Prune(S,G), Join(S,G), or Graft(S,G) message was received on interface I with its upstream neighbor address set to the router's address on I. The router MUST send an Assert(S,G) on the receiving interface I to initiate an Assert negotiation. The Assert state machine remains in the Assert Loser(L) state. If a Graft(S,G) was received, the router MUST respond with a GraftAck(S,G).
私はプルーン（S、G）を受信し、（S、G）に参加、または移植片（S、G）Aプルーン（S、G）、（S、G）に参加、または移植片（S、G）メッセージがインターフェイスで受信しましたその上流隣接アドレスがI.上のルータのアドレスに設定してルータがアサートネゴシエーションを開始する受信インタフェースIにアサート（S、G）を送信しなければなりません。アサート状態マシンはアサート敗者（L）状態のままです。グラフト（S、G）を受信した場合、ルータはGraftAck（S、G）で応答しなければなりません。
The following is a summary of the rules for generating and processing Assert messages. It is not intended to be definitive (the state machines and pseudocode provide the definitive behavior). Instead, it provides some rationale for the behavior.
以下は、アサートメッセージを生成し、処理するためのルールをまとめたものです。 （ステートマシンと擬似コードは決定的な動作を提供します）決定的であることを意図したものではありません。代わりに、それは行動のためのいくつかの理論的根拠を提供します。
1. The Assert winner for (S,G) must act as the local forwarder for (S,G) on behalf of all downstream members. 2. PIM messages are directed to the RPF' neighbor and not to the regular RPF neighbor. 3. An Assert loser that receives a Prune(S,G), Join(S,G), or Graft(S,G) directed to it initiates a new Assert negotiation so that the downstream router can correct its RPF'(S). 4. An Assert winner for (S,G) sends a cancelling assert when it is about to stop forwarding on an (S,G) entry. Example: If a router is being taken down, then a canceling assert is sent.
1.（S、G）のためのAssertの勝者は、すべての下流のメンバーを代表して（S、G）のためのローカルフォワーダとして行動しなければなりません。 2. PIMメッセージがRPF」隣人にしていない通常のRPF隣人に向けられています。 3.プルーン（S、G）を受信アンアサート敗者、（S、G）に参加、または移植片（S、G）下流ルータがRPF '（S）を補正することができるように、それは新しいアサートネゴシエーションを開始するように指示。 （S、G）エントリに転送を停止しようとしている場合（S、G）4.アンアサート勝者はキャンセルアサートを送信します。例：ルータがダウン取られている場合は、キャンセルアサートが送信されます。
All PIM-DM packets use the same format as PIM-SM packets. In the event of a discrepancy, PIM-SM [4] should be considered the definitive specification. All PIM control messages have IP protocol number 103. All PIM-DM messages MUST be sent with a TTL of 1. All PIM-DM messages except Graft and Graft Ack messages MUST be sent to the ALL-PIM-ROUTERS group. Graft messages SHOULD be unicast to the RPF'(S). Graft Ack messages MUST be unicast to the sender of the Graft.
すべてのPIM-DMのパケットは、PIM-SMパケットと同じ形式を使用します。不一致の場合には、PIM-SM [4]決定的な仕様を考慮すべきです。すべてのPIM制御メッセージは、IPプロトコル番号103の全PIM-DMメッセージがALL-PIM-ルータグループに送信されなければならない移植片および移植片のAckメッセージを除く1.すべてのPIM-DMメッセージのTTLで送らなければなりません有します。移植片のメッセージがRPF '（S）にユニキャストされるべきである（SHOULD）。グラフトACKメッセージは、移植片の送信元にユニキャストされなければなりません。
The IPv4 ALL-PIM-ROUTERS group is 224.0.0.13. The IPv6 ALL-PIM-ROUTERS group is 'ff02::d'.
IPv4のALL-PIM-ROUTERSグループが224.0.0.13です。 IPv6のALL-PIM-ROUTERSグループは、 'FF02 :: D' です。
All PIM control messages have the following header:
すべての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. Available types are as follows: 0 = Hello 1 = Register (PIM-SM only) 2 = Register Stop (PIM-SM only) 3 = Join/Prune 4 = Bootstrap (PIM-SM only) 5 = Assert 6 = Graft 7 = Graft Ack 8 = Candidate RP Advertisement (PIM-SM only) 9 = State Refresh
特定のPIMメッセージの種類を入力します。次のように利用可能なタイプがある：0 =ハロー1 =レジスタ（PIM-SMのみ）2 =停止レジスタ（PIM-SMのみ）3 =参加/プルーン4 =ブートストラップ（PIM-SMのみ）5 =アサート6 =グラフト7 =グラフトのAck 8 =候補RP広告（PIM-SMのみ）9 =ステートリフレッシュ
Reserved Set to zero on transmission. Ignored upon receipt.
送信時にゼロに設定された予約。受信時に無視されます。
Checksum The checksum is the standard IP checksum; i.e., the 16 bit one's complement of the one's complement sum of the entire PIM message. For computing checksum, the checksum field is zeroed.
チェックサムは、チェックサムは、標準のIPチェックサムです。すなわち、全体のPIMメッセージの1の補数和の16ビットの1の補数。チェックサムを計算するために、チェックサムフィールドがゼロにされます。
For IPv6, the checksum also includes the IPv6 "pseudo-header", as specified in RFC 2460, Section 8.1 [5].
RFC 2460で指定されたIPv6のために、チェックサムはまた、IPv6の「擬似ヘッダ」を含む、セクション8.1 [5]。
An Encoded Unicast Address has 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. Values 0 - 127 are as assigned by the IANA for Internet Address Families in [9]. Values 128 - 250 are reserved to be assigned by the IANA for PIM specific Address Families. Values 251 - 255 are designated for private use. As there is no assignment authority for this space; collisions should be expected.
ADDR家族このアドレスの「ユニキャストアドレス」欄のPIMアドレスファミリ。値0 - [9]でインターネットアドレスファミリのためにIANAによって割り当てられるように127です。 128の値 - 250は、PIM特定のアドレスファミリのためにIANAによって割り当てられるように予約されています。 255私的使用のために指定されている - 251は値。このスペースには、割り当て権限がありませんよう。衝突が予想されなければなりません。
Encoding Type The type of encoding used with 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.
与えられたアドレスファミリとエンコードタイプで表されるようにユニキャストユニキャストアドレスです。
An Encoded Group address has 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 As described above.
ADDR家族としては、前述しました。
Encoding Type As described above.
上述したようなタイプをコードします。
B Indicates that the group range should use Bidirectional PIM [16]. Transmitted as zero; ignored upon receipt.
Bグループの範囲は、双方向PIM [16]を使用する必要があることを示します。ゼロとして送信されます。領収書で無視。
Reserved Transmitted as zero. Ignored upon receipt.
予約ゼロとして送信します。受信時に無視されます。
Z Indicates that the group range is an admin scope zone. This is used in the Bootstrap Router Mechanism [18] only. For all other purposes, this bit is set to zero and ignored on receipt.
Zは、グループ範囲は、管理スコープゾーンであることを示します。これが唯一のブートストラップルータのメカニズム[18]で使用されています。他のすべての目的のために、このビットがゼロに設定され、領収書の上で無視します。
Mask Len The mask length field is 8 bits. The value is the number of contiguous left justified one bits used as a mask, which, combined with the address, describes a range of addresses. 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 address then the mask length MUST equal the address length. PIM-DM routers MUST only send for a single address.
マスク長フィールドは8ビットであるレンマスク。値は、連続する左の数は、アドレスと組み合わされ、アドレスの範囲を説明し、マスクとして使用される1つのビットを正当化されます。これは、指定されたアドレスファミリとエンコードタイプのためのビットのアドレスの長さ以下です。メッセージが単一のアドレスに送信されている場合、マスクの長さは、アドレス長が等しくなければなりません。 PIM-DMルータは、単一のアドレスに送らなければなりません。
Group Multicast Address The address of the multicast group.
グループマルチキャストは、マルチキャストグループのアドレス。
An Encoded Source address has 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 As described above.
ADDR家族としては、前述しました。
Encoding Type As described above.
上述したようなタイプをコードします。
Rsrvd Reserved. Transmitted as zero. Ignored upon receipt.
Rsrvd予約。ゼロとして送信されます。受信時に無視されます。
S The Sparse Bit. Set to 0 for PIM-DM. Ignored upon receipt.
スパースビットは、S。 PIM-DMのために0に設定します。受信時に無視されます。
W The Wild Card Bit. Set to 0 for PIM-DM. Ignored upon receipt.
ワイルドカードビットW。 PIM-DMのために0に設定します。受信時に無視されます。
R The Rendezvous Point Tree bit. Set to 0 for PIM-DM. Ignored upon receipt.
ランデブーポイントツリーのビットをR。 PIM-DMのために0に設定します。受信時に無視されます。
Mask Len As described above. PIM-DM routers MUST only send for a single source address.
上述したようレンマスク。 PIM-DMルータは、単一の送信元アドレスのために送らなければなりません。
Source Address The source address.
ソースは、ソースアドレス。
The PIM Hello message, as defined by PIM-SM [4], has the following format:
PIM-SM [4]で定義されるようにPIM Helloメッセージは、次の形式を有します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Value |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Value |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Ver, Type, Reserved, Checksum Described above.
PIM版、タイプは、予約済み、チェックサムは、前述しました。
Option Type The type of option given in the Option Value field. Available types are as follows:
オプションは、オプション値]フィールドで指定したオプションの種類を入力します。次のように使用可能なタイプは次のとおりです。
0 Reserved
1 Hello Hold Time
2 LAN Prune Delay
3 - 16 Reserved
17 To be assigned by IANA
18 Deprecated and SHOULD NOT be used
19 DR Priority (PIM-SM Only)
20 Generation ID
21 State Refresh Capable
22 Bidir Capable
23 - 65000 To be assigned by IANA
65001 - 65535 Reserved for Private Use [9]
Unknown options SHOULD be ignored.
不明なオプションは無視されるべきです。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hold Time is the number of seconds a receiver MUST keep the neighbor reachable. If the Hold Time 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. Furthermore, if the Holdtime is set to '0', the information is timed out immediately. The Hello Hold Time option MUST be used by PIM-DM routers.
ホールド時間は、受信機が到達可能な隣人を維持しなければならない秒数です。隣人アウトホールド時間が「0xffffの」に設定されている場合は、このメッセージの受信者は決して回。これは、定期的にHelloメッセージでリンクを追いつい避けるために、ダイヤルオンデマンドリンクを使用することができます。ホールドタイムが「0」に設定されている場合、また、情報がすぐにタイムアウトしています。こんにちはホールド時間オプションはPIM-DMルータで使用されなければなりません。
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| LAN Prune Delay | Override Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The LAN_Prune_Delay option is used to tune the prune propagation delay on multi-access LANs. The T bit is used by PIM-SM and SHOULD be set to 0 by PIM-DM routers and ignored upon receipt. The LAN Delay and Override Interval fields are time intervals in units of milliseconds and are used to tune the value of the J/P Override Interval and its derived timer values. Section 4.3.5 describes how these values affect the behavior of a router. The LAN Prune Delay SHOULD be used by PIM-DM routers.
LAN_Prune_Delayオプションは、マルチアクセスLANのプルーンの伝播遅延を調整するために使用されます。 Tビットは、PIM-SMによって使用され、PIM-DMルータが0に設定され、受信時に無視されるべきです。 LAN遅延と間隔フィールドをオーバーライドミリ秒単位の時間間隔であり、J / Pオーバーライド間隔とその派生タイマ値の値を調整するために使用されています。 4.3.5項では、これらの値は、ルータの動作に影響を与える方法を説明します。 LANプルーン遅延は、PIM-DMルータで使用されるべきです。
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 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. The Generation ID option MAY be used by PIM-DM routers.
世代IDは、Helloメッセージが送信されたインターフェイスのためのランダム値です。 PIMフォワーディングがインターフェイス上で起動または再起動されるたびに生成IDが再生成されます。ジェネレーションIDオプションは、PIM-DMルータで使用されるかもしれません。
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 = 21 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version = 1 | Interval | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Interval field is the router's configured State Refresh Interval in seconds. The Reserved field is set to zero and ignored upon receipt. The State Refresh Capable option MUST be used by State Refresh capable PIM-DM routers.
Intervalフィールドには、秒単位でルータの設定済みステートリフレッシュ間隔です。予約フィールドはゼロに設定し、受信時に無視されます。ステートリフレッシュできるオプションは、ステートリフレッシュできるPIM-DMルータで使用されなければなりません。
PIM Join/Prune messages, as defined in PIM-SM [4], have the following format:
PIM-SMで定義されるようにPIM /プルーンメッセージに参加し[4]、次の形式を有します。
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 | Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Joined Source Address n (Encoded Source Format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pruned Source Address 1 (Encoded Source Format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pruned Source Address n (Encoded Source Format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Ver, Type, Reserved, Checksum Described above.
PIM版、タイプは、予約済み、チェックサムは、前述しました。
Upstream Neighbor Address The address of the upstream neighbor. The format for this address is given in the Encoded Unicast address in Section 4.7.2. PIM-DM routers MUST set this field to the RPF next hop.
上流の隣人は、上流の隣人のアドレス。このアドレスの形式は、セクション4.7.2でエンコードされたユニキャストアドレスに与えられています。 PIM-DMルータはRPFネクストホップにこのフィールドを設定しなければなりません。
Reserved Transmitted as zero. Ignored upon receipt.
予約ゼロとして送信します。受信時に無視されます。
Hold Time The number of seconds a receiving PIM-DM router MUST keep a Prune state alive, unless removed by a Join or Graft message. If the Hold Time is '0xffff', the receiver MUST NOT remove the Prune state unless a corresponding Join or Graft message is received. The Hold Time is ignored in Join messages.
参加またはグラフトメッセージによって除去されない限り時間を保持する秒数受信PIM-DMルータは、生きているプルーンの状態を維持しなければなりません。ホールド時間は「0xffffと」である場合、対応する参加またはグラフトメッセージが受信されない限り、受信機は、プルーンの状態を削除してはなりません。ホールド時間は、参加メッセージでは無視されます。
Number of Groups Number of multicast group sets contained in the message.
メッセージに含まれるマルチキャストグループセットのグループ数の数。
Multicast Group Address The multicast group address in the Encoded Multicast address format given in Section 4.7.3.
マルチキャストグループは、セクション4.7.3で与えられたエンコードされたマルチキャストアドレス形式でマルチキャストグループアドレス。
Number of Joined Sources Number of Join source addresses listed for a given group.
与えられたグループのためにリストされている送信元アドレスに参加する参加元数の数。
Number of Pruned Sources Number of Prune source addresses listed for a given group.
与えられたグループのためにリストされているプルーンソースアドレスの剪定源数の数。
Join Source Address 1..n This list contains the sources from which the sending router wishes to continue to receive multicast messages for the given group on this interface. The addresses use the Encoded Source address format given in Section 4.7.4.
このリストは、送信ルータは、このインターフェイス上の特定のグループのマルチキャストメッセージを受信するために継続したい、そこから情報源が含まれている1..Nソースアドレスに参加。アドレスは、セクション4.7.4で与えられた符号化されたソースアドレス形式を使用します。
Prune Source Address 1..n This list contains the sources from which the sending router does not wish to receive multicast messages for the given group on this interface. The addresses use the Encoded Source address format given in Section 4.7.4.
このリスト1..nのプルーンソースアドレスは、送信ルータは、このインターフェイス上の特定のグループのマルチキャストメッセージを受信したくないから、ソースが含まれています。アドレスは、セクション4.7.4で与えられた符号化されたソースアドレス形式を使用します。
PIM Assert Messages, as defined in PIM-SM [4], have the following format:
PIMアサートメッセージ、PIM-SMで定義されるように[4]は、次の形式を有します。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address (Encoded Group Format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address (Encoded Unicast Format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Metric Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Ver, Type, Reserved, Checksum Described above.
PIM版、タイプは、予約済み、チェックサムは、前述しました。
Multicast Group Address The multicast group address in the Encoded Multicast address format given in Section 4.7.3.
マルチキャストグループは、セクション4.7.3で与えられたエンコードされたマルチキャストアドレス形式でマルチキャストグループアドレス。
Source Address The source address in the Encoded Unicast address format given in Section 4.7.2.
ソースは、第4.7.2項で与えられたエンコードされたユニキャストアドレス形式の送信元アドレス。
R The Rendezvous Point Tree bit. Set to 0 for PIM-DM. Ignored upon receipt.
ランデブーポイントツリーのビットをR。 PIM-DMのために0に設定します。受信時に無視されます。
Metric Preference The preference value assigned to the unicast routing protocol that provided the route to the source.
メトリック好ましい源への経路を提供し、ユニキャストルーティングプロトコルに割り当てられた優先度値。
Metric The cost metric of the unicast route to the source. The metric is in units applicable to the unicast routing protocol used.
ソースへのユニキャストルートのメトリックコストメトリック。メトリックは、使用されるユニキャストルーティングプロトコルに適用単位です。
PIM Graft messages use the same format as Join/Prune messages, except that the Type field is set to 6. The source address MUST be in the Join section of the message. The Hold Time field SHOULD be zero and SHOULD be ignored when a Graft is received.
PIMグラフトメッセージは、Typeフィールドは、送信元アドレスは、メッセージの参加セクションでなければなりません6に設定されていることを除いて、参加/プルーンメッセージと同じフォーマットを使用します。ホールド時間フィールドはゼロでなければならず、移植片を受け取ったときに無視されるべきです。
PIM Graft Ack messages are identical in format to the received Graft message, except that the Type field is set to 7. The Upstream Neighbor Address field SHOULD be set to the sender of the Graft message and SHOULD be ignored upon receipt.
タイプフィールドが7に設定されている上流隣接アドレスフィールドがグラフトメッセージの送信者に設定されるべきであり、受信時に無視されるべき以外PIMグラフトACKメッセージは、受信されたグラフトメッセージにフォーマットにおいて同一です。
PIM State Refresh Messages have the following format:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address (Encoded Group Format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address (Encoded Unicast Format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address (Encoded Unicast Format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Metric Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Masklen | TTL |P|N|O|Reserved | Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Ver, Type, Reserved, Checksum Described above.
PIM版、タイプは、予約済み、チェックサムは、前述しました。
Multicast Group Address The multicast group address in the Encoded Multicast address format given in Section 4.7.3.
マルチキャストグループは、セクション4.7.3で与えられたエンコードされたマルチキャストアドレス形式でマルチキャストグループアドレス。
Source Address The address of the data source in the Encoded Unicast address format given in Section 4.7.2.
ソースは、第4.7.2項で与えられたエンコードされたユニキャストアドレス形式でデータソースのアドレス。
Originator Address The address of the first hop router in the Encoded Unicast address format given in Section 4.7.2.
発信者は、セクション4.7.2で与えられたエンコードされたユニキャストアドレス形式で最初のホップルータのアドレス。
R The Rendezvous Point Tree bit. Set to 0 for PIM-DM. Ignored upon receipt.
ランデブーポイントツリーのビットをR。 PIM-DMのために0に設定します。受信時に無視されます。
Metric Preference The preference value assigned to the unicast routing protocol that provided the route to the source.
メトリック好ましい源への経路を提供し、ユニキャストルーティングプロトコルに割り当てられた優先度値。
Metric The cost metric of the unicast route to the source. The metric is in units applicable to the unicast routing protocol used.
ソースへのユニキャストルートのメトリックコストメトリック。メトリックは、使用されるユニキャストルーティングプロトコルに適用単位です。
Masklen The length of the address mask of the unicast route to the source.
ソースへのユニキャスト経路のアドレスマスクの長さをMasklen。
TTL Time To Live of the State Refresh message. Decremented each time the message is forwarded. Note that this is different from the IP Header TTL, which is always set to 1.
TTL時間は、ステートリフレッシュメッセージを生きること。メッセージが転送されるたびにデクリメント。これは常に1に設定されているIPヘッダのTTLとは異なるので注意してください。
P Prune indicator flag. This MUST be set to 1 if the State Refresh is to be sent on a Pruned interface. Otherwise, it MUST be set to 0.
Pプルーンインジケータフラグ。ステートリフレッシュが剪定されたインターフェイス上で送信される場合、これは1に設定しなければなりません。それ以外の場合は、0に設定しなければなりません。
N Prune Now flag. This SHOULD be set to 1 by the State Refresh originator on every third State Refresh message and SHOULD be ignored upon receipt. This is for compatibility with earlier versions of state refresh.
Nプルーン今フラグ。これは、すべての第三ステートリフレッシュメッセージにステートリフレッシュ発信によって1に設定する必要があり、受信時に無視されるべきです。これは、状態リフレッシュの以前のバージョンとの互換性のためです。
O Assert Override flag. This SHOULD be set to 1 by upstream routers on a LAN if the Assert Timer (AT(S,G)) is not running and SHOULD be ignored upon receipt. This is for compatibility with earlier versions of state refresh.
O上書きフラグをアサートします。アサートタイマー（AT（S、G））が実行されていないと、受信時に無視されるべき場合、これはLAN上のアップストリームルータによって1に設定されるべきです。これは、状態リフレッシュの以前のバージョンとの互換性のためです。
Reserved Set to zero and ignored upon receipt.
予約はゼロに設定し、受信時に無視されます。
Interval Set by the originating router to the interval (in seconds) between consecutive State Refresh messages for this (S,G) pair.
この（S、G）ペアの連続したステートリフレッシュメッセージ間の間隔（秒単位）への発信側ルータによって設定された間隔。
PIM-DM maintains the following timers. 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 downward towards zero.
PIM-DMは、次のタイマーを維持します。すべてのタイマーはカウントダウンタイマーです - 彼らは、その時点で、彼らは一般的にアクションをトリガー、値に設定し、ゼロにカウントダウンされています。もちろん、彼らは同じように簡単に絶対満了時間は、リアルタイムクロックに対して記憶され、比較され、カウントアップタイマとして実施が、本明細書における言語は、それらがゼロに向かって下方にカウントと仮定することができます。
Global Timers Hello Timer: HT
グローバルタイマこんにちはタイマー：HT
Per interface (I): Per neighbor (N): Neighbor Liveness Timer: NLT(N,I)
隣人あたり（N）：：ネイバーライブネスタイマー：NLT（N、I）インターフェイス（I）あたり
Per (S,G) Pair: (S,G) Assert Timer: AT(S,G,I) (S,G) Prune Timer: PT(S,G,I) (S,G) PrunePending Timer: PPT(S,G,I)
当たり（S、G）ペア：（S、G）をアサートタイマー：PT（S、G、I）（S、G）PrunePendingタイマ：（S、G、I）（S、G）プルーンタイマAT PPT（ S、G、I）
Per (S,G) Pair: (S,G) Graft Retry Timer: GRT(S,G) (S,G) Upstream Override Timer: OT(S,G) (S,G) Prune Limit Timer: PLT(S,G) (S,G) Source Active Timer: SAT(S,G) (S,G) State Refresh Timer: SRT(S,G)
当たり（S、G）ペア：（S、G）グラフトリトライタイマー：GRT（S、G）（S、G）上流オーバーライドタイマ：OT（S、G）（S、G）プルーン制限タイマー：PLT（S 、G）（S、G）ソースアクティブタイマー：SAT（S、G）（S、G）ステートリフレッシュタイマ：SRT（S、G）
When timer values are started or restarted, they are set to default values. The following tables summarize those default values.
タイマ値が起動または再起動されると、それらはデフォルト値に設定されています。以下の表は、これらのデフォルト値をまとめたもの。
Timer Name: Hello Timer (HT)
+----------------------+--------+--------------------------------------+
| Value Name | Value | Explanation |
+----------------------+--------+--------------------------------------+
|Hello_Period | 30 sec | Periodic interval for hello messages |
+----------------------+--------+--------------------------------------+
|Triggered_Hello_Delay | 5 sec | Random interval for initial Hello |
| | | message on bootup or triggered Hello |
| | | message to a rebooting neighbor |
+----------------------+--------+--------------------------------------+
Hello messages are sent on every active interface once every Hello_Period seconds. 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).
helloメッセージは、すべてのHello_Period秒ごとにアクティブなインターフェイス上で送信されます。システムのパワーアップ時に、タイマが同期化を防ぐためのrand（0、Triggered_Hello_Delay）に初期化されます。新規または再起動ネイバーが検出されると、応答こんにちはは、ランド（0、Triggered_Hello_Delay）内で送信されます。
Timer Name: Neighbor Liveness Timer (NLT(N,I))
+-------------------+-----------------+--------------------------------+
| Value Name | Value | Explanation |
+-------------------+-----------------+--------------------------------+
| Hello Holdtime | From message | Hold Time from Hello Message |
+-------------------+-----------------+--------------------------------+
Timer Name: PrunePending Timer (PPT(S,G,I))
+-----------------------+---------------+------------------------------+
| Value Name | Value | Explanation |
+-----------------------+---------------+------------------------------+
| J/P_Override_Interval | OI(I) + PD(I) | Short time after a Prune to |
| | | allow other routers on the |
| | | LAN to send a Join |
+-----------------------+---------------+------------------------------+
The J/P_Override_Interval is the sum of the interface's Override_Interval (OI(I)) and Propagation_Delay (PD(I)). If all routers on a LAN are using the LAN Prune Delay option, both parameters MUST be set to the largest value on the LAN. Otherwise, the Override_Interval (OI(I)) MUST be set to 2.5 seconds, and the Propagation_Delay (PD(I)) MUST be set to 0.5 seconds.
J / P_Override_IntervalインターフェイスのOverride_Interval（OI（I））とPROPAGATION_DELAY（PD（I））の合計です。 LAN上のすべてのルータがLANプルーンDelayオプションを使用している場合は、両方のパラメータは、LAN上の最大値に設定しなければなりません。そうでない場合、Override_Interval（OI（I））は、2.5秒に設定しなければなりません、そしてPROPAGATION_DELAY（PD（I））は、0.5秒に設定しなければなりません。
Timer Name: Prune Timer (PT(S,G,I))
+----------------+----------------+------------------------------------+
| Value Name | Value | Explanation |
+----------------+----------------+------------------------------------+
| Prune Holdtime | From message | Hold Time read from Prune Message |
+----------------+----------------+------------------------------------+
Timer Name: Assert Timer (AT(S,G,I))
+--------------------------+---------+---------------------------------+
| Value Name | Value | Explanation |
+--------------------------+---------+---------------------------------+
| Assert Time | 180 sec | 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. If all members of a LAN are state refresh enabled, the Assert Time will be three times the received RefreshInterval(S,G).
歴史的な理由のために、アサートメッセージはホールドタイムフィールドを欠いていることに留意されたいです。このように、デフォルト値からアサート期間を変更することは推奨されません。 LANのすべてのメンバーが有効な状態リフレッシュされている場合は、アサート期間は3回受けRefreshInterval（S、G）となります。
Timer Name: Graft Retry Timer (GRT(S,G))
+--------------------+-------+-----------------------------------------+
| Value Name | Value | Explanation |
+--------------------+-------+-----------------------------------------+
| Graft_Retry_Period | 3 sec | In the absence of receipt of a GraftAck |
| | | message, the time before retransmission |
| | | of a Graft message |
+--------------------+-------+-----------------------------------------+
Timer Name: Upstream Override Timer (OT(S,G))
+------------+----------------+----------------------------------------+
| Value Name | Value | Explanation |
+------------+----------------+----------------------------------------|
| t_override | rand(0, OI(I)) | Randomized delay to prevent response |
| | | implosion when sending a join message |
| | | to override someone else's prune |
+------------+----------------+----------------------------------------+
t_override is a random value between 0 and the interface's Override_Interval (OI(I)). If all routers on a LAN are using the LAN Prune Delay option, the Override_Interval (OI(I)) MUST be set to the largest value on the LAN. Otherwise, the Override_Interval (OI(I)) MUST be set to 2.5 seconds.
t_overrideは0およびインターフェイスのOverride_Interval（OI（I））の間のランダムな値です。 LAN上のすべてのルータがLANプルーンDelayオプションを使用している場合は、Override_Interval（OI（I））は、LAN上の最大値に設定しなければなりません。それ以外の場合は、Override_Interval（OI（I））は2.5秒に設定しなければなりません。
Timer Name: Prune Limit Timer (PLT(S,G))
+------------+--------------------+------------------------------------+
| Value Name | Value | Explanation |
+------------+--------------------+------------------------------------|
| t_limit | Default: 210 secs | Used to prevent Prune storms on a |
| | | LAN |
+------------+--------------------+------------------------------------+
Timer Name: Source Active Timer (SAT(S,G))
+----------------+-------------------+---------------------------------+
| Value Name | Value | Explanation |
+----------------+-------------------+---------------------------------+
| SourceLifetime | Default: 210 secs | Period of time after receiving |
| | | a multicast message a directly |
| | | attached router will continue |
| | | to send State Refresh messages |
+----------------+-------------------+---------------------------------+
Timer Name: State Refresh Timer (SRT(S,G))
+-----------------+------------------+---------------------------------+
| Value Name | Value | Explanation |
+-----------------+------------------+---------------------------------+
| RefreshInterval | Default: 60 secs | Interval between successive |
| | | state refresh messages |
+-----------------+------------------+---------------------------------+
PIM-DM is designed to be independent of underlying unicast routing protocols and will interact only to the extent needed to perform RPF checks. It is generally assumed that multicast area and autonomous system boundaries will correspond to the same boundaries for unicast routing, though a deployment that does not follow this assumption is not precluded by this specification.
PIM-DMは、基礎となるユニキャストルーティングプロトコルに依存しないように設計されており、RPFチェックを実行するのに必要な程度にのみ相互作用します。この仮定に従わない配置は、本明細書によって除外されないけれども、一般的に、マルチキャストエリアと自律システム境界がユニキャストルーティングのために同一の境界に対応することが想定されます。
In general, PIM-DM interactions with other multicast routing protocols should be in compliance with RFC 2715 [7]. Other specific interactions are noted below.
一般的に、他のマルチキャストルーティングプロトコルとPIM-DM相互作用は、RFC 2715に準拠しなければならない[7]。他の特異的相互作用は、以下に記載されています。
PIM-DM is not intended to interact directly with PIM-SM, even though they share a common packet format. It is particularly important to note that a router cannot differentiate between a PIM-DM neighbor and a PIM-SM neighbor based on Hello messages.
PIM-DMは、それらが共通のパケット・フォーマットを共有するにもかかわらず、PIM-SMと直接対話するものではありません。ルータがPIM-DMの隣人とHelloメッセージに基づいて、PIM-SMの隣人を区別できないことに注意することが特に重要です。
In the event that a PIM-DM router becomes a neighbor of a PIM-SM router, the two will effectively form a simplex link, with the PIM-DM router sending all multicast messages to the PIM-SM router while the PIM-SM router sends no multicast messages to the PIM-DM router.
PIM-DMルータがPIM-SMルータの隣人になった場合には、二人は効果的にPIM-DMルータがPIM-SMルータながら、PIM-SMルータにすべてのマルチキャストメッセージを送信すると、シンプレックスリンクを形成しますPIM-DMルータへのマルチキャストメッセージを送信しません。
The common packet format permits a hybrid PIM-SM/DM implementation that would use PIM-SM when a rendezvous point is known and PIM-DM when one is not. Such an implementation is outside the scope of this document.
共通のパケット・フォーマットは、一つではない場合ランデブーポイントが知られており、PIM-DMされたときにPIM-SMを使用するハイブリッドPIM-SM / DMの実装を可能にします。そのような実装はこの文書の範囲外です。
PIM-DM will forward received multicast data packets to neighboring host group members in all cases except when the PIM-DM router is in an Assert Loser state on that interface. Note that a PIM Prune message is not permitted to prevent the delivery of messages to a network with group members.
PIM-DMは、PIM-DMルータはそのインターフェイス上でアサート敗者状態である場合を除いて、すべての場合において、隣接するホストグループのメンバーに受信したマルチキャストデータパケットを転送します。 PIMプルーンメッセージは、グループメンバーとネットワークへのメッセージの配信を防止するために許可されていないことに留意されたいです。
A PIM-DM Router MAY use the DR Priority option described in PIM-SM [14] to elect an IGMP v1 querier.
PIM-DMルータは、IGMP v1のクエリアを選出するPIM-SM [14]に記載のDR優先度オプションを使用するかもしれません。
PIM-DM makes no special considerations for SSM [15]. All Prunes and Grafts within the protocol are for a specific source, so no additional checks have to be made.
PIM-DMは、SSM [15]のための特別な配慮を行いません。プロトコル内のすべてのプルーンおよびグラフトは、特定のソースのためのものであるので、追加のチェックがなされなければなりません。
Although multicast group scope boundaries are generally identical to routing area boundaries, it is conceivable that a routing area might be partitioned for a particular multicast group. PIM-DM routers MUST NOT send any messages concerning a particular group across that group's scope boundary.
マルチキャストグループスコープの境界は領域境界をルーティングと概ね同じであるが、ルーティング領域が特定のマルチキャストグループのために分配されるかもしれないことが考えられます。 PIM-DMルータは、そのグループのスコープの境界を越えて、特定のグループに関連するすべてのメッセージを送ってはいけません。
The PIM Address Family field was chosen to be 8 bits as a tradeoff between packet format and use of the IANA assigned numbers. When the PIM packet format was designed, only 15 values were assigned for Address Families, and large numbers of new Address Families were not envisioned; 8 bits seemed large enough. However, the IANA assigns Address Families in a 16 bit value. Therefore, the PIM Address Family is allocated as follows:
PIMアドレスファミリフィールドは、IANA割り当てられた番号のパケットフォーマットと使用との間のトレードオフとして8ビットとなるように選択しました。 PIMパケットフォーマットを設計した場合には、唯一の15の値は、アドレスファミリ用に割り当てられていた、と新しいアドレスファミリの多くは想定されていませんでした。 8ビットが十分に大きいように見えました。しかし、IANAは、16ビット値のアドレスファミリを割り当てます。次のようにそのため、PIMアドレスファミリが割り当てられています：
Values 0 - 127 are designated to have the same meaning as IANA assigned Address Family Numbers [9].
値は0から127までは、IANA割り当てられたアドレスファミリ番号と同じ意味を持つように指定されている[9]。
Values 128 - 250 are designated to be assigned by the IANA based on IESG approval, as defined in [8].
128の値 - で定義されるように250は、IESGの承認に基づいて、IANAによって割り当てられるように指定されている[8]。
Values 251 - 255 are designated for Private Use, as defined in [8].
251の値 - で定義された255は、私的使用のために指定されている[8]。
Values 17 - 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 [8]. Assignments are valid for one year and may be renewed. Permanent assignments require a specification, as defined in [8].
17値は - 65000は、IANAによって割り当てられることになっています。スペースが大きいためまず[8]で定義されるように、添え最初に来るように、それらが割り当てられてもよいです。割り当ては1年間有効で、更新することができます。 [8]で定義されるように永久的な割り当ては、仕様を必要とします。
The IPsec authentication header [10] 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. In any case, a PIM router SHOULD NOT accept and process PIM messages from neighbors unless a valid Hello message has been received from that neighbor.
IPsec認証ヘッダ[10] PIMプロトコルメッセージのデータ保全性保護およびGroupWiseデータ発信元認証を提供するために使用され得ます。 PIMメッセージの認証は、不正または変更されたPIMメッセージによって引き起こされる不必要な行動から保護することができます。有効なHelloメッセージは、そのネイバーから受信されていない限り、どのような場合には、PIMルータがネイバーからPIMメッセージを受け入れ、処理しないでください。
Note that PIM-DM has no rendezvous point, and therefore no single point of failure that may be vulnerable. Because PIM-DM uses unicast routes provided by an unknown routing protocol, it may suffer collateral effects if the unicast routing protocol is attacked.
PIM-DMはないランデブーポイント、脆弱である可能性がある障害のゆえ単一点を有していないことに留意されたいです。 PIM-DMは、未知のルーティングプロトコルによって提供されるユニキャストルートを使用しているため、ユニキャストルーティングプロトコルが攻撃された場合、それが担保影響を受けることができます。
The extent of possible damage depends on the type of counterfeit messages accepted. We next consider the impact of possible forgeries. A forged PIM-DM message is link local and 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.
損傷の程度は受け入れられた偽造メッセージの種類によって異なります。私たちは、次の可能な偽造の影響を考慮してください。鍛造PIM-DMメッセージは、リンクローカルであり、それがローカルホストによって送信された場合や、それが危険にさらさまたは非準拠のルータでLAN上に許可された場合のみ、LANに到達することができます。
1. A forged Hello message can cause multicast traffic to be delivered to links where there are no legitimate requestors, potentially wasting bandwidth on that link. On a multi-access LAN, the effects are limited without the capability to forge a Join message, as other routers will Prune the link if the traffic is not desired.
1. Aは、Helloメッセージは、マルチキャストトラフィックが潜在的にそのリンク上の帯域幅を浪費し、正当な要求者が存在しないリンクに配信されることがあります偽造しました。マルチアクセスLANには、効果がトラフィックを希望されていない場合、他のルータがリンクを整理しますと、参加メッセージを偽造する機能のない制限されています。
2. A forged Join/Prune message can cause multicast traffic to be delivered to links where there are no legitimate requestors, potentially wasting bandwidth on that link. A forged Prune 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 Prune with a Join before the upstream router stops forwarding data to the LAN.
2. Aはプルーンのメッセージがマルチキャストトラフィックが潜在的にそのリンク上の帯域幅を浪費し、正当な要求者が存在しないリンクに配信されることがあります/参加鍛造しました。いずれかが合法的に上流のルータは、LANへのデータの転送を停止する前に、LAN上のルータが参加してプルーンをオーバーライドします参加しているため、マルチアクセスLAN上の偽造プルーンのメッセージは、一般的にPIMの重要な攻撃ではありません。
3. A forged Graft message can cause multicast traffic to be delivered to links where there are no legitimate requestors, potentially wasting bandwidth on that link. In principle, Graft messages could be sent multiple hops because they are unicast to the upstream router. This should not be a problem, as the remote forger should have no way to get a Hello message to the target of the attack. Without a valid Hello message, the receiving router SHOULD NOT accept the Graft.
3.偽造グラフトメッセージは、マルチキャストトラフィックは、潜在的にそのリンク上の帯域幅を浪費し、正当な要求者が存在しないリンクに配信されることがあります。彼らは上流のルータへのユニキャストであるため、原則的には、グラフトメッセージは、複数のホップを送ることができます。リモート偽造者が攻撃のターゲットにHelloメッセージを取得する方法がありませんする必要があり、これは、問題になることはありません。有効なHelloメッセージがなければ、受信ルータは、移植片を受け入れるべきではありません。
4. A forged GraftAck message has no impact, as it will be ignored unless the router has recently sent a Graft to its upstream router.
4. Aは、ルータが、最近、その上流ルータに移植片を送っていない限り、それは無視されるようにGraftAckメッセージは、影響を与えない偽造しました。
5. By forging an Assert message on a multi-access LAN, an attacker could cause the legitimate forwarder to stop forwarding traffic to the LAN. Such a forgery would prevent any hosts downstream of that LAN from receiving traffic.
5.マルチアクセスLAN上のAssertメッセージを鍛造することにより、攻撃者は正当なフォワーダがLANへのトラフィックの転送を停止する可能性があります。このような偽造は、トラフィックを受信しているLANの下流の任意のホストを防止するであろう。
6. A forged State Refresh message on a multi-access LAN would have the same impact as a forged Assert message, having the same general functions. In addition, forged State Refresh messages would be propagated downstream and might be used in a denial of service attack. Therefore, a PIM-DM router SHOULD rate limit State Refresh messages propagated.
6. Aは、マルチアクセスLANは、同じ一般的な機能を有する、鍛造アサートメッセージと同じ影響を有するであろうオン状態更新メッセージを偽造しました。また、鍛造ステートリフレッシュメッセージが下流に伝播されるだろうし、サービス拒否攻撃で使用される可能性があります。そのため、PIM-DMルータが伝播制限ステートリフレッシュメッセージを評価すべきです。
A PIM-DM router SHOULD provide an option to limit the set of neighbors from which it will accept PIM-DM messages. Either static configuration of IP addresses or an IPSec security association may be used. All options that restrict the range of addresses from which packets are accepted MUST default to allowing all packets.
PIM-DMルータは、PIM-DMメッセージを受け入れるから、隣人のセットを制限するためのオプションを提供する必要があります。静的IPアドレスの設定やIPSecセキュリティアソシエーションのいずれかを使用することができます。パケットが受け入れられているから、アドレスの範囲を制限するすべてのオプションはすべてのパケットを許可するデフォルトしなければなりません。
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メッセージを受信していない元のルータからのプロトコルメッセージを受け入れるべきではありません。
The IPSec [10] transport mode using the Authentication Header (AH) is the recommended method to prevent the above attacks in 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. The Encapsulating Security
IPSecは、認証ヘッダ（AH）を使用して[10]トランスポート・モードは、PIM上記の攻撃を防ぐために推奨される方法です。特定のAH認証アルゴリズムと認証アルゴリズムの選択とキーの選択を含むパラメータは、ネットワーク管理者によって設定されます。カプセル化セキュリティ
Payload (ESP) MAY also be used to provide both encryption and authentication of PIM protocol messages. When IPsec authentication is used, a PIM router SHOULD reject (drop without processing) any unauthorized PIM protocol messages.
ペイロード（ESP）は、PIMプロトコルメッセージの暗号化と認証の両方を提供するために使用され得ます。 IPsec認証を使用する場合、PIMルータは（処理なしドロップ）不正PIMプロトコルメッセージを拒否すべきです。
To use IPSec, the administrator of a PIM network configures each PIM router with one or more Security Associations and associated Security Parameters Indices 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 Security Associations. It assumes that manual configuration of Security Associations is performed, but it does not preclude the use of some future negotiation protocol such as GDOI [17] to establish Security Associations.
IPSecを使用するには、PIMネットワークの管理者は、PIMプロトコルメッセージを認証するために送信者によって使用され、受信PIMプロトコルメッセージを認証するために受信機によって使用される1つのまたは複数のセキュリティアソシエーションとそれに関連するセキュリティパラメータインデックスと各PIMルータを設定します。この文書では、セキュリティアソシエーションを確立するためのプロトコルを説明していません。これは、セキュリティアソシエーションの手動設定が行われていることを前提としていますが、それはセキュリティアソシエーションを確立するために、このようなGDOI [17]など、いくつかの将来の交渉プロトコルの使用を排除するものではありません。
The network administrator defines a Security Association (SA) and Security Parameters Index (SPI) to be used to authenticate all PIM-DM protocol messages from each router on each link in a PIM-DM domain.
ネットワーク管理者は、PIM-DMドメイン内の各リンク上の各ルータからすべてのPIM-DMプロトコルメッセージを認証するために使用されるセキュリティアソシエーション（SA）とセキュリティパラメータインデックス（SPI）を定義します。
In order to avoid the problem of allocating individual keys for each neighbor on a link to each individual router, it is acceptable to establish only one authentication key for all PIM-DM routers on a link. This will not specifically authenticate the individual router sending the message, but will ensure that the sender is a PIM-DM router on that link. If this method is used, the receiver of the message MUST ignore the received sequence number, thus disabling anti-replay mechanisms. The effects of disabling anti-replay mechanisms are essentially the same as the effects of forged messages, described in Section 7.1, with the additional protection that the forger can only reuse legitimate messages.
個々のルータへのリンク上の各隣人のために個々のキーを割り当てる問題を回避するためには、リンク上のすべてのPIM-DMルータのための唯一の認証キーを確立するために許容可能です。これは、具体的メッセージを送信する個々のルータを認証しませんが、送信者がそのリンク上のPIM-DMルータであることを保証します。この方法が使用される場合、メッセージの受信側は、このようにアンチリプレイ機構を無効に、受信したシーケンス番号を無視しなければなりません。アンチリプレイメカニズムを無効にした場合の効果は、基本的に偽造が唯一正当なメッセージを再利用することができます追加の保護と、7.1節で説明した偽造メッセージの効果と同じです。
The Security Policy Database at a PIM-DM router should be configured to ensure that all incoming and outgoing PIM-DM packets use the SA associated with the interface to which the packet is sent. Note that, according to [10], there is nominally a different Security Association Database (SAD) for each router interface. Thus, the selected Security Association for an inbound PIM-DM packet can vary depending on the interface on which the packet arrived. This fact allows the network administrator to use different authentication methods for each link, even though the destination address is the same for most PIM-DM packets, regardless of interface.
PIM-DMルータでのセキュリティポリシーデータベースは、すべての着信と発信のPIM-DMのパケットは、パケットが送信されているインタフェースに関連付けられたSAを使用することを確保するように設定する必要があります。 [10]によれば、なお、名目上の各ルータインターフェイスの異なるセキュリティアソシエーションデータベース（SAD）があります。このように、インバウンドPIM-DMパケットの選択セキュリティアソシエーションは、パケットが到着したインターフェイスによって異なります。この事実は、宛先アドレスに関係なく、インターフェースの、ほとんどのPIM-DMパケットについて同じであっても、ネットワーク管理者は、各リンクに対して異なる認証方法を使用することができます。
There are a number of possible denial of service attacks against PIM that can be caused by generating false PIM protocol messages or even by generating false data traffic. Authenticating PIM protocol traffic prevents some, but not all, of these attacks. The possible attacks include the following:
偽PIMプロトコルメッセージを生成することによって、あるいは偽のデータトラフィックを発生させることによって引き起こされる可能性がPIMに対するサービス攻撃の可能性否定の数があります。 PIMプロトコルトラフィックの認証は、いくつかのを防ぎ、すべてではないが、これらの攻撃の。攻撃の可能性には次のものがあります。
* Sending packets to many different group addresses quickly can amount to a denial of service attack in and of itself. These messages will initially be flooded throughout the network before they are pruned back. The maintenance of state machines and State Refresh messages will be a continual drain on network resources.
*すぐに多くの異なったグループアドレスにパケットを送信すると、それ自体のサービス拒否攻撃に達することができます。彼らが戻って剪定される前に、これらのメッセージは、最初のネットワーク全体にフラッディングされます。ステート・マシンとステートリフレッシュメッセージのメンテナンスは、ネットワークリソースへの継続的なドレインになります。
* Forged State Refresh messages sent quickly could be propagated by downstream routers, creating a potential denial of service attack. Therefore, a PIM-DM router SHOULD limit the rate of State Refresh messages propagated.
*すぐに送信されフォージドステートリフレッシュメッセージは、サービス攻撃の可能性否定を作成、下流のルータによって伝播することができます。そのため、PIM-DMルータが伝播ステートリフレッシュメッセージのレートを制限すべきです。
The major features of PIM-DM were originally designed by Stephen Deering, Deborah Estrin, Dino Farinacci, Van Jacobson, Ahmed Helmy, David Meyer, and Liming Wei. Additional features for state refresh were designed by Dino Farinacci, Isidor Kouvelas, and Kurt Windisch. This revision was undertaken to incorporate some of the lessons learned during the evolution of the PIM-SM specification and early deployments of PIM-DM.
PIM-DMの主な特徴は、もともとスティーブンデアリング、デボラ・エストリン、ディノファリナッチ、バン・ジェイコブソン、アーメド・ヘルミー、デビッド・マイヤー、そして黎明魏によって設計されました。状態リフレッシュのための追加機能はディーノファリナッチ、イジドールKouvelas、およびクルトWindischによって設計されました。この改正は、レッスンの一部はPIM-SM仕様とPIM-DMの早期展開の進化の過程で学んだ組み込むために行われました。
Thanks the PIM Working Group for their comments.
彼らのコメントをありがとうPIMワーキンググループを。
[1] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[1]デアリング、S.、 "IPマルチキャスティングのためのホスト拡大"、STD 5、RFC 1112、1989年8月。
[2] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[2]フェナー、W.、 "インターネットグループ管理プロトコル、バージョン2"、RFC 2236、1997年11月。
[3] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[3]カイン、B.、デアリング、S.、Kouvelas、I.、フェナー、B.、およびA. Thyagarajan、 "インターネットグループ管理プロトコル、バージョン3"、RFC 3376、2002年10月。
[4] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Liu, C., Sharma, P., and L. Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998.
[4] Estrin、D.、ファリナッチ、D.、Helmy、A.、ターラー、D.、デアリング、S.、ハンドレー、M.、ヤコブソン、V.、劉、C.、シャルマ、P.、およびL 。魏、 "プロトコル独立マルチキャスト - スパースモード（PIM-SM）：プロトコル仕様"、RFC 2362、1998年6月。
[5] 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] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[6]デアリング、S.、フェナー、W.、およびB.ハーバーマン、 "マルチキャストリスナ発見IPv6の（MLD）"、RFC 2710、1999年10月。
[7] Thaler, D., "Interoperability Rules for Multicast Routing Protocols", RFC 2715, October 1999.
[7]、RFC 2715、1999年10月ターラー、D.、 "マルチキャストルーティングプロトコルの相互運用規則"。
[8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[8] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[9] IANA, "Address Family Numbers", linked from http://www.iana.org/numbers.html.
[9] IANA、 "アドレスファミリ番号は"、http://www.iana.org/numbers.htmlからリンクされています。
[10] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[10]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[11] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[11]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[12] Deering, S.E., "Multicast Routing in a Datagram Internetwork", Ph.D. Thesis, Electrical Engineering Dept., Stanford University, December 1991.
[12]デアリング、S.E.、「データグラムインターネットワークにおけるマルチキャストルーティング」、博士論文、電気工学部門、スタンフォード大学、1991年12月。
[13] Waitzman, D., Partridge, C., and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988.
[13] Waitzman、D.、ヤマウズラ、C.、およびS.デアリング、 "距離ベクトルマルチキャストルーティングプロトコル"、RFC 1075、1988年11月。
[14] Fenner, W., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", Work in Progress.
[14]フェナー、W.、ハンドレー、M.、ホルブルック、H.、およびI. Kouvelas、 "プロトコル独立マルチキャスト - スパースモード（PIM-SM）：プロトコル仕様（改訂）"、ProgressのWork。
[15] Holbrook, H. and B. Cain, "Source Specific Multicast for IP", Work in Progress.
[15]ホルブルック、H.、およびB.カイン、「IPのためのソース固有マルチキャスト」が進行中で働いています。
[16] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bi-directional Protocol Independent Multicast", Work in Progress.
[16]ハンドレー、M.、Kouvelas、I.、スピークマン、T.、およびL. Vicisano、 "双方向プロトコル独立マルチキャスト"、進行中の作業。
[17] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
[17] Baugher、M.、ヴァイス、B.、Hardjono、T.、およびH.ハーニー、 "解釈のグループドメイン"、RFC 3547、2003年7月。
[18] Fenner, W., Handley, M., Kermode, R., and D. Thaler, "Bootstrap Router (BSR) Mechanism for PIM Sparse Mode", Work in Progress.
、進行中の作業[18]フェナー、W.、ハンドレー、M.、Kermode、R.、およびD.ターレル、 "PIMスパースモードのためのブートストラップルータ（BSR）メカニズム"。
Authors' Addresses
著者のアドレス
Andrew Adams NextHop Technologies 825 Victors Way, Suite 100 Ann Arbor, MI 48108-2738
アンドリュー・アダムスのNextHop Technologies社825ビクターズウェイ、スイート100アナーバー、ミシガン州48108から2738
EMail: ala@nexthop.com
メールアドレス：ala@nexthop.com
Jonathan Nicholas ITT Industries Aerospace/Communications Division 100 Kingsland Rd Clifton, NJ 07014
ジョナサン・ニコラスITTインダストリーズ航空宇宙/コミュニケーション部100キングスランドRdのクリフトン、NJ 07014
EMail: jonathan.nicholas@itt.com
メールアドレス：jonathan.nicholas@itt.com
William Siadak NextHop Technologies 825 Victors Way, Suite 100 Ann Arbor, MI 48108-2738
ウィリアムSiadakのNextHop Technologies社825ビクターズウェイ、スイート100アナーバー、ミシガン州48108から2738
EMail: wfs@nexthop.com
メールアドレス：wfs@nexthop.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
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 IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 IETF文書の権利に関するIETFの手続きの情報は、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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。