RFC 6226 - PIM Group-to-Rendezvous-Point Mapping 日本語訳

URL : https://tools.ietf.org/html/rfc6226
タイトル : RFC 6226 - PIMグループ・ツー・ランデブーポイントのマッピング
翻訳編集 : 自動生成

Internet Engineering Task Force (IETF)                          B. Joshi
Request for Comments: 6226                     Infosys Technologies Ltd.
Updates: 4601                                                 A. Kessler
Category: Standards Track                            Cisco Systems, Inc.
ISSN: 2070-1721                                              D. McWalter
                                                                May 2011

                 PIM Group-to-Rendezvous-Point Mapping

Abstract

抽象

Each Protocol Independent Multicast - Sparse Mode (PIM-SM) router in a PIM domain that supports Any Source Multicast (ASM) maintains Group-to-RP mappings that are used to identify a Rendezvous Point (RP) for a specific multicast group. PIM-SM has defined an algorithm to choose a RP from the Group-to-RP mappings learned using various mechanisms. This algorithm does not consider the PIM mode and the mechanism through which a Group-to-RP mapping was learned.

各プロトコル独立マルチキャスト - 任意のソースマルチキャスト（ASM）をサポートするPIMドメイン内の希薄モード（PIM-SM）ルータは、特定のマルチキャストグループのランデブーポイント（RP）を識別するために使用されているグループに-RPマッピングを維持します。 PIM-SMは、グループ・ツー・RPマッピングは、様々なメカニズムを使用して学んだからRPを選択するアルゴリズムを定義しています。このアルゴリズムは、PIMモードおよびグループ-RPマッピングが学習された通過メカニズムを考慮していません。

This document defines a standard algorithm to deterministically choose between several Group-to-RP mappings for a specific group. This document first explains the requirements to extend the Group-to-RP mapping algorithm and then proposes the new algorithm.

この文書では、決定論的に、特定のグループのために、いくつかのグループに-RPマッピングの間で選択するための標準的なアルゴリズムを定義します。この文書では、最初のグループに-RPマッピングアルゴリズムを拡張するための要件を説明し、その後、新しいアルゴリズムを提案しています。

Status of This Memo

このメモのステータス

This is an Internet Standards Track document.

これは、インターネット標準化過程文書です。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6226.

このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6226で取得することができます。

著作権表示

著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。

Table of Contents

   1. Introduction ....................................................2
   2. Terminology .....................................................3
   3. Existing Algorithm ..............................................4
   4. Assumptions .....................................................5
   5. Common Use Cases ................................................5
   6. Proposed Algorithm ..............................................6
   7. Interpretation of MIB Objects ...................................8
   8. Clarification for MIB Objects ...................................8
   9. Use of Dynamic Group-to-RP Mapping Protocols ....................9
   10. Considerations for Bidirectional-PIM and BSR Hash ..............9
   11. Filtering Group-to-RP Mappings at Domain Boundaries ............9
   12. Security Considerations .......................................10
   13. Acknowledgements ..............................................10
   14. Normative References ..........................................10

1. Introduction

1. はじめに

Multiple mechanisms exist today to create and distribute Group-to-RP mappings. Each PIM-SM router may learn Group-to-RP mappings through various mechanisms, as described in Section 4.

複数のメカニズムは、グループ・ツー・RPマッピングを作成し、配布するために、今日存在します。第4節で説明したように、各PIM-SMルータは、様々なメカニズムによって、グループ・ツー・RPマッピングを学習することがあります。

It is critical that each router select the same 'RP' for a specific multicast group address; otherwise, full multicast connectivity will not be established. This is true even when using an Anycast RP to provide redundancy. This RP address may correspond to a different physical router, but it is one logical RP address and must be consistent across the PIM domain. This is usually achieved by using the same algorithm to select the RP in all the PIM routers in a domain.

各ルータが特定のマルチキャストグループアドレスのため同じ「RP」を選択することが重要です。それ以外の場合は、完全なマルチキャスト接続が確立されません。これは、冗長性を提供するために、エニーキャストRPを使用する場合でも当てはまります。このRPアドレスは、異なる物理ルータに対応していてもよいが、それは一つの論理RPアドレスで、PIMドメイン間で一致している必要があります。これは通常、ドメイン内のすべてのPIMルータでRPを選択するために、同じアルゴリズムを使用することによって達成されます。

PIM-SM [RFC4601] has defined an algorithm to select a 'RP' for a given multicast group address, but it is not flexible enough for an administrator to apply various policies. Please refer to Section 3 for more details.

PIM-SM [RFC4601]は特定のマルチキャストグループアドレスのための「RP」を選択するアルゴリズムを定義しているが、それはさまざまなポリシーを適用するには、管理者のための十分な柔軟性ではありません。詳細はセクション3を参照してください。

The PIM-STD-MIB [RFC5060] includes a number of objects to allow an administrator to set the precedence for Group-to-RP mappings that are learned statically or dynamically and stored in the 'pimGroupMappingTable'. The Management Information Base (MIB) module also defines an algorithm that can be applied to the data contained in the 'pimGroupMappingTable' to determine Group-to-RP mappings. However, this algorithm is not completely deterministic, because it includes an implementation-specific 'precedence' value.

PIM-STD-MIB [RFC5060]は、静的または動的に学習及び「pimGroupMappingTable」に格納されているグループとRPのマッピングのための優先順位を設定するために管理者を可能にするオブジェクトの数を含んでいます。管理情報ベース（MIB）モジュールはまた、グループとRPのマッピングを決定するために、「pimGroupMappingTable」に含まれるデータに適用することができるアルゴリズムを定義します。それは実装固有の「優先度」の値を含んでいるのでしかし、このアルゴリズムは、完全に決定論的ではありません。

Network management stations will be able to deduce which RPs will be selected by applying the algorithm from this document to the list of Group-to-RP mappings from the 'pimGroupMappingTable'. The algorithm provides MIB visibility into how routers will apply Group-to-RP mappings and also fixes the inconsistency introduced by the way that different vendors implement the selection of the Group-to-RP mappings to create multicast forwarding state.

ネットワーク管理ステーションは「pimGroupMappingTable」からグループへ-RPマッピングのリストに、この文書からアルゴリズムを適用することにより、RPが選択される推測することができるようになります。このアルゴリズムは、ルータがグループに-RPマッピングを適用しても、異なるベンダーがマルチキャスト転送状態を作成するには、グループ-RPマッピングの選択を実装することによって導入された矛盾を修正する方法にMIBの可視性を提供します。

Embedded-RP, as defined in Section 7.1 of "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address" [RFC3956], specifies the following: "To avoid loops and inconsistencies, for addresses in the range ff70::/12, the Embedded-RP mapping MUST be considered the longest possible match and higher priority than any other mechanism".

「レンジFF70 :: / 12のアドレスのためのループと矛盾を回避するには、次のセクションで定義されている組み込み-RPは、「IPv6マルチキャストアドレスでのランデブーポイント（RP）アドレスを埋め込み」[RFC3956]の7.1には、以下の指定します、埋め込み-RPマッピング「は、任意の他の機構よりも可能な限り長い一致より高い優先度とみなされなければなりません。

2. Terminology

2.用語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。

This document also uses the following terms:

また、このドキュメントでは、次の用語を使用しています：

o PIM Mode

おぴＭもで

PIM Mode is the mode of operation for which a particular multicast group is used. Wherever this term is used in this document, it refers to either Sparse Mode or Bidirectional (BIDIR) Mode.

PIMモードは、特定のマルチキャストグループが使用される動作モードです。この用語が本文書で使用される限り、それは、スパースモードまたは双方向（BIDIR）モードのいずれかを指します。

o Dynamic Group-to-RP Mapping Mechanisms

OダイナミックグループツーRPのマッピングメカニズム

The term "dynamic Group-to-RP mapping mechanisms" in this document refers to Bootstrap Router (BSR) [RFC5059] and Auto-RP.

この文書における用語「動的グループ・ツー・RPマッピングメカニズムは、」ルータ（BSR）[RFC5059]とAuto-RPをブートストラップすることを指します。

o Dynamic Mappings and Dynamically Learned Mappings

Oダイナミックマッピングおよび動的に学習マッピング

The terms "dynamic mappings" and "dynamically learned mappings" refer to Group-to-RP mappings that have been learned by either BSR or Auto-RP. Group-to-RP mappings that have been learned by Embedded-RP are referred to as Embedded Group-to-RP mappings.

用語「ダイナミックマッピング」と「動的に学習マッピングは、」BSRまたはAuto-RPのいずれかによって学習されているグループ-RPマッピングを参照してください。組み込み-RPによって学習されたグループに-RPマッピングは、組み込みグループに-RPマッピングと呼ばれています。

o Filtering

フィルタリングO

Filtering is the selective discarding of dynamic Group-to-RP mapping information, based on the group address, the type of Group-to-RP mapping message, and the interface on which the mapping message was received.

フィルタリングは、グループアドレス、グループ・ツー・RPマッピング・メッセージのタイプ、およびマッピングメッセージを受信したインターフェイスに基づいて、動的グループ・ツー・RPマッピング情報を選択的に廃棄します。

o Multicast Domain and Boundaries

マルチキャストドメインとの境界O

The term "multicast domain" used in this document refers to a network topology that has a consistent set of Group-to-RP mappings. The interface between two or more multicast domains is a multicast domain boundary. The multicast boundaries are usually enforced by filtering the dynamic mapping messages and/or configuring different static RP mappings.

この文書で使用される用語「マルチキャストドメインは、」グループ-RPマッピングの一貫性を持っているネットワークトポロジを指します。二つ以上のマルチキャストドメイン間の界面は、マルチキャストドメインの境界です。マルチキャスト境界は通常、動的マッピングメッセージをフィルタリングおよび/または異なる静的RPマッピングを構成することによって実施されます。

3. Existing Algorithm

3.既存のアルゴリズム

The existing algorithm defined in PIM-SM (Section 4.7.1 of [RFC4601]) does not consider the following constraints:

PIM-SM（[RFC4601]のセクション4.7.1）で定義された既存のアルゴリズムは、以下の制約を考慮していません。

o It does not consider the origin of a Group-to-RP mapping and therefore will treat all of them equally.

Oそれはグループ-RPマッピングの起源を考慮していないため、均等にそれらのすべてを扱います。

o It does not provide the flexibility to give higher priority to a specific PIM mode. For example, an entry learned for the PIM-BIDIR Mode is treated with the same priority as an entry learned for PIM-SM.

Oそれは特定のPIMモードを優先するための柔軟性を提供していません。例えば、エントリはPIM-BIDIRモードがエントリはPIM-SMのために学習されたのと同じ優先順位で処理するために学びました。

The algorithm defined in this document updates the algorithm defined in PIM-SM (Section 4.7.1 of [RFC4601]). The new algorithm is backward compatible and will produce the same result only if the Group-to-RP mappings are learned from a single mapping source. The full benefits of the new algorithm will not be realized until it is widely deployed.

この文書で定義されたアルゴリズムは、PIM-SM（[RFC4601]のセクション4.7.1）で定義されたアルゴリズムを更新します。新しいアルゴリズムは、下位互換性があり、グループに-RPマッピングが単一のマッピングソースから学習される場合にのみ、同じ結果を生成します。それが広く展開されるまで、新しいアルゴリズムの完全な利点が実現されることはありません。

4. Assumptions

4.想定

We have made the following assumptions in defining this algorithm:

私たちは、このアルゴリズムを定義するには、以下の仮定を行いました。

o A Group-to-RP mapping can be learned from various mechanisms. We assume that the following list is ordered by decreasing preference for these mechanisms:

Oグループへ-RPマッピングは、さまざまなメカニズムから学ぶことができます。私たちは、以下のリストは、これらのメカニズムのための好みを減少させることによって発注されていることを前提としています。

* Embedded Group-to-RP mappings

*組み込みグループ-RPマッピング

* Dynamically learned mappings

*動的に学習のマッピング

* Static configuration

*静的な設定

* Other mapping method

*その他のマッピング方法

o Embedded Group-to-RP mappings are special and always have the highest priority. They cannot be overridden by static configuration or by dynamic Group-to-RP mappings.

O組込みグループに-RPマッピングは特別で、常に最高の優先度を持っています。彼らは、静的な構成によって、または動的グループ-RPマッピングによって上書きすることはできません。

o Dynamic mappings will override a static RP configuration if they have overlapping ranges. However, it is possible to override dynamic Group-to-RP mappings with static configurations, either by filtering, or by configuring longer static group addresses that override dynamic mappings when longest prefix matching is applied.

彼らは範囲が重複している場合は、O、動的マッピングは、スタティックRPの設定を上書きします。しかし、いずれかのフィルタリングによって、または最長プレフィックスマッチングが適用されるときに、動的マッピングをオーバーライド長い静的グループアドレスを設定することにより、静的構成の動的なグループに-RPマッピングを上書きすることが可能です。

o A Group-to-RP mapping learned for PIM-BIDIR Mode is preferred to an entry learned for PIM-SM Mode as stipulated in Section 3.3 of [RFC5059].

[RFC5059]のセクション3.3に定めるOグループとRPのマッピングは、PIM-BIDIRモードの学習さはPIM-SMモードのために学習されたエントリに好ましいです。

o Dynamic Group-to-RP mapping mechanisms are filtered at domain boundaries or for policy enforcement inside a domain.

Oダイナミックグループ-RPマッピングのメカニズムは、ドメイン境界で、またはドメイン内のポリシーの施行のためにフィルタリングされます。

5. Common Use Cases

5.一般的なユースケース

A network operator deploying IP Multicast will require a deterministic way to select the precedence for Group-to-RP mappings in the following use cases:

IPマルチキャストを展開し、ネットワークオペレータは、次の使用例では、グループ-RPマッピングの優先順位を選択するために、決定論的な方法が必要になります。

o Default static Group-to-RP mappings with dynamically learned entries

O動的に学習のエントリを持つ静的グループへ-RPマッピングをデフォルト

Many network operators will have a dedicated infrastructure for the standard multicast group range (224/4) and so might be using statically configured Group-to-RP mappings for this range. In this case, to support some specific applications, they might want to learn Group-to-RP mappings dynamically using either the BSR or Auto-RP mechanism. In this case, to select Group-to-RP mappings for these specific applications, a longer prefix match should be given preference over statically configured Group-to-RP mappings. For example, 239.100.0.0/16, an administratively scoped multicast address range, could be learned for a corporate communications application. Network operators may change the Group-to-RP mappings for these applications more often, and the mappings would need to be learned dynamically. This is not an issue for IPv6 Multicast address ranges.

多くのネットワークオペレータは、この範囲のために静的に設定されたグループに-RPマッピングを使用している場合がありますので、標準のマルチキャストグループ範囲（224/4）用の専用インフラを持っているとします。この場合、いくつかの特定のアプリケーションをサポートするために、彼らはBSRまたはAuto-RPメカニズムのいずれかを使用して動的にグループに-RPマッピングを学びたいと思うかもしれません。この場合、これらの特定のアプリケーションのためのグループツーRPマッピングを選択するために、長いプレフィックスマッチが静的に設定されたグループ-RPマッピングよりも優先されなければなりません。たとえば、239.100.0.0/16、管理スコープのマルチキャストアドレスの範囲は、企業の通信アプリケーションのために学習することができます。ネットワークオペレータは、より多くの場合、これらのアプリケーションのグループツーRPのマッピングを変更することができ、およびマッピングが動的に学習する必要があります。これは、IPv6マルチキャストアドレス範囲のための問題ではありません。

o Migration situations

Oの移行状況

Network operators occasionally go through a migration due to an acquisition or a change in their network design. In order to facilitate this migration, there is a need to have a deterministic behavior of Group-to-RP mapping selection for entries learned using the BSR and Auto-RP mechanisms. This will help in avoiding any unforeseen interoperability issues between different vendors' network elements.

ネットワークオペレータは時折による買収やそのネットワークの設計変更への移行を経ます。この移行を容易にするために、エントリはBSRとAuto-RPメカニズムを使用して学んだのグループ-RPマッピングの選択の決定論的振る舞いを持っている必要があります。これは、異なるベンダーのネットワーク要素間の任意の不測の相互運用性の問題を回避するのに役立つだろう。

o Use by management systems

O管理システムで使用してください

A network management station can determine the RP for a specific group in a specific router by running this algorithm on the Group-to-RP mapping table fetched using MIB objects.

ネットワーク管理ステーションは、MIBオブジェクトを使用して、フェッチグループとRPのマッピングテーブルにこのアルゴリズムを実行することによって、特定のルータの特定のグループのためのRPを決定することができます。

6. Proposed Algorithm

6.アルゴリズムを提案しました

The following algorithm deterministically chooses between several Group-to-RP mappings for a specific group. It also addresses the above-mentioned shortcomings in the existing mechanism.

次のアルゴリズムは、決定論的に、特定のグループのために、いくつかのグループに-RPマッピングの間で選択します。また、既存の機構では、上記の欠点に対処します。

1. If the multicast group address being looked up contains an embedded RP, the RP address extracted from the group address is selected as the Group-to-RP mapping.

1.ルックアップされているマルチキャストグループアドレスが埋め込まれたRPが含まれている場合は、グループアドレスから抽出されたRPアドレスは、グループとRPのマッピングとして選択されます。

2. If the multicast group address being looked up is in the Source Specific Multicast (SSM) range or is configured for Dense Mode, no Group-to-RP mapping is selected, and this algorithm terminates. The fact that no Group-to-RP mapping has been selected can be represented in the PIM-STD-MIB module [RFC5060] by setting the address type of the RP to 'unknown', as described in Section 8.

2.検索されるマルチキャストグループアドレスは、ソース固有マルチキャスト（SSM）の範囲にあるか、稠密モード用に設定されている場合は、グループ-RPマッピングが選択されていないが、このアルゴリズムは終了されます。何グループとRPのマッピングが選択されていないという事実は、セクション8に記載されているように、「不明」にRPのアドレスタイプを設定することにより、PIM-STD-MIBモジュール[RFC5060]で表すことができます。

3. From the set of all Group-to-RP mapping entries, the subset whose group prefix contains the multicast group that is being looked up is selected.

すべてのグループ-RPマッピングエントリのセット3.は、そのグループの接頭辞サブセットが選択されて見上げているマルチキャストグループが含まれています。

4. If there are no entries available, then the Group-to-RP mapping is undefined, and this algorithm terminates.

4.使用可能なエントリがない場合は、[グループ-RPマッピングが未定義であり、このアルゴリズムは終了します。

5. A longest prefix match is performed on the subset of Group-to-RP mappings.

5. A最長プレフィックス一致は、グループ-RPマッピングのサブセット上で実行されます。

        *  If there is only one entry available, then that entry is
           selected as the Group-to-RP mapping.

* If there are multiple entries available, the algorithm continues with this smaller set of Group-to-RP mappings.

利用可能な複数のエントリがある場合*、アルゴリズムは、グループ-RPマッピングのこの小さなセットを続行します。

6. From the remaining set of Group-to-RP mappings, we select the subset of entries based on the preference for the PIM modes to which the multicast group addresses are assigned. A Group-to-RP mapping entry with PIM Mode 'BIDIR' will be preferred to an entry with PIM Mode 'PIM-SM'.

グループ-RPマッピングの残りのセット6.、私たちは、マルチキャストグループアドレスが割り当てられているPIMモードの好みに基づいてエントリのサブセットを選択します。 PIMモード「BIDIR」がグループに-RPマッピングエントリPIMモード「PIM-SM」でエントリーすることが好ましいです。

        *  If there is only one entry available, then that entry is
           selected as the Group-to-RP mapping.

* If there are multiple entries available, the algorithm continues with this smaller set of Group-to-RP mappings.

利用可能な複数のエントリがある場合*、アルゴリズムは、グループ-RPマッピングのこの小さなセットを続行します。

7. From the remaining set of Group-to-RP mappings, we select the subset of the entries based on the origin. Group-to-RP mappings learned dynamically are preferred over static mappings. If the remaining dynamic Group-to-RP mappings are from BSR and Auto-RP, then the mappings from BSR are preferred.

グループ-RPマッピングの残りのセットから7、我々は、原点に基づいてエントリのサブセットを選択します。グループツーRPのマッピングを動的に静的マッピングよりも好ましい学びました。残りのダイナミックグループに-RPマッピングがBSRとAuto-RPからある場合、BSRからのマッピングが好ましいです。

        *  If there is only one entry available, then that entry is
           selected as the Group-to-RP mapping.

* If there are multiple entries available, the algorithm continues with this smaller set of Group-to-RP mappings.

利用可能な複数のエントリがある場合*、アルゴリズムは、グループ-RPマッピングのこの小さなセットを続行します。

8. If the remaining Group-to-RP mappings were learned through BSR, then the RP will be selected by comparing the RP Priority values in the Candidate-RP-Advertisement messages. The RP mapping with the lowest value indicates the highest priority [RFC5059].

8.残りのグループに-RPマッピングがBSRによって学習された場合、RPは候補RP-広告メッセージ内のRPの優先順位値を比較することにより選択されます。最小値を持つRPマッピングは最高の優先順位[RFC5059]を示しています。

        *  If more than one RP has the same highest priority (i.e., the
           same lowest value), the algorithm continues with those Group-
           to-RP mappings.

* If the remaining Group-to-RP mappings were NOT learned from BSR, the algorithm continues with the next step.

残りのグループに-RPマッピングはBSRから学んでなかった場合は*、アルゴリズムは次のステップに進みます。

9. If the remaining Group-to-RP mappings were learned through BSR and the PIM Mode of the group is 'PIM-SM', then the hash function as defined in Section 4.7.2 of [RFC4601] will be used to choose the RP. The RP with the highest resulting hash value will be selected. Please see Section 10 for consideration of hash for BIDIR-PIM and BSR.

9.残りのグループに-RPマッピングは、グループのBSRおよびPIMモードを介して学習された場合は、[RFC4601]のセクション4.7.2で定義されている「PIM-SM」の場合、ハッシュ関数で選択するために使用されますRP。最高の結果のハッシュ値を持つRPが選択されます。 BIDIR-PIMおよびBSRのハッシュの検討については、セクション10を参照してください。

        *  If more than one RP has the same highest hash value, the
           algorithm continues with those Group-to-RP mappings.

* If the remaining Group-to-RP mappings were NOT learned from BSR, the algorithm continues with the next step.

残りのグループに-RPマッピングはBSRから学んでなかった場合は*、アルゴリズムは次のステップに進みます。

10. From the remaining set of Group-to-RP mappings, the RP with the highest IP address (numerically greater) will be selected. This will serve as a final tiebreaker.

グループ-RPマッピングの残りのセットから10は、（数値的に大きい）最大のIPアドレスを持つRPが選択されます。これは、最終的なタイブレーカーとして機能します。

7. Interpretation of MIB Objects

MIBオブジェクトの7解釈

As described in [RFC5060], the Group-to-RP mapping information is summarized in the pimGroupMappingTable. The precedence value is stored in the 'pimGroupMappingPrecedence' object, which covers both the dynamically learned Group-to-RP mapping information and the static configuration. For static configurations, the 'pimGroupMappingPrecedence' object uses the value of the 'pimStaticRPPrecedence' object from the pimStaticRPTable.

[RFC5060]に記載されているように、グループ・ツー・RPマッピング情報はpimGroupMappingTableに要約されています。優先順位値は、動的に学習グループへ-RPマッピング情報と静的構成の両方をカバー「pimGroupMappingPrecedence」オブジェクトに格納されています。静的構成では、「pimGroupMappingPrecedence」オブジェクトがpimStaticRPTableから「pimStaticRPPrecedence」オブジェクトの値を使用します。

The algorithm defined in this document does not use the concept of precedence, and therefore the values configured in the 'pimGroupMappingPrecedence' and 'pimStaticRPPrecedence' objects in the PIM-STD-MIB module [RFC5060] are not applicable to the new algorithm. The objects still retain their meaning for 'legacy' implementations, but since the algorithm defined in this document is to be used in preference to those found in PIM-SM [RFC4601] and the PIM-STD-MIB [RFC5060], the values of these objects will be ignored on implementations that support the new algorithm.

この文書で定義されたアルゴリズムは、優先順位の概念を使用しないので、「pimGroupMappingPrecedence」およびPIM-STD-MIBモジュール[RFC5060]の「pimStaticRPPrecedence」オブジェクトに設定された値は、新しいアルゴリズムには適用できません。オブジェクトはまだ「レガシー」実装にその意味を保持するが、本文書で定義されたアルゴリズムは、PIM-SM [RFC4601]とPIM-STD-MIB [RFC5060]の値に見られるものに優先して使用するためこれらのオブジェクトは、新しいアルゴリズムをサポートする実装では無視されます。

8. Clarification for MIB Objects

MIBオブジェクトの8明確化

An implementation of this specification can continue to be managed using the PIM-STD-MIB [RFC5060]. Group-to-RP mapping entries are created in the pimGroupMappingTable for group ranges that are SSM or Dense mode. In these cases, the pimGroupMappingRPAddressType object is set to unknown(0), and the PIM Mode in the pimGroupMappingPimMode object is set to either ssm(2) or dm(5) to reflect the type of the group range.

この仕様の実装は、PIM-STD-MIB [RFC5060]を使用して管理し続けることができます。グループ-RPマッピングエントリはSSMまたは稠密モードあるグループの範囲についてpimGroupMappingTableに作成されます。これらのケースでは、pimGroupMappingRPAddressTypeオブジェクトがpimGroupMappingPimModeオブジェクト内の未知（0）、およびPIMモードは、グループ範囲の種類を反映するようにSSM（2）又はDM（5）のいずれかに設定されているに設定されています。

Also, all the entries that are already included in the SSM Range table in the IP Multicast MIB [RFC5132] are copied to the pimGroupMappingTable. Such entries have their type in the pimGroupMappingOrigin object set to configSsm(3) and the RP address type in the pimGroupMappingRPAddressType object set to unknown(0), as described above.

また、すでにIPマルチキャストMIB [RFC5132]でSSM範囲テーブルに含まれているすべてのエントリがpimGroupMappingTableにコピーされます。上記のようなエントリは、configSsm（3）に設定pimGroupMappingOriginオブジェクトと（0）は、未知に設定pimGroupMappingRPAddressTypeオブジェクト内のRPアドレスタイプでそのタイプを有します。

9. Use of Dynamic Group-to-RP Mapping Protocols

動的グループ・ツー・RPマッピングプロトコルの9.

It is not usually necessary to run several dynamic Group-to-RP mapping mechanisms in one administrative domain. Specifically, interoperation of BSR and Auto-RP is OPTIONAL.

1つの管理ドメインに複数のダイナミックグループ-RPマッピングメカニズムを実行するために通常必要はありません。具体的には、BSRとAuto-RPの相互運用はオプションです。

However, if a router does receive two overlapping sets of Group-to-RP mappings, for example from Auto-RP and BSR, then some algorithm is needed to deterministically resolve the situation. The algorithm in this document MUST be used on all routers in the domain. This can be important at domain border routers, and is likely to avoid conflicts caused by misconfiguration (when routers receive overlapping sets of Group-to-RP mappings) and when configuration is changing.

しかし、ルータが自動RPおよびBSRから例えば、その後、いくつかのアルゴリズムが決定論的状況を解決するために必要とされる、グループ-RPマッピングの2つの重複セットを受信した場合。この文書に記載されているアルゴリズムは、ドメイン内のすべてのルータで使用しなければなりません。これは、ドメイン境界ルータでは重要であり、（ルータはグループ-RPマッピングの重複セットを受信したとき）と、設定が変更されたときの設定ミスによって引き起こされる競合を回避する可能性があることができます。

An implementation of PIM that supports only one mechanism for learning Group-to-RP mappings MUST also use this algorithm. The algorithm has been chosen so that existing standard implementations are already compliant.

グループへの-RPマッピングを学習するための唯一のメカニズムをサポートしていPIMの実装は、このアルゴリズムを使用する必要があります。既存の標準実装がすでに準拠しているように、アルゴリズムが選択されています。

10. Considerations for Bidirectional-PIM and BSR Hash

双方向PIMおよびBSRハッシュ10.考慮事項

BIDIR-PIM [RFC5015] is designed to avoid any data-driven events. This is especially true in the case of a source-only branch. The RP mapping is determined based on a group mask when the mapping is received through a dynamic mapping protocol or statically configured.

BIDIR-PIM [RFC5015]は任意のデータ駆動型のイベントを回避するように設計されています。これはソースのみのブランチの場合には特にそうです。 RPマッピングは、マッピングは動的マッピングプロトコルを介して受信されたか、静的に設定されているグループマスクに基づいて決定されます。

Therefore, based on the algorithm defined in this document, the hash in BSR is ignored for PIM-BIDIR RP mappings. It is RECOMMENDED that network operators configure only one PIM-BIDIR RP for each RP Priority.

そのため、この文書で定義されたアルゴリズムに基づいて、BSR内のハッシュは、PIM-BIDIR RPのマッピングでは無視されます。ネットワークオペレータが各RPの優先順位のための唯一のPIM-BIDIR RPを設定することをお勧めします。

11. Filtering Group-to-RP Mappings at Domain Boundaries

ドメイン境界で11フィルタリンググループツーRPのマッピング

An implementation of PIM SHOULD support configuration to filter specific dynamic mechanisms for a valid group prefix range. For example, it should be possible to allow an administratively scoped address range, such as 239/8, for the Auto-RP protocol, but to filter out the BSR advertisement for the same range. Similarly, it should be possible to filter out all Group-to-RP mappings learned from BSR or the Auto-RP protocol.

PIMの実装では、有効なグループプレフィックス範囲の特定の動的メカニズムをフィルタリングする構成をサポートしなければなりません。例えば、自動RPプロトコルに対して、例えば8分の239として、管理スコープアドレス範囲を可能にすることが可能であるべきであるが、同じ範囲に対してBSR広告をフィルタリングします。同様に、BSRまたはAuto-RPプロトコルから学んだすべてのグループツーRPのマッピングをフィルタリングすることが可能です。

12. Security Considerations

12.セキュリティの考慮事項

This document enhances an existing algorithm to deterministically choose between several Group-to-RP mappings for a specific group. Different routers may select a different Group-to-RP mapping for the same group if the Group-to-RP mappings learned in these routers are not consistent. For example, let us assume that BSR is not enabled in one of the routers, and so it does not learn any Group-to-RP mappings from BSR. Now the Group-to-RP mappings learned in this router may not be consistent with other routers in the network; it may select a different RP or may not select any RP for a given group. Such situations can be avoided if the mechanisms used to learn Group-to-RP mappings are secure and consistent across the network. Secure transport of the mapping protocols can be accomplished by using authentication with IPsec, as described in Section 6.3 of [RFC4601].

この文書では、決定論的に、特定のグループのために、いくつかのグループに-RPマッピングの間で選択するために、既存のアルゴリズムを強化します。これらのルータで学んだグループに-RPマッピングが一致していない場合は、別のルータは、同じグループの別のグループに-RPマッピングを選択することができます。たとえば、私たちはBSRは、ルータの1つで有効になっていない、ので、それはBSRから任意のグループに-RPマッピングを学習しないと仮定しましょう。今、このルータで学んだグループツーRPのマッピングは、ネットワーク内の他のルータと一致しない場合があります。それは別のRPを選択したり、特定のグループのいずれかのRPを選択しない場合があります。グループへの-RPマッピングを学ぶために使用されるメカニズムは、安全かつネットワーク全体で一貫している場合には、このような事態を回避することができます。 [RFC4601]のセクション6.3で説明したように、マッピング・プロトコルの安全な輸送は、IPsecで認証を使用することによって達成することができます。

13. Acknowledgements

13.謝辞

This document is created based on discussion that occurred during work on the PIM-STD-MIB [RFC5060]. Many thanks to Stig Venaas, Yiqun Cai, and Toerless Eckert for providing useful comments.

この文書は、PIM-STD-MIB [RFC5060]での作業中に発生した議論に基づいて作成されます。有益なコメントを提供するためのスティグVenaas、Yiqunカイ、およびToerlessエッカートに感謝します。

14. Normative References

14.引用規格

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004.

[RFC3956] Savola、P.とB.ハーバーマン、 "IPv6マルチキャストアドレスでのランデブーポイント（RP）アドレスを埋め込み"、RFC 3956、2004年11月。

[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.

[RFC4601]フェナー、B.、ハンドリー、M.、ホルブルック、H.、およびI. Kouvelas、 "プロトコル独立マルチキャスト - スパースモード（PIM-SM）：プロトコル仕様（改訂）"、RFC 4601、2006年8月。

[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007.

[RFC5015]ハンドレー、M.、Kouvelas、I.、スピークマン、T.、およびL. Vicisano、 "双方向プロトコル独立マルチキャスト（BIDIR-PIM）"、RFC 5015、2007年10月。

[RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)", RFC 5059, January 2008.

[RFC5059] Bhaskar、N.、ガル、A.、リンガード、J.、およびS. Venaas、 "プロトコル独立マルチキャスト（PIM）のためのブートストラップルータ（BSR）メカニズム"、RFC 5059、2008年1月。

[RFC5060] Sivaramu, R., Lingard, J., McWalter, D., Joshi, B., and A. Kessler, "Protocol Independent Multicast MIB", RFC 5060, January 2008.

[RFC5060] Sivaramu、R.、リンガード、J.、McWalter、D.、女子、B.、およびA.ケスラー、 "プロトコル独立マルチキャストMIB"、RFC 5060、2008年1月。

[RFC5132] McWalter, D., Thaler, D., and A. Kessler, "IP Multicast MIB", RFC 5132, December 2007.

[RFC5132] McWalter、D.、ターラー、D.、およびA.ケスラー、 "IPマルチキャストMIB"、RFC 5132、2007年12月。

Authors' Addresses

著者のアドレス

Bharat Joshi Infosys Technologies Ltd. 44 Electronics City, Hosur Road Bangalore 560 100 India

バーラト女子インフォシス・テクノロジーズ株式会社44エレクトロニクスシティ、ホスールロードバンガロール560 100インド

EMail: bharat_joshi@infosys.com URI: http://www.infosys.com/

電子メール：bharat_joshi@infosys.com URI：http://www.infosys.com/

Andy Kessler Cisco Systems, Inc. 425 E. Tasman Drive San Jose, CA 95134 USA

アンディ・ケスラーシスコシステムズ社425 E.タスマン・ドライブサンノゼ、CA 95134 USA

EMail: kessler@cisco.com URI: http://www.cisco.com/

電子メール：kessler@cisco.com URI：http://www.cisco.com/

David McWalter

デビッドMcWalter

EMail: david@mcwalter.eu

メールアドレス：david@mcwalter.eu