Network Working Group M. Handley
Request for Comments: 5015 UCL
Category: Standards Track I. Kouvelas
T. Speakman
Cisco
L. Vicisano
Digital Fountain
October 2007
Bidirectional Protocol Independent Multicast (BIDIR-PIM)
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
This document discusses Bidirectional PIM (BIDIR-PIM), a variant of PIM Sparse-Mode that builds bidirectional shared trees connecting multicast sources and receivers. Bidirectional trees are built using a fail-safe Designated Forwarder (DF) election mechanism operating on each link of a multicast topology. With the assistance of the DF, multicast data is natively forwarded from sources to the Rendezvous-Point (RP) and hence along the shared tree to receivers without requiring source-specific state. The DF election takes place at RP discovery time and provides the route to the RP, thus eliminating the requirement for data-driven protocol events.
この文書は、双方向PIM（BIDIR-PIM）、マルチキャスト送信元と受信機とを接続する双方向の共有ツリーを構築するPIMスパースモードの変形例を説明します。双方向ツリーは、マルチキャストトポロジの各リンク上で動作してフェイルセーフ指定フォワーダ（DF）選挙メカニズムを使用して構築されています。 DFの助けを借りて、マルチキャストデータは、ネイティブソース固有の状態を必要とせずに、ランデブーポイント（RP）に、したがって、受信機への共有ツリーに沿ってソースから転送されます。 DF選定はRP発見時間で行われますので、データ駆動型のプロトコルイベントの必要性を排除し、RPへのルートを提供します。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
2.1. Definitions ................................................4
2.2. Pseudocode Notation ........................................6
3. Protocol Specification ..........................................6
3.1. BIDIR-PIM Protocol State ...................................7
3.1.1. General Purpose State ...............................8
3.1.2. RPA State ...........................................8
3.1.3. Group State .........................................9
3.1.4. State Summarization Macros .........................10
3.2. PIM Neighbor Discovery ....................................11
3.3. Data Packet Forwarding Rules ..............................11
3.3.1. Upstream Forwarding at RP ..........................12
3.3.2. Source-Only Branches ...............................12
3.3.3. Directly Connected Sources .........................13
3.4. PIM Join/Prune Messages ...................................13
3.4.1. Receiving (*,G) Join/Prune Messages ................13
3.4.2. Sending Join/Prune Messages ........................16
3.5. Designated Forwarder (DF) Election ........................18
3.5.1. DF Requirements ....................................18
3.5.2. DF Election Description ............................19
3.5.2.1. Bootstrap Election ........................20
3.5.2.2. Loser Metric Changes ......................20
3.5.2.3. Winner Metric Changes .....................21
3.5.2.4. Winner Loses Path .........................22
3.5.2.5. Late Router Starting Up ...................22
3.5.2.6. Winner Dies ...............................22
3.5.3. Election Protocol Specification ....................22
3.5.3.1. Election State ............................22
3.5.3.2. Election Messages .........................23
3.5.3.3. Election Events ...........................24
3.5.3.4. Election Actions ..........................25
3.5.3.5. Election State Transitions ................26
3.5.4. Election Reliability Enhancements ..................30
3.5.5. Missing Pass .......................................30
3.5.6. Periodic Winner Announcement .......................30
3.6. Timers, Counters, and Constants ...........................31
3.7. BIDIR-PIM Packet Formats ..................................34
3.7.1. DF Election Packet Formats .........................34
3.7.2. Backoff Message ....................................36
3.7.3. Pass Message .......................................36
3.7.4. Bidirectional Capable PIM-Hello Option .............37
4. RP Discovery ...................................................37
5. Security Considerations ........................................38
5.1. Attacks Based on Forged Messages ..........................38
5.1.1. Election of an Incorrect DF ........................38
5.1.2. Preventing Election Convergence ....................39
5.2. Non-Cryptographic Authentication Mechanisms ...............39
5.2.1. Basic Access Control ...............................39
5.3. Authentication Using IPsec ................................40
5.4. Denial-of-Service Attacks .................................40
6. IANA Considerations ............................................40
7. Acknowledgments ................................................40
8. Normative References ...........................................40
9. Informative References .........................................41
List of Figures
Figure 1. Downstream group per-interface state machine ............15
Figure 2. Upstream group state machine ............................17
Figure 3. Designated Forwarder election state machine .............27
This document specifies Bidirectional PIM (BIDIR-PIM), a variant of PIM Sparse-Mode (PIM-SM) [4] that builds bidirectional shared trees connecting multicast sources and receivers.
この文書は、双方向PIM（BIDIR-PIM）、PIMスパースモード（PIM-SM）[4]マルチキャストソースおよび受信機を接続する双方向の共有ツリーを構築するの変異体を指定します。
PIM-SM constructs unidirectional shared trees that are used to forward data from senders to receivers of a multicast group. PIM-SM also allows the construction of source-specific trees, but this capability is not related to the protocol described in this document.
PIM-SMは、マルチキャストグループの受信者に送信者からデータを転送するために使用される一方向共有ツリーを構築します。 PIM-SMは、ソース特有の木の構築を可能にするが、この機能は、本文書に記載のプロトコルに関連しません。
The shared tree for each multicast group is rooted at a multicast router called the Rendezvous Point (RP). Different multicast groups can use separate RPs within a PIM domain.
各マルチキャストグループの共有ツリーは、ランデブーポイント（RP）と呼ばれるマルチキャストルータに根ざしています。異なるマルチキャストグループには、PIMドメイン内の別のRPを使用することができます。
In unidirectional PIM-SM, there are two possible methods for distributing data packets on the shared tree. These differ in the way packets are forwarded from a source to the RP:
一方向PIM-SMは、共有ツリー上のデータパケットを配信するための二つの可能な方法があります。これらは、パケットはRPにソースから転送される方法が異なります。
o Initially, when a source starts transmitting, its first hop router encapsulates data packets in special control messages (Registers) that are unicast to the RP. After reaching the RP, the packets are decapsulated and distributed on the shared tree.
ソースが送信を開始するときにOまず、最初のホップルータは、RPにユニキャストされている特殊な制御メッセージ（レジスタ）にデータパケットをカプセル化します。 RPに達した後、パケットはカプセル化が解除され、共有ツリー上に分散します。
o A transition from the above distribution mode can be made at a later stage. This is achieved by building source-specific state on all routers along the path between the source and the RP. This state is then used to natively forward packets from that source.
O上記分配モードからの遷移は、後の段階で行うことができます。これは、ソースとRPとの間の経路に沿った全てのルータでソース固有の状態を構築することによって達成されます。この状態は、そのソースからネイティブにパケットを転送するために使用されます。
Both of these mechanisms suffer from problems. Encapsulation results in significant processing, bandwidth, and delay overheads. Forwarding using source-specific state has additional protocol and memory requirements.
これらのメカニズムの両方が問題を抱えています。重要な処理、帯域幅、および遅延オーバーヘッドでのカプセル化の結果。ソース固有の状態を用いて転送することは、追加のプロトコルおよびメモリ要件を有しています。
Bidirectional PIM dispenses with both encapsulation and source state by allowing packets to be natively forwarded from a source to the RP using shared tree state. In contrast to PIM-SM, this mode of forwarding does not require any data-driven events.
双方向PIMは、パケットがネイティブで共有ツリーの状態を使用してRPにソースから転送されるようにすることによって、カプセル化、ソース状態の両方で分配します。 PIM-SMとは対照的に、フォワーディングのこのモードでは、任意のデータ駆動型のイベントを必要としません。
The protocol specification in this document assumes familiarity with the PIM-SM specification in [4]. Portions of the BIDIR-PIM protocol operation that are identical to that of PIM-SM are only defined by reference.
この文書に記載されているプロトコル仕様[4]におけるPIM-SM仕様に精通して前提。 PIM-SMのものと同一であるBIDIR-PIMプロトコルの動作の一部のみが参照することにより定義されます。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and indicate requirement levels for compliant BIDIR-PIM implementations.
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" RFC 2119に記載されるように解釈されるべきである[1]と対応BIDIR-PIM実装の要求レベルを示します。
This specification uses a number of terms to refer to the roles of routers participating in BIDIR-PIM. The following terms have special significance for BIDIR-PIM:
この仕様はBIDIR-PIMに参加するルータの役割を参照するために多くの用語を使用します。以下の用語はBIDIR-PIMのための特別な意味を持っています。
Multicast Routing Information Base (MRIB) The multicast topology table, which is typically derived from the unicast routing table, or routing protocols such as Multiprotocol BGP (MBGP) [8] that carry multicast-specific topology information. It is used by PIM for establishing the RPF interface (used in the forwarding rules). In PIM-SM, the MRIB is also used to make decisions regarding where to forward Join/Prune messages, whereas in BIDIR-PIM, it is used as a source for routing metrics for the DF election process.
典型的には、ユニキャストルーティングテーブル、又はそのようなマルチプロトコルBGP（MBGP）などのルーティングプロトコルから導出されるマルチキャストルーティング情報ベース（MRIB）マルチキャストトポロジーテーブル、[8]マルチキャスト固有のトポロジ情報を運ぶこと。これは、（転送ルールで使用される）RPFインターフェイスを確立するためにPIMによって使用されます。 BIDIR-PIMで、それはDF選定プロセスのメトリックをルーティングするためのソースとして使用されているのに対し、PIM-SMでは、MRIBはまた、/プルーンJoinメッセージを転送する方法に関する決定を行うために使用されます。
Rendezvous Point Address (RPA) An RPA is an address that is used as the root of the distribution tree for a range of multicast groups. The RPA must be routable from all routers in the PIM domain. The RPA does not need to correspond to an address for an interface of a real router. In this respect, BIDIR-PIM differs from PIM-SM, which requires an actual router to be configured as the Rendezvous Point (RP). Join messages from receivers for a BIDIR-PIM group propagate hop-by-hop towards the RPA.
ランデブーポイントアドレスは、（RPA）RPAアンはマルチキャストグループの範囲の配信ツリーのルートとして使用されるアドレスです。 RPAは、PIMドメイン内のすべてのルータからのルーティング可能でなければなりません。 RPAは、実際のルータのインターフェイスのアドレスに対応している必要はありません。この点において、BIDIR-PIMは、ランデブーポイント（RP）として構成されるべき実際のルータを必要とPIM-SMとは異なります。 RPAに向けてホップバイホップを伝播BIDIR-PIMグループの受信者からのメッセージに参加しましょう。
Rendezvous Point Link (RPL) An RPL for a particular RPA is the physical link to which the RPA belongs. In BIDIR-PIM, all multicast traffic to groups mapping to a specific RPA is forwarded on the RPL of that RPA. The RPL is special within a BIDIR-PIM domain as it is the only link on which a Designated Forwarder election does not take place (see DF definition below).
ランデブーポイントリンク（RPL）特定のRPAのためのRPLは、RPAが属する物理的なリンクです。 BIDIR-PIMでは、特定のRPAへのグループへのマッピングすべてのマルチキャストトラフィックはそのRPAのRPLに転送されます。それは指定フォワーダ選挙は（以下DFの定義を参照）を行わないで唯一のリンクであるとして、RPLはBIDIR-PIMドメイン内に特別なものです。
Upstream Towards the root (RPA) of the tree. The direction used by packets traveling from sources to the RPL.
ツリーのルート（RPA）に向けて上流。 RPLの供給源から移動するパケットで使用される方向。
Downstream Away from the root of the tree. The direction on which packets travel from the RPL to receivers.
アウェイツリーのルートから下流。パケットが受信機にRPLから走行する上方向。
Designated Forwarder (DF) The protocol presented in this document is largely based on the concept of a Designated Forwarder (DF). A single DF exists for each RPA on every link within a BIDIR-PIM domain (this includes both multi-access and point-to-point links). The only exception is the RPL on which no DF exists. The DF is the router on the link with the best route to the RPA (determined by comparing MRIB provided metrics). A DF for a given RPA is in charge of forwarding downstream traffic onto its link, and forwarding upstream traffic from its link towards the RPL. It does this for all the bidirectional groups that map to the RPA. The DF on a link is also responsible for processing Join messages from downstream routers on the link as well as ensuring that packets are forwarded to local receivers (discovered through a local membership mechanism such as MLD [3] or IGMP [2]).
指定フォワーダ（DF）この文書のプロトコルは、主に指定フォワーダ（DF）の概念に基づいています。単一DF（これはマルチアクセスポイントツーポイントリンクの両方を含む）BIDIR-PIMドメイン内のすべてのリンク上の各RPAのために存在します。唯一の例外は一切DFが存在しない上RPLです。 DFは（MRIB提供メトリックを比較することによって決定）RPAへの最良のルートとのリンク上のルータです。所与RPAのためのDFは、そのリンクにダウンストリームトラフィックを転送し、そしてRPLに対するそのリンクからのアップストリームトラフィックの転送を担当します。これは、RPAにマッピングされたすべての双方向のグループのためにこれを行います。リンク上DFは、リンク上のダウンストリームのルータからのメッセージを参加処理と同様に、パケットがローカル受信機に転送されることを保証する責任がある（例えば、MLDのようなローカルメンバーシップ機構を介して発見された[3]又はIGMP [2]）。
RPF Interface RPF stands for "Reverse Path Forwarding". The RPF Interface of a router with respect to an address is the interface that the MRIB indicates should be used to reach that address. In the case of a BIDIR-PIM multicast group, the RPF interface is determined by looking up the RPA in the MRIB. The RPF information determines the interface of the router that would be used to send packets towards the RPL for the group.
RPFインターフェイスRPFは、「リバースパス転送」の略です。アドレスに対するルータのRPFインタフェースはMRIBがそのアドレスに到達するために使用されるべきで示すインターフェースです。 BIDIR-PIMマルチキャストグループの場合、RPFインタフェースはMRIBにRPAを調べることによって決定されます。 RPF情報は、グループのRPLに向かってパケットを送信するために使用されるルータのインターフェースを決定します。
RPF Neighbor The RPF Neighbor of a router with respect to an address is the neighbor that the MRIB indicates should be used to reach that address. Note that in BIDIR-PIM, the RPF neighbor for a group is not necessarily the router on the RPF interface that Join messages for that group would be directed to (Join messages are only directed to the DF on the RPF interface for the group).
RPF隣人は、アドレスに関してルータのRPFネイバーは、MRIBは、そのアドレスに到達するために使用されるべきであることを示すことを隣人です。 BIDIR-PIMに、グループのためのRPF隣人が（Joinメッセージを唯一のグループのためのRPFインターフェイス上のDFに向けられている）、そのグループのためのメッセージはに向けられるであろう参加RPFインターフェイス上のルータが必ずしもないことに留意されたいです。
Tree Information Base (TIB) This is the collection of state at a PIM router that has been created by receiving PIM Join/Prune messages, PIM DF election messages, and IGMP or MLD information from local hosts. It essentially stores the state of all multicast distribution trees at that router.
ツリー情報ベース（TIB）これは、ローカルホストから、PIM DF選定メッセージ、およびIGMPまたはMLD情報/参加PIMプルーンメッセージを受信することにより作成されたPIMルータでの状態のコレクションです。それは本質的にそのルータでは、すべてのマルチキャスト配信ツリーの状態を格納します。
Multicast Forwarding Information Base (MFIB) The TIB holds all the state that is necessary to forward multicast packets at a router. However, although this specification defines forwarding in terms of the TIB, to actually forward packets using the TIB is very inefficient. Instead, a real router implementation will normally build an efficient MFIB from the TIB state to perform forwarding. How this is done is implementation-specific, and is not discussed in this document.
マルチキャスト転送情報ベース（MFIB）TIBは、ルータにマルチキャストパケットを転送する必要があるすべての状態を保持します。この仕様は、実際に前方にTIBを使用してパケットに、TIBの点で転送定義するものの、非常に非効率的です。代わりに、実際のルータの実装は、通常の転送を実行するためにTIB状態から効率的なMFIBを構築します。これはどのように行われている実装固有であり、この文書で説明されていません。
We use set notation in several places in this specification.
私たちは、この仕様では、いくつかの場所に設定された表記法を使用しています。
A (+) B is the union of two sets, A and B.
（+）Bは二組、AとBの和集合であります
A (-) B is the elements of set A that are not in set B.
（ - ）Bは、セットBにはない集合Aの要素であります
NULL is the empty set or list.
NULLは空のセットまたはリストです。
In addition, we use C-like syntax:
加えて、我々はCに似た構文を使用します。
= denotes assignment of a variable.
=変数の割り当てを示しています。
== denotes a comparison for equality.
==平等のための比較を示しています。
!= denotes a comparison for inequality.
！=不平等のための比較を示しています。
Braces { and } are used for grouping.
ブレースは、{と}グループ化するために使用されます。
The specification of BIDIR-PIM is broken into several parts:
BIDIR-PIMの仕様は、いくつかの部分に分割されます。
o Section 3.1 details the protocol state stored.
O 3.1節詳細プロトコル状態が記憶されます。
o Section 3.2 defines the BIDIR-PIM extensions to the PIM-SM [4] neighbor discovery mechanism.
Oセクション3.2は、PIM-SM [4]近隣探索メカニズムにBIDIR-PIM拡張機能を定義します。
o Section 3.3 specifies the data packet forwarding rules.
O部3.3は、データパケットの転送ルールを指定します。
o Section 3.4 specifies the BIDIR-PIM Join/Prune generation and processing rules.
O部3.4はBIDIR-PIMは/プルーン生成および処理ルールに参加指定します。
o Section 3.5 specifies the Designated Forwarder (DF) election.
O部3.5は指定フォワーダ（DF）選挙を指定します。
o Section 3.7 specifies the PIM packet formats.
O部3.7は、PIMパケットフォーマットを指定します。
o Section 3.6 summarizes BIDIR-PIM timers and gives their default values.
O部3.6はBIDIR-PIMタイマーを要約し、そのデフォルト値を示します。
This section specifies all the protocol state that a BIDIR-PIM implementation should maintain in order 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 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.
このセクションでは、BIDIR-PIMの実装が正しく機能するために維持する必要があるすべてのプロトコル状態を指定します。それはこのルータでは、すべてのマルチキャスト配信ツリーの状態を保持していると私たちは、この状態ツリー情報ベースまたはTIBを名づけます。この仕様では、我々は、TIBの面でPIMメカニズムを定義します。しかし、唯一の非常に単純な実装では、実際にこのような状態の面でパケット転送の操作を実装します。ほとんどの実装では、TIBの関連する状態が変化したときに、その後更新されるマルチキャスト転送テーブルを構築するために、この状態を使用します。
Although we specify precisely the state to be kept, this does not mean that an implementation of BIDIR-PIM needs to hold the state in this form. This is actually an abstract state definition, which is needed in order to specify the router's behavior. A BIDIR-PIM implementation is free to hold whatever internal state it requires, and will still be conformant with this specification so long as it results in the same externally visible protocol behavior as an abstract router that holds the following state.
我々が保持されるように、正確な状態を指定しますが、これはBIDIR-PIMの実装は、この形式で状態を保持する必要があることを意味するものではありません。これは実際にルータの動作を指定するために必要とされる抽象状態の定義、です。 BIDIR-PIM実装は、それが必要とする内部どんな状態を保持して自由であり、さらに、それが以下の状態を保持する抽象ルータと同じ外部から見えるプロトコルの動作になり、この仕様に準拠します。
We divide TIB state into two sections:
我々は2つのセクションにTIB状態を分割します：
RPA state State that maintains the DF election information for each RPA.
各RPAのためのDF選定情報を保持RPA状態状態。
Group state State that maintains a group-specific tree for groups that map to a given RPA.
与えられたRPAにマップするグループのグループ固有の木を維持し、グループ状態状態。
The state that should be kept is described below. Of course, implementations will only maintain state when it is relevant to forwarding operations - for example, the "NoInfo" state might be assumed from the lack of other state information, rather than being held explicitly.
維持されるべき状態は以下の通りです。それは操作を転送に関連している場合は、当然、実装は唯一の状態を維持する - 例えば、「NoInfo」状態ではなく、明示的に開催されるより、他の状態情報の不足から推定される可能性があります。
A router holds the following state that is not specific to an RPA or group:
ルータは、RPAまたはグループに固有のものではない以下の状態を保持します。
Neighbor State:
近隣の状態：
For each neighbor:
各隣人のために：
o Neighbor's Gen ID
O隣人の世代ID
o Neighbor liveness timer (NLT)
Oネイバーライブネスタイマー（NLT）
o Other information from neighbor's Hello
隣人のHelloからその他の情報O
For more information on Hello information, look at Section 3.2 as well as the PIM-SM specification in [4].
こんにちは情報の詳細については、3.2節と同様に、[4]でPIM-SMの仕様を見てください。
A router maintains a multicast-group to RPA mapping, which is built through static configuration or by using an automatic RP discovery mechanism like BSR or AUTO-RP (see Section 4). For each BIDIR-PIM RPA, a router holds the following state:
ルータは、静的な構成を介して、またはBSRまたはAuto-RPのような自動RPディスカバリメカニズム（セクション4を参照）を使用して構築されるRPAマッピング、マルチキャストグループを維持します。各BIDIR-PIM RPAの場合、ルータは次の状態を保持します。
o RPA (actual address)
O RPA（実際のアドレス）
Designated Forwarder (DF) State:
指定フォワーダ（DF）状態：
For each router interface:
各ルータインターフェイスの場合：
Acting DF information:
DFの情報を代行：
o DF IP Address
O DF IPアドレス
o DF metric
O DFメトリック
Election information:
選挙情報：
o Election State
選挙州立O
o DF election-Timer (DFT)
O DF選定タイマー（DFT）
o Message-Count (MC)
Oメッセージ・カウント（MC）
Current best offer:
現在の最善のオファー：
o IP address of best offering router o Best offering router metric
ベスト募集ルータメトリックO最良の募集ルータのO IPアドレス
Designated Forwarder state is described in Section 3.5.
指定フォワーダの状態は、セクション3.5に記載されています。
For every group G, a router keeps the following state:
各グループGの場合、ルータは次の状態を保持します。
Group state:
グループの状態：
For each interface:
各インタフェースの場合：
Local Membership:
ローカルメンバーシップ：
o State: One of {"NoInfo", "Include"}
O状態：の一つ{ "NoInfo"、 "含みます"}
PIM Join/Prune State:
PIM /プルーンの状態に参加：
o State: One of {"NoInfo" (NI), "Join" (J), "PrunePending" (PP)}
O状態：{ "NoInfo"（NI）は、 "参加"（J）、 "PrunePending"（PP）}の一つ
o PrunePendingTimer (PPT)
PrunePendingTimer（PPT）
o Join/Prune Expiry Timer (ET)
O参加/プルーン有効期限タイマ（ET）
Not interface specific:
特定のインタフェースではありません。
o Upstream Join/Prune Timer (JT)
O上流には、/プルーンタイマー（JT）に参加します
o Last RPA Used
O最終RPAが使用されます
Local membership is the result of the local membership mechanism (such as IGMP [2]) running on that interface. This information is used by the pim_include(*,G) macro described in Section 3.1.4.
ローカル・メンバーシップは、そのインターフェイス上で実行されている（例えば、IGMP [2]のような）ローカルメンバシップメカニズムの結果です。この情報は、セクション3.1.4に記載pim_include（*、G）マクロによって使用されます。
PIM Join/Prune state is the result of receiving PIM (*,G) Join/Prune messages on this interface, and is specified in Section 3.4.1. The state is used by the macros that calculate the outgoing interface list in Section 3.1.4, and in the JoinDesired(G) macro (defined in Section 3.4.2) that is used in deciding whether a Join(*,G) should be sent upstream.
PIM /プルーン状態は、このインターフェイス上でPIM（*、G）参加/プルーンメッセージを受信した結果であり、セクション3.4.1で指定され参加。状態は、セクション3.1.4に発信インターフェイスリストを計算するマクロによって使用され、（G、*）に参加するかどうかを決定する際に使用される（セクション3.4.2で定義された）JoinDesired（G）マクロ内であるべきであるれます上流に送りました。
The upstream Join/Prune timer is used to send out periodic Join(*,G) messages, and to override Prune(*,G) messages from peers on an upstream LAN interface.
上流の参加/プルーンタイマーは、定期的な参加（*、G）メッセージを送信すると、上流のLANインターフェイス上のピアからプルーン（*、G）メッセージを無効にするために使用されます。
The last RPA used must be stored because if the group to RPA mapping changes (see RP Set changes in [4]), then state must be torn down and rebuilt for groups whose RPA changes.
使用された最後のRPAを記憶しなければならないのでならRPAマッピングの変更は、状態が解体されなければならない（[4]におけるRPセットの変更を参照）、そのRPA変更グループに対して再構築するグループ。
Using this state, we define the following "macro" definitions that we will use in the descriptions of the state machines and pseudocode in the following sections.
この状態を使用して、我々は次のセクションでは、ステートマシンと擬似コードの記述に使用されます、次の「マクロ」の定義を定義します。
olist(G) = RPF_interface(RPA(G)) (+) joins(G) (+) pim_include(G)
OLIST（G）= RPF_interface（RPA（G））（+）（G）ジョイン（+）pim_include（G）
RPF_interface(RPA) is the interface the MRIB indicates would be used to route packets to RPA. The olist(G) is the list of interfaces on which packets to group G must be forwarded.
RPF_interface（RPA）はMRIBがRPAにパケットをルーティングするために使用される示すインターフェースです。 OLIST（G）が転送されなければならないグループGにパケットれたインターフェースのリストです。
The macro pim_include(G) indicates the interfaces to which traffic might be forwarded because of hosts that are local members on that interface.
マクロpim_include（G）は、トラフィックが原因で、そのインターフェイス上でローカルメンバーでホストから転送される可能性があるにインターフェイスを示します。
pim_include(G) = { all interfaces I such that: I_am_DF(RPA(G),I) AND local_receiver_include(G,I) }
pim_include（G）= {すべてのインタフェースIように：I_am_DF（RPA（G）、I）AND local_receiver_include（G、I）}
The clause "I_am_DF(RPA,I)" is TRUE if the router is in the Win or Backoff states in the DF election state machine (described in Section 3.5) for the given RPA on interface I. Otherwise, it is FALSE.
句「I_am_DF（RPA、I）は、」そうでなければ、それはFALSEであるルータが勝つか、バックオフである場合、インタフェースI.に与えられたRPAのため（3.5節で説明）DF選定ステートマシンで述べTRUEです。
The clause "local_receiver_include(G,I)" is true if the IGMP module, MLD module, or other local membership mechanism has determined that there are local members on interface I that desire to receive traffic sent to group G.
IGMPモジュールは、MLDモジュール、または他のローカルメンバーシップ機構がグループGに送信されたインターフェースIトラフィックを受信するために、その欲求のローカルメンバーが存在すると判断した場合句「local_receiver_include（G、I）が」真であります
The set "joins(G)" is the set of all interfaces on which the router has received (*,G) Joins:
セット「（G）ジョイン」は、ルータが受信したすべてのインターフェイスのセット（*、G）が参加されます。
joins(G) = { all interfaces I such that I_am_DF(RPA(G),I) AND DownstreamJPState(G,I) is either Joined or PrunePending }
（G）= {I_am_DF（RPA（G）、I）AND DownstreamJPState（G、I）が参加又はPrunePendingれるかことを私はこのようなすべてのインターフェースを}合流
DownstreamJPState(G,I) is the state of the finite state machine in Section 3.4.1.
DownstreamJPState（G、I）は、セクション3.4.1における有限状態機械の状態です。
RPF_DF(RPA) is the neighbor that Join messages must be sent to in order to build the group shared tree rooted at the RPL for the given RPA. This is the Designated-Forwarder on the RPF_interface(RPA).
RPF_DF（RPA）は、与えられたRPAのためのRPLをルートグループ共有ツリーを構築するためにに送信する必要がありJoinメッセージを隣人です。これはRPF_interface（RPA）に指定-フォワーダです。
PIM routers exchange PIM-Hello messages with their neighboring PIM routers. These messages are used to update the Neighbor State described in Section 3.1. The procedures for generating and processing Hello messages as well as maintaining Neighbor State are specified in the PIM-SM [4] documentation.
PIMルータその隣接PIMルータとの交流PIM-Helloメッセージ。これらのメッセージは、3.1節で説明した近隣国家を更新するために使用されています。生成処理Helloメッセージを同様に隣人状態を維持するための手順は、PIM-SM [4]マニュアルで指定されています。
BIDIR-PIM introduces the Bidirectional Capable PIM-Hello option that MUST be included in all Hello messages from a BIDIR-PIM capable router. The Bidirectional Capable option advertises the router's ability to participate in the BIDIR-PIM protocol. The format of the Bidirectional Capable option is described in Section 3.7.
BIDIR-PIMはBIDIR-PIM対応ルータからのすべてのHelloメッセージに含まれなければならない双方向できるPIM-こんにちはオプションを紹介します。双方向が可能なオプションはBIDIR-PIMプロトコルに参加するルータの能力をアドバタイズします。双方向が可能なオプションの形式は、3.7節に記述されています。
If a BIDIR-PIM router receives a PIM-Hello message that does not contain the Bidirectional Capable option from one of its neighbors, the error must be logged to the router administrator in a rate-limited manner.
BIDIR-PIMルータはその隣人の1から双方向が可能なオプションが含まれていないPIM-Helloメッセージを受信した場合、エラーレートが制限された方法で、ルータの管理者にログインする必要があります。
For groups mapping to a given RPA, the following responsibilities are uniquely assigned to the DF for that RPA on each link:
所与RPAのグループマッピングのために、以下の責任を一意に各リンク上のRPAのためのDFに割り当てられています。
o The DF is the only router that forwards packets traveling downstream onto the link.
O DFは、リンクの上、下流移動するパケットを転送する唯一のルータがあります。
o The DF is the only router that picks-up upstream traveling packets off the link to forward towards the RPL.
O DFは、ピック・アップ上流移動するパケットをリンクオフRPLに向けて転送するように、唯一のルータがあります。
Non-DF routers on a link, which use that link as their RPF interface to reach the RPA, may perform the following forwarding actions for bidirectional groups:
RPAに到達するために彼らのRPFインターフェイスとしてそのリンクを使用するリンク上の非DFルータは、双方向のグループのための次の転送アクションを実行することがあります。
o Forward packets from the link towards downstream receivers.
下流の受信機へのリンクからOパケットを転送。
o Forward packets from downstream sources onto the link (provided they are the DF for the downstream link from which the packet was picked-up).
リンクに下流源からO転送パケット（これらは、パケットが、ピックアップされたダウンストリームリンクに対してDF提供されます）。
The BIDIR-PIM packet forwarding rules are defined below in pseudocode.
BIDIR-PIMパケット転送ルールは、擬似コードで以下に定義されます。
iif is the incoming interface of the packet. G is the destination address of the packet (group address). RPA is the Rendezvous Point Address for this group.
IIFは、パケットの着信インターフェイスです。 Gはパケット（グループアドレス）の宛先アドレスです。 RPAは、このグループのランデブーポイントアドレスです。
First we check to see whether the packet should be accepted based on TIB state and the interface that the packet arrived on. A packet is accepted if it arrives on the RPF interface to reach the RPA (downstream traveling packet) or if the router is the DF on the interface the packet arrives (upstream traveling packet).
まず、パケットがTIB状態とパケットが到着したインターフェイスに基づいて受け入れられるべきであるかどうかを確認します。それはRPA（下流走行パケット）に到達するRPFインターフェイスに到着した場合、またはルータがパケット（上流走行パケット）の到着インタフェース上DFである場合、パケットは受け入れられます。
If the packet should be forwarded, we build an outgoing interface list for the packet.
パケットを転送する必要がある場合、我々は、パケットの発信インターフェイスリストを構築します。
Finally, we remove the incoming interface from the outgoing interface list we've created, and if the resulting outgoing interface list is not empty, we forward the packet out of those interfaces.
最後に、私たちが作成した発信インターフェイスリストから着信インターフェイスを削除し、そして得られた発信インターフェイスリストが空でない場合、我々は、これらのインタフェースのうち、パケットを転送します。
On receipt of data to G on interface iif: if( iif == RPF_interface(RPA) || I_am_DF(RPA,iif) ) { oiflist = olist(G) (-) iif forward packet on all interfaces in oiflist }
{ - oiflist内のすべてのインターフェイス上でのIIF転送パケット（）oiflist = OLIST（G）} IF（IIF == RPF_interface（RPA）|| I_am_DF（RPA、IIF））：IIFインタフェース上のGへのデータを受信します
When configuring a BIDIR-PIM domain, it is possible to assign the Rendezvous Point Address (RPA) such that it does not belong to a physical box but instead is simply a routable address. Routers that have interfaces on the RPL that the RPA belongs to will upstream forward traffic onto the link. Joins from receivers in the domain will propagate hop-by-hop till they reach one of the routers connected to the RPL where they will terminate (as there will be no DF elected on the RPL).
BIDIR-PIMドメインを設定する場合、物理的なボックスに属していないようにランデブーポイントアドレス（RPA）を割り当てることが可能であるが、代わりに、単純にルーティング可能なアドレスです。 RPAは、リンクにトラフィックを転送します上流に属していることをRPL上のインターフェイスを持つルータ。彼らは（RPLに選出された何のDFがないように）彼らは終了しますRPLに接続されたルータの1に達するまで、ホップバイホップを伝播するドメインの受信機から参加。
If instead the administrator chooses to configure the RPA to be the address of a physical interface of a specific router, then nothing changes. That router must still upstream forward traffic on to the RPL and behave no differently than any other router with an interface on the RPL.
代わりに、管理者が特定のルータの物理インターフェイスのアドレスにRPAを設定することを選択した場合、何も変わりません。そのルータは、RPLの上、まだ上流トラフィックを転送して、RPLのインターフェイスを持つ他のルータとは異なる全く振る舞いはなりません。
To configure a BIDIR-PIM network to operate in a mode similar to that of PIM-SM where a single router (the RP) is acting as the root of the distribution tree, the RPA can be configured to be the loopback interface of a router.
単一ルータ（RP）は、配信ツリーのルートとして機能しているPIM-SMのものと同様のモードで動作するようにBIDIR-PIMネットワークを設定するために、RPAは、ルータのループバックインタフェースであるように構成することができます。
Source-only branches of the distribution tree for a group G are branches that do not lead to any receivers, but that are used to forward packets traveling upstream from sources towards the RPL. Routers along source-only branches only have the RPF interface to the RPA in their olist for G, and hence do not need to maintain any group specific state. Upstream forwarding can be performed using only RPA specific state. An implementation may decide to maintain group state for source-only branches for accounting or performance reasons. However, doing so requires data-driven events (to discover the groups with active sources), thus sacrificing one of the main benefits of BIDIR-PIM.
グループGの配布ツリーのソースのみのブランチがどの受信機につながらないが、それはRPLに向けた情報源から上流に移動するパケットを転送するために使用されている枝です。ソースのみの枝に沿ってルータは、Gのみのために彼らのOLISTでRPAへのRPFインターフェイスを持ち、したがって、任意のグループの特定の状態を維持する必要はありません。上流の転送は、RPA、特定の状態を使用して行うことができます。実装は、会計やパフォーマンスの理由から、ソースのみの支店のグループ状態を維持するように決定することができます。しかし、そうすることはこれBIDIR-PIMの主な利点の一つを犠牲にする、（アクティブソースとグループを発見するために）データ駆動型のイベントが必要です。
A major advantage of using a Designated Forwarder in BIDIR-PIM compared to PIM-SM is that special treatment is no longer required for sources that are directly connected to a router. Data from such sources does not need to be differentiated from other multicast traffic and will automatically be picked up by the DF and forwarded upstream. This removes the need for performing a directly-connected-source check for data to groups that do not have existing state.
PIM-SMに比べBIDIR-PIMで指定フォワーダを使用することの主な利点は、特別な治療がもはやルータに直接接続されているソースに必要とされることはありません。そのような情報源からのデータは、他のマルチキャストトラフィックと区別する必要がないと自動的に上流のDFでピックアップし、転送されます。これは、既存の状態を持っていないグループにデータの直接接続されたソースのチェックを実行する必要がなくなります。
BIDIR-PIM Join/Prune messages are used to construct group-specific distribution trees between receivers and the RPL. Joins are originated by last-hop routers that are elected as the DF on an interface with directly connected receivers. The Joins propagate hop-by-hop towards the RPA until they reach a router connected to the RPL.
BIDIR-PIM参加/プルーンメッセージは、受信機とRPLの間にグループ固有の分散ツリーを構築するために使用されます。直接接続された受信機とのインタフェース上DFとして選出され、最後のホップルータによって発信されるジョイン。彼らはRPLに接続されたルータに到達するまで、ホップバイホップRPAへの伝播を結合します。
A BIDIR-PIM Join/Prune message consists of a list of Joined and Pruned Groups. When processing a received Join/Prune message, each Joined or Pruned Group is effectively considered individually by applying the following state machines. When considering a Join/Prune message whose PIM Destination field addresses this router, (*,G) Joins and Prunes can affect the downstream state machine. When considering a Join/Prune message whose PIM Destination field addresses another router, most Join or Prune entries could affect the upstream state machine.
BIDIR-PIM参加/プルーンのメッセージが参加し、剪定されたグループのリストで構成されます。受信した参加/プルーンメッセージを処理する場合、それぞれが参加又はプルーニンググループを効果的に以下の状態マシンを適用することにより、個々に考えられています。そのPIM Destinationフィールドのアドレスをこのルータに参加/プルーンのメッセージ、（*、G）を考慮すると参加とプルーンは、下流のステートマシンに影響を与えることができます。そのPIM先フィールドが別のルータに対処しましょう/プルーンのメッセージを考えるとき、ほとんどの参加やプルーンのエントリは、上流のステートマシンに影響を与える可能性があります。
When a router receives a Join(*,G) or Prune(*,G), it MUST first check to see whether the RP address in the message matches RPA(G) (the router's idea of what the Rendezvous Point Address is). If the RP address in the message does not match RPA(G), the Join or Prune MUST be silently dropped.
ルータが参加（*、G）またはプルーン（*、G）を受信すると、それは最初のメッセージ内のRPアドレスは、RPA（G）（ランデブーポイントアドレスが何であるかのルータのアイデアを）一致するかどうかを確認するためにチェックしなければなりません。メッセージ内のRPアドレスは、RPA（G）と一致しない場合は、参加やプルーンを静かに下げなければなりません。
If a router has no RPA information for the group (e.g., has not recently received a BSR message), then it MAY choose to accept Join(*,G) or Prune(*,G) and treat the RP address in the message as
ルータが基（例えば、最近、BSRメッセージを受信していない）のためのRPA情報を持っていない場合、それは（*、G）またはプルーン（*、G）に参加受け入れることを選択し、メッセージなどでRPアドレスを扱うかもしれ
RPA(G). If the newly discovered RPA did not previously exist for any other group, a DF election has to be initiated.
RPA（G）。新たに発見されたRPAは、以前に他のグループのために存在していなかった場合は、DF選定が開始されることがあります。
Note that a router will process a Join(*,G) targeted to itself even if it is not the DF for RP(G) on the interface on which the message was received. This is an optimisation to eliminate the Join delay of one Join period (t_periodic) in the case where a new DF processes the received Pass and Join messages in reverse order. The BIDIR-PIM forwarding logic will ensure that data packets are not forwarded on such an interface while the router is not the DF (unless it is the RPF interface towards the RPA).
ルータが参加処理することに注意してください（*、G）は、メッセージを受信したインターフェイス上のRPのためのDF（G）でない場合であっても、それ自体を対象。これは、新しいDFは、受信パスを処理する場合には期間（t_periodic）に参加して、逆の順序でメッセージを参加一方の参加遅延を解消する最適化です。 BIDIR-PIM転送ロジックは、ルータがDFないが（それがRPAに向かってRPFインタフェースがない限り）そのデータ・パケットは、インターフェイス上で転送されないようになります。
The per-interface state machine for receiving (*,G) Join/Prune Messages is given below. There are three states:
（*、G）参加/プルーンメッセージを受信するためのインターフェイス単位のステートマシンを以下に示します。 3つの状態があります。
NoInfo (NI) The interface has no (*,G) Join state and no timers running.
NoInfo（NI）インタフェースには（*、G）の状態となしタイマーの実行に参加していません。
Join (J) The interface has (*,G) Join state. If the router is the DF on this interface (I_am_DF(RPA(G),I) is TRUE), the Join state will cause us to forward packets destined for G on this interface.
参加（J）インターフェースは、（*、G）ステートに参加。ルータは、このインターフェイスのDFである場合（I_am_DF（RPA（G）、I）がTRUEである）、参加状態は、私たちは、このインターフェイス上でG宛てのパケットを転送するようになります。
PrunePending (PP) The router has received a Prune(*,G) on this interface from a downstream neighbor and is waiting to see whether the Prune will be overridden by another downstream router. For forwarding purposes, the PrunePending state functions exactly like the Join state.
PrunePending（PP）ルータは、ダウンストリームネイバーから、このインターフェイス上でプルーン（*、G）を受信したとプルーンが別の下流のルータによって上書きされるかどうかを確認するために待機しています。転送のために、正確に入会状態などのPrunePending状態機能。
In addition, the state machine uses two timers:
また、ステートマシンは2つのタイマーを使用しています。
ExpiryTimer (ET) This timer is restarted when a valid Join(*,G) is received. Expiry of the ExpiryTimer causes the interface state to revert to NoInfo for this group.
ExpiryTimer（ET）有効な参加時にこのタイマーが再開される（*、G）が受信されます。 ExpiryTimerの有効期限は、このグループのためにNoInfoに戻す界面状態を引き起こします。
PrunePendingTimer (PPT) This timer is set when a valid Prune(*,G) is received. Expiry of the PrunePendingTimer causes the interface state to revert to NoInfo for this group.
有効なプルーン（*、G）を受信したときPrunePendingTimer（PPT）このタイマーが設定されています。 PrunePendingTimerの有効期限は、このグループのためにNoInfoに戻す界面状態を引き起こします。
Figure 1: Downstream group per-interface state machine in tabular form
図1：表形式の下流グループごとのインターフェイスステートマシン
+---------------++---------------------------------------------------+
| || Prev State |
|Event ++---------------+-----------------+-----------------+
| || NoInfo (NI) | Join (J) | PrunePending |
| || | | (PP) |
+---------------++---------------+-----------------+-----------------+
| || -> J state | -> J state | -> J state |
|Receive || start Expiry | restart Expiry | restart Expiry |
|Join(*,G) || Timer | Timer | Timer; stop |
| || | | PrunePending- |
| || | | Timer |
+---------------++---------------+-----------------+-----------------+
|Receive || - | -> PP state | -> PP state |
|Prune(*,G) || | start Prune- | |
| || | PendingTimer | |
+---------------++---------------+-----------------+-----------------+
|PrunePending- || - | - | -> NI state |
|Timer Expires || | | Send Prune- |
| || | | Echo(*,G) |
+---------------++---------------+-----------------+-----------------+
|Expiry Timer || - | -> NI state | -> NI state |
|Expires || | | |
+---------------++---------------+-----------------+-----------------+
|Stop Being DF || - | -> NI state | -> NI state |
|on I || | | |
+---------------++---------------+-----------------+-----------------+
The transition events "Receive Join(*,G)" and "Receive Prune(*,G)" imply receiving a Join or Prune targeted to this router's address on the received interface. If the destination address is not correct, these state transitions in this state machine must not occur, although seeing such a packet may cause state transitions in other state machines.
遷移イベントは、「（*、G）が参加受信」と「プルーン（*、G）を受信」に参加受ける暗示やプルーンは、受信したインターフェイス上でこのルータのアドレスを対象。宛先アドレスが正しくない場合は、このようなパケットを見てすることは、他のステートマシンの状態遷移を引き起こすかもしれないが、この状態のマシンでこれらの状態遷移は、発生してはいけません。
On unnumbered interfaces on point-to-point links, the router's address should be the same as the source address it chose for the Hello packet it sent over that interface. However, on point-to-point links, we also RECOMMEND that PIM messages with a destination address of all zeros also be accepted.
ポイントツーポイントリンク上のアンナンバードインターフェイスでは、ルータのアドレスは、それがそのインターフェイスを介して送信されるHelloパケットのために選択した送信元アドレスと同じでなければなりません。しかし、ポイントツーポイントリンク上で、我々はまた、すべてゼロの宛先アドレスを持つPIMメッセージも受け入れられることをお勧めします。
The transition event "Stop Being DF" implies a DF re-election taking place on this router interface for RPA(G) and the router changing status from being the active DF to being a non-DF router (the value of the I_am_DF macro changing to FALSE).
「停止ビーイングDFが」DFの再選RPAのためのこのルータインターフェイス（G）上で行われ、ルータが非DFルータであることにアクティブDFであることからステータスを変更することを意味遷移イベント（I_am_DFマクロ変更値FALSEに）。
When ExpiryTimer is started or restarted, it is set to the HoldTime from the Join/Prune message that triggered the timer.
ExpiryTimerが起動または再起動する場合は、タイマーをトリガーに参加/プルーンのメッセージからのHoldTimeに設定されています。
When PrunePendingTimer is started, it is set to the J/P_Override_Interval if the router has more than one neighbor on that interface; otherwise, it is set to zero causing it to expire immediately.
PrunePendingTimerが開始されると、ルータはそのインターフェイス上に複数の隣人を持っている場合、それはJ / P_Override_Intervalに設定されています。そうでない場合は、それがすぐに期限切れに原因がゼロに設定されています。
The action "Send PruneEcho(*,G)" is triggered when the router stops forwarding on an interface as a result of a Prune. A PruneEcho(*,G) is simply a Prune(*,G) message sent by the upstream router to itself on a LAN. Its purpose is to add additional reliability so that if a Prune that should have been overridden by another router is lost locally on the LAN, then the PruneEcho may be received and cause the override to happen. A PruneEcho(*,G) need not be sent when the router has only one neighbor on the link.
ルータはプルーンの結果としてインタフェースに転送停止時アクション「PruneEcho（*、G）を送る」がトリガされます。 PruneEcho（*、G）は、単にLAN上の自身にアップストリームルータによって送信されたプルーン（*、G）メッセージです。その目的は、別のルータによって上書きされているはずプルーンは、LAN上でローカルに失われた場合、その後、PruneEchoを受信してオーバーライドが発生する原因となることができるように、追加の信頼性を追加することです。 PruneEcho（*、G）は、ルータがリンク上の唯一の隣人を持っているときに送信する必要はありません。
The downstream per-interface state machines described above hold Join state from downstream PIM routers. This state then determines whether a router needs to propagate a Join(*,G) upstream towards the RPA. Such Join(*,G) messages are sent on the RPF interface towards the RPA and are targeted at the DF on that interface.
上記下流インターフェースごとの状態機械は、下流のPIMルータから状態を参加保持します。この状態は、その後、上流RPAに向けて（*、G）ルータが参加伝播する必要があるかどうかを判定する。このような参加（*、G）メッセージはRPAに向けてRPFインターフェイス上で送信され、そのインターフェイス上でDFをターゲットにしています。
If a router wishes to propagate a Join(*,G) upstream, it must also watch for messages on its upstream interface from other routers on that subnet, and these may modify its behavior. If it sees a Join(*,G) to the correct upstream neighbor, it should suppress its own Join(*,G). If it sees a Prune(*,G) to the correct upstream neighbor, it should be prepared to override that Prune by sending a Join(*,G) almost immediately. Finally, if it sees the Generation ID (see PIM-SM specification [4]) of the correct upstream neighbor change, it knows that the upstream neighbor has lost state, and it should be prepared to refresh the state by sending a Join(*,G) almost immediately.
ルータが参加（*、G）上流を伝播することを希望する場合は、それはまた、そのサブネット上の他のルータからのアップストリームインターフェイス上のメッセージを監視しなければならない、これらはその動作を変更することがあります。それが正しい上流の隣人に（*、G）参加見れば、それは自身の参加抑える必要があります（*、G）。それが正しい上流の隣人へのプルーン（*、G）を見れば、ほとんどすぐに（*、G）に参加送信することによって、そのプルーンを上書きするために準備する必要があります。それが正しい上流隣接変更の世代IDを（[4] PIM-SM仕様を参照してください）見れば最終的に、それは*（上流の隣人が状態を失っている、そして参加を送信することにより、状態をリフレッシュするために準備されるべきであることを知っていますほとんどすぐに、G）。
In addition, changes in the next hop towards the RPA trigger a Prune off from the old next hop and join towards the new next hop. Such a change can be caused by the following two events:
また、RPAに向けた次のホップの変化は古いネクストホップからプルーンをオフトリガーと新しい次のホップの方に参加します。このような変更は、次の2つのイベントによって引き起こされる可能性があります。
o The MRIB indicates that the RPF Interface towards the RPA has changed. In this case the DF on the new RPF interface becomes the new RPF Neighbor.
O MRIBはRPAへのRPFインターフェイスが変更されたことを示しています。この場合、新しいRPFインターフェイス上のDFは新しいRPFネイバーになります。
o There is a DF re-election on the RPF interface and a new router emerges as the DF.
OありRPFインターフェイス上のDFの再選挙で、新しいルータはDFとして現れます。
The upstream (*,G) state machine only contains two states:
上流（*、G）ステートマシンは、2つの状態しか含まれています。
Not Joined The downstream state machines indicate that the router does not need to join the RPA tree for this group.
参加していない下流のステートマシンは、ルータがこのグループのRPAツリーに参加する必要がないことを示しています。
Joined The downstream state machines indicate that the router would like to join the RPA tree for this group.
下流のステートマシンは、ルータがこのグループのRPAツリーに参加したいことを示している入社。
In addition, one timer JT(G) is kept, which is used to trigger the sending of a Join(*,G) to the upstream next hop towards the RPA (the DF on the RPF interface for RPA(G)).
加えて、1つのタイマーJT（G）は、RPA（RPAのためのRPFインターフェイス上のDF（G））に向かってアップストリームの次のホップに参加（*、G）の送信をトリガするために使用され、維持されます。
Figure 2: Upstream group state machine in tabular form
図2：表形式の上流グループ状態マシン
+---------------------+----------------------------------------------+
| | Event |
| Prev State +-----------------------+----------------------+
| | JoinDesired(G) | JoinDesired(G) |
| | ->True | ->False |
+---------------------+-----------------------+----------------------+
| | -> J state | - |
| NotJoined (NJ) | Send Join(*,G); | |
| | Set Timer to | |
| | t_periodic | |
+---------------------+-----------------------+----------------------+
| Joined (J) | - | -> NJ state |
| | | Send Prune(*,G) |
+---------------------+-----------------------+----------------------+
In addition, we have the following transitions that occur within the Joined state:
また、当社は、接合状態内で発生し、次の遷移を持っています：
+--------------------------------------------------------------------+
| In Joined (J) State |
+----------------+----------------+-----------------+----------------+
|Timer Expires | See Join(*,G) | See Prune(*,G) | RPF_DF(RPA(G)) |
| | to | to | GenID changes |
| | RPF_DF(RPA(G)) | RPF_DF(RPA(G)) | |
+----------------+----------------+-----------------+----------------+
|Send | Increase Timer | Decrease Timer | Decrease Timer |
|Join(*,G); Set | to | to t_override | to t_override |
|Timer to | t_suppressed | | |
|t_periodic | | | |
+----------------+----------------+-----------------+----------------+
+--------------------------------------------------------------------+
| In Joined (J) State |
+-----------------------------------+--------------------------------+
| Change of RPF_DF(RPA(G)) | RPF_DF(RPA(G)) GenID |
| | changes |
+-----------------------------------+--------------------------------+
| Send Join(*,G) to new | Decrease Timer to |
| DF; Send Prune(*,G) to | t_override |
| old DF; set Timer to | |
| t_periodic | |
+-----------------------------------+--------------------------------+
This state machine uses the following macro:
このステートマシンは、次のマクロを使用しています：
bool JoinDesired(G) { if (olist(G) (-) RPF_interface(RPA(G))) != NULL return TRUE else return FALSE }
BOOL JoinDesired（G）{もし！（OLIST（G）（ - ）RPF_interface（RPA（G）））= NULL戻り他TRUEはFALSEを返します}
This section presents a fail-safe mechanism for electing a per-RPA designated router on each link in a BIDIR-PIM domain. We call this router the Designated Forwarder (DF). The DF election does not take place on the RPL for an RPA.
このセクションでは、BIDIR-PIMドメイン内の各リンクにあたり-RPA指定ルータを選出のためのフェイルセーフメカニズムを提供します。私たちは、指定フォワーダ（DF）このルータを呼び出します。 DF選定は、RPAのためのRPLに行われません。
The DF election chooses the best router on a link to assume responsibility for forwarding traffic between the RPL and the link for the range of multicast groups served by the RPA. Different multicast groups that share a common RPA share the same upstream direction. Hence, the election of an upstream forwarder on each link does not have to be a group-specific decision but instead can be RPA-specific. As the number of RPAs is typically small, the number of elections that have to be performed is significantly reduced by this observation.
DF選定は、RPLとRPAが提供するマルチキャストグループの範囲のためのリンク間でトラフィックを転送するための責任を負うために、リンク上で最高のルータを選択します。共通のRPAを共有する異なるマルチキャストグループは、同じアップストリーム方向を共有します。したがって、各リンク上のアップストリームフォワーダの選挙は、グループ固有の意思決定をする必要はありませんが、代わりにRPA-特定することができます。 RPASの数は、典型的には小さいように、実行されなければならない選挙の数を大幅この観察によって低減されます。
To optimise tree creation, it is desirable that the winner of the election process should be the router on the link with the "best" unicast routing metric (as reported by the MRIB) to reach the RPA. When comparing metrics from different unicast routing protocols, we use the same comparison rules used by the PIM-SM assert process [4].
ツリーの作成を最適化するためには、選挙プロセスの勝者はRPAに到達する（MRIBによって報告されるように）「最良の」ユニキャストルーティングメトリックとのリンク上のルータであることが望ましいです。異なるユニキャストルーティングプロトコルのメトリックを比較した場合、PIM-SMが使用する我々が使用するのと同じ比較ルールは、[4]の処理をアサート。
The election process needs to take place when information on a new RPA initially becomes available. The result can be re-used as new bidir groups that map to the same RPA are encountered. However, there are some conditions under which an update to the election is required:
選挙プロセスは、新たなRPAの情報が最初に利用可能になったときに場所を取る必要があります。その結果、発生した同じRPAにマップする新しい双方向グループとして再使用することができます。しかし、選挙への更新が必要とされるの下でいくつかの条件があります。
o There is a change in unicast metric to reach the RPA for any of the routers on the link.
Oリンク上のルータのいずれかのRPAに到達するために、ユニキャストメトリックの変化があります。
o The interface on which the RPA is reachable (RPF Interface) changes to an interface for which the router was previously the DF.
RPAが到達されたインターフェース（RPFインタフェース）Oルータが以前DFであったためにインターフェイスに変化します。
o A new PIM neighbor starts up on a link that must participate in the elections and be informed of the current outcome.
O新しいPIMネイバーが選挙に参加しなければならないと現在の結果が通知されたリンク上で起動します。
o The elected DF fails (detected through neighbor information timeout or MRIB RPF change at downstream router).
選出されたDFに障害が発生したO（ネイバー情報のタイムアウトまたは下流のルータでMRIBのRPFの変更を通じて検出）。
The election process has to be robust enough to ensure with very high probability that all routers on the link have a consistent view of the DF. Given the forwarding rules described in Section 3.3, loops may result if multiple routers end-up thinking that they should be responsible for forwarding. To minimize the possibility of this occurrence, the election algorithm has been biased towards discarding DF information and suspending forwarding during periods of ambiguity.
選挙プロセスは、リンク上のすべてのルータがDFの一貫したビューを持っている非常に高い確率で確保するのに十分な堅牢である必要があります。複数のルータエンドアップは、彼らが転送のために責任を負うべきであると考えた場合、セクション3.3で説明した転送ルールを考えると、ループが発生することがあります。この発生の可能性を最小限に抑えるために、選挙アルゴリズムは、DFの情報を破棄し、あいまいさの期間中に転送を一時停止に偏ってきました。
This section gives an outline of the DF election process. It does not provide the definitive specification for the DF election. If any discrepancy exists between Section 3.5.3 and this section, the specification in Section 3.5.3 is to be assumed correct.
このセクションでは、DF選定プロセスの概要を示します。これは、DF選定のための決定的な仕様を提供していません。任意の不一致は、セクション3.5.3、このセクションの間に存在する場合、セクション3.5.3に仕様が正しいと仮定されます。
To perform the election of the DF for a particular RPA, routers on a link need to exchange their unicast routing metric information for reaching the RPA. Routers advertise their own metrics in Offer, Winner, Backoff, and Pass messages. The advertised metric is calculated using the RPF Interface and metric to reach the RPA available through the MRIB. When a router is participating in a DF election for an RPA on the interface that its MRIB indicates as the RPF Interface, then that router MUST always advertise an infinite metric in its election messages. When a router is participating in a DF election on an interface other than the MRIB-indicated RPF Interface then it MUST advertise the MRIB-provided metrics in its election messages.
特定のRPAのためにDFの選挙を実行するには、リンク上のルータは、RPAに到達するための彼らのユニキャストルーティングメトリック情報を交換する必要があります。ルータはオファー、受賞、バックオフで独自の指標を宣伝し、メッセージを渡します。アドバタイズされたメトリックは、MRIBを介して利用可能なRPAに到達するためにRPFインターフェイスおよびメトリックを使用して計算されます。ルータがMRIBがRPFインターフェイスとして示しインターフェイスでRPAのためのDF選定に参加している場合は、そのルータは、常に選挙のメッセージに無限のメトリックをアドバタイズする必要があります。ルータがMRIBで示したRPFインターフェイス以外のインターフェイス上でDF選定に参加しているとき、それはその選挙のメッセージにMRIBが提供するメトリックをアドバタイズする必要があります。
In the election protocol described below, many message exchanges are repeated Election_Robustness times for reliability. In all those cases, the message retransmissions are spaced in time by a small random interval. All of the following description is specific to the election on a single link for a single RPA.
以下に説明する選挙プロトコルでは、多くのメッセージ交換は、信頼性Election_Robustness回繰り返されます。これらすべての場合において、メッセージ再送信は、小さなランダムな間隔によって時間的に間隔を置いて配置されています。以下の記述はすべて、単一のRPAのための単一のリンク上の選挙に固有のものです。
Initially, when no DF has been elected, routers finding out about a new RPA start participating in the election by sending Offer messages. Offer messages include the router's metric to reach the RPA. Offers are periodically retransmitted with a period of Offer_Interval.
最初は、とき何のDFは、ルータが新しいRPAは、オファーメッセージを送ることによって、選挙に参加して開始について調べること、選出されていません。オファーメッセージは、RPAに到達するためのルータのメトリックが含まれます。オファーは定期的にOffer_Intervalの周期で再送されています。
If a router hears a better offer than its own from a neighbor, it stops participating in the election for a period of Election_Robustness * Offer_Interval, thus giving a chance to the neighbor with the better metric to be elected DF. If during this period no winner is elected, the router restarts the election from the beginning. If at any point during the initial election a router receives an out of order offer with worse metrics than its own, then it restarts the election from the beginning.
ルータがネイバーから、自身のより良いプランを聞けば、それはこのようにDF選出するためのより良いメトリックで隣人にチャンスを与え、Election_Robustness * Offer_Intervalの期間のために選挙に参加して停止します。この期間中に何の勝者が選出されていない場合、ルータは最初から選挙を再起動します。最初の選挙の中の任意の時点で、ルータは、自身よりも悪いメトリックを持つためのオファーのうちを受信した場合、それは最初から選挙を再起動します。
The result should be that all routers except the best candidate stop advertising their offers.
結果は、最高の候補者を除くすべてのルータが自分のオファーを宣伝停止することでなければなりません。
A router assumes the role of the DF after having advertised its metrics Election_Robustness times without receiving any offer from any other neighbor. At that point, it transmits a Winner message that declares to every other router on the link the identity of the winner and the metrics it is using.
ルータは、他のネイバーからの任意のオファーを受けることなく、そのメトリックElection_Robustness回の広告を出した後にDFの役割を前提としています。その時点で、それがリンクの上に他のすべてのルータに勝者とそれが使用されるメトリックのアイデンティティを宣言受賞メッセージを送信します。
Routers receiving a Winner message stop participating in the election and record the identity and metrics of the winner. If the local metrics are better than those of the winner, then the router records the identity of the winner (accepting it as the acting DF) but re-initiates the election to try and take over.
勝者メッセージを受信したルータは、選挙に参加して停止し、勝者のアイデンティティとメトリックを記録します。ローカルメトリックは、勝者のものより優れている場合、ルータは勝者のアイデンティティを記録する（演技DFとしてそれを受け入れる）が、試してみて引き継ぐために選挙を再起動します。
Whenever the unicast metric to an RPA changes at a non-DF router to a value that is better than that previously advertised by the acting DF, the router with the new better metric should take action to eventually assume forwarding responsibility. When the metric change is detected, the non-DF router with the now better metric restarts the DF election process by sending Offer messages with this new metric. Note that at any point during an election if no response is received after Election_Robustness retransmissions of an offer, a router assumes the role of the DF following the usual Winner announcement procedure.
RPAへのユニキャストメトリックは、以前に演技DFによって広告よりも優れている値に非DFのルータで変更するたびに、新しいより良いメトリックを持つルータが最終的に責任を転送すると仮定する行動を取る必要があります。メトリックの変更が検出されると、今より良いメトリックが再起動した非DFルータこの新しいメトリックとオファーメッセージを送信することにより、DF選定プロセス。応答がオファーのElection_Robustness再送後に受信されない場合、選挙中の任意の時点で、ルータは通常の受賞発表の手順に従ってDFの役割を前提としています。
Upon receipt of an offer that is worse than its current metric, the DF will respond with a Winner message declaring its status and advertising its better metric. Upon receiving the Winner message, the originator of the Offer records the identity of the DF and aborts the election.
その現在のメトリックよりも悪いのオファーを受信すると、DFは勝者のメッセージがその地位を宣言し、その優れたメトリックをアドバタイズすると応答します。勝者メッセージを受信すると、オファーの発信元はDFのアイデンティティを記録し、選挙を中止します。
Upon receipt of an offer that is better than its current metric, the DF records the identity and metrics of the offering router and responds with a Backoff message. This instructs the offering router to hold off for a short period of time while the unicast routing stabilizes and other routers get a chance to put in their offers. The Backoff message includes the offering router's new metric and address. All routers on the link that have pending offers with metrics worse than those in the Backoff message (including the original offering router) will hold further offers for a period of time defined in the Backoff message.
その現在のメトリックよりも優れているのオファーを受信すると、DFは募集ルータのアイデンティティとメトリックを記録し、バックオフメッセージで応答します。これは、ユニキャストルーティングが安定し、他のルータがその申し出に置くためにチャンスを得る一方で、時間の短い期間のためにオフに保持するために提供ルータに指示します。バックオフメッセージが提供ルータの新しいメトリックとアドレスが含まれています。 （オリジナルの募集ルータを含む）バックオフメッセージのものよりも悪いメトリックを持つ保留中のオファーを持っているリンク上のすべてのルータは、バックオフメッセージで定義された期間のための更なるオファーを開催します。
If a third router sends a better offer during the Backoff_Period, the Backoff message is repeated for the new offer and the Backoff_Period is restarted.
第三ルータがBackoff_Period中に、より良いプランを送信した場合、バックオフメッセージは、新たな提供のために繰り返され、Backoff_Periodが再起動されます。
Before the Backoff_Period expires, the acting DF nominates the router having made the best offer as the new DF using a Pass message. This message includes the IDs and metrics of both the old and new DFs. The old DF stops performing its tasks at the time the Pass message transmission is made. The new DF assumes the role of the DF as soon as it receives the Pass message. All other routers on the link take note of the new DF and its metric. Note that this event constitutes an RPF Neighbor change, which may trigger Join messages to the new DF (see Section 3.4).
Backoff_Periodの有効期限が切れる前に、演技DFは、ルータがパスメッセージを使用して、新しいDFとして最適な提案をした指名します。このメッセージは、新旧両方のDFのIDとメトリックが含まれます。古いDFはパスメッセージの送信が行われた時点でそのタスクを実行停止します。新しいDFはすぐにそれがパスメッセージを受信するとDFの役割を前提としています。リンク上の他のすべてのルータは、新たなDFとそのメトリックのノートを取ります。このイベントは、新しいDFへのJoinメッセージを引き起こす可能性RPFネイバーの変更を構成することに注意してください（セクション3.4を参照してください）。
If the DF's routing metric to reach the RPA changes to a worse value, it sends a set of Election_Robustness randomly spaced Winner messages on the link, advertising the new metric. Routers that receive this announcement but have a better metric may respond with an Offer message that results in the same handoff procedure described above. All routers assume the DF has not changed until they see a Pass or Winner message indicating the change.
DFのRPAに到達するメトリックルーティングが悪化した値に変更された場合、それが新しいメトリックをアドバタイズする、リンク上のElection_Robustnessランダム間隔の勝者メッセージのセットを送信します。この発表を受け、より良いメトリックを持っているルータは、上記と同様のハンドオフ手順になりオファーメッセージで応答することができます。すべてのルータは、彼らが変化を示すパスや受賞のメッセージが表示されるまで、DFが変更されていないと仮定します。
There is no pressure to make this handoff quickly if the acting DF still has a path to the RPL. The old path may now be suboptimal, but it will still work while the re-election is in progress.
演技DFはまだRPLへのパスを持っている場合はすぐにこのハンドオフを作るためには圧力はありません。古いパスは今、次善のかもしれませんが、再選挙が進行している間、それはまだ動作します。
If a router's RPF Interface to the RPA switches to be on a link for which it is acting as the DF, then it can no longer provide forwarding services for that link. It therefore immediately stops being the DF and restarts the election. As its path to the RPA is through the link, an infinite metric is used in the Offer message it sends.
RPAへのルータのRPFインターフェイスは、それがDFとして機能しているリンク上にあるように切り替えると、それはもはや、そのリンクの転送サービスを提供することはできません。したがって、すぐにDFをされて停止し、選挙を再起動します。 RPAへのパスがリンクを介してあるので、無限のメトリックは、送信するオファーメッセージで使用されています。
A late router starting up after the DF election process has completed will have no immediate knowledge of the election outcome. As a result, it will start advertising its metric in Offer messages. As soon as this happens, the currently elected DF will respond with a Winner message if its metric is better than the metric in the Offer message, or with a Backoff message if its metric is worse than the metric in the Offer message.
DF選定プロセスが完了した後に起動下旬ルータは、選挙結果の即時知識を持っていません。その結果、オファーメッセージでそのメトリックをアドバタイズを開始します。そのメトリックは、オファーメッセージ内のメトリックよりも悪化している場合は、そのメトリックがオファーメッセージで、またはバックオフメッセージとメトリックよりも優れているかのようにすぐにこの問題が発生したとして、現在選出されているDFは勝者メッセージで応答します。
Whenever the DF dies, a new DF has to be elected. The speed at which this can be achieved depends on whether there are any downstream routers on the link.
DFが死ぬたびに、新しいDFを選出する必要があります。これを達成することができる速度は、リンク上の任意の下流のルータが存在するかどうかによって異なります。
If there are downstream routers, typically their MRIB reported next-hop before the DF dies will be the DF itself. They will therefore notice either a change in the metric for the route to the RPA or a change in next-hop away from the DF and can restart the election by transmitting Offer messages. If according to the MRIB the RPA is now reachable through the same link via another upstream router, an infinite metric will be used in the Offer.
下流のルータが存在する場合は、DFが死ぬ前に、典型的には、そのMRIBは、ネクストホップを報告したDF自体になります。従って、それらは、離れたDFからRPAへのルートまたはネクストホップの変化のメトリックの変化のいずれかに気づくでしょうし、オファーメッセージを送信することにより、選挙を再起動することができます。 MRIBによるRPAは今、別の上流のルータを経由して同じリンクを介して到達可能である場合には、無限のメトリックはオファーに使用されます。
If no downstream routers are present, the only way for other upstream routers to detect a DF failure is by the timeout of the PIM neighbor information, which will take significantly longer.
ダウンストリームルータが存在しない場合は、他の上流のルータがDFの故障を検出するための唯一の方法は、かなり時間がかかりますPIMネイバー情報のタイムアウトです。
This section provides the definitive specification for the DF election process. If any discrepancy exists between Section 3.5.2 and this section, the specification in this section is to be assumed correct.
このセクションでは、DF選定プロセスのための決定的な仕様を提供します。任意の不一致は、セクション3.5.2、このセクションの間に存在する場合、このセクションの仕様は正しいと仮定されます。
The DF election state is maintained per RPA for each multicast enabled interface I on the router as introduced in Section 3.1.
DF選定状態が、私は、セクション3.1で導入され、ルータ上のインターフェイスを有効にし、各マルチキャストのためのRPAごとに維持されます。
The state machine has the following four states:
ステートマシンは、次の4つの状態があります。
Offer Initial election state. When in the Offer state, a router thinks it can eventually become the winner and periodically generates Offer messages.
初期の選挙状態を提供します。ときオファー状態では、ルータは、それが最終的に勝者になることができると考えて、定期的にオファーメッセージを生成します。
Lose In this state, the router knows that there either is a different election winner or that no router on the link has a path to the RPA.
この状態で負け、ルータは、どちらかが別の選挙の勝者があることを知っているか、リンクにはルータがRPAへのパスを持っていないこと。
Win The router is the acting DF without any contest.
ルータはどんなコンテストのない演技DFで勝ちます。
Backoff The router is the acting DF but another router has made a bid to take over.
バックオフルータが動作するDFですが、別のルータが引き継ぐために入札を行いました。
In the state machine, a router is considered to be an acting DF if it is in the Win or Backoff states.
ステートマシンでは、ルータは、それが勝つか、バックオフ状態にある場合に演技DFであると考えられています。
The operation of the election protocol makes use of the variables and timers described below:
選挙プロトコルの動作を説明変数とタイマーを使用しています：
Acting DF information Used to store the identity and advertised metrics of the election winner that is the currently acting DF.
現在、演技DFである選挙の勝者のアイデンティティと広告されたメトリックを格納するために使用演技のDF情報。
DF election-Timer (DFT) Used to schedule transmission of Offer, Winner, and Pass messages.
DF選挙タイマー（DFT）オファー、受賞、およびパスメッセージの送信をスケジュールするために使用します。
Message-Count (MC) Used to maintain the number of times an Offer or Winner message has been transmitted.
オファーや受賞のメッセージが送信された回数を維持するために使用するメッセージ・カウント（MC）。
Best-Offer Used by the DF to record the identity and advertised metrics of the router that has made the last offer, for use when sending the Path message.
アイデンティティとPathメッセージを送信する際に使用するため、最後のオファーをしたルータのアドバタイズされたメトリックを記録するためにDFが使用する最高のオファー。
The election process uses the following PIM control messages. The packet format is described in Section 3.7:
選挙プロセスは、以下のPIMコントロールメッセージを使用しています。パケットフォーマットは、3.7節で説明します。
Offer (OfferingID, Metric) Sent by routers that believe they have a better metric to the RPA than the metric that has been on offer so far.
彼らは、これまで提供してきたメトリックよりもRPAに優れたメトリックを持っていると信じて、ルータによって送信されたオファー（OfferingID、メートル法）。
Winner (DF-ID, DF-Metric) Sent by a router when assuming the role of the DF or when re-asserting in response to worse offers.
DFの役割を想定したとき、またはより悪い申し出に応じて再アサート時にルータによって送信され受賞（DF-ID、DF-メートル）。
Backoff (DF-ID, DF-Metric, OfferingID, OfferMetric, BackoffInterval) Used by the DF to acknowledge better offers. It instructs other routers with equal or worse offers to wait until the DF passes responsibility to the sender of the offer.
バックオフ（DF-ID、DF-メトリック、OfferingID、OfferMetric、BackoffInterval）は、より良いオファーを確認するためにDFによって使用されます。これは、DFがオファーの送信者に責任を通過するまで待つように等しいか悪い申し出を持つ他のルータに指示します。
Pass (Old-DF-ID, Old-DF-Metric, New-DF-ID, New-DF-Metric) Used by the old DF to pass forwarding responsibility to a router that has previously made an offer. The Old-DF-Metric is the current metric of the DF at the time the pass is sent.
峠（旧-DF-ID、旧-DF-メトリック、新DF-ID、新DF-メトリックは）以前のオファーをしたルータへの転送の責任を渡すために、古いDFによって使用されます。旧-DF-メトリックは、パスが送信された時点でのDFの現在の測定基準です。
Note that when a router is participating in a DF election for an RPA on the interface that its MRIB indicates as the RPF Interface, then that router MUST always advertise an infinite metric in its election messages. When a router is participating in a DF election on an interface other than the MRIB-indicated RPF Interface, then it MUST advertise the MRIB-provided metrics in its election messages.
ルータがMRIBがRPFインターフェイスとして示しインターフェイス上RPAのためのDF選定に参加しているとき、そのルータは、常にその選挙のメッセージに無限のメトリックを広告しなければならないことに注意してください。ルータがMRIBで示したRPFインターフェイス以外のインターフェイス上でDF選定に参加しているとき、それはその選挙のメッセージにMRIBが提供するメトリックをアドバタイズする必要があります。
During protocol operation, the following events can take place:
プロトコルの動作時には、以下のイベントを行うことができます。
Control message reception Reception of one of the four control DF election messages (Offer, Winner, Backoff, and Pass). When a control message is received and actions are specified on a condition that metrics are Better or Worse, the comparison must be performed as follows:
4つの制御DF選定メッセージのいずれかの制御メッセージ受信レセプション（オファー、受賞、バックオフ、およびパス）。制御メッセージが受信され、アクションがメトリックは良くも悪くもあることを条件に指定された場合、以下のように、比較を実行する必要があります。
o On receipt of an Offer or Winner message, compare the current metrics for the RPA with the metrics advertised for the sender of the message.
Oオファー又はウィナーメッセージを受信すると、メッセージの送信者のためにアドバタイズメトリックとRPAのための現在のメトリックを比較します。
o On receipt of a Backoff or Pass message, compare the current metrics for the RPA with the metrics advertised for the target of the message.
Oバックオフまたはパスメッセージを受信すると、メッセージのターゲットのアドバタイズメトリックとRPAのための現在のメトリックを比較します。
Path to RPA lost Losing the path to the RPA can happen in two ways. The first happens when the route learned through the MRIB is withdrawn and the MRIB no longer reports an available route to reach the RPA. The second case happens when the next-hop information reported by the MRIB changes to indicate a next-hop that is reachable through the router interface under consideration. Clearly, as the router is using the interface as its RPF Interface, it cannot offer forwarding services towards the RPL to other routers on that link.
RPAへのパスは、RPAへのパスは以下の2つの方法で発生する可能性が負け失いました。 MRIBが撤回されていないとMRIBは、もはやRPAに到達するために使用可能なルートを報告してルートが学習時に最初に発生します。 MRIB変化によって報告ネクストホップ情報は、考慮中のルータインターフェイスを介して到達可能な次のホップを指示するときに、第2のケースが起こります。ルータがRPFインターフェイスとしてインターフェイスを使用しているとして、明らかに、それは、そのリンク上の他のルータにRPLへの転送サービスを提供することはできません。
Metric reported by the MRIB to reach the RPA changes This event is triggered when the MRIB supplied information for the RPA changes and the new information provides a path to the RPA. If the new MRIB information either reports no route or reports a next-hop interface through the interface for which the DF election is taking place, then the "Path to RPA lost" event triggers instead. In specific states, the event may be further filtered by specifying whether it is expected of the metric to become better or worse and which of the stored metrics the new MRIB information must be compared against. The new information must be compared with either the router's old metric, the stored DF metric, or the stored Best Offer metric.
RPAに到達するためにMRIBによって報告されたメトリックは、MRIBはRPAの変更のための情報を提供し、新たな情報がRPAへのパスを提供する場合、このイベントがトリガされた変更します。新しいMRIB情報のいずれかの報告がないルートやレポート場合はDFの選挙が行われているインタフェースを介して、ネクストホップインターフェイスは、そのイベントではなくトリガー「RPAへのパスが失われました」。特定の状態では、イベントは、さらに、良いか悪いと格納されたメトリックのどの新しいMRIB情報が比較されなければならないとなるようにメトリックが期待されているかどうかを指定することによってフィルタリングすることができます。新しい情報は、ルータの古いメトリック、保存されたDFメトリック、または保存されたベストオファーメトリックのいずれかと比較されなければなりません。
Election-Timer (DFT) expiration Expiration of the DFT election timer can cause message transmission and state transitions. The event might be further qualified by specifying the value of the Message Count (MC) as well as the current existence of a path to the RPA (as defined above).
DFTの選挙タイマーの選挙タイマー（DFT）有効期限有効期限は、メッセージの送信や状態遷移を引き起こす可能性があります。 （上記で定義した）イベントは、さらに、メッセージ数（MC）、ならびにRPAへのパスの現在の存在の値を指定することによって修飾されるかもしれません。
Detection of DF failure Detection of DF failure can occur through the timeout of PIM neighbor state.
DF障害のDF故障検出の検出は、PIMネイバー状態のタイムアウトを介して起こり得ます。
The DF election state machine action descriptions use the following notation in addition to the pseudocode notation described earlier in this specification:
DF選定・ステート・マシンのアクションの説明は、この明細書で前述した擬似コード表記に加えて、以下の表記を使用します。
?= denotes the operation of lowering a timer to a new value. If the timer is not running, then it is started using the new value. If the timer is running with an expiration lower than the new value, then the timer is not altered.
？=新しい値にタイマーを下げる動作を示しています。タイマーが実行されていない場合、それは、新しい値を使用して開始されます。タイマーが新しい値よりも低く、有効期限で実行されている場合、タイマーは変更されません。
When an action of "set DF to Sender or Target" is encountered during receipt of a Winner, Pass, or Backoff message, it means the following:
「SenderにDFを設定したり、ターゲット」のアクションが受賞、パス、またはバックオフメッセージの受信時に遭遇した場合、それは次のことを意味します。
o On receipt of a Winner message, set the DF to be the originator of the message and record its metrics.
勝者メッセージを受信するとo、DFは、メッセージの発信者であること及びそのメトリックを記録するように設定します。
o On receipt of a Pass message, set the DF to be the target of the message and record its metrics.
Oパスメッセージを受信すると、DFは、メッセージのターゲットとなると、そのメトリックを記録するように設定しました。
o On receipt of a Backoff message, set the DF to be the originator of the message and record its metrics.
バックオフメッセージを受信するとo、DFは、メッセージの発信者であること及びそのメトリックを記録するように設定します。
When a Designated Forwarder election is initiated, the starting state is the Offer state, the message counter (MC) is set to zero, and the DF election Timer (DFT) is set to OPlow (see Section 3.6 for a definition of timer values).
指定フォワーダ選挙が開始されると、開始状態はオファー状態で、メッセージカウンタ（MC）がゼロに設定され、かつDF選挙タイマー（DFT）は、（タイマ値の定義については、セクション3.6を参照）OPlowに設定されています。
Figure 3: Designated Forwarder election state machine in tabular form
図3：表形式で指定フォワーダ選挙ステートマシン
+-------------+------------------------------------------------------+
| | Event |
| Prev State +-----------------+------------------+-----------------+
| | Recv better | Recv better | Recv better |
| | Pass / Win | Backoff | Offer |
+-------------+-----------------+------------------+-----------------+
| | -> Lose | - | - |
| Offer | DF = Sender or | DFT = BOperiod | DFT = OPhigh; |
| | Target; Stop | + OPlow; MC = | MC = 0 |
| | DFT | 0 | |
+-------------+-----------------+------------------+-----------------+
| | - | - | -> Offer |
| Lose | DF = Sender or | DF = Sender | DFT = OPhigh; |
| | Target | | MC = 0 |
+-------------+-----------------+------------------+-----------------+
| | -> Lose | -> Lose | -> Backoff |
| | DF = Sender or | DF = Sender; | Set Best to |
| Win | Target; Stop | Stop DFT | Sender; Send |
| | DFT | | Backoff; DFT = |
| | | | BOperiod |
+-------------+-----------------+------------------+-----------------+
| | -> Lose | -> Lose | - |
| | DF = Sender or | DF = Sender; | Set Best to |
| Backoff | Target; Stop | Stop DFT | Sender; Send |
| | DFT | | Backoff; DFT = |
| | | | BOperiod |
+-------------+-----------------+------------------+-----------------+
+-----------+-------------------------------------------------------+
| | Event |
| +-------------+-------------+--------------+------------+
|Prev State |Recv Backoff |Recv Pass |Recv Worse |Recv worse |
| |for us |for us |Pass / Win / |Offer |
| | | |Backoff | |
+-----------+-------------+-------------+--------------+------------+
| |- |-> Win |- |- |
| |DFT = |Stop DFT |Set DF to |DFT ?= |
|Offer |BOperiod + | |Sender or |OPlow; MC = |
| |OPlow; MC = | |Target; DFT |0 |
| |0 | |?= OPlow; MC | |
| | | |= 0 | |
+-----------+-------------+-------------+--------------+------------+
| |-> Offer |-> Offer |-> Offer |-> Offer |
| |DF = Sender; |DF = Sender; |DF = Sender |DFT = OPlow;|
|Lose |DFT = OPlow; |DFT = OPlow; |or Target; |MC = 0 |
| |MC = 0 |MC = 0 |DFT = OPlow; | |
| | | |MC = 0 | |
+-----------+-------------+-------------+--------------+------------+
| |-> Offer |-> Offer |-> Offer |- |
| |DF = Sender; |DF = Sender; |DF = Sender |Send Winner |
|Win |DFT = OPlow; |DFT = OPlow; |or Target; | |
| |MC = 0 |MC = 0 |DFT = OPlow; | |
| | | |MC = 0 | |
+-----------+-------------+-------------+--------------+------------+
| |-> Offer |-> Offer |-> Offer |-> Win |
| |DF = Sender; |DF = Sender; |DF = Sender |Send Winner;|
|Backoff |DFT = OPlow; |DFT = OPlow; |or Target; |Stop DFT |
| |MC = 0 |MC = 0 |DFT = OPlow; | |
| | | |MC = 0 | |
+-----------+-------------+-------------+--------------+------------+
+--------------------------------------------------------------------+
| In Offer State |
+----------------------+----------------------+----------------------+
| DFT Expires and MC | DFT Expires and MC | DFT Expires and MC |
| is less than | is equal to | is equal to |
| Robustness | Robustness and we | Robustness and |
| | have path to RPA | there is no path |
| | | to RPA |
+----------------------+----------------------+----------------------+
| - | -> Win | -> Lose |
| Send Offer; DFT = | Send Winner | Set DF to None |
| OPlow; MC = MC + 1 | | |
+----------------------+----------------------+----------------------+
+--------------------------------------------------------------------+
| In Offer State |
+--------------------------------------------------------------------+
| Metric changes and is now worse |
+--------------------------------------------------------------------+
| DFT ?= OPlow |
| MC = 0 |
+--------------------------------------------------------------------+
+--------------------------------------------------------------------+
| In Lose State |
+------------------------------+-------------------------------------+
| Detect DF Failure | Metric changes and now |
| | is better than DF |
+------------------------------+-------------------------------------+
| -> Offer | -> Offer |
| DF = None; DFT = | DFT = OPlow_int; MC = 0 |
| OPlow_int; MC = 0 | |
+------------------------------+-------------------------------------+
+--------------------------------------------------------------------+
| In Win State |
+----------------------+-----------------------+---------------------+
| Metric changes and | Timer Expires and | Path to RPA lost |
| is now worse | MC is less than | |
| | Robustness | |
+----------------------+-----------------------+---------------------+
| - | - | -> Offer |
| DFT = OPlow; MC = | Send Winner; DFT = | Set DF to None; |
| 0 | OPlow; MC = MC + 1 | DFT = OPlow; MC = |
| | | 0 |
+----------------------+-----------------------+---------------------+
+--------------------------------------------------------------------+
| In Backoff State |
+----------------------+-----------------------+---------------------+
| Metric changes and | Timer Expires | Path to RPA lost |
| is now better than | | |
| Best | | |
+----------------------+-----------------------+---------------------+
| -> Win | -> Lose | -> Offer |
| Stop Timer | Send Pass; Set DF | Set DF to None; |
| | to stored Best | DFT = OPlow; MC = |
| | | 0 |
+----------------------+-----------------------+---------------------+
For the correct operation of BIDIR-PIM, it is very important to avoid situations where two routers consider themselves to be Designated Forwarders for the same link. The two precautions below are not required for correct operation but can help diagnose and correct anomalies.
BIDIR-PIMの正しい動作のために、2つのルータに同じリンクのためのフォワーダを指定するために自分自身を検討状況を回避することが非常に重要です。下の2つの注意事項は、正しい動作のために必要されていないが、診断し、正しい異常を助けることができます。
After a DF has been elected, a router whose metrics change to become better than the DF will attempt to take over. If during the re-election the acting DF has a condition that causes it to lose all of the election messages (like a CPU overload), the new candidate will transmit three offers and assume the role of the forwarder resulting in two DFs on the link. This situation is pathological and should be corrected by fixing the overloaded router. It is desirable that such an event can be detected by a network administrator.
DFが選出された後、そのメトリックDFよりはましになるように変更ルータが引き継ぐしようとします。再選挙の際に働くDFはそれが（CPUの過負荷などの）選挙メッセージのすべてを失うことになり症状がある場合は、新しい候補は3つのオファーを送信し、リンク上の2人のDFの結果としてフォワーダーの役割を引き継ぎます。この状況は、病的で、オーバーロードルータを固定することにより補正する必要があります。このようなイベントは、ネットワーク管理者によって検出できることが望ましいです。
When a router becomes the DF for a link without receiving a Pass message from the known old DF, the PIM neighbor information for the old DF can be marked to this effect. Upon receiving the next PIM Hello message from the old DF, the router can retransmit Winner messages for all the RPAs for which it is acting as the DF. The anomaly may also be logged by the router in a rate-limited manner to alert the operator.
ルータが知られている古いDFからのパスメッセージを受信せずにリンクするためにDFになると、古いDFのためのPIMネイバー情報は、この効果にマークすることができます。古いDFから次のPIM Helloメッセージを受信すると、ルータはDFとして動作されているすべてのRPASための勝者メッセージを再送信することができます。異常は、オペレータに警告するためにレート制限された様式で、ルータによって記録されてもよいです。
An additional degree of safety can be achieved by having the DF for each RPA periodically announce its status in a Winner message. Transmission of the periodic Winner message can be restricted to occur only for RPAs that have active groups, thus avoiding the periodic control traffic in areas of the network without senders or receivers for a particular RPA.
安全性の追加の程度は、各RPAは、定期的に勝者のメッセージにその状態を通知するためのDFを有することによって達成することができます。周期的な勝者メッセージの送信は、このように特定のRPAのための送信者または受信することなく、ネットワークの分野で周期的制御トラフィックを回避する、唯一の活性基を有するRPASに対して発生するように制限することができます。
BIDIR-PIM maintains the following timers, as discussed in Section 3.1. All timers are countdown timers - they are set to a value and count down to zero, at which point they typically trigger an action. Of course they can just as easily be implemented as count-up timers, where the absolute expiry time is stored and compared against a real-time clock, but the language in this specification assumes that they count downwards to zero.
3.1節で述べたようにBIDIR-PIMは、次のタイマーを維持します。すべてのタイマーはカウントダウンタイマーです - 彼らは、その時点で、彼らは一般的にアクションをトリガー、値に設定し、ゼロにカウントダウンされています。もちろん、彼らは同じように簡単に絶対有効期限の時間は、リアルタイムクロックに対して保存され、比較され、カウントアップタイマー、として実装されますが、この仕様では、言語は、彼らがゼロに下向きに数えることを前提としてすることができます。
Per Rendezvous-Point Address (RPA):
パーランデブーポイントアドレス（RPA）：
Per interface (I):
インターフェイスごとに（I）：
DF Election Timer: DFT(RPA,I)
DF選挙タイマー：DFT（RPA、I）
Per Group (G):
グループごと（G）：
Upstream Join Timer: JT(G)
JT（G）：上流タイマー参加
Per interface (I):
インターフェイスごとに（I）：
Join Expiry Timer: ET(G,I)
参加有効期限タイマー：ET（G、I）
PrunePendingTimer: PPT(G,I)
PrunePendingTimer：PPT（G、I）
When timers are started or restarted, they are set to default values. This section summarizes those default values.
タイマーが起動または再起動されると、それらはデフォルト値に設定されています。ここでは、これらのデフォルト値をまとめたもの。
Timer Name: DF Election Timer (DFT)
タイマー名：DF選挙タイマー（DFT）
+-------------------+------------------------+-----------------------+
| Value Name | Value | Explanation |
+-------------------+------------------------+-----------------------+
| Offer_Period | 100 ms | Interval to wait |
| | | between repeated |
| | | Offer and Winner |
| | | messages. |
+-------------------+------------------------+-----------------------+
| Backoff_Period | 1 sec | Period that acting |
| | | DF waits between |
| | | receiving a better |
| | | Offer and sending |
| | | the Pass message |
| | | to transfer DF |
| | | responsibility. |
+-------------------+------------------------+-----------------------+
| OPlow | rand(0.5, 1) * | Range of actual |
| | Offer_Period | randomised value |
| | | used between |
| | | repeated messages. |
+-------------------+------------------------+-----------------------+
| OPhigh | Election_Robustness | Interval to wait |
| | * Offer_Period | in order to give a |
| | | chance to a router |
| | | with a better |
| | | Offer to become |
| | | the DF. |
+-------------------+------------------------+-----------------------+
Timer Names: Join Expiry Timer (ET(G,I))
タイマー名：参加満了タイマ（ET（G、I））
+---------------+---------------+------------------------------------+
|Value Name | Value | Explanation |
+---------------+---------------+------------------------------------+
|J/P HoldTime | from message | Hold Time from Join/Prune Message |
+---------------+---------------+------------------------------------+
Timer Names: PrunePendingTimer (PPT(G,I))
タイマー名：PrunePendingTimer（PPT（G、I））
+-------------------------+-------------------+----------------------+
| Value Name | Value | Explanation |
+-------------------------+-------------------+----------------------+
| J/P Override Interval | Default: 3 secs | Short period after |
| | | a Join or Prune to |
| | | allow other |
| | | routers on the LAN |
| | | to override the |
| | | Join or Prune |
+-------------------------+-------------------+----------------------+
Note that the value of the J/P Override Interval is interface specific and depends on both the Propagation_Delay and the Override_Interval values that may change when Hello messages are received [4].
J / Pの値がインターバルインターフェース特異的であり、PROPAGATION_DELAYとHelloメッセージを受信したときに変更することができるOverride_Interval値[4]の両方に依存オーバーライドすることに注意してください。
Timer Names: Upstream Join Timer (JT(G))
タイマー名：上流参加タイマー（JT（G））
+------------+-------------------+-----------------------------------+
Value Name |Value Explanation |
+------------+-------------------+-----------------------------------+
t_periodic |Default: 60 secs Period between Join/Prune Messages |
+------------+-------------------+-----------------------------------+
t_suppressed |rand(1.1 * Suppression period when someone |
| |t_periodic, 1.4 * else sends a J/P message so we |
| |t_periodic) don't need to do so. |
+------------+-------------------+-----------------------------------+
t_override |rand(0, 0.9 * J/P Randomized delay to prevent |
| |Override Interval) response implosion when sending a |
| | Join message to override someone |
| | else's Prune message. |
+------------+-------------------+-----------------------------------+
For more information about these values, refer to the PIM-SM [4] documentation.
これらの値の詳細については、PIM-SM [4]マニュアルを参照してください。
Constant Name: DF Election Robustness
定数名：DF選挙頑健性
+-------------------------+------------------+-----------------------+
| Constant Name | Value | Explanation |
+-------------------------+------------------+-----------------------+
| Election_Robustness | Default: 3 | Minimum number of |
| | | election messages |
| | | that must be lost |
| | | in order for |
| | | election to fail. |
+-------------------------+------------------+-----------------------+
This section describes the details of the packet formats for BIDIR-PIM control messages. BIDIR-PIM shares a number of control messages in common with PIM-SM [4]. These include the Hello and Join/Prune messages as well as the format for the Encoded-Unicast address. For details on the format of these packets, please refer to the PIM-SM documentation. Here we will only define the additional packets that are introduced by BIDIR-PIM. These are the packets used in the DF election process as well as the Bidirectional Capable PIM-Hello option.
このセクションでは、BIDIR-PIM制御メッセージのパケットフォーマットの詳細について説明します。 BIDIR-PIMは、PIM-SM [4]と共通の制御メッセージの数を共有します。これらのハローを含めると/プルーンのメッセージだけでなく、エンコードされたユニキャストアドレスの形式に参加します。これらのパケットのフォーマットの詳細については、PIM-SMのドキュメントを参照してください。ここでは、唯一のBIDIR-PIMによって導入された追加パケットを定義します。これらは、DF選定プロセスだけでなく、双方向できるPIM-こんにちはオプションで使用されるパケットです。
All PIM control messages have IP protocol number 103.
すべてのPIMコントロールメッセージは、IPプロトコル番号103を持っています。
BIDIR-PIM messages are multicast with TTL 1 to the `ALL-PIM-ROUTERS' group. The IPv4 `ALL-PIM-ROUTERS' group is `224.0.0.13'. The IPv6 `ALL-PIM-ROUTERS' group is `ff02::d'.
BIDIR-PIMメッセージは、 `ALL-PIM-ルータのグループにTTL 1でマルチキャストされています。 IPv4の `ALL-PIM-ROUTERS」グループは` 224.0.0.13' です。 IPv6の `ALL-PIM-ROUTERS 'グループは` FF02 :: D' です。
All DF election BIDIR-PIM control messages share the common header below:
すべてのDF選定BIDIR-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 |Subtype| Rsvd | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP Address (Encoded-Unicast format) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Metric Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Ver PIM Version number is 2.
PIM版PIMバージョン番号は2です。
Type All DF-Election PIM control messages share the PIM message Type of 10.
メッセージは10のPIMメッセージタイプを共有するすべてのDF-選挙のPIMコントロールを入力します。
Subtype Subtypes for DF election messages are:
DF選定メッセージのサブタイプのサブタイプは以下のとおりです。
1 = Offer
2 = Winner
3 = Backoff
4 = Pass
Rsvd Set to zero on transmission. Ignored on receipt.
RSVD送信時にゼロに設定してください。領収書の上で無視。
Checksum A standard checksum IP checksum is used, i.e., the 16-bit one's complement of the one's complement sum of the entire PIM message. For computing the checksum, the checksum field is zeroed.
サムA標準チェックサムIPチェックサムが使用され、すなわち、全体のPIMメッセージの1の補数和の16ビットの1の補数。チェックサムを計算するために、チェックサムフィールドがゼロにされます。
RP Address The bidirectional RPA for which the election is taking place. The format is described in [4], Section 4.9.1.
RPアドレス選挙が行われている双方向RPA。フォーマットは、[4]、セクション4.9.1に記載されています。
Sender Metric Preference Preference value assigned to the unicast routing protocol that the message sender used to obtain the route to the RPA.
メッセージの送信者がRPAへのルートを取得するために使用されるユニキャストルーティングプロトコルに割り当てられた送信者メトリック嗜好プリファレンス値。
Sender Metric The unicast routing table metric used by the message sender to reach the RPA. The metric is in units applicable to the unicast routing protocol used.
送信者メトリックRPAに到達するために、メッセージ送信者によって使用されるユニキャストルーティングテーブルメトリック。メトリックは、使用されるユニキャストルーティングプロトコルに適用単位です。
In addition to the fields defined above, the Backoff and Pass messages have the extra fields described below.
上記で定義されたフィールドに加えて、バックオフとパスのメッセージは以下の余分なフィールドを持っています。
The Backoff message uses the following fields in addition to the common election message format described above.
バックオフメッセージは、上述した一般的な選挙メッセージフォーマットに加えて、以下のフィールドを使用します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offering Address (Encoded-Unicast format) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offering Metric Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offering Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Offering Address The address of the router that made the last (best) Offer. The format is described in [4], Section 4.9.1.
最後（最高の）オファーをしたルータのアドレスアドレスを提供しています。フォーマットは、[4]、セクション4.9.1に記載されています。
Offering Metric Preference Preference value assigned to the unicast routing protocol that the offering router used to obtain the route to the RPA.
提供ルータがRPAへのルートを取得するために使用されるユニキャストルーティングプロトコルに割り当てられたメトリック嗜好プリファレンス値を提供します。
Offering Metric The unicast routing table metric used by the offering router to reach the RPA. The metric is in units applicable to the unicast routing protocol used.
メトリックにRPAに到達するために提供するルータで使用されるユニキャストルーティングテーブルのメトリックを提供しています。メトリックは、使用されるユニキャストルーティングプロトコルに適用単位です。
Interval The backoff interval in milliseconds to be used by routers with worse metrics than the offering router.
ミリ秒単位の間隔バックオフ間隔が提供ルーターよりも悪いメトリックでルータによって使用されます。
The Pass message uses the following fields in addition to the common election fields described above.
パスメッセージは、上記の一般的な選挙の分野に加えて、次のフィールドを使用しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New Winner Address (Encoded-Unicast format) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New Winner Metric Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New Winner Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
New Winner Address The address of the router that made the last (best) Offer. The format is described in [4], Section 4.9.1.
新しい勝者は最後（最高の）オファーをしたルータのアドレス。フォーマットは、[4]、セクション4.9.1に記載されています。
New Winner Metric Preference Preference value assigned to the unicast routing protocol that the offering router used to obtain the route to the RPA.
提供ルータがRPAへのルートを取得するために使用されるユニキャストルーティングプロトコルに割り当てられた新しい勝者メトリック嗜好プリファレンス値。
New Winner Metric The unicast routing table metric used by the offering router to reach the RPA. The metric is in units applicable to the unicast routing protocol used.
新しい勝者メトリックRPAに到達するために提供するルータで使用されるユニキャストルーティングテーブルのメトリック。メトリックは、使用されるユニキャストルーティングプロトコルに適用単位です。
BIDIR-PIM introduces one new PIM-Hello option.
BIDIR-PIM、1つの新しいPIM-こんにちはオプションを紹介します。
o OptionType 22: Bidirectional Capable
でoptionType 22 O：双方向可能
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 22 | Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Routers discover that a range of multicast group addresses operates in bidirectional mode, and that the address of the Rendezvous-Point address (RPA) is serving the group range either through static configuration or using an automatic RP discovery mechanism like the PIM Bootstrap mechanism (BSR) [7] or Auto-RP.
ルータは（BSRをマルチキャストグループアドレスの範囲が双方向モードで動作すること、及びランデブーポイントアドレス（RPA）のアドレスは、静的構成を介してグループ範囲にサービスを提供するか、PIMブートストラップ機構のような自動RPディスカバリメカニズムを使用していることを発見します）[7]またはAuto-RP。
The IPsec [5] authentication header MAY be used to provide data integrity protection and group-wise data origin authentication of BIDIR-PIM protocol messages. Authentication of BIDIR-PIM messages can protect against unwanted behaviour caused by unauthorized or altered BIDIR-PIM messages.
IPsecは、[5]認証ヘッダは、データの整合性保護とBIDIR-PIMプロトコルメッセージのグループごとのデータ発信元認証を提供するために使用され得ます。 BIDIR-PIMメッセージの認証は、不正または変更されたBIDIR-PIMメッセージによって引き起こされる不要な動作から保護することができます。
As in PIM Sparse-Mode, the extent of possible damage depends on the type of counterfeit messages accepted. BIDIR-PIM only uses link-local multicast messages sent to the ALL_PIM_ROUTERS address, hence attacks can only be carried out by directly connected nodes, or with the complicity of directly connected routers.
PIMスパースモードのように、損傷の程度が受け入れ偽造メッセージのタイプに依存します。 BIDIR-PIMは、従って攻撃のみ直接接続されたノードによって、または直接接続されたルータの共謀を用いて行うことができるALL_PIM_ROUTERSアドレスに送信されたリンクローカルマルチキャストメッセージを使用します。
Some of the BIDIR-PIM protocol messages (Join/Prune and Hello) are identical, both in format and functionality, to the respective messages used in PIM-SM. Security considerations for these messages are to be found in [4]. Other messages (DF-election messages) are specific to BIDIR-PIM and will be discussed in the following paragraphs.
BIDIR-PIMプロトコルメッセージの一部は、PIM-SMで使用される各メッセージに、形式および機能の両方において同一である（/プルーンとハローが参加します）。これらのメッセージのセキュリティに関する考慮事項は、[4]に見られます。その他のメッセージ（DF-選挙メッセージ）BIDIR-PIMに固有のものであり、以下の段落で説明します。
By forging DF-election messages, an attacker can disrupt the election of the Designated Forwarder on a link in two different ways:
DF-選挙メッセージを鍛造することにより、攻撃者は、2つの異なる方法でリンクを指定フォワーダの選挙を妨害することができます。
An attacker can force its election as DF by participating in a regular election and advertising the best metric to reach the RPA. An attacker can also try to force the election of another router as DF by sending an Offer, Winner, or Pass message and impersonating another router. In some cases (e.g., the Offer), multiple messages might be needed to carry out an attack.
攻撃者は、通常の選挙に参加し、RPAに到達するために最善のメトリックをアドバタイズすることでDFとしての選挙を強制することができます。攻撃者はまた、オファー、受賞、またはパスメッセージを送信し、別のルータになりすますことでDFとして別のルータの選出を強制しようとすることができます。いくつかのケース（例えば、オファー）では、複数のメッセージには、攻撃を実行するために必要になる場合があります。
In the case of Offer or Winner messages, the attacker will have to impersonate the node that it wants to have become the DF. In the case of the Pass, it will have to impersonate the current DF. This type of attack causes the wrong DF to be recorded in all nodes apart from the one that is being impersonated. This node typically will be able to detect the anomaly and, possibly, restart a new election.
オファーや受賞のメッセージの場合、攻撃者は、それがDFになっていたいノードを偽装する必要があります。峠のケースでは、現在のDFを偽装する必要があります。この種の攻撃は、間違ったDFが偽装されているものから離れて、すべてのノードに記録されます。このノードは通常、異常を検出して、おそらく、新しい選挙を再起動することができるようになります。
A more sophisticated attacker might carry out a concurrent DoS attack on the node being impersonated, so that it will not be able to detect the forged packets and/or take countermeasures.
偽造パケットを検出および/または対策を取ることができなくなりますように、より洗練された攻撃者は、偽装されたノード上の同時DoS攻撃を実行する可能性があります。
All attacks based on impersonation can be detected by all routers and avoided if the source of DF-election messages can be authenticated. When authentication is available, spoofed messages MUST be discarded and a rate-limited warning message SHOULD be logged.
偽装に基づくすべての攻撃は、すべてのルータによって検出され、DF-選挙メッセージの送信元を認証することができる場合に回避することができます。認証が利用可能である場合には、偽装されたメッセージは捨てなければなりませんし、レート制限警告メッセージが記録されるべきです。
A more subtle attacker could use MAC-level addresses to partition the set of recipients of DF-election messages and create an inconsistent DF view on the link. For example, the attacker could use unicast MAC addresses for its forged DF-election messages. To prevent this type of attack, BIDIR-PIM routers SHOULD check the destination MAC address of received DF-election messages. This however is ineffective on links that do not support layer-2 multicast delivery.
より微妙な攻撃者は、DF-選挙メッセージの受信者の集合を分割し、リンク上の一貫性のないDFのビューを作成するために、MACレベルのアドレスを使用することができます。例えば、攻撃者は、その偽造DF-選挙メッセージのためのユニキャストMACアドレスを使用することができます。この種の攻撃を防ぐために、BIDIR-PIMルータが受信DF-選挙メッセージの宛先MACアドレスを確認する必要があります。しかし、これは、レイヤ2マルチキャスト配信をサポートしていないリンク上では無効です。
Source authentication is also sufficient to prevent this kind of attack.
ソース認証もこの種の攻撃を防止するのに十分です。
By forging DF election messages, an attacker can prevent the election from converging, thus disrupting the establishment of multicast forwarding trees. There are many ways to achieve this. The simplest is by sending an infinite sequence of Offer messages (the metric used in the messages is not important).
DF選定メッセージを鍛造することにより、攻撃者は、このようにマルチキャスト転送ツリーの確立を破壊し、収束から選挙を防ぐことができます。これを達成するための多くの方法があります。最も単純には、オファーメッセージ（メッセージの中で使用されるメトリックは重要ではありません）の無限列を送信することです。
A BIDIR-PIM router SHOULD provide an option to limit the set of neighbors from which it will accept Join/Prune, Assert, and DF-election messages. Either static configuration of IP addresses or an IPsec security association may be used. Furthermore, a PIM router SHOULD NOT accept protocol messages from a router from which it has not yet received a valid Hello message.
BIDIR-PIMルータは、それが参加/プルーン、アサート、及びDF-選挙メッセージを受け入れるから、隣人のセットを制限するためのオプションを提供する必要があります。静的IPアドレスの設定やIPsecセキュリティ協会のどちらかを使用することができます。さらに、PIMルータは、それがまだ有効なHelloメッセージを受信していない元のルータからのプロトコルメッセージを受け入れるべきではありません。
In a PIM-SM domain, when all routers are trusted, it is possible to implement a basic form of access control for both sources and receivers: Receivers can be validated by the last-hop DR and sources can be validated by the first-hop DR and/or the RP.
すべてのルータが信頼されているPIM-SMドメインでは、ソースと受信機の両方のためのアクセス制御の基本的な形態を実現することができる：受信機は、最後のホップDRによって検証することができ、ソースは、最初のホップによって検証することができますDRおよび/またはRP。
In BIDIR-PIM, this is generally feasible only for receivers, as sources can send to the multicast group without the need for routers to detect their activity and create source-specific state. However, it is possible to modify the standard BIDIR-PIM behaviour, in a backward compatible way, to allow per-source access control. The tradeoff would be protocol simplicity, memory, and processing requirements.
ソースはそれらの活性を検出し、ソース固有の状態を作成するためにルータを必要とすることなく、マルチキャストグループに送信できるようにBIDIR-PIMでは、これは、唯一の受信機のために一般的に可能です。しかし、あたり、ソースのアクセス制御を可能にするために、後方互換性のある方法で、標準BIDIR-PIMの動作を変更することが可能です。トレードオフは、プロトコルシンプルさ、メモリ、および処理要件になります。
Just as with PIM-SM, the IPsec [5] transport mode using the Authentication Header (AH) is the recommended method to prevent the above attacks against BIDIR-PIM.
ちょうどPIM-SMと同様に、認証ヘッダ（AH）を使用したIPsec [5]トランスポートモードはBIDIR-PIMに対して上記の攻撃を防ぐために推奨される方法です。
It is recommended that IPsec authentication be applied to all BIDIR-PIM protocol messages. The specification on how this is done is found in [4]. Specifically, the authentication of PIM-SM link-local messages, described in [4], applies to all BIDIR-PIM messages as well.
IPsecの認証はすべてBIDIR-PIMプロトコルメッセージに適用することをお勧めします。これがどのように行われるかの仕様は、[4]に含まれています。具体的には、[4]に記載のPIM-SMリンクローカルメッセージの認証は、同様に全てBIDIR-PIMメッセージに適用されます。
The denial-of-service attack based on forged Join messages, described in [4], also applies to BIDIR-PIM.
で説明したJoinメッセージを偽造に基づいてサービス拒否攻撃は、[4]、またBIDIR-PIMに適用されます。
IANA has assigned OptionType 22 to the "Bidirectional Capable" option.
IANAは、「双方向できる」オプションにでoptionType 22を割り当てています。
The bidirectional proposal in this document is heavily based on the ideas and text presented by Estrin and Farinacci in [6]. The main difference between the two proposals is in the method chosen for upstream forwarding.
この文書に記載されている双方向の提案は重くにEstrinとファリナッチが提示アイデアやテキストに基づいている[6]。二つの提案の主な違いは、上流の転送のために選択された方法です。
We would also like to thank John Zwiebel at Cisco, Deborah Estrin at ISI/USC, Bill Fenner at AT&T Research, as well as Nidhi Bhaskar, Yiqun Cai, Toerless Eckert, Apoorva Karan, Rajitha Sumanasekera, and Beau Williamson at Cisco for their contributions and comments to this document.
我々はまた、彼らの貢献のためにシスコのCiscoのJohn Zwiebel、ISI / USCのデボラ・エストリン、AT＆T Researchのビルフェナー、などNidhi Bhaskar、Yiqunカイ、Toerlessエッカート、Apoorvaカラン、Rajitha Sumanasekera、およびボー・ウィリアムソンに感謝したいと思いますこのドキュメントにコメントしています。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[2]カイン、B.、デアリング、S.、Kouvelas、I.、フェナー、B.、およびA. Thyagarajan、 "インターネットグループ管理プロトコル、バージョン3"、RFC 3376、2002年10月。
[3] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[3]デアリング、S.、フェナー、W.、およびB.ハーバーマン、 "マルチキャストリスナ発見IPv6の（MLD）"、RFC 2710、1999年10月。
[4] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[4]フェナー、B.、ハンドリー、M.、ホルブルック、H.、およびI. Kouvelas、 "プロトコル独立マルチキャスト - スパースモード（PIM-SM）：プロトコル仕様（改訂）"、RFC 4601、2006年8月を。
[5] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[5]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[6] Estrin, D. and D. Farinacci, "Bi-directional Shared Trees in PIM-SM", Work in Progress, May 1999.
[6] Estrin、D.とD.ファリナッチ、 "PIM-SMでの双方向の共有ツリー"、進歩、1999年5月での作業。
[7] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap Router (BSR) Mechanism for PIM", Work in Progress, February 2007.
[7] Bhaskar、N.、ガル、A.、リンガード、J.、およびS. Venaas、 "PIMブートストラップルータ（BSR）メカニズム"、進歩、2007年2月ワーク。
[8] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[8]ベイツ、T.、チャンドラ、R.、キャッツ、D.、およびY. Rekhter、 "BGP-4のためのマルチプロトコルの拡張"、RFC 4760、2007年1月を。
Index
指数
DF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5,18
Downstream. . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
DownstreamJPState(G,I). . . . . . . . . . . . . . . . . . . . . . 10
ET(G,I) . . . . . . . . . . . . . . . . . . . . . . . . . . . 9,14,33
ET(RPA,I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
I_am_DF(RPA,I). . . . . . . . . . . . . . . . . . . . . . . .10,12,14
J/P_HoldTime. . . . . . . . . . . . . . . . . . . . . . . . . . . 33
J/P_Override_Interval . . . . . . . . . . . . . . . . . . . . . 16,33
JoinDesired(G). . . . . . . . . . . . . . . . . . . . . . . . . . 18
joins(G). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
JT(*,G) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
JT(G) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9,33
local_receiver_include(G,I) . . . . . . . . . . . . . . . . . . . 10
MFIB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
NLT(N,I). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Offer_Period. . . . . . . . . . . . . . . . . . . . . . . . . . . 32
olist(G). . . . . . . . . . . . . . . . . . . . . . . . . . .10,12,18
Bidirectional Capable OptionType . . . . . . . . . . . . . . . . 37
pim_include(G). . . . . . . . . . . . . . . . . . . . . . . . . . 10
PPT(G,I). . . . . . . . . . . . . . . . . . . . . . . . . . . 9,14,33
RPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
RPF_interface(RPA). . . . . . . . . . . . . . . . . . . . . . . 10,12
RPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
TIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
t_override. . . . . . . . . . . . . . . . . . . . . . . . . . . 17,33
t_periodic. . . . . . . . . . . . . . . . . . . . . . . . . . . 17,33
t_suppressed. . . . . . . . . . . . . . . . . . . . . . . . . . 17,33
Upstream. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses
著者のアドレス
Mark Handley Computer Science Department University College London EMail: M.Handley@cs.ucl.ac.uk
マーク・ハンドリーコンピュータサイエンス学部ユニバーシティ・カレッジ・ロンドンのEメール：M.Handley@cs.ucl.ac.uk
Isidor Kouvelas Cisco Systems EMail: kouvelas@cisco.com
ISIDOREにKouvelasアイビーシステムEMAIL：kouvelas@kisso.kom
Tony Speakman Cisco Systems EMail: speakman@cisco.com
トニー・スピークマンシスコシステムズ電子メール：speakman@cisco.com
Lorenzo Vicisano Digital Fountain EMail: lorenzo@digitalfountain.com
ロレンツォVicisanoデジタル噴水Eメール：lorenzo@digitalfountain.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
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, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。