[要約] RFC 3973は、PIM-DM（Protocol Independent Multicast - Dense Mode）のプロトコル仕様を定義しています。このRFCの目的は、密集モードでのマルチキャスト通信をサポートするためのプロトコルを提供することです。
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)
プロトコル非依存マルチキャスト - 高密度モード (PIM-DM): プロトコル仕様 (改訂版)
Status of This Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネット コミュニティ向けの実験プロトコルを定義します。いかなる種類のインターネット標準も指定しません。改善のための議論と提案が求められます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (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.
この文書では、Protocol Independent Multicast - Dense Mode (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 (Dense Mode) と呼ばれます。この設計の基礎は主に、IP マルチキャスト ルーティングに関する Deering の初期の研究に基づいて構築されました [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」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「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 は MRIB を使用して、RPF インターフェイスに関する決定を行います。
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 ルーターによって維持され、ローカル ホストから PIM メッセージと IGMP 情報を受信することによって作成される状態のコレクションです。基本的に、そのルーターにあるすべてのマルチキャスト配信ツリーの状態を保存します。
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) IP パケットに関連付けられた送信元 S と宛先グループ G をペアにします。
We use set notation in several places in this specification.
この仕様では、いくつかの場所でセット表記を使用します。
A (+) B is the union of two sets, A and B.
A ( ) B は、2 つのセット A と B の和集合です。
A (-) B are the elements of set A that are not in set B.
A (-) 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.
操作は指定された順序で実行する必要があることに注意してください。これは、B が必ずしも A の部分集合であるとは限らないため、(-) が真の差分演算子ではないという事実によるものです。つまり、A ( ) B (-) C = A (-) C ( ) B は a ではありません。C が A と B の両方のサブセットでない限り、ステートメントは true になります。
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 状態の存続期間は有限です。その有効期限が切れると、データは以前にプルーニングされたブランチに再び転送されます。
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 では、Join、Prune、および Graft の生成および処理ルールを指定します。* セクション 4.5 では、State Refresh の生成および転送ルールを指定します。* セクション 4.6 では、Assert の生成と処理のルールを指定します。* セクション 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) エントリに関連付けられたルートおよび状態情報を維持しなければなりません(MUST)。(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)
各インターフェイスの場合: Hello Timer (HT) State Refresh Capable LAN Delay Enabled Propagation Delay (PD) Override Interval (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 Neighbor の Gen 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"}
PIM (S,G) Prune State: State: One of {"NoInfo" (NI), "Pruned" (P), "PrunePending" (PP)} Prune Pending Timer (PPT) Prune Timer (PT)
PIM (S,G) プルーン状態: 状態: {"NoInfo" (NI)、"Pruned" (P)、"PrunePending" (PP)} のいずれか プルーン保留タイマー (PPT) プルーン タイマー (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
(S,G) 勝者のアサート 状態: 状態: {"NoInfo" (NI)、"I loss Assert" (L)、"I win Assert" (W)} のいずれか Assert Timer (AT) 勝者の IP アドレスをアサート 勝者の IP アドレスをアサートメトリックのアサート
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)
アップストリーム インターフェイス固有: Graft/Prune 状態: 状態: {"NoInfo" (NI)、"Pruned" (P)、"Forwarding" (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)
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)}
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) は、ソース S の RPF インターフェイスを返します。つまり、MRIB によって示されるように、S に到達するために使用されるインターフェイスを返します。
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.
マクロ local_receiver_include(S,G,I) は、IGMP モジュールまたは他のローカル メンバーシップ メカニズム ([1]、[2]、[3]、[6]) が、インターフェイス I にシークするローカル メンバーが存在すると判断した場合に true になります。特に S から G に送信されたトラフィックを受信します。
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.
マクロ local_receiver_include(*,G,I) は、IGMP モジュールまたは他のローカル メンバーシップ メカニズムが、G に送信されたすべてのトラフィックを受信しようとするローカル メンバーがインターフェイス I 上に存在すると判断した場合に true になります。この判断は、次のことを考慮する必要があることに注意してください。ルーター上で、またはルーターによって開始されるメンバーシップ参加。
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_exclude(S,G,I) が true の場合、マクロ local_receiver_exclude(S,G,I) は true になりますが、どのローカル メンバーも S からのトラフィックを受信しようとしていません。
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:
セット prunes(S,G) は、ルータが Prune(S,G) メッセージを受信したすべてのインターフェイスのセットです。
prunes(S,G) = {all interfaces I such that
DownstreamPState(S,G,I) is in Pruned state}
The set lost_assert(S,G) is the set of all interfaces on which the router has lost an (S,G) Assert.
セット loss_assert(S,G) は、ルータが (S,G) アサートを失ったすべてのインターフェイスのセットです。
lost_assert(S,G) = {all interfaces I such that
lost_assert(S,G,I) == TRUE}
boundary(G) = {all interfaces I with an administratively scoped
boundary for group G}
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.
次の疑似コード マクロ定義も、仕様内の多くの場所で使用されています。基本的に、RPF' は、PIM-DM アサートによってネイバーの通常の選択がオーバーライドされない限り、送信元に対する 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 )
}
}
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_Am_Assert_loser(S, G, I) は、インターフェイス I 上の (S,G) のアサート ステート マシン (セクション 4.6) が「I am Assert Loser」状態にある場合に true になります。
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) は、パケットを S にルーティングするために使用されることを MRIB が示すインターフェイスです。
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 チェックに失敗したパケットは転送してはなりません (MUST NOT)。ルータはパケットで指定された (S,G) ペアのアサート プロセスを実行します。送信元へのルートが見つからないパケットは破棄しなければなりません(MUST)。
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:
インターフェイス iif で G 宛ての S からのデータ パケットを受信すると、次のようになります。
if (iif == RPF_interface(S) AND UpstreamPState(S,G) != Pruned) {
oiflist = olist(S,G)
} else {
oiflist = NULL
}
forward packet on all interfaces in oiflist
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 の Upstream(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 は、Hello メッセージを使用して他の PIM ルータを検出します。Hello メッセージは、PIM 対応の各インターフェイスで定期的に送信されます。Hello メッセージは ALL-PIM-ROUTERS グループにマルチキャストされます。PIM がインターフェイス上で有効になっている場合、またはルーターが最初に起動する場合、Hello Timer (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 メッセージは Hello_Period ごとに送信されなければなりません (MUST)。単一の Hello タイマーを使用して、すべてのアクティブなインターフェイスで Hello メッセージの送信をトリガーできます (MAY)。Hello タイマーは、期限切れになる場合を除いてリセットしてはなりません (SHOULD NOT)。
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 メッセージを受信した場合、受信ルータは受信インターフェース、送信者、および認識されたオプションに含まれる情報を記録するものとします(SHALL)。この情報は、Hello メッセージの Hold Time フィールドに数秒間保持されます。特定の近隣 N から新しい Hello メッセージを受信した場合、近隣ライブネス タイマー (NLT(N,I)) を新しく受信した Hello Holdtime にリセットしなければなりません (MUST)。新しい隣接ルータから Hello メッセージを受信した場合、受信ルータは 0 から Triggered_Hello_Delay までのランダムな遅延の後に独自の Hello メッセージを送信する必要があります (SHOULD)。
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 をアクティブに保つことが合理的に期待できる値に設定する必要があります。ほとんどのリンクでは、これは 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.
Hold Time が「0xffff」に設定されている場合、受信ルーターはその Hello メッセージをタイムアウトにしてはなりません (MUST NOT)。この機能は、定期的な 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 アドレスを変更する場合、PIM ネイバーが古い情報を即座に削除できるように、ホールド タイムがゼロの Hello メッセージが（IP アドレスが変更された場合は古い IP アドレスとともに）ただちに送信されるべきです（SHOULD）。
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.
異なる世代 ID (GenID) を持つアクティブなネイバーから Hello メッセージを受信した場合、ネイバーは再起動されており、正しい (S,G) 状態を含んでいない可能性があります。Hello メッセージは、0 から Triggered_Hello_Delay (4.8 を参照) までのランダムな遅延の後、他のメッセージが送信される前に送信されるべきです (SHOULD)。隣接ルータが下流にある場合、ルータは、下流ルータにプルーンとアサートのステータスを示すアサート勝者である (S,G) ペアの最後の状態更新メッセージを再実行してもよい(MAY)。これらの状態更新メッセージは、Hello メッセージの直後に送信されるべきです (SHOULD)。ネイバーが (S,G) エントリの上流ネイバーである場合、ルータはプルーンの送信と上流ルータでのプルーン状態の再確立を許可するためにプルーン制限タイマーをキャンセルしてもよい(MAY)。
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 内に受信した State Refresh メッセージを使用してもよい(MAY)。ステート リフレッシュ ソースは RPF'(S) となり、すべてのインターフェイスのプルーン ステータスはステート リフレッシュ メッセージのプルーン インジケータ ビットに従って設定されます。Prune Indicator が設定されている場合、ルータは PruneLimitTimer を Prune_Holdtime に設定し、すべてのダウンストリーム インターフェイスの PruneTimer を State Refresh の間隔の 2 倍に設定する必要があります (SHOULD)。その後、ルーターはセクション 4.5.1 で説明されているように状態リフレッシュを伝播すべきです(SHOULD)。
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 プルーン遅延オプションをサポートしている場合、その 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 プルーン遅延オプションのオーバーライド間隔フィールドで必要なランダム化の量についての見解を表します。LAN 上のすべてのルータが LAN プルーン遅延オプションを使用する場合、LAN 上のすべてのルータは、Override_Interval を LAN 上の最大の Override 値に設定しなければなりません。
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 プルーン遅延オプションでルーターによって挿入される 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、Prune、および Graft メッセージの生成と処理について説明します。プルーン メッセージは、S からグループ G 宛てのトラフィックが望ましくないことを示すために、S の上流ネイバーに向けて送信されます。ダウンストリーム ルーター A と B の場合、A はデータの受信を継続したいが、B は受信を希望していない場合、A は B の Prune に応答して Join を送信し、Prune をオーバーライドします。これは、PIM-DM で Join メッセージが使用される唯一の状況です。最後に、Graft メッセージを使用して、以前に剪定されたブランチを配信ツリーに再結合します。
The Upstream(S,G) state machine for sending Prune, Graft, and Join messages is given below. There are three states.
Prune、Graft、Join メッセージを送信するための Upstream(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) これは、Upsteam(S,G) ステート マシンの開始状態です。ステート マシンは、開始したばかりの場合、または oiflist(S,G) != 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) は空です。ルーターは、S からグループ G にアドレス指定されたデータを転送しません。
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.
AckPending (AP) ルータは Pruned(P) 状態にありましたが、この (S,G) エントリの発信インターフェイスの 1 つで Downstream(S,G) ステート マシンで遷移が発生しました。これは、S からのトラフィックが にアドレス指定されていることを示しています。G を再度転送する必要があります。Graft メッセージは RPF'(S) に送信されましたが、Graft 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)) このタイマーは、Graft がアップストリームに送信されるときに設定されます。対応する GraftAck がタイマーの期限が切れる前に受信されなかった場合、別の Graft が送信され、GraftRetry タイマーがリセットされます。Graft 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).
オーバーライド タイマー (OT(S,G)) このタイマーは、olist(S,G) != NULL のアップストリーム インターフェイスで Prune(S,G) が受信されたときに設定されます。タイマーが期限切れになると、Join(S,G) メッセージがアップストリーム インターフェイスに送信されます。このタイマーは通常、t_override に設定されます (4.8 を参照)。
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 上のプルーンのレート制限に使用されます。これは、Upstream(S,G) ステート マシンが Pruned 状態にある場合にのみ使用されます。このタイマーが動作している場合、Prune を送信することはできません。このタイマーは通常 t_limit に設定されます (4.8 を参照)。
+-------------+ +-------------+
| | 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) エントリの着信インターフェイス上で、このルータのアドレスを対象とした Graft Ack メッセージを受信することを意味します。宛先アドレスが正しくない場合、このステート マシンの状態遷移は発生してはなりません。
When the Upstream(S,G) state machine is in the Forwarding (F) state, the following events may trigger a transition:
Upstream(S,G) ステート マシンが Forwarding (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.
データ パケットが RPF_Interface(S) に到着し、かつ olist(S,G) == NULL かつ S が直接接続されていません。 Upstream(S,G) ステート マシンは Pruned (P) 状態に移行し、Prune(S,G) を送信する必要があります。RPF'(S) に設定し、PLT(S,G) を t_limit 秒に設定します。
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.
State Refresh(S,G) RPF'(S) から受信しました。 Upstream(S,G) ステート マシンは、Forwarding ステートのままです。受信した State Refresh の Prune Indicator ビットが 1 に設定されている場合、このルータはランダムな短い間隔の後に上流ルータの Prune 状態をオーバーライドする必要があります。OT(S,G) が実行中でなく、Prune Indicator ビットが 1 に等しい場合、ルータは OT(S,G) を t_override 秒に設定しなければなりません (MUST)。
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.
「Join(S,G) to RPF'(S)」を参照してください。 このイベントは、RPF_interface(S) が共有メディアの場合にのみ関係します。このルーターは、RPF_interface(S) 上の別のルーターが Join(S,G) を RPF'(S,G) に送信するのを確認します。OT(S,G) が実行されている場合は、ルーターが以前に受信した Prune をオーバーライドするように Join をスケジュールしていたことを意味します。別のルータは、Join でより迅速に応答したため、ローカル ルータが実行中の場合、その OT(S,G) をキャンセルする必要があります (SHOULD)。Upstream(S,G) ステート マシンは、Forwarding (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.
「Prune(S,G) および S が直接接続されていない」を参照してください。 このイベントは、RPF_interface(S) が共有メディアの場合にのみ関係します。このルータは、RPF_interface(S) 上の別のルータが Prune(S,G) を送信することを確認します。このルーターはフォワーディング状態にあるため、ランダムな短い間隔の後にプルーンをオーバーライドする必要があります。OT(S,G) が実行されていない場合、ルーターは OT(S,G) を t_override 秒に設定しなければなりません (MUST)。Upstream(S,G) ステート マシンは、Forwarding (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)) が期限切れになります。ルータは、以前に検出されたプルーンをオーバーライドするために、Join(S,G) を RPF'(S) に送信しなければなりません (MUST)。Upstream(S,G) ステート マシンは、Forwarding (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 が直接接続されていない Upstream(S,G) ステート マシンは、Pruned (P) ステートに遷移し、Prune(S,G) を RPF'(S) に送信し、PLT(S,G) から t_limit 秒。
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 でなく、かつ S が直接接続されていない ユニキャスト ルーティングまたはアサート状態により、RPF_Interface(S) への変更を含め、RPF'(S) が変更されます。Upstream(S,G) 状態マシンは、AckPending (AP) 状態に移行し、新しい RPF'(S) に Graft をユニキャストし、GraftRetry Timer (GRT(S,G)) を Graft_Retry_Period に設定しなければなりません (MUST)。
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_Interface(S) への変更を含め、RPF'(S) が変更されます。Upstream(S,G) ステート マシンは、Pruned (P) ステートに遷移しなければなりません。
When the Upstream(S,G) state machine is in the Pruned (P) state, the following events may trigger a transition:
Upstream(S,G) ステート マシンが Pruned (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 にアドレス指定されたトラフィックを要求しているか、以前の Prune が失われています。すべてのデータ パケットに応答して Prune(S,G) が生成されるのを防ぐために、PruneLimit タイマー (PLT(S,G)) が使用されます。PLT(S,G) の有効期限が切れると、ルーターはソースから直接受信しなかったデータ パケットに応答して別のプルーンを送信する必要があります。Prune(S,G) は RPF'(S) に送信されなければならず、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.
State Refresh(S,G) RPF'(S) から受信しました。 Upstream(S,G) ステート マシンはプルーニングされた状態のままです。State Refresh の Prune Indicator ビットが 0 に設定されており、PLT(S,G) が実行されていない場合は、Prune(S,G) を RPF'(S) に送信しなければならず、PLT(S,G) はt_limit に設定します。State Refresh の Prune Indicator ビットが 1 に設定されている場合、ルータは PLT(S,G) を t_limit にリセットしなければなりません (MUST)。
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).
Prune(S,G) から RPF'(S) を参照 Prune(S,G) は、RPF_interface(S) から RPF'(S) に見られます。Upstream(S,G) ステート マシンは Pruned (P) 状態のままです。ルータは、PLT(S,G) の現在の値より大きい場合、受信メッセージの Holdtime フィールドの値に PLT(S,G) をリセットしてもよい(MAY)。
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 Graft message to RPF'(S). The Graft Retry Timer (GRT(S,G)) MUST be set to Graft_Retry_Period.
olist(S,G)->non-NULL かつ S が直接接続されていない olist(S,G) マクロによって定義されたインターフェイスのセットは空ではなくなり、S からグループ G にアドレス指定されたトラフィックを転送する必要があることを示します。Upstream(S,G) 状態マシンは、PLT(S,G) をキャンセルし、AckPending (AP) 状態に移行し、グラフト メッセージを RPF'(S) にユニキャストしなければなりません (MUST)。Graft Retry Timer (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) の変更 AND olist(S,G) == 非 NULL AND S NOT 直接接続 ユニキャスト ルーティングまたはアサート状態により、RPF_Interface(S) への変更を含む RPF'(S) の変更が発生します。Upstream(S,G) ステートマシンは、PLT(S,G) をキャンセルし、AckPending (AP) 状態に移行し、新しい RPF'(S) に Graft ユニキャストを送信し、GraftRetry タイマー (GRT(S,G)) から Graft_Retry_Period まで。
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) の変更 AND olist(S,G) == NULL AND S が直接接続されていない ユニキャスト ルーティングまたはアサート状態により、RPF_Interface(S) への変更を含む RPF'(S) の変更が発生します。Upstream(S,G) ステート マシンは Pruned (P) 状態に留まり、PLT(S,G) タイマーをキャンセルしなければなりません (MUST)。
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 が直接接続されるようにユニキャスト ルーティングが変更されました。Upstream(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.
State Refresh(S,G) プルーン インジケータ == 1 の RPF'(S) から受信しました。 Upstream(S,G) ステート マシンは AckPending 状態のままです。ルーターは、ランダムな短い間隔の後に、上流ルーターの Prune 状態をオーバーライドする必要があります。OT(S,G) が実行中でなく、Prune Indicator ビットが 1 に等しい場合、ルータは OT(S,G) を t_override 秒に設定しなければなりません (MUST)。
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.
State Refresh(S,G) Prune Indicator == 0 の RPF'(S) から受信 ルータは GraftRetry Timer (GRT(S,G)) をキャンセルし、Forwarding (F) 状態に移行しなければなりません (MUST)。
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.
「Join(S,G) to RPF'(S,G)」を参照してください。 このイベントは、RPF_interface(S) が共有メディアの場合にのみ関係します。このルーターは、RPF_interface(S) 上の別のルーターが Join(S,G) を RPF'(S,G) に送信するのを確認します。OT(S,G) が実行されている場合は、ルーターが以前に受信した Prune をオーバーライドするように Join をスケジュールしていたことを意味します。別のルータは、Join でより迅速に応答したため、ローカル ルータが実行中の場合、その OT(S,G) をキャンセルする必要があります (SHOULD)。Upstream(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.
Prune(S,G) を参照してください。 このイベントは、RPF_interface(S) が共有メディアの場合にのみ関係します。このルータは、RPF_interface(S) 上の別のルータが Prune(S,G) を送信することを確認します。このルーターは AckPending (AP) 状態にあるため、ランダムな短い間隔の後に Prune をオーバーライドする必要があります。OT(S,G) が実行されていない場合、ルーターは OT(S,G) を t_override 秒に設定しなければなりません (MUST)。アップストリーム (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)) の期限が切れます。ルータは、Join(S,G) を RPF'(S) に送信しなければなりません (MUST)。Upstream(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) マクロによって定義されたインターフェイスのセットは null になり、グループ G にアドレス指定された S からのトラフィックは転送されないことを示します。Upstream(S,G) ステート マシンは、Pruned (P) ステートに遷移しなければなりません。Prune(S,G) は、上流隣接フィールドに RPF'(S) という名前を付けて、RPF_interface(S) にマルチキャストしなければなりません (MUST)。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 にならず、かつ S が直接接続されていない ユニキャスト ルーティングまたはアサート状態により、RPF_Interface(S) への変更を含め、RPF'(S) が変更されます。Upstream(S,G) ステート マシンは AckPending (AP) 状態のままです。Graft は新しい RPF'(S) にユニキャストし、GraftRetry タイマー (GRT(S,G)) を Graft_Retry_Period にリセットする必要があります。
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) の変更 AND olist(S,G) == NULL AND S が直接接続されていない ユニキャスト ルーティングまたはアサート状態により、RPF_Interface(S) への変更を含む RPF'(S) の変更が発生します。Upstream(S,G) ステート マシンは、Pruned (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 タイマーはキャンセルされなければならず、Upstream(S,G) ステート マシンは Forwarding(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) の期限が切れる この (S,G) エントリの GraftRetry タイマー (GRT(S,G)) が期限切れになります。Upstream(S,G) ステート マシンは AckPending (AP) 状態のままです。(S,G) の別の Graft メッセージは RPF'(S) にユニキャストされ、GraftRetry タイマー (GRT(S,G)) は Graft_Retry_Period にリセットされるべきです(SHOULD)。ルータは、再試行を中止する前に、設定された回数だけ再試行することが推奨されます。
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'(S) からの GraftAck(S,G) を参照してください。 GraftAck は RPF'(S) から受信されます。GraftRetry タイマーはキャンセルされなければならず、Upstream(S,G) ステート マシンは Forwarding(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.
インターフェイス I で Prune、Join、および Graft メッセージを受信するための Prune(S,G) ダウンストリーム ステート マシンを以下に示します。このステート マシンは、アップストリーム インターフェイス上で常に 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.
NoInfo(NI) インターフェイスには (S,G) Prune 状態がなく、Prune タイマー (PT(S,G,I)) も PrunePending タイマー ((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) ルータは、このインターフェイスでダウンストリーム ネイバーから Prune(S,G) を受信し、プルーンが別のダウンストリーム ルータによってオーバーライドされるかどうかを待機しています。転送の目的では、PrunePending 状態は NoInfo 状態とまったく同じように機能します。
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.
Pruned(P) ルータは、このインターフェイス上でダウンストリーム ネイバーから Prune(S,G) を受信しましたが、Prune はオーバーライドされませんでした。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.
PrunePending タイマー (PPT(S,G,I)) このタイマーは、有効な Prune(S,G) が受信されたときに設定されます。PrunePending タイマー (PPT(S,G,I)) が満了すると、インターフェイスは Pruned 状態に移行します。
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.
Prune タイマー (PT(S,G,I)) このタイマーは、PrunePending タイマー (PT(S,G,I)) が期限切れになると設定されます。プルーン タイマー (PT(S,G,I)) が満了すると、インターフェイスは NoInfo (NI) 状態に移行し、S からグループ G にアドレス指定されたデータがインターフェイス上で転送されるようになります。
+-------------+ +-------------+
| | 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.
遷移イベント「Receive Graft(S,G)」、「Receive Prune(S,G)」、および「Receive Join(S,G)」は、このルータのアドレスが I に含まれる Graft、Prune、または Join メッセージを受信することを示します。メッセージの上流隣接フィールドに含まれます。上流の近隣フィールドが I 上のこのルータのアドレスと一致しない場合、このステート マシンでのこれらの状態遷移は発生してはなりません。
When the Prune(S,G) Downstream state machine is in the NoInfo (NI) state, the following events may trigger a transition:
Prune(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.
Receive Prune(S,G) Prune(S,G) は、インターフェイス I でルータのアドレスに設定されたアップストリーム ネイバー フィールドとともにインターフェイス I で受信されます。インターフェイス I の Prune(S,G) ダウンストリーム ステート マシンは、PrunePending に移行する必要があります。(PP)状態。ルーターが I 上に複数のネイバーを持つ場合、PrunePending タイマー (PPT(S,G,I)) を J/P_Override_Interval に設定しなければなりません (MUST)。ルーターがインターフェイス I 上にネイバーが 1 つしかない場合、PPT(S,G,I) を設定すべきです(SHOULD)。、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.
Receive Graft(S,G) Graft(S,G) は、インターフェイス I でルータのアドレスに設定されたアップストリーム ネイバー フィールドとともにインターフェイス I で受信されます。インターフェイス I の Prune(S,G) ダウンストリーム ステート マシンは、NoInfo に留まります。(NI) 状態。GraftAck(S,G) は Graft(S,G) メッセージの発信者にユニキャストされなければなりません (MUST)。
When the Prune(S,G) downstream state machine is in the PrunePending (PP) state, the following events may trigger a transition.
Prune(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.
Join(S,G) の受信 Join(S,G) は、インターフェイス I でルータのアドレスに設定されたアップストリーム ネイバー フィールドとともにインターフェイス I で受信されます。インターフェイス I の Prune(S,G) ダウンストリーム ステート マシンは、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.
Receive Graft(S,G) Graft(S,G) は、インターフェイス I でルータのアドレスに設定されたアップストリーム ネイバー フィールドとともにインターフェイス I で受信されます。インターフェイス I の Prune(S,G) ダウンストリーム ステート マシンは、NoInfo に移行する必要があります。(NI) 状態であり、Graft Ack メッセージを Graft 発信者にユニキャストしなければなりません (MUST)。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) の期限が切れる PrunePending タイマー (PPT(S,G,I)) が期限切れになり、近隣の誰も以前の Prune(S,G) メッセージをオーバーライドしていないことを示します。インターフェイス I の Prune(S,G) ダウンストリーム ステート マシンは、Pruned (P) 状態に遷移する必要があります。プルーン タイマー (PT(S,G,I)) が開始され、受信した Prune_Hold_Time から J/P_Override_Interval を引いた値に初期化されなければなりません。複数の PIM ネイバーがある場合は、PruneEcho(S,G) を I で送信する必要があります。PruneEcho(S,G) は、それ自体をアップストリーム ネイバーとして、アップストリーム ルータによって LAN にマルチキャストされる Prune(S,G) メッセージです。その目的は、Prune をオーバーライドするはずだった Join が LAN 上でローカルに失われた場合に、PruneEcho(S,G) を受信して新しい Join メッセージをトリガーできるように、信頼性を高めることです。PruneEcho(S,G) は、PIM ネイバーが 1 つだけあるインターフェイスではオプションです。さらに、ルータは、アップストリーム(S,G) ステートマシンで起こり得るあらゆる遷移を評価しなければなりません (MUST)。
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) はインターフェイス I になります S の上流インターフェイスが変更されました。インターフェイス I の Prune(S,G) ダウンストリーム ステート マシンは、NoInfo (NI) 状態に遷移する必要があります。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.
Prune(S,G) ダウンストリーム ステート マシンが Pruned (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.
Receive Prune(S,G) Prune(S,G) は、インターフェイス I でルータのアドレスに設定されたアップストリーム ネイバー フィールドとともにインターフェイス I で受信されます。インターフェイス I の Prune(S,G) ダウンストリーム ステート マシンは、Pruned 状態のままになります。(P)の状態。Prune タイマー (PT(S,G,I)) が現在の値より大きい場合、Prune(S,G) メッセージに含まれるホールドタイムにリセットされるべきです (SHOULD)。
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.
Join(S,G) の受信 Join(S,G) は、I 上のルータのアドレスに設定されたアップストリーム ネイバー フィールドを持つインターフェイス I で受信されます。インターフェイス I 上の Prune(S,G) ダウンストリーム ステート マシンは、インターフェイス I に移行する必要があります。NoInfo (NI) 状態。プルーン タイマー (PT(S,G,I)) はキャンセルする必要があります。ルータは、Upstream(S,G) ステートマシンで起こり得るあらゆる遷移を評価しなければなりません (MUST)。
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.
Receive Graft(S,G) Graft(S,G) は、インターフェイス I でルータのアドレスに設定されたアップストリーム ネイバー フィールドとともにインターフェイス I で受信されます。インターフェイス I の Prune(S,G) ダウンストリーム ステート マシンは、NoInfo に移行する必要があります。(NI) 状態を確認し、Graft Ack を Graft のソースに送り返します。プルーン タイマー (PT(S,G,I)) はキャンセルする必要があります。ルータは、Upstream(S,G) ステートマシンで起こり得るあらゆる遷移を評価しなければなりません (MUST)。
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) の期限切れ プルーン タイマー (PT(S,G,I)) が期限切れになり、グループ G にアドレス指定された S からのデータを再びインターフェイス I にフラッディングする時期が来たことを示します。インターフェイス上のダウンストリーム ステート マシンは、NoInfo (NI) 状態に遷移する必要があります。ルータは、Upstream(S,G) ステートマシンで起こり得るあらゆる遷移を評価しなければなりません (MUST)。
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) はインターフェイス I になります S の上流インターフェイスが変更されました。インターフェイス I の Prune(S,G) ダウンストリーム ステート マシンは、NoInfo (NI) 状態に遷移する必要があります。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 に State Refresh(S,G) を送信します。ルーターはインターフェイス I の Prune(S,G) 状態をリフレッシュしました。ルーターは、Prune Timer (PT(S,G,I)) をアクティブな状態からホールドタイムにリセットしなければなりません(MUST)。インターフェイス 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.
State Refresh メッセージ (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;
if (I は prunes(S,G) に含まれています) { SRM のプルーン インジケータ ビットを 1 に設定します。
if StateRefreshCapable(I) == TRUE
set PT(S,G) to largest active holdtime read from a Prune
message accepted on I;
} else {
set Prune Indicator bit of SRM' to 0;
}
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; }
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 に設定されている場合、Boundary(I,G) は TRUE になります。
StateRefreshCapable(I) is TRUE if all neighbors on an interface use the State Refresh option.
インターフェイス上のすべてのネイバーが State Refresh オプションを使用する場合、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.
StateRefreshRateLimit(S,G) は、最後に受信した StateRefresh(S,G) からの経過時間が設定された RefreshLimitInterval より短い場合に 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) は、状態リフレッシュ メッセージ (SRM) に含まれる TTL を返します。これは、IP ヘッダーに含まれる TTL とは異なります。
Threshold(I) returns the minimum TTL that a packet must have before it can be transmitted on interface I.
Threshold(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.
このセクションでは、State Refresh メッセージの生成について説明します。これらのメッセージは、送信元に直接接続されている PIM-DM ルーターによって定期的に生成されます。PIM-DM ルーターの (S,G) エントリごとに 1 つの Origination(S,G) ステート マシンが存在します。
The Origination(S,G) state machine has the following states:
Origination(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) これは、Origination(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.
Originator(O) この状態にある場合、ルータは定期的に State Refresh メッセージを発信します。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)) このタイマーは、状態リフレッシュ メッセージが生成されるタイミングを制御します。タイマーは、Origination(S,G) ステート マシンが O ステートに遷移するときに最初に設定されます。Origination(S,G) ステート マシンが NO ステートに遷移すると、これはキャンセルされます。このタイマーは通常、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)) このタイマーは、Origination(S,G) ステート マシンが O ステートに遷移するときに最初にセットされ、グループ G にアドレス指定された S からのすべてのデータ パケットを受信するとリセットされます。有効期限が切れると、Origination(S,G) ステート マシンは NO 状態に遷移します。このタイマーは通常、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:
Originating(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.
グループ G にアドレス指定された直接接続されたソース S から受信したデータ パケット ルータは、発信者 (O) 状態に遷移し、SAT(S,G) を SourceLifetime に設定し、SRT(S,G) を StateRefreshInterval に設定しなければなりません (MUST)。ルーターは、State Refresh メッセージで使用するためにパケットの TTL を記録すべきです (SHOULD)。
When the Originating(S,G) state machine is in the Originator (O) state, the following events may trigger a transition:
Originating(S,G) ステート マシンが Originator (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 から G 宛てのデータ パケットを受信する ルータは発信者 (O) 状態のままであり、SAT(S,G) を SourceLifetime にリセットしなければなりません (MUST)。パケットの TTL が以前に記録された TTL よりも大きい場合、ルータはパケットの TTL と一致するように記録された TTL を増やす必要があります (SHOULD)。ルータは、処理するすべてのマルチキャスト パケットの TTL を検査することを避けるために、実装固有のサンプリング ポリシーに基づいて TTL を記録してもよい(MAY)。
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) 状態のままであり、SRT(S,G) を StateRefreshInterval にリセットしなければなりません。ルーターは、TTL を除き、State Refresh Forwarding ルール (セクション 4.5.1) で説明されているように、送信用の State Refresh メッセージも生成しなければなりません (MUST)。S から G までのデータ パケットの TTL が記録されている場合、各 State Refresh メッセージの TTL は記録された最高の TTL に設定されます。それ以外の場合、TTL は構成された状態リフレッシュ TTL に設定されます。State Refresh メッセージが送信されるインターフェイスを示します。Prune(S,G) ダウンストリーム ステート マシンが Pruned (P) 状態にある場合、I 経由で送信される State Refresh メッセージ内で Prune-Indicator ビットを 1 に設定しなければなりません (MUST)。それ以外の場合、Prune-Indicator ビットは必ず 1 に設定しなければなりません (MUST)。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) 状態に移行しなければなりません (MUST)。
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) の両方をキャンセルしなければなりません (MUST)。
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 フィールドが順番に比較され、最初に小さい値が優先されます。すべてのフィールドが等しい場合、Assert メッセージの送信元ルーターの IP アドレスがタイブレーカーとして使用され、最大の IP アドレスが優先されます。
An Assert metric for (S,G) to include in (or compare against) an Assert message sent on interface I should be computed by using the following pseudocode:
インターフェイス I で送信されるアサート メッセージに含める (または比較する) (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()
}
}
spt_assert_metric(S,I) gives the Assert metric we use if we're sending an Assert based on active (S,G) forwarding state:
spt_assert_metric(S,I) は、アクティブ (S,G) フォワーディング状態に基づいてアサートを送信する場合に使用するアサート メトリックを示します。
assert_metric
spt_assert_metric(S,I) {
return {0,MRIB.pref(S),MRIB.metric(S),my_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:
finity_assert_metric() は、Assert を送信するために必要な Assert メトリックを提供しますが、(S,G) 転送状態と一致しません。
assert_metric
infinite_assert_metric() {
return {1,infinity,infinity,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) の Assert メッセージです。Assert 勝者は、アップストリーム インターフェイスをこのインターフェイスに変更するときに、このメッセージを送信します。他のルーターはこのメトリックを確認し、フォワーディング状態を持つルーターが独自のアサートを送信し、アサート勝者を再確立します。
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 メッセージは現在の勝者からの Assert メッセージであるため、特別な処理は必要ありません。
The macro lost_assert(S,G,I), is used in the olist computations of Section 4.1.3, and is defined as follows:
マクロ loss_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)))
}
}
AssertWinner(S,G,I) defaults to NULL, and AssertWinnerMetric(S,G,I) defaults to Infinity when in the NoInfo state.
NoInfo 状態の場合、AssertWinner(S,G,I) はデフォルトで NULL になり、AssertWinnerMetric(S,G,I) はデフォルトで Infinity になります。
The (S,G) Assert state machine for interface I is shown in Figure 4. There are three states:
インターフェイス I の (S,G) Assert ステート マシンを図 4 に示します。次の 3 つの状態があります。
NoInfo (NI) This router has no (S,G) Assert state on interface I.
NoInfo (NI) このルータには、インターフェイス I に (S,G) アサート状態がありません。
I am Assert Winner (W) This router has won an (S,G) Assert on interface I. It is now responsible for forwarding traffic from S destined for G via interface I.
I am Assert Winner (W) このルータは、インターフェイス I で (S,G) Assert を獲得しました。現在、インターフェイス I を介して S から G 宛てのトラフィックを転送する役割を担っています。
I am Assert Loser (L) This router has lost an (S,G) Assert on interface I. It must not forward packets from S destined for G onto interface I.
私はアサート敗者です (L) このルータはインターフェイス I で (S,G) アサートを失いました。S から G 宛てのパケットをインターフェイス 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)
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) データ パケットがダウンストリーム インターフェイスに到着します。 I (S,G) データ パケットがダウンストリーム インターフェイスに到着します。このルータがこの (S,G) の Assert 勝者になると楽観的に想定されます。Assert ステート マシンは、「I am Assert Winner」状態に移行し、Assert(S,G) をインターフェイス I に送信し、自身のアドレスとメトリックを Assert Winner として保存し、Assert_Timer (AT(S,G,I) Assert_Time に設定し、それによって (S,G) の Assert ネゴシエーションを開始します。
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.
Receive Inferior (Assert OR State Refresh) AND CouldAssert(S,G,I)==TRUE インターフェイス I 上の独自のアサート メトリックよりも劣る (S,G) のアサートまたはステート リフレッシュを受信しました。アサート ステート マシンは [MUST] (必須)「I am Assert Winner」状態に移行し、Assert(S,G) をインターフェイス I に送信し、自身のアドレスとメトリックを Assert Winner として保存し、Assert Timer (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.
優先アサートまたはステート リフレッシュの受信 受信したアサートまたはステート リフレッシュは、このルータよりも優れたメトリックを持っているため、アサート ステート マシンは「I am Assert Loser」状態に移行し、アサート勝者のアドレスとメトリックを保存しなければなりません (MUST)。メトリックがアサートで受信された場合、ルータはアサート タイマー (AT(S,G,I)) を Assert_Time に設定しなければなりません (MUST)。メトリックがステート リフレッシュで受信された場合、ルータはアサート タイマー (AT(S,G,I)) を受信したステート リフレッシュ間隔の 3 倍に設定しなければなりません (MUST)。CouldAssert(S,G,I) == TRUE の場合、ルータはアサート タイマーと等しいプルーン ホールド タイムでアサート勝者に Prune(S,G) をマルチキャストし、そのアップストリーム(S,G) の変更を評価しなければなりません (MUST)。) ステートマシン。
When in "I am Assert Winner" state, the following events trigger transitions:
「I am Assert Winner」状態の場合、次のイベントが遷移をトリガーします。
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) データ パケットがダウンストリーム インターフェイスに到着します。 I (S,G) データ パケットがダウンストリーム インターフェイスに到着します。Assert ステート マシンは、「I am Assert Winner」状態のままです。ルータは、Assert(S,G) をインターフェイス I に送信し、Assert Timer (AT(S,G,I) を Assert_Time に設定しなければなりません)。
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 メトリックよりも悪い S メトリックを含む (S,G) アサートを受信しました。アサートを送信した人が間違っています。ルータは、Assert(S,G) をインターフェイス I に送信し、Assert Timer (AT(S,G,I)) を Assert_Time にリセットしなければなりません (MUST)。
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.
優先アサートまたはステート リフレッシュの受信 インターフェイス I 上のこのルーターの S メトリックよりも優れたメトリックを持つ (S,G) アサートまたはステート リフレッシュを受信しました。アサート ステート マシンは、「I am Assert Loser」状態に移行し、new 勝者のアドレスとメトリックをアサートします。メトリックがアサートで受信された場合、ルータはアサート タイマー (AT(S,G,I)) を Assert_Time に設定しなければなりません (MUST)。メトリックがステート リフレッシュで受信された場合、ルータはアサート タイマー (AT(S,G,I)) をステート リフレッシュ間隔の 3 倍に設定しなければなりません (MUST)。ルータはまた、Assert タイマーと等しい Prune Hold Time で Prune(S,G) を Assert 勝者にマルチキャストし、Upstream(S,G) ステートマシンの変更を評価しなければなりません (MUST)。
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) メッセージを送信しています。ルータは、アサート タイマー (AT(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 the NoInfo (NI) state.
AT(S,G,I) が期限切れになる (S,G) アサート タイマー (AT(S,G,I)) が期限切れになります。Assert ステート マシンは NoInfo (NI) 状態に遷移しなければなりません (MUST)。
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 になりました。このルーターはアサート勝者のアクションを実行できなくなります。そのため、アサート ステート マシンは NoInfo (NI) 状態に移行し、インターフェイス I に AssertCancel(S,G) を送信し、アサート タイマー (AT(S,G,I))、自身をアサート勝者から削除します。
When in "I am Assert Loser" state, the following transitions can occur:
「I am Assert Loser」状態になると、次の遷移が発生する可能性があります。
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 メトリックよりも悪いアサートまたはステート リフレッシュを受信しました（通常、勝者のメトリックは悪化しました）。Assert ステート マシンは NoInfo (NI) 状態に遷移し、AT(S,G,I) をキャンセルしなければなりません (MUST)。ルータは、以前の Assert Winner のアドレスとメトリックを削除し、Upstream(S,G) ステート マシンへの可能な遷移を評価しなければなりません (MUST)。通常、このルータは、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 ステート マシンは Loser (L) 状態のままです。メトリックがアサートで受信された場合、ルータはアサート タイマー (AT(S,G,I)) を Assert_Time に設定しなければなりません (MUST)。メトリックがステート リフレッシュで受信された場合、ルータはアサート タイマー (AT(S,G,I)) を受信したステート リフレッシュ間隔の 3 倍に設定しなければなりません (MUST)。メトリックが現在の Assert Winner よりも優れている場合、ルーターは新しい Assert Winner のアドレスとメトリックを保存しなければなりません (MUST)。CouldAssert(S,G,I) == TRUE の場合、ルーターは Prune(S,G) をマルチキャストしなければなりません (MUST)。新しいアサート勝者に。
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)) が期限切れになります。Assert ステート マシンは NoInfo (NI) 状態に遷移しなければなりません (MUST)。ルーターは、Assert Winner のアドレスとメトリックを削除しなければなりません (MUST)。CouldAssert == TRUE の場合、ルータは Upstream(S,G) ステート マシンへの可能な遷移を評価しなければなりません (MUST)。
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 -> FALSE インターフェイス I が S の RPF インターフェイスになったため、CouldAssert は FALSE になりました。 Assert ステート マシンは NoInfo (NI) 状態に移行し、AT(S,G,I) をキャンセルし、Assert Winner に関する情報を削除しなければなりません (MUST)。私。
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 -> TRUE インターフェース I は以前は S の RPF インターフェースでしたが、現在はそうではないため、CouldAssert は TRUE になりました。Assert ステート マシンは NoInfo (NI) 状態に遷移し、AT(S,G,I) をキャンセルし、I 上の Assert Winner に関する情報を削除しなければなりません (MUST)。
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)) が期限切れになりました。Assert ステート マシンは、NoInfo (NI) ステートに遷移し、Assert Winner のアドレスとメトリックを削除し、Upstream(S,G) ステート マシンへの可能な遷移を評価しなければなりません (MUST)。
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).
Receive Prune(S,G)、Join(S,G)、または Graft(S,G) Prune(S,G)、Join(S,G)、または Graft(S,G) メッセージがインターフェイス I で受信されました。ルータは、Assert ネゴシエーションを開始するために、受信インターフェイス I で Assert(S,G) を送信しなければなりません (MUST)。Assert ステート マシンは Assert Loser(L) 状態のままです。Graft(S,G) を受信した場合、ルータは GraftAck(S,G) で応答しなければなりません (MUST)。
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.
以下は、Assert メッセージの生成と処理のルールの概要です。これは最終的なものであることを意図したものではありません (ステート マシンと疑似コードが最終的な動作を提供します)。代わりに、その動作の理論的根拠を提供します。
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. 自分宛ての Prune(S,G)、Join(S,G)、または Graft(S,G) を受信した Assert 敗者は、ダウンストリーム ルータが RPF'(S) を修正できるように、新しい Assert ネゴシエーションを開始します。。4. (S,G) のアサート勝者は、(S,G) エントリの転送を停止しようとしているときに、キャンセルするアサートを送信します。例: ルーターがダウンしている場合、キャンセルアサートが送信されます。
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 メッセージは、TTL 1 で送信されなければなりません。Graft および Graft Ack メッセージを除くすべての PIM-DM メッセージは、ALL-PIM-ROUTERS グループに送信されなければなりません。グラフト メッセージは RPF にユニキャストされるべきです (SHOULD)。Graft Ack メッセージは Graft の送信者にユニキャストされなければなりません (MUST)。
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 Ver 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
Type 特定の PIM メッセージのタイプ。使用可能なタイプは次のとおりです。 0 = Hello 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].
IPv6 の場合、RFC 2460、セクション 8.1 [5] で指定されているように、チェックサムには IPv6 の「疑似ヘッダー」も含まれます。
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 Family このアドレスの「ユニキャスト アドレス」フィールドの PIM アドレス ファミリ。値 0 ～ 127 は、[9] でインターネット アドレス ファミリに対して IANA によって割り当てられたものです。値 128 ～ 250 は、IANA によって PIM 固有のアドレス ファミリに割り当てられるように予約されています。値 251 ～ 255 は私用に指定されています。このスペースには割り当て権限がないため、衝突が予想されるはずです。
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.
アドレスファミリー 上で説明したとおり。
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.
Mask Len マスク長フィールドは 8 ビットです。この値は、マスクとして使用される連続する左詰めの 1 ビットの数であり、アドレスと組み合わされてアドレス範囲を表します。これは、指定されたアドレス ファミリおよびエンコーディング タイプのビット単位のアドレス長以下です。メッセージが単一のアドレスに送信される場合、マスクの長さはアドレスの長さと等しくなければなりません。PIM-DM ルーターは、単一のアドレスに対してのみ送信しなければなりません (MUST)。
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.
アドレスファミリー 上で説明したとおり。
Encoding Type As described above.
エンコーディングタイプ 前述の通り。
Rsrvd Reserved. Transmitted as zero. Ignored upon receipt.
予約済み。ゼロとして送信されます。受信時に無視されました。
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 ルーターは、単一の送信元アドレスに対してのみ送信しなければなりません (MUST)。
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 Ver、Type、Reserved、Checksum 上記。
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」に設定されている場合、情報はすぐにタイムアウトになります。Hello Hold Time オプションは、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 に設定され、受信時に無視されるべきです (SHOULD)。「LAN 遅延」フィールドと「オーバーライド間隔」フィールドは、ミリ秒単位の時間間隔であり、J/P オーバーライド間隔の値とその派生タイマー値を調整するために使用されます。セクション 4.3.5 では、これらの値がルーターの動作にどのような影響を与えるかについて説明します。LAN プルーン遅延は、PIM-DM ルーターによって使用される必要があります (SHOULD)。
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 メッセージが送信されるインターフェイスのランダムな値です。生成 ID は、インターフェイス上で PIM 転送が開始または再開されるたびに再生成されます。Generation ID オプションは、PIM-DM ルーターによって使用されてもよい(MAY)。
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.
[間隔] フィールドは、ルーターに設定された状態更新間隔 (秒単位) です。Reserved フィールドはゼロに設定され、受信時に無視されます。State Refresh Capable オプションは、State Refresh 対応 PIM-DM ルーターで使用する必要があります。
PIM Join/Prune messages, as defined in PIM-SM [4], have the following format:
PIM-SM [4] で定義されている PIM Join/Prune メッセージの形式は次のとおりです。
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 Ver、Type、Reserved、Checksum 上記。
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.
Hold Time 受信側 PIM-DM ルーターが、Join または Graft メッセージによって削除されない限り、Prune 状態を維持しなければならない秒数。Hold Time が '0xffff' の場合、受信側は、対応する Join または Graft メッセージを受信しない限り、Prune 状態を削除してはなりません (MUST NOT)。ホールド タイムは参加メッセージでは無視されます。
Number of Groups Number of multicast group sets contained in the message.
Number of Groups メッセージに含まれるマルチキャスト グループ セットの数。
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-SM [4] で定義されている 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Metric Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Ver, Type, Reserved, Checksum Described above.
PIM Ver、Type、Reserved、Checksum 上記。
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 Graft メッセージは、Type フィールドが 6 に設定されていることを除いて、Join/Prune メッセージと同じ形式を使用します。送信元アドレスは、メッセージの Join セクションになければなりません。Hold Time フィールドはゼロであるべきであり、グラフトの受信時には無視されるべきです。
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.
PIM Graft Ack メッセージは、Type フィールドが 7 に設定されることを除いて、受信した Graft メッセージと形式が同じです。Upstream Neighbor Address フィールドは Graft メッセージの送信者に設定されるべきであり、受信時に無視されるべきです。
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 Ver、Type、Reserved、Checksum 上記。
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 Time To Live。メッセージが転送されるたびに減分されます。これは、常に 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 プルーンインジケーターフラグ。State Refresh がプルーニングされたインターフェイスで送信される場合は、これを 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 今すぐプルーンするフラグ。これは、State Refresh メッセージの 3 つごとに State Refresh 発信者によって 1 に設定されるべきであり、受信時には無視されるべきです (SHOULD)。これは、以前のバージョンの状態リフレッシュとの互換性のためです。
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.
Interval この (S,G) ペアの連続する State Refresh メッセージ間の間隔 (秒単位) が発信元ルーターによって設定されます。
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)
インターフェイスごと (I): ネイバーごと (N): ネイバー ライブネス タイマー: NLT(N,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)
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)
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) に初期化されます。新しいネイバーまたは再起動中のネイバーが検出されると、応答する Hello が rand(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 プルーン遅延オプションを使用している場合、両方のパラメータを 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).
歴史的な理由により、Assert メッセージには Holdtime フィールドが欠如していることに注意してください。したがって、アサート時間をデフォルト値から変更することは推奨されません。LAN のすべてのメンバーが状態リフレッシュを有効にしている場合、アサート時間は受信した RefreshInterval(S,G) の 3 倍になります。
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 Prune 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 と直接対話することを目的としていません。ルーターは、Hello メッセージに基づいて PIM-DM ネイバーと 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 ルーターのネイバーになる場合、この 2 つは事実上シンプレックス リンクを形成し、PIM-DM ルーターはすべてのマルチキャスト メッセージを PIM-SM ルーターに送信し、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-SM を使用し、ランデブー ポイントがわかっていない場合は PIM-DM を使用するハイブリッド 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 ルータがそのインターフェイス上で Assert Loser 状態にある場合を除くすべての場合、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 優先度オプションを使用してもよい(MAY)。
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 ルーターは、特定のグループに関するメッセージをそのグループのスコープ境界を越えて送信してはなりません (MUST NOT)。
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: Values 0 - 127 are designated to have the same meaning as IANA assigned Address Family Numbers [9].
PIM アドレス ファミリ フィールドは、パケット フォーマットと IANA 割り当て番号の使用との間のトレードオフとして 8 ビットが選択されました。PIM パケット形式が設計されたとき、アドレス ファミリに割り当てられた値は 15 のみであり、多数の新しいアドレス ファミリは想定されていませんでした。8 ビットでも十分大きいように思えました。ただし、IANA はアドレス ファミリを 16 ビット値で割り当てます。したがって、PIM アドレス ファミリは次のように割り当てられます。値 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 は、[8] で定義されているように、IESG の承認に基づいて IANA によって割り当てられるように指定されています。
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 プロトコル メッセージのデータ完全性保護とグループごとのデータ発信元認証を提供するために使用できます (MAY)。PIM メッセージを認証すると、未承認または変更された PIM メッセージによって引き起こされる望ましくない動作から保護できます。いずれの場合でも、PIM ルータは、近隣から有効な Hello メッセージを受信しない限り、近隣からの PIM メッセージを受け入れて処理してはなりません (SHOULD NOT)。
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. 偽造された 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. 偽造された Join/Prune メッセージにより、正当な要求元が存在しないリンクにマルチキャスト トラフィックが配信され、そのリンクの帯域幅が無駄になる可能性があります。マルチアクセス LAN 上で偽造された Prune メッセージは、通常、PIM では重大な攻撃ではありません。これは、LAN 上の正当に参加しているルータは、上流のルータが LAN へのデータの転送を停止する前に、Join で Prune をオーバーライドするためです。
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. 偽造された Graft メッセージにより、正当な要求元が存在しないリンクにマルチキャスト トラフィックが配信され、そのリンクの帯域幅が無駄になる可能性があります。原則として、グラフト メッセージは上流ルーターにユニキャストされるため、複数のホップで送信される可能性があります。リモート偽造者は攻撃対象に Hello メッセージを取得する方法がないはずなので、これは問題にはなりません。有効な Hello メッセージがなければ、受信ルータは Graft を受け入れるべきではありません (SHOULD NOT)。
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. ルーターが最近上流ルーターに Graft を送信していない限り無視されるため、偽造された 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. マルチアクセス LAN 上で偽造された State Refresh メッセージは、同じ一般的な機能を持ち、偽造された Assert メッセージと同じ影響を及ぼします。さらに、偽造された State Refresh メッセージが下流に伝播され、サービス拒否攻撃に使用される可能性があります。したがって、PIM-DM ルーターは、伝播される State Refresh メッセージのレートを制限する必要があります (SHOULD)。
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 メッセージを受け入れるネイバーのセットを制限するオプションを提供すべきです (SHOULD)。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 メッセージをまだ受信していないルーターからのプロトコル メッセージを受け入れてはなりません (SHOULD NOT)。
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 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.
PIM で上記の攻撃を防ぐには、認証ヘッダー (AH) を使用する IPSec [10] トランスポート モードが推奨される方法です。認証アルゴリズムの選択やキーの選択など、特定の AH 認証アルゴリズムとパラメータは、ネットワーク管理者によって構成されます。カプセル化セキュリティ ペイロード (ESP) は、PIM プロトコル メッセージの暗号化と認証の両方を提供するために使用することもできます (MAY)。IPsec 認証が使用される場合、PIM ルーターは、許可されていない PIM プロトコル メッセージを拒否する (処理せずにドロップする) 必要があります (SHOULD)。
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 ルータに対して認証キーを 1 つだけ確立することが許容されます。これは、メッセージを送信する個々のルーターを具体的に認証するわけではありませんが、送信者がそのリンク上の 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 ルーターは、伝播される State Refresh メッセージの速度を制限する必要があります (SHOULD)。
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 の主な機能は、もともと Stephen Deering、Deborah Estrin、Dino Farinacci、Van Jacobson、Ahmed Helmy、David Meyer、Liming Wei によって設計されました。状態更新の追加機能は、Dino Farinacci、Isidor Kouvelas、Kurt 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] Deering, S.、「IP マルチキャストのホスト拡張」、STD 5、RFC 1112、1989 年 8 月。
[2] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[2] Fenner, 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] Cain, B.、Deering, S.、Kouvelas, I.、Fenner, 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.、Farinacci, D.、Helmy, A.、Thaler, D.、Deering, S.、Handley, M.、Jacobson, V.、Liu, C.、Sharma, P.、L. Wei、「プロトコル独立マルチキャスト - スパース モード (PIM-SM): プロトコル仕様」、RFC 2362、1998 年 6 月。
[5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[5] Deering, 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] Deering, S.、Fenner, W.、および B. Haberman、「IPv6 のマルチキャスト リスナー検出 (MLD)」、RFC 2710、1999 年 10 月。
[7] Thaler, D., "Interoperability Rules for Multicast Routing Protocols", RFC 2715, October 1999.
[7] Thaler, D.、「マルチキャスト ルーティング プロトコルの相互運用性ルール」、RFC 2715、1999 年 10 月。
[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. Alvestruct、「RFC で IANA 考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998 年 10 月。
[9] IANA, "Address Family Numbers", linked from http://www.iana.org/numbers.html.
[9] IANA、「Address Family Numbers」、http://www.iana.org/numbers.html からリンク。
[10] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[10] Kent, S. および R. Atkinson、「インターネット プロトコルのセキュリティ アーキテクチャ」、RFC 2401、1998 年 11 月。
[11] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[11] Bradner, S.、「要件レベルを示すために RFC で使用するキーワード」、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] Deering, S.E.、「データグラム インターネットワークにおけるマルチキャスト ルーティング」、Ph.D.論文、スタンフォード大学電気工学部、1991 年 12 月。
[13] Waitzman, D., Partridge, C., and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988.
[13] Waitzman, D.、Partridge, C.、および S. Deering、「距離ベクトル マルチキャスト ルーティング プロトコル」、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] Fenner, W.、Handley, M.、Holbrook, H.、および I. Kouvelas、「プロトコルに依存しないマルチキャスト - スパース モード (PIM-SM): プロトコル仕様 (改訂版)」、進行中の作業。
[15] Holbrook, H. and B. Cain, "Source Specific Multicast for IP", Work in Progress.
[15] Holbrook、H.、B. Cain、「Source Specific Multicast for IP」、進行中。
[16] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bi-directional Protocol Independent Multicast", Work in Progress.
[16] Handley, M.、Kouvelas, I.、Speakman, 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.、Weis, B.、Hardjono, T.、および H. Harney、「The Group Domain of Interpretation」、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] Fenner, W.、Handley, M.、Kermode, R.、および D. Thaler、「PIM スパース モードのブートストラップ ルーター (BSR) メカニズム」、進行中。
Authors' Addresses
著者の住所
Andrew Adams NextHop Technologies 825 Victors Way, Suite 100 Ann Arbor, MI 48108-2738
Andrew Adams NextHop Technologies 825 Victors Way, Suite 100 Ann Arbor, MI 48108-2738
EMail: ala@nexthop.com
Jonathan Nicholas ITT Industries Aerospace/Communications Division 100 Kingsland Rd Clifton, NJ 07014
Jonathan Nicholas ITT Industries 航空宇宙/通信部門 100 Kingsland Rd Clifton, NJ 07014
EMail: jonathan.nicholas@itt.com
William Siadak NextHop Technologies 825 Victors Way, Suite 100 Ann Arbor, MI 48108-2738
William Siadak NextHop Technologies 825 Victors Way, Suite 100 Ann Arbor, MI 48108-2738
EMail: 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.
この文書およびここに含まれる情報は「現状のまま」で提供され、寄稿者、寄稿者が代表または後援する組織（存在する場合）、インターネット協会およびインターネット エンジニアリング タスク フォースは、明示的または明示的または明示的に、すべての保証を否認します。ここに記載された情報の使用がいかなる権利も侵害しないことの黙示的な保証、または商品性や特定の目的への適合性の黙示的な保証を含みますが、これに限定されません。
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.
IETF 事務局に提出された IPR 開示のコピー、および利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような所有権の使用に対する一般ライセンスまたは許可を取得しようとする試みの結果を入手できます。IETF オンライン IPR リポジトリ http://www.ietf.org/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 (ietf-ipr@ietf.org) に送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC エディター機能の資金は現在、インターネット協会によって提供されています。