[要約] RFC 5186は、IGMPv3/MLDv2とマルチキャストルーティングプロトコルの相互作用に関する情報を提供します。このRFCの目的は、マルチキャスト通信におけるグループ管理とルーティングの効果的な統合を促進することです。
Network Working Group B. Haberman
Request for Comments: 5186 Johns Hopkins University
Category: Informational J. Martin
Woven Systems
May 2008
Internet Group Management Protocol Version 3 (IGMPv3) / Multicast Listener Discovery Version 2 (MLDv2) and Multicast Routing Protocol Interaction
インターネットグループ管理プロトコルバージョン3（IGMPV3） /マルチキャストリスナーディスカバリーバージョン2（MLDV2）およびマルチキャストルーティングプロトコルインタラクション
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
概要
The definitions of the Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) require new behavior within the multicast routing protocols. The additional source information contained in IGMPv3 and MLDv2 messages necessitates that multicast routing protocols manage and utilize the information. This document describes how multicast routing protocols will interact with these source-filtering group management protocols.
インターネットグループ管理プロトコルバージョン3（IGMPV3）およびマルチキャストリスナーディスカバリーバージョン2（MLDV2）の定義には、マルチキャストルーティングプロトコル内の新しい動作が必要です。IGMPV3およびMLDV2メッセージに含まれる追加のソース情報は、マルチキャストルーティングプロトコルが情報を管理および利用する必要があります。このドキュメントでは、マルチキャストルーティングプロトコルがこれらのソースフィルタリンググループ管理プロトコルとどのように相互作用するかについて説明します。
The definitions of IGMPv3 [IGMP3] and MLDv2 [MLDv2] require new behavior within the multicast routing protocols. The additional source information contained in IGMPv3 and MLDv2 messages necessitates that multicast routing protocols manage and utilize the information. This document will describe how multicast routing protocols will interpret information learned from these source-filtering group management protocols.
IGMPV3 [IgMP3]およびMLDV2 [MLDV2]の定義には、マルチキャストルーティングプロトコル内の新しい動作が必要です。IGMPV3およびMLDV2メッセージに含まれる追加のソース情報は、マルチキャストルーティングプロトコルが情報を管理および利用する必要があります。このドキュメントでは、マルチキャストルーティングプロトコルが、これらのソースフィルタリンググループ管理プロトコルから学んだ情報をどのように解釈するかについて説明します。
Existing multicast routing protocols utilize the group management database in determining if local members exist for a particular multicast group. With previous group management protocols, this database had one type of record indicating the group for which there was interest and the associated local interfaces.
既存のマルチキャストルーティングプロトコルは、特定のマルチキャストグループにローカルメンバーが存在するかどうかを判断するために、グループ管理データベースを利用しています。以前のグループ管理プロトコルでは、このデータベースには、関心があるグループと関連するローカルインターフェイスを示す1つのタイプのレコードがありました。
In the case of IGMPv3 and MLDv2, these routing protocols may now build multicast forwarding state based on the source filter information available for each multicast group that has local membership. This requires that the group management database have four record types. Only one record may exist for a given interface and a given multicast group.
IGMPV3およびMLDV2の場合、これらのルーティングプロトコルは、ローカルメンバーシップを持つ各マルチキャストグループが利用できるソースフィルター情報に基づいて、マルチキャスト転送状態を構築することができます。これには、グループ管理データベースに4つのレコードタイプがあることが必要です。特定のインターフェイスと特定のマルチキャストグループには1つのレコードのみが存在する可能性があります。
1. EXCLUDE <> The EXCLUDE <> record indicates interest in all sources destined to this group address for a set of local interfaces. It is equivalent to the single record type existing in previous versions of the group management protocols.
1. 除外<>除外<>レコードは、ローカルインターフェイスのセットのこのグループアドレスに導かれるすべてのソースへの関心を示します。これは、グループ管理プロトコルの以前のバージョンに存在する単一のレコードタイプに相当します。
2. INCLUDE <> The INCLUDE <> record indicates that there is no interest in any sources destined to this group address for a set of local interfaces.
2. include <> include <>レコードは、ローカルインターフェイスのセットのこのグループアドレスに向けられたソースに関心がないことを示します。
3. EXCLUDE <list> The EXCLUDE <list> record indicates that there is interest in all sources other than the specifically listed sources for a set of local interfaces.
3. exclude <list> exclude <list>レコードは、ローカルインターフェイスのセットに具体的にリストされているソース以外のすべてのソースに関心があることを示しています。
4. INCLUDE <list> The INCLUDE <list> record indicates that there is interest in only the specifically listed sources for a set of local interfaces.
4. include <list> include <list>レコードは、一連のローカルインターフェイスの特別にリストされているソースのみに関心があることを示します。
The records in the group management database should be utilized when generating forwarding state for a multicast group. If the source address in the multicast packet exists in the database for the specified multicast group and is in an INCLUDE list or is not listed in an EXCLUDE list, the multicast routing protocol should add the interface to the list of downstream interfaces; otherwise, it should not be added based on local group membership.
グループ管理データベースのレコードは、マルチキャストグループの転送状態を生成するときに使用する必要があります。マルチキャストパケットのソースアドレスが、指定されたマルチキャストグループのデータベースに存在し、インクルードリストにある場合、または除外リストにリストされていない場合、マルチキャストルーティングプロトコルはインターフェイスをダウンストリームインターフェイスのリストに追加する必要があります。それ以外の場合は、ローカルグループのメンバーシップに基づいて追加しないでください。
The Distance Vector Multicast Routing Protocol (DVMRP) [DVMRP] does not incorporate any knowledge of the multicast group's senders. Therefore, DVMRP will act only on the multicast group address contained in an IGMPv3 or MLDv2 report.
距離ベクトルマルチキャストルーティングプロトコル（DVMRP）[DVMRP]には、マルチキャストグループの送信者に関する知識は組み込まれていません。したがって、DVMRPは、IGMPV3またはMLDV2レポートに含まれるマルチキャストグループアドレスにのみ機能します。
Future standardized versions of DVMRP may incorporate pruning and grafting messages similar to PIM-DM (discussed in Section 5). The rules defined in Section 5 can be applied in this situation.
DVMRPの将来の標準化されたバージョンには、PIM-DMと同様の剪定メッセージと接ぎ木メッセージが組み込まれる場合があります（セクション5で説明）。セクション5で定義されているルールは、この状況で適用できます。
In Multicast Extensions to OSPF (MOSPF) [MOSPF], the consideration of source filter information in the group management database is limited to the building of forwarding state (discussed above). This is due to the flooding of group-membership-LSAs within MOSPF.
OSPF（MOSPF）[MOSPF]へのマルチキャスト拡張では、グループ管理データベースでのソースフィルター情報の考慮事項は、転送状態の構築に限定されています（上記）。これは、MOSPF内のグループメンバーシップLSAの洪水によるものです。
The PIM-DM protocol [PIMDM] interaction with a source-filtering group management protocol is important in two areas: multicast distribution tree pruning and multicast distribution tree grafting. The following sections will describe the behavior needed in PIM-DM to interoperate with IGMPv3 and MLDv2.
PIM-DMプロトコル[PIMDM]ソースフィルタリンググループ管理プロトコルとの相互作用は、マルチキャスト分布ツリープルーニングとマルチキャスト分布ツリー移植の2つの領域で重要です。次のセクションでは、IgMPv3およびMLDV2と相互操作するためにPIM-DMで必要な動作について説明します。
PIM-DM prune messages are initiated when a PIM-DM router determines that there are no entities interested in the data flowing on the (S,G) forwarding state. If the multicast router is running IGMPv3 or MLDv2, this is determined by the source S being in EXCLUDE state in the source filter for the destination G, or all interest in G being terminated for an existing (S,G) forwarding entry.
PIM-DMプルーンメッセージは、PIM-DMルーターが（s、g）転送状態に流れるデータに関心のあるエンティティがないと判断したときに開始されます。マルチキャストルーターがIGMPV3またはMLDV2を実行している場合、これは宛先Gのソースフィルターの除外状態になっているソースSまたは既存の（S、G）転送エントリに対してGのすべての関心によって決定されます。
PIM-DM graft messages are sent in order to override an existing PIM-DM prune. In the case of IGMPv3 or MLDv2, this occurs when prune state exists for (S,G) and a state change occurs in which the source filter state for S changes to INCLUDE for the specified G.
既存のPIM-DMプルーンをオーバーライドするために、PIM-DMグラフトメッセージが送信されます。Igmpv3またはMLDV2の場合、これはプルーン状態が（s、g）に対して存在するときに発生し、sの変化が指定されたGに含まれるSOURCEフィルター状態が発生する場合に発生します。
A PIM-SM interaction takes place when a PM-SM [PIMSM] router receives an IGMP or MLD message regarding a group address that is in the Any Source Multicast (ASM) range. This range is defined as the entire multicast address space excluding the global SSM range [SSM] and any locally defined Source Specific space.
PM-SM [PIMSM]ルーターが、任意のソースマルチキャスト（ASM）範囲にあるグループアドレスに関するIGMPまたはMLDメッセージをPM-SM [PIMSM]ルーターが受信すると、PIM-SM相互作用が行われます。この範囲は、グローバルSSM範囲[SSM]およびローカルに定義されたソース固有のスペースを除くマルチキャストアドレス空間全体として定義されます。
PIM-SM join messages are initiated when a PIM-SM router determines that there are entities interested in a specific group or a specific source sending to the group. If this is due to an IGMPv3 or MLDv2 report with a zero-length EXCLUDE list, then the join is sent as a (*,G) join towards the RP.
PIM-SM結合メッセージは、PIM-SMルーターが特定のグループまたはグループに送信する特定のソースに関心のあるエンティティがあると判断したときに開始されます。これがゼロ長除外リストを備えたIGMPV3またはMLDV2レポートが原因である場合、結合はRPに向かって（*、g）結合として送信されます。
If the join is triggered by an IGMPv3 or MLDv2 state change that affects source information, the PIM-SM join is sent as a (S,G) join towards the specific source. This behavior optimizes the join process, as well as facilitates the adoption of the SSM model. The generation of this (S,G) join can cause failures in architectures where leaf routers do not have global reachability, and thus, can be overridden by local policy. If this is the case, then all triggered joins are sent towards the RP as (*,G) joins. The router sending the (*,G) join is responsible for filtering the data as per the IGMPv3 database before forwarding.
ソース情報に影響を与えるIGMPV3またはMLDV2状態の変更によって結合がトリガーされると、PIM-SM結合は特定のソースに向かって（s、g）結合として送信されます。この動作は、結合プロセスを最適化し、SSMモデルの採用を促進します。この（s、g）結合の生成は、葉のルーターがグローバルな到達可能性を持たないため、ローカルポリシーによって無効になるアーキテクチャに障害を引き起こす可能性があります。この場合、すべてのトリガーされた結合は、（*、g）結合としてRPに送られます。（*、g）結合を送信するルーターは、転送前にIGMPV3データベースに従ってデータをフィルタリングする責任があります。
PIM-SM prune messages are initiated when a PIM-SM router determines that there are no entities interested in a specific group, or a specific source sending to the group. If this is triggered by either receiving a report with an EXCLUDE or if a specific Source/Group times out, then an (S,G) prune is sent towards the upstream router. If all of the IGMPv3 or MLDv2 derived requests for a group time out, then (S,G) and (*,G) prunes are sent upstream as needed to stop all flow of traffic for that group.
PIM-SMプルーンメッセージは、PIM-SMルーターが特定のグループに関心のあるエンティティ、またはグループに送信する特定のソースがないと判断したときに開始されます。これが除外されたレポートを受信するか、特定のソース/グループがタイムアウトする場合にトリガーされる場合、（s、g）プルーンがアップストリームルーターに送られます。IGMPV3またはMLDV2のすべてのリクエストがグループタイムアウトのリクエストを導き出した場合、（s、g）および（*、g）プルーンが必要に応じて上流に送信され、そのグループのすべてのトラフィックの流れを止めます。
A PIM-SSM interaction takes place when a PIM-SM router receives an IGMPv3 or MLDv2 message regarding a group address that is in the Source Specific Multicast range. This behavior is not defined in this document, but rather in [PIMSM].
PIM-SSMの相互作用は、PIM-SMルーターがソース固有のマルチキャスト範囲にあるグループアドレスに関するIGMPV3またはMLDV2メッセージを受信するときに行われます。この動作は、このドキュメントではなく、[PIMSM]で定義されています。
This document does not introduce any additional security issues above and beyond those already discussed in [PIMDM], [PIMSM], [IGMP3], and [MLDv2].
このドキュメントでは、[PIMDM]、[PIMSM]、[IGMP3]、および[MLDV2]で既に議論されているものを超えて追加のセキュリティ問題を紹介しません。
The authors would like to thank Murali Brahmadesam, Leonard Giuliano, and Hal Sandick for their feedback and suggestions.
著者は、フィードバックと提案をしてくれたMurali Brahmadesam、Leonard Giuliano、およびHal Sandickに感謝したいと思います。
[IGMP3] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[Igmp3] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、B。、およびA. Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC 3376、2002年10月。
[MLDv2] Vida, R., Ed., and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[MLDV2] Vida、R.、ed。、およびL. Costa、ed。、「IPv6のマルチキャストリスナーディスカバリーバージョン2（MLDV2）」、RFC 3810、2004年6月。
[DVMRP] Waitzman, D., Partridge, C., and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988.
[DVMRP] Waitzman、D.、Partridge、C。、およびS. Deering、「距離ベクトルマルチキャストルーティングプロトコル」、RFC 1075、1988年11月。
[MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994.
[Mospf] Moy、J。、「OSPFへのマルチキャスト拡張」、RFC 1584、1994年3月。
[PIMDM] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005.
[Pimdm] Adams、A.、Nicholas、J.、およびW. Siadak、「プロトコル独立マルチキャスト - 密度モード（PIM -DM）：プロトコル仕様（改訂）」、RFC 3973、2005年1月。
[PIMSM] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[PIMSM] Fenner、B.、Handley、M.、Holbrook、H。、およびI. Kouvelas、 "Protocol Independent Multicast -Sparse Mode（PIM -SM）：プロトコル仕様（改訂）、RFC 4601、2006年8月。
[SSM] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[SSM] Holbrook、H。およびB. Cain、「IPのソース固有のマルチキャスト」、RFC 4607、2006年8月。
Authors' Addresses
著者のアドレス
Brian Haberman The Johns Hopkins University Applied Physics Laboratory 11100 Johns Hopkins Road Laurel, MD 20723-6099 US
ブライアンハーバーマンジョンズホプキンス大学応用物理学研究所11100ジョンズホプキンスロードローレル、メリーランド20723-6099 US
Phone: +1 443 778 1319
EMail: brian@innovationslab.net
Jim Martin Woven Systems 2455 Augustine Drive, Suite 211 Santa Clara, CA 95054 US
Jim Martin Woven Systems 2455 Augustine Drive、Suite 211 Santa Clara、CA 95054 US
Phone: +1 408 654-8143
EMail: jim@wovensystems.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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への情報をお問い合わせください。