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

原文URL : https://datatracker.ietf.org/doc/html/rfc6226
タイトル : RFC 6226 - PIMグループからレンダブスポイントマッピング
翻訳編集 : 自動生成

[要約] RFC 6226は、PIMグループとランデブーポイントのマッピングに関するプロトコル仕様です。その目的は、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

PIMグループからレンダブスポイントマッピング

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.

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

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.

このドキュメントは、特定のグループのいくつかのグループ間マッピングを決定的に選択する標準アルゴリズムを定義します。このドキュメントでは、最初にグループ間マッピングアルゴリズムを拡張するための要件を説明し、新しいアルゴリズムを提案します。

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.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6226で取得できます。

著作権表示

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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.

グループ間マッピングを作成および配布するために、複数のメカニズムが現在存在しています。各PIM-SMルーターは、セクション4で説明されているように、さまざまなメカニズムを通じてグループ間マッピングを学習できます。

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」を選択することが重要です。それ以外の場合、完全なマルチキャスト接続は確立されません。これは、Anycast RPを使用して冗長性を提供する場合でも当てはまります。このRPアドレスは、異なる物理ルーターに対応する場合がありますが、1つの論理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」に保存されるグループ間マッピングの優先順位を設定できるようにする多くのオブジェクトが含まれています。管理情報ベース（MIB）モジュールは、グループ間マッピングを決定するために「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」のグループ間マッピングのリストにアルゴリズムを適用することにより、どのRPSが選択されるかを推測できます。このアルゴリズムは、Routerがグループ間マッピングを適用する方法のMIBの可視性を提供し、さまざまなベンダーがグループツーRPマッピングの選択を実装してマルチキャスト転送状態を作成する方法によって導入された矛盾を修正します。

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".

「IPv6マルチキャストアドレスにランデブーポイント（RP）アドレスを埋め込む」[RFC3956]のセクション7.1で定義されているように、埋め込みRP [RFC3956]は、「ループと矛盾を回避するために、FF70 ::/12のアドレスについて」、埋め込まれた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

o PIMモード

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 動的なグループ間マッピングメカニズム

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によって学習されたグループ間マッピングは、埋め込まれたグループ間マッピングと呼ばれます。

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.

フィルタリングは、グループアドレス、グループ間マッピングメッセージのタイプ、およびマッピングメッセージが受信されたインターフェイスに基づいて、動的なグループ間マッピング情報の選択的廃棄です。

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.

このドキュメントで使用されている「マルチキャストドメイン」という用語は、グループ間マッピングの一貫したセットを持つネットワークトポロジを指します。2つ以上のマルチキャストドメイン間のインターフェイスは、マルチキャストドメイン境界です。マルチキャストの境界は通常、動的マッピングメッセージをフィルタリングしたり、異なる静的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 グループ間マッピングの起源を考慮していないため、それらすべてを均等に扱います。

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）。新しいアルゴリズムは後方互換性があり、グループ間マッピングが単一のマッピングソースから学習された場合にのみ、同じ結果が生成されます。新しいアルゴリズムの完全な利点は、広く展開されるまで実現されません。

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 グループ間マッピングは、さまざまなメカニズムから学ぶことができます。次のリストは、これらのメカニズムの好みを減らすことによって順序付けられると想定しています。

* 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 埋め込まれたグループ間マッピングは特別であり、常に最優先事項があります。静的構成や動的なグループ間マッピングではオーバーライドすることはできません。

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構成をオーバーライドします。ただし、フィルタリングするか、最も長いプレフィックスマッチングが適用されたときに動的マッピングをオーバーライドする長い静的グループアドレスを構成することにより、静的構成で動的なグループ間マッピングをオーバーライドすることができます。

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].

o [RFC5059]のセクション3.3で規定されているPIM-SMモードで学習したエントリよりも、PIM-ビディールモードで学習したグループ間マッピングが優先されます。

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

o 動的なグループ間マッピングメカニズムは、ドメイン境界またはドメイン内のポリシー施行のためにフィルタリングされます。

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マルチキャストを展開するネットワークオペレーターは、次のユースケースでグループ間マッピングの優先順位を選択するための決定論的な方法が必要です。

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

o 動的に学習したエントリを備えたデフォルトの静的グループ間マッピング

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.

多くのネットワークオペレーターは、標準のマルチキャストグループ範囲（224/4）に専用のインフラストラクチャを持つため、この範囲に静的に構成されたグループ間マッピングを使用している可能性があります。この場合、いくつかの特定のアプリケーションをサポートするために、BSRまたはAuto-RPメカニズムのいずれかを使用して、グループ間マッピングを動的に学習したい場合があります。この場合、これらの特定のアプリケーションのグループ間マッピングを選択するには、静的に構成されたグループ間マッピングよりも長いプレフィックスマッチを優先する必要があります。たとえば、管理上のスコープマルチキャストアドレス範囲である239.100.0.0/16は、企業通信アプリケーションのために学習できます。ネットワークオペレーターは、これらのアプリケーションのグループ間マッピングをより頻繁に変更する場合があり、マッピングを動的に学習する必要があります。これは、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メカニズムを使用して学習したエントリのグループ間マッピング選択の決定論的な動作をする必要があります。これは、さまざまなベンダーのネットワーク要素間の予期せぬ相互運用性の問題を回避するのに役立ちます。

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を決定できます。

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.

次のアルゴリズムは、特定のグループのいくつかのグループ間マッピングの間で決定的に選択します。また、既存のメカニズムにおける上記の欠点にも対処します。

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アドレスがグループ間マッピングとして選択されます。

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）範囲にある場合、または密なモード用に構成されている場合、グループ間マッピングは選択されておらず、このアルゴリズムは終了します。セクション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.

3. すべてのグループ間マッピングエントリのセットから、グループプレフィックスが検索されているマルチキャストグループが含まれているサブセットが選択されています。

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

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

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

5. グループ間マッピングのサブセットで、最長のプレフィックスマッチが実行されます。

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

* 利用可能なエントリが1つしかない場合、そのエントリはグループ間マッピングとして選択されます。

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

* 複数のエントリがある場合、アルゴリズムはこの小さなグループ間マッピングのセットで続きます。

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'.

6. グループ間マッピングの残りのセットから、マルチキャストグループアドレスが割り当てられるPIMモードの好みに基づいて、エントリのサブセットを選択します。PIMモード「Bidir」を使用したグループ間マッピングエントリは、PIMモード「PIM-SM」を使用したエントリよりも優先されます。

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

* 利用可能なエントリが1つしかない場合、そのエントリはグループ間マッピングとして選択されます。

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

* 複数のエントリがある場合、アルゴリズムはこの小さなグループ間マッピングのセットで続きます。

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.

7. グループ間マッピングの残りのセットから、原点に基づいてエントリのサブセットを選択します。Group-to-RPマッピングは、静的マッピングよりも動的に学習されます。残りの動的グループからRPへのマッピングがBSRおよびAuto-RPからのものである場合、BSRからのマッピングが推奨されます。

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

* 利用可能なエントリが1つしかない場合、そのエントリはグループ間マッピングとして選択されます。

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

* 複数のエントリがある場合、アルゴリズムはこの小さなグループ間マッピングのセットで続きます。

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.

* 複数のRPが同じ優先度（つまり、最も低い値）を持っている場合、アルゴリズムはそれらのグループ間マッピングで継続します。

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

* 残りのグループ間マッピングが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. 残りのグループ間マッピングがBSRを介して学習され、グループのPIMモードが「PIM-SM」である場合、[RFC4601]のセクション4.7.2で定義されているハッシュ関数を使用して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.

* 複数のRPが最も高いハッシュ値を持っている場合、アルゴリズムはそれらのグループ間マッピングで継続します。

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

* 残りのグループ間マッピングが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.

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

7. Interpretation of MIB Objects

7. MIBオブジェクトの解釈

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]で説明されているように、グループ間マッピング情報はPimgroupMappingTableに要約されています。優先値は、動的に学習されたグループ間マッピング情報と静的構成の両方をカバーする「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.

このドキュメントで定義されているアルゴリズムは、優先順位の概念を使用せず、したがって、PIMSTD-MIBモジュール[RFC5060]の「PimgroupMappingPrecedence」および「PimstaticRpprecedence」オブジェクトで構成された値は、新しいアルゴリズムに適用されます。オブジェクトは依然として「レガシー」の実装に対する意味を保持していますが、このドキュメントで定義されているアルゴリズムは、PIM-SM [RFC4601]およびPIM-STD-MIB [RFC5060]、PIM-STD-MIB [RFC5060]に見られるものよりも優先されているため、これらのオブジェクトは、新しいアルゴリズムをサポートする実装では無視されます。

8. Clarification for MIB Objects

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

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]を使用して引き続き管理できます。グループ間マッピングエントリは、SSMまたは高密度モードのグループ範囲のPimgroupMappingTableで作成されます。これらの場合、PimgroupMappingRpaddressTypeオブジェクトは不明（0）に設定され、PimgroupMappingPimmodeオブジェクトの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）に設定され、pimgroupmappingrpaddresstypeオブジェクトに設定されたpimgroupmappingrpaddresstypeオブジェクトに設定されたpimgroupmappingoriginオブジェクトにタイプを持っています（0）。

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

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つの管理ドメインでいくつかの動的なグループ間マッピングメカニズムを実行する必要はありません。具体的には、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.

ただし、ルーターがAuto-RPやBSRなどのグループ間マッピングの2つのオーバーラップセットを受け取っている場合、状況を決定的に解決するためにいくつかのアルゴリズムが必要です。このドキュメントのアルゴリズムは、ドメイン内のすべてのルーターで使用する必要があります。これは、ドメインボーダールーターで重要である可能性があり、誤った構成によって引き起こされる競合を回避する可能性があります（ルーターがグループ間マッピングの重複セットを受け取る場合）、および構成が変更されている場合。

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.

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

10. Considerations for Bidirectional-PIM and BSR Hash

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

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の優先度ごとに1つのPIM-Bidir RPのみを構成することをお勧めします。

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

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

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の実装は、有効なグループプレフィックス範囲の特定の動的メカニズムをフィルタリングする構成をサポートする必要があります。たとえば、Auto-RPプロトコルの場合は239/8などの管理上スコープアドレス範囲を許可しますが、同じ範囲でBSR広告を除外することができるはずです。同様に、BSRまたはAuto-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].

このドキュメントは、特定のグループのいくつかのグループ間マッピングを決定的に選択するために、既存のアルゴリズムを強化します。これらのルーターで学習したグループ間マッピングが一貫していない場合、異なるルーターは同じグループに対して異なるグループ間マッピングを選択する場合があります。たとえば、BSRがルーターの1つで有効になっていないため、BSRからグループ間マッピングを学習しないと仮定しましょう。これで、このルーターで学習したグループ間マッピングは、ネットワーク内の他のルーターと一致していない可能性があります。別の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]の作業中に発生した議論に基づいて作成されます。便利なコメントを提供してくれたStig Venaas、Yiqun Cai、およびToerless Eckertに感謝します。

14. Normative References

14. 引用文献

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

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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. Haberman、「IPv6マルチキャストアドレスにRendezvous Point（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] Fenner、B.、Handley、M.、Holbrook、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] Handley、M.、Kouvelas、I.、Speakman、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.、Gall、A.、Lingard、J。、およびS. Venaas、「ブートストラップルーター（BSR）プロトコル独立マルチキャスト（PIM）のメカニズム」、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.、Lingard、J.、McWalter、D.、Joshi、B。、およびA. Kessler、「Protocol Independent Multicast MIB」、RFC 5060、2008年1月。

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

[RFC5132] McWalter、D.、Thaler、D。、およびA. Kessler、「IP Multicast MIB」、RFC 5132、2007年12月。

Authors' Addresses

著者のアドレス

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

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

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

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

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

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

David McWalter

デビッド・マクワルター

   EMail: david@mcwalter.eu