[要約] RFC 5790は、IGMPv3とMLDv2プロトコルの軽量なバージョンを提供し、マルチキャストグループの管理と通信を向上させることを目的としています。
Internet Engineering Task Force (IETF) H. Liu
Request for Comments: 5790 W. Cao
Category: Standards Track Huawei Technologies
ISSN: 2070-1721 H. Asaeda
Keio University
February 2010
Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols
軽量インターネットグループ管理プロトコルバージョン3（IGMPV3）およびマルチキャストリスナーディスカバリーバージョン2（MLDV2）プロトコル
Abstract
概要
This document describes lightweight IGMPv3 and MLDv2 protocols (LW-IGMPv3 and LW-MLDv2), which simplify the standard (full) versions of IGMPv3 and MLDv2. The interoperability with the full versions and the previous versions of IGMP and MLD is also taken into account.
このドキュメントは、IGMPV3およびMLDV2の標準（フル）バージョンを簡素化する軽量IgMPV3およびMLDV2プロトコル（LW-IGMPV3およびLW-MLDV2）について説明します。完全なバージョンとIGMPおよびMLDの以前のバージョンとの相互運用性も考慮されています。
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/rfc5790.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5790で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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ライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Simplification Method Overview ..................................4
3.1. Behavior of Group Members ..................................5
3.2. Behavior of Multicast Routers ..............................5
4. LW-IGMPv3 Protocol for Group Members ............................6
4.1. Query and Report Messages ..................................6
4.2. Action on Change of Interface State ........................6
4.3. Action on Reception of a Query .............................7
4.4. LW-IGMPv3 Group Record Types ...............................7
5. LW-IGMPv3 Protocol for Multicast Routers ........................9
5.1. Group Timers and Source Timers in the Lightweight Version ..9
5.2. Source-Specific Forwarding Rules ..........................10
5.3. Reception of Current-State Records ........................10
5.4. Reception of Source-List-Change and
Filter-Mode-Change Records ................................12
6. Interoperability ...............................................13
6.1. Interoperation with the Full Version of IGMPv3/MLDv2 ......13
6.1.1. Behavior of Group Members ..........................13
6.1.2. Behavior of Multicast Routers ......................13
6.2. Interoperation with IGMPv1/IGMPv2 .........................14
6.2.1. Behavior of Group Members ..........................14
6.2.2. Behavior of Multicast Routers ......................14
6.3. Interoperation with MLDv1 .................................15
7. Implementation Considerations ..................................15
7.1. Implementation of Source-Specific Multicast ...............15
7.2. Implementation of Multicast Source Filter (MSF) APIs ......16
8. Security Considerations ........................................16
9. Acknowledgements ...............................................16
10. References ....................................................16
10.1. Normative References .....................................16
10.2. Informative References ...................................17
IGMP version 3 [2] and MLD version 2 [3] implement source filtering capabilities that are not supported by their earlier versions, IGMPv1 [4], IGMPv2 [5], and MLDv1 [6]. An IGMPv3- or MLDv2-capable host can tell its upstream router which group it would like to join by specifying which sources it does or does not intend to receive multicast traffic from. IGMPv3 and MLDv2 add the capability for a multicast router to learn sources that are of interest or that are not of interest for a particular multicast address. This information is used during forwarding of multicast data packets.
IGMPバージョン3 [2]およびMLDバージョン2 [3]は、以前のバージョンであるIGMPV1 [4]、IGMPV2 [5]、およびMLDV1 [6]でサポートされていないソースフィルタリング機能を実装しています。IGMPV3またはMLDV2対応のホストは、マルチキャストトラフィックを受信するかどうかを指定することにより、上流のルーターにどのグループを結合したいかを伝えることができます。IGMPV3とMLDV2は、マルチキャストルーターの機能を追加して、特定のマルチキャストアドレスに興味のあるソースや関心がないソースを学習します。この情報は、マルチキャストデータパケットの転送中に使用されます。
INCLUDE and EXCLUDE filter-modes are introduced to support the source filtering function. If a host wants to receive from specific sources, it sends an IGMPv3 or MLDv2 report with filter-mode set to INCLUDE. If the host does not want to receive from some sources, it sends a report with filter-mode set to EXCLUDE. A source-list for the given sources shall be included in the Report message.
Sourceフィルタリング機能をサポートするために、フィルターモードを含めると除外されます。ホストが特定のソースから受信したい場合、IGMPV3またはMLDV2レポートをフィルターモードを含めるように設定して送信します。ホストが一部のソースから受け取りたくない場合、除外するフィルターモードセットを備えたレポートを送信します。指定されたソースのソースリストをレポートメッセージに含めるものとします。
INCLUDE and EXCLUDE filter-modes are also defined in a multicast router to process the IGMPv3 or MLDv2 reports. When a multicast router receives the Report messages from its downstream hosts, it forwards the corresponding multicast traffic by managing requested group and source addresses. Group timers and source timers are used to maintain the forwarding state of desired groups and sources under certain filter-modes. When a group report arrives or a certain timer expires, a multicast router may update the desired or undesired source-lists, reset related timer values, change filter-mode, or trigger group queries. With all of the above factors correlating with each other, the determination rules become relatively complex, as the interface states could be frequently changed.
IGMPV3またはMLDV2レポートを処理するために、マルチキャストルーターでもフィルターモードを含めて除外されます。マルチキャストルーターがダウンストリームホストからレポートメッセージを受信すると、リクエストされたグループとソースアドレスを管理することにより、対応するマルチキャストトラフィックを転送します。グループタイマーとソースタイマーは、特定のフィルターモードの下で、目的のグループとソースの転送状態を維持するために使用されます。グループレポートが到着するか、特定のタイマーが有効になると、マルチキャストルーターは、目的または望ましくないソースリストを更新し、関連するタイマー値をリセットし、フィルターモードを変更し、グループクエリをトリガーできます。上記のすべての要因が互いに相関することで、インターフェイス状態を頻繁に変更できるため、決定ルールは比較的複雑になります。
The multicast filter-mode improves the ability of the multicast receiver to express its desires. It is useful to support Source-Specific Multicast (SSM) [7] by specifying interesting source addresses with INCLUDE mode. However, practical applications do not use EXCLUDE mode to block sources very often, because a user or application usually wants to specify desired source addresses, not undesired source addresses. Even if a user explicitly refuses traffic from some sources in a group, when other users in the same shared network have an interest in these sources, the corresponding multicast traffic will still be forwarded to the network. It is generally unnecessary to support the filtering function that blocks sources.
マルチキャストフィルターモードは、マルチキャストレシーバーがその欲求を表現する能力を向上させます。インクルードモードを使用して興味深いソースアドレスを指定することにより、ソース固有のマルチキャスト（SSM）[7]をサポートすることは便利です。ただし、ユーザーまたはアプリケーションは通常、望ましくないソースアドレスではなく、目的のソースアドレスを指定する必要があるため、実際のアプリケーションでは除外モードを使用してソースをブロックすることはほとんどありません。ユーザーがグループの一部のソースからのトラフィックを明示的に拒否したとしても、同じ共有ネットワークの他のユーザーがこれらのソースに関心を持っている場合、対応するマルチキャストトラフィックは引き続きネットワークに転送されます。一般に、ソースをブロックするフィルタリング関数をサポートする必要はありません。
This document proposes simplified versions of IGMPv3 and MLDv2, named Lightweight IGMPv3 and Lightweight MLDv2 (or LW-IGMPv3 and LW-MLDv2). LW-IGMPv3 and LW-MLDv2 are subsets of the standard IGMPv3 and MLDv2.
このドキュメントは、軽量IgMPv3および軽量MLDV2（またはLW-Igmpv3およびLW-MLDV2）という名前のIgMPv3およびMLDV2の簡略バージョンを提案しています。LW-IGMPV3およびLW-MLDV2は、標準のIGMPV3およびMLDV2のサブセットです。
They support both Any-Source Multicast (ASM) and SSM communications without a filtering function that blocks sources. Not only are they compatible with the standard IGMPv3 and MLDv2, but also the protocol operations made by hosts and routers (or switches performing IGMPv3/ MLDv2 snooping) are simplified to reduce the complicated operations. Since LW-IGMPv3 and LW-MLDv2 are fully compatible with IGMPv3 and MLDv2, hosts or routers that have implemented the full version do not need to implement or modify anything to cooperate with LW-IGMPv3/ LW-MLDv2 hosts or routers.
ソースをブロックするフィルタリング関数なしで、あらゆるソースマルチキャスト（ASM）とSSM通信をサポートしています。標準のIGMPV3およびMLDV2と互換性があるだけでなく、ホストとルーター（またはIGMPV3/ MLDV2スヌーピングを実行するスイッチ）が作成したプロトコル操作も簡素化して、複雑な動作を減らします。LW-IGMPV3およびLW-MLDV2はIGMPV3およびMLDV2と完全に互換性があるため、フルバージョンを実装したホストまたはルーターは、LW-IGMPV3/ LW-MLDV2ホストまたはルーターと協力するために何も実装または変更する必要はありません。
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 [1].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [1]に記載されているように解釈される。
In addition, the following terms are used in this document.
さらに、このドキュメントでは、次の用語が使用されています。
(*,G) join: An operation triggered by a host that wants to join a group G. In this case, the host receives from all sources sending to group G. This is typical in ASM communication.
（*、g）結合：グループGに参加したいホストによってトリガーされた操作。この場合、ホストはグループGに送信するすべてのソースから受信します。これはASM通信で典型的です。
(S,G) join: An operation triggered by a host that wants to join a group G, specifying a desired source S. In this case, the host receives traffic only from source S sending to group G.
（S、G）結合：グループGに参加したいホストによってトリガーされた操作。目的のソースSを指定します。
INCLUDE (S,G) join: An operation triggered by a host that wants to join a group G under INCLUDE filter-mode, specifying a desired source S. Same meaning as (S,G) join.
include（s、g）結合：インクルードモードの下にグループGに参加したいホストによってトリガーされた操作。目的のソースSを指定します。
EXCLUDE (*,G) join: An operation triggered by a host that wants to join a group G under EXCLUDE filter-mode. Same meaning as (*,G) join.
除外（*、g）結合：除外フィルターモードの下でグループGに参加したいホストによってトリガーされる操作。（*、g）結合と同じ意味。
EXCLUDE (S,G) join: An operation triggered by a host that wants to join a group G under EXCLUDE filter-mode, specifying an undesired source S. This operation is not supported by LW-IGMPv3/LW-MLDv2.
除外（s、g）結合：除外フィルターモードの下でグループGに参加したいホストによってトリガーされる操作、望ましくないソースSを指定します。
The principle is to simplify the host's and router's behavior as much as possible to improve efficiency, while guaranteeing interoperability with the full versions, and introducing no side effects on applications.
原則は、ホストとルーターの動作を可能な限り簡素化して効率を改善し、完全なバージョンとの相互運用性を保証し、アプリケーションに副作用を導入しないことです。
For convenience, this document mainly discusses IGMPv3, since MLDv2 inherits the same source filtering mechanism, but this document additionally shows MLDv2's unique specifications when needed.
便利なため、このドキュメントは主にIgMPv3について説明します。MLDV2は同じソースフィルタリングメカニズムを継承しているためですが、このドキュメントは必要に応じてMLDV2の一意の仕様をさらに示しています。
LW-IGMPv3 inherits the service interface model of IGMPv3.
LW-IGMPV3は、IGMPV3のサービスインターフェイスモデルを継承します。
IPMulticastListen ( socket, interface, multicast-address, filter-mode, source-list )
IPMulticastListen（ソケット、インターフェイス、マルチキャストアドレス、フィルターモード、ソースリスト）
In the lightweight protocol, INCLUDE mode on the host part has the same usage as the full version for INCLUDE (S,G) join, while EXCLUDE mode on the host part is preserved only for excluding null source-lists, which denotes a (*,G) join as used by IGMPv2/IGMPv1/MLDv1. The detailed host operation of LW-IGMPv3/LW-MLDv2 is described in Section 4.
軽量プロトコルでは、ホストパートのincludeモードは、include（s、g）結合のフルバージョンと同じ使用法を持っていますが、ホストパーツの除外モードはnullソースリストを除外するためにのみ保存されます。、g）IgMPv2/Igmpv1/MLDV1で使用されているように結合します。LW-IGMPV3/LW-MLDV2の詳細なホスト操作は、セクション4で説明されています。
In IGMPv3, router filter-mode is defined to optimize the state description of a group membership [2]. As a rule, once a member report is in EXCLUDE mode, the router filter-mode for the group will be set to EXCLUDE. When all systems cease sending EXCLUDE mode reports, the filter-mode for that group may transit back to INCLUDE mode. The group timer is used to identify such a transition.
IGMPV3では、グループメンバーシップの状態の説明を最適化するためにルーターフィルターモードが定義されています[2]。原則として、メンバーレポートが除外モードになると、グループのルーターフィルターモードが除外されるように設定されます。すべてのシステムが除外モードレポートの送信を停止すると、そのグループのフィルターモードは、モードを含めるように戻って戻ることができます。グループタイマーは、そのような遷移を識別するために使用されます。
In LW-IGMPv3, hosts primarily send INCLUDE requests, and also can request an EXCLUDE (*,G) join, which can be interpreted by the router as a request to include all sources. Without the more general form of EXCLUDE requests, it is unnecessary for the router to maintain the EXCLUDE filter-mode, and the state model for multicast routers can be simplified as:
LW-Igmpv3では、ホストは主に含まれるリクエストを送信し、すべてのソースを含めるリクエストとしてルーターによって解釈できる除外（*、g）結合を要求することもできます。より一般的なフォームの除外要求がなければ、ルーターが除外フィルターモードを維持する必要はありません。マルチキャストルーターの状態モデルは次のように簡素化できます。
(multicast address, group timer, (source records))
（マルチキャストアドレス、グループタイマー、（ソースレコード））
Here a group timer is kept to represent a (*,G) join. Its basic behavior is: when a router receives a (*,G) join, it will set its group timer and keep the source-list for sources specified in the previously received source records. When the group timer expires, the router may change to reception of the listed sources only. The definition of the source record is the same as in the full version.
ここでは、グループタイマーが（*、g）結合を表すために保持されます。その基本的な動作は、ルーターが（*、g）結合を受信すると、グループタイマーを設定し、以前に受信したソースレコードで指定されたソースのソースリストを保持します。グループタイマーの有効期限が切れると、ルーターはリストされたソースのみの受信に変更される場合があります。ソースレコードの定義は、フルバージョンと同じです。
The elimination of the filter-mode will greatly simplify the router behavior. The details of router operation are described in Section 5.
フィルターモードの除去により、ルーターの動作が大幅に簡素化されます。ルーター操作の詳細については、セクション5で説明します。
LW-IGMPv3 uses the same two sets of messages, Query and Report messages, as the full version protocols. There is no difference between the definition and usage of the Query message. But the report types in lightweight protocols are reduced because an operation that triggers EXCLUDE (S,G) join is omitted.
LW-IGMPV3は、フルバージョンのプロトコルと同じ2セットのメッセージ、クエリおよびレポートメッセージを使用します。クエリメッセージの定義と使用法に違いはありません。ただし、軽量プロトコルのレポートタイプは、トリガーを除外する操作（s、g）の結合が省略されているため、削減されます。
There are three Group Record Types defined in the full IGMPv3: the Current-State Record denoted by MODE_IS_INCLUDE (referred to as IS_IN) or MODE_IS_EXCLUDE (IS_EX), the Filter-Mode-Change Record denoted by CHANGE_TO_INCLUDE_MODE (TO_IN) or CHANGE_TO_EXCLUDE_MODE (TO_EX), and the Source-List-Change Record denoted by ALLOW_NEW_SOURCES (ALLOW) or BLOCK_OLD_SOURCES (BLOCK). LW-IGMPv3 inherits the actions on change of interface state and on reception of a query, but the IS_IN and IS_EX record types are eliminated and Current-State Records are replaced by other records. The following sections explain the details.
完全なIGMPv3で定義された3つのグループレコードタイプがあります。MODE_IS_INCLUDE（IS_INと呼ばれる）またはMODE_IS_EXCLUDE（IS_EX）で示される現在の状態レコード、Change_TO_INCLUDE_MODE（TO_IN）またはCHANGE_TO_TO_TOCCLUDE_MODE（to_ex）によって示されるフィルターモード変更レコード、およびAllow_new_sources（lock）またはblock_old_sources（block）によって示されるソースリストチェンジレコード。LW-IGMPV3は、インターフェイス状態の変更とクエリの受信に関するアクションを継承しますが、IS_INおよびIS_EXレコードタイプは排除され、現在の状態レコードは他のレコードに置き換えられます。次のセクションでは、詳細について説明します。
When the state of an interface of a group member host is changed, a State-Change Report for that interface is immediately transmitted from that interface. The type and contents of the Group Record(s) in that report are determined by comparing the filter-mode and source-list for the affected multicast address before and after the change. While the requirements for the computation are the same as for the full version, in a lightweight version host the interface state change rules are simplified due to the reduction of message types. The contents of the new transmitted report are calculated as follows (Group Record Types are described in Section 4.4):
グループメンバーホストのインターフェイスの状態が変更されると、そのインターフェイスの状態変化レポートがすぐにそのインターフェイスから送信されます。そのレポートのグループレコードのタイプと内容は、変更の前後に影響を受けるマルチキャストアドレスのフィルターモードとソースリストを比較することにより決定されます。計算の要件はフルバージョンの要件と同じですが、軽量バージョンホストでは、メッセージタイプが減少するため、インターフェイス状態変更ルールが簡素化されます。新しい送信レポートの内容は、次のように計算されます（グループレコードタイプはセクション4.4で説明されています）。
Old State New State State-Change Report Sent
----------- ----------- ------------------------
INCLUDE (A) INCLUDE (B) ALLOW(B-A), BLOCK(A-B)
（a）を含む（b）許可（b-a）、ブロック（a-b）を含める
INCLUDE (A) EXCLUDE ({}) TO_EX({})
INCLUDE ({}) EXCLUDE ({}) TO_EX({})
EXCLUDE ({}) INCLUDE (B) TO_IN(B)
As in the full version, to cover the possibility of the State-Change Report being missed by one or more multicast routers, it is retransmitted [Robustness Variable]-1 more times, at intervals chosen at random from the range (0, [Unsolicited Report Interval]). (These values are defined in [2][3].)
フルバージョンのように、1つ以上のマルチキャストルーターが状態変化レポートが見逃される可能性をカバーするために、範囲からランダムに選択された間隔で選択された[堅牢性変数] -1回再送信されます（0、[unsloclited）レポート間隔]）。（これらの値は[2] [3]で定義されています。）
As in the full version, when a lightweight version host receives a query, it does not respond immediately. Instead, it delays its response by a random amount of time, bounded by the Max Resp Time value derived from the Max Resp Code in the received Query message [2][3]. The system may receive a variety of queries on different interfaces and of different kinds (e.g., General Queries, Group-Specific Queries, and Group-and-Source-Specific Queries), each of which may require its own delayed response.
フルバージョンのように、軽量バージョンのホストがクエリを受け取ると、すぐには応答しません。代わりに、受信クエリメッセージ[2] [3]のMAX RESPコードから派生したMAX RESP時間値に制限されたランダムな時間によって応答を遅らせます。システムは、さまざまなインターフェイスやさまざまな種類のさまざまなクエリ（一般的なクエリ、グループ固有のクエリ、グループおよびソース固有のクエリなど）を受け取る場合があり、それぞれが独自の遅延応答を必要とする場合があります。
Before scheduling a response to a query, the system must first consider previously scheduled pending responses and in many cases schedule a combined response. Therefore, the lightweight version host must be able to maintain the following state:
クエリへの応答をスケジュールする前に、システムは最初に以前にスケジュールされた保留中の応答を考慮し、多くの場合、複合応答をスケジュールする必要があります。したがって、軽量バージョンのホストは、次の状態を維持できる必要があります。
o A timer per interface for scheduling responses to General Queries.
o 一般的なクエリへの応答をスケジュールするためのインターフェイスごとのタイマー。
o A per-group and interface timer for scheduling responses to Group-Specific and Group-and-Source-Specific Queries.
o グループ固有およびグループおよびソース固有のクエリに対する応答をスケジュールするためのグループごとのインターフェイスタイマー。
o A per-group and interface list of sources to be reported in the response to a Group-and-Source-Specific Query.
o グループとソース固有のクエリへの応答で報告されるソースのグループごととインターフェイスリスト。
LW-IGMPv3 inherits the full version's rules that are used to determine if a report needs to be scheduled. The difference is regarding the simplification of EXCLUDE filter-mode and the type of report as detailed in Section 4.4.
LW-IGMPV3は、レポートをスケジュールする必要があるかどうかを判断するために使用されるフルバージョンのルールを継承します。違いは、セクション4.4で詳述されている除外フィルターモードの簡素化とレポートのタイプに関するものです。
Among the Group Record Types defined in the full IGMPv3, several record types are not used in LW-IGMPv3 as some of the processes related to the filter-mode change to the EXCLUDE mode are eliminated and some of the Report messages are converged into a record having a null source address list. All of the record types of Report messages used by the full and lightweight version protocols are shown as follows:
完全なIGMPV3で定義されたグループレコードタイプの中で、除外モードへのフィルターモードの変更に関連するプロセスの一部が排除され、レポートメッセージの一部がレコードに収束されるため、いくつかのレコードタイプがLW-IGMPV3では使用されていません。ヌルソースアドレスリストがあります。完全および軽量バージョンのプロトコルで使用されるレポートのレポートメッセージのすべては、次のように表示されます。
IGMPv3 LW-IGMPv3 Comments
--------- --------- -------------------------------------
IS_EX({}) TO_EX({}) Query response for (*,G) join
IS_EX(x) N/A Query response for EXCLUDE (x,G) join
is_ex（x）n/a exclude（x、g）結合のクエリ応答
IS_IN(x) ALLOW(x) Query response for INCLUDE (x,G) join
is_in（x）akain（x）for include（x、g）結合のクエリ応答
ALLOW(x) ALLOW(x) INCLUDE (x,G) join
（x）許可（x）を含む（x、g）結合
BLOCK(x) BLOCK(x) INCLUDE (x,G) leave
ブロック（x）block（x）を含む（x、g）休暇
TO_IN(x) TO_IN(x) Change to INCLUDE (x,G) join
to_in（x）to_in（x）変更して（x、g）結合
TO_IN({}) TO_IN({}) (*,G) leave
TO_EX(x) N/A Change to EXCLUDE (x,G) join
to_ex（x）n/a除外する（x、g）結合
TO_EX({}) TO_EX({}) (*,G) join
where "x" represents a non-null source address list and "({})" represents a null source address list. For instance, IS_EX({}) means a report whose record type is IS_EX with a null source address list. "N/A" represents not applicable (or no use) because the corresponding operation should not occur in the lightweight version protocols.
ここで、「x」は非ヌルのソースアドレスリストを表し、「（{}）」はnullソースアドレスリストを表します。たとえば、is_ex（{}）は、nullソースアドレスリストを持つレコードタイプがis_exであるレポートを意味します。「n/a」は、対応する操作が軽量バージョンプロトコルでは発生しないため、適用されない（または使用しない）を表します。
LW-IGMPv3 does not use EXCLUDE filter-mode with a non-null source address list. A multicast router creates the same state when it receives a Report message containing either IS_EX({}) or TO_EX({}) record types. Therefore, LW-IGMPv3 integrates the IS_EX({}) operation with the TO_EX({}) operation.
LW-IGMPV3は、非ヌルのソースアドレスリストを持つ除外フィルターモードを使用しません。マルチキャストルーターは、is_ex（{{}）またはto_ex（{{}）レコードタイプのいずれかを含むレポートメッセージを受信するときに同じ状態を作成します。したがって、LW-IGMPV3は、IS_EX（{{}）操作をTO_EX（{{}）操作と統合します。
When an LW-IGMPv3 host needs to make a query response for the state of INCLUDE (x,G) join, it makes a response whose message type is expressed with ALLOW(x), instead of using the IS_IN record type. Because the router's processing of the two messages is exactly the same, the IS_IN(x) type is eliminated for simplification.
LW-IGMPV3ホストがINCLUST（x、g）結合の状態のクエリ応答を行う必要がある場合、IS_INレコードタイプを使用する代わりに、メッセージタイプがAlow（x）で表現される応答を作成します。2つのメッセージのルーターの処理はまったく同じであるため、単純化のためにIS_IN（x）タイプが排除されます。
An LW-IGMPv3 host does not use EXCLUDE mode, while TO_IN and TO_EX records are used for example in the following situation: the host first launches an application (AP1) that requests INCLUDE (x,G) join, and sends ALLOW(x). Then the host launches another application (AP2) that joins (*,G), and it sends TO_EX({}). In this condition, when AP2 terminates but AP1 keeps working on the lightweight version host, the host sends a report with TO_IN(x) record type for [Robustness Variable] times.
LW-IGMPV3ホストは除外モードを使用しませんが、TO_INおよびTO_EXレコードは次の状況で使用されます。。次に、ホストは結合する別のアプリケーション（AP2）を起動し（*、g）、to_ex（{}）を送信します。この条件では、AP2が終了するが、AP1が軽量バージョンのホストで作業を続けている場合、ホストは[ロバストネス変数]時間のto_in（x）レコードタイプを含むレポートを送信します。
Although an LW-IGMPv3 host adopts the four message types (ALLOW, BLOCK, TO_IN, and TO_EX) for simplification, using IS_EX({}) and IS_IN(x) (respectively, instead of TO_EX({}) and ALLOW(x)) in response to queries is not inhibited. This will not introduce the interoperation problem because the router process is, respectively, the same for the mentioned two message set, as long as the router implementation follows the rules given by full IGMPv3.
LW-IGMPV3ホストは、IS_EX（{{}）とIS_IN（x）を使用して、単純化のために4つのメッセージタイプ（許容、ブロック、to_in、およびto_ex）を採用しますが（to_ex（{}）、（x）を許可する代わりに））クエリへの応答は、抑制されていません。ルータープロセスは、ルーターの実装が完全なIGMPV3によって与えられたルールに従う限り、それぞれルータープロセスが言及された2つのメッセージセットで同じであるため、相互操作の問題を導入しません。
The major difference between the full and lightweight version protocols on the router part is that in the lightweight version filter-mode is discarded and the function of the group timer is redefined. The states maintained by the lightweight router are reduced and the protocol operation is greatly simplified.
ルーター部分のフルバージョンと軽量バージョンのプロトコルの主な違いは、軽量バージョンでフィルターモードが破棄され、グループタイマーの関数が再定義されることです。軽量ルーターによって維持されている状態は削減され、プロトコル操作が大幅に簡素化されます。
In lightweight and full IGMPv3 routers, a source timer is kept for each source record and it is updated when the source is present in a received report. It indicates the validity of the source and needs to be referred to when the router takes its forwarding decision.
軽量で完全なIGMPV3ルーターでは、ソース記録ごとにソースタイマーが保持され、受信レポートにソースが存在すると更新されます。これは、ソースの有効性を示し、ルーターが転送決定を下したときに参照する必要があります。
The group timer being used in the full version of IGMPv3 for transitioning the router's filter-mode from EXCLUDE to INCLUDE is redefined in the lightweight protocols to identify the non-source-specific receiving state maintained for (*,G) join. Once a group record of TO_EX({}) is received, the group timer is set to represent this (*,G) group join. The expiration of the group timer indicates that there are no more listeners on the attached network for this (*,G) group. Then if at this moment there are unexpired sources (whose source timers are greater than zero), the router will change to receiving traffic for those sources only. The role of the group timer can be summarized as follows:
IGMPV3のフルバージョンで使用されているグループタイマーは、ルーターのフィルターモードを除外から含めるように遷移するために使用されます。軽量プロトコルで再定義され、（*、g）結合のために維持されている非ソース固有の受信状態を識別します。to_ex（{{}）のグループレコードが受信されると、グループタイマーはこの（*、g）グループ結合を表すように設定されます。グループタイマーの有効期限は、この（*、g）グループの添付ネットワークにこれ以上のリスナーがいないことを示しています。その時点で、期限が切れていないソース（ソースタイマーがゼロより大きい）がある場合、ルーターはそれらのソースのみのトラフィックの受信に変更されます。グループタイマーの役割は、次のように要約できます。
Group Timer Value Actions/Comments
------------------ --------------------------------------
G_Timer > 0 All members in this group.
g_timer> 0このグループのすべてのメンバー。
G_Timer == 0 No more listeners to this (*,G) group. If all source timers have expired, then delete group record. If there are still source record timers running, use those source records with running timers as the source record state.
g_timer == 0この（*、g）グループのリスナーはもうありません。すべてのソースタイマーが期限切れになった場合は、グループレコードを削除します。まだソースレコードタイマーが実行されている場合は、それらのソースレコードを実行しているタイマーをソースレコード状態として使用します。
The operation related to the group and source timers has some differences compared to the full IGMPv3. In the full version, if a source timer expires under the EXCLUDE router filter-mode, its corresponding source record is not deleted until the group timer expires for indicating undesired sources. In the lightweight version, since there is no need to keep such records for blocking specific sources, if a source timer expires, its source record should be deleted immediately, not waiting for the time-out of the group timer.
グループおよびソースタイマーに関連する操作には、完全なIGMPV3と比較していくつかの違いがあります。フルバージョンでは、ソースタイマーが除外ルーターフィルターモードの下で期限切れになった場合、対応するソースレコードは、不要なソースを示すためにグループタイマーが期限切れになるまで削除されません。軽量バージョンでは、特定のソースをブロックするためにそのようなレコードを保持する必要がないため、ソースタイマーが期限切れになった場合、そのソースレコードは、グループタイマーのタイムアウトを待つことなく、すぐに削除する必要があります。
A full version multicast router needs to consult IGMPv3 state information when it makes decisions on forwarding a datagram from a source, based on the router filter-mode and source timer. In LW-IGMPv3, because of the absence of the router filter-mode, the group timer and source timer could be used for such decisions. The forwarding suggestion made by LW-IGMPv3 to the routing protocols is summarized as follows:
フルバージョンのマルチキャストルーターは、ルーターフィルターモードとソースタイマーに基づいて、ソースからデータグラムを転送することを決定するときにIGMPV3の状態情報を参照する必要があります。LW-IGMPV3では、ルーターフィルターモードがないため、グループタイマーとソースタイマーをそのような決定に使用できます。LW-IGMPV3がルーティングプロトコルに行った転送の提案は、次のように要約されています。
Group Timer Source Timer Action
------------ ------------------ -----------------------
G_Timer == 0 S_Timer > 0 Suggest forwarding traffic from source
g_timer == 0 s_timer> 0ソースからトラフィックを転送することを提案する
G_Timer == 0 S_Timer == 0 Suggest stopping forwarding traffic from source and remove source record. If there are no more source records for the group, delete group record
g_timer == 0 s_timer == 0ソースからトラフィックの転送を停止し、ソースレコードを削除することをお勧めします。グループにソースレコードがもうない場合は、グループレコードを削除します
G_Timer == 0 No Source Elements Suggest not forwarding traffic from source
g_timer == 0ソースからトラフィックを転送しないことを提案するソース要素はありません
G_Timer > 0 S_Timer >= 0 Suggest forwarding traffic from source
g_timer> 0 s_timer> = 0ソースからトラフィックを転送することを提案する
G_Timer > 0 No Source Elements Suggest forwarding traffic from source
g_timer> 0ソース要素はソースからトラフィックを転送することを提案していません
When receiving Current-State Records, the LW-IGMPv3 router resets its group or source timers and updates its source-list within the group. For source-specific group reception state (when G_Timer == 0 and S_Timer > 0), the source-list contains sources whose traffic will be forwarded by the router, while in non-source-specific group reception (when G_Timer > 0), the source-list remembers the valid sources to receive traffic from after toggling to source-specific reception state.
現在の状態レコードを受信すると、LW-IGMPV3ルーターはグループまたはソースタイマーをリセットし、グループ内のソースリストを更新します。ソース固有のグループ受信状態（g_timer == 0およびs_timer> 0の場合）の場合、ソースリストには、トラフィックがルーターによって転送されるソースが含まれていますが、非ソース固有のグループ受信（G_Timer> 0の場合）、ソースリストは、ソース固有の受信状態に切り替えた後からトラフィックを受信する有効なソースを覚えています。
Although the LW-IGMPv3 host only sends a subset of the messages of the full version, the LW-IGMPv3 router should be able to process as many messages as possible to be compatible with the full version host. Note that if the report type is IS_EX(x) with a non-empty source-list, the router will treat it as the same type of report with an empty source-list. The following table describes the action taken by a multicast router after receiving Current-State Records. The notations have the same meaning as those in the full IGMPv3 protocol.
LW-IGMPV3ホストはフルバージョンのメッセージのサブセットのみを送信しますが、LW-IGMPV3ルーターは、フルバージョンのホストと互換性があるためにできるだけ多くのメッセージを処理できるはずです。レポートタイプが空でないソースリストを使用してis_ex（x）である場合、ルーターは空のソースリストを使用して同じタイプのレポートとして扱うことに注意してください。次の表は、現在の状態レコードを受信した後のマルチキャストルーターが取ったアクションについて説明しています。表記は、完全なIGMPV3プロトコルの意味と同じ意味を持っています。
Old New
Source- Source-
Group Timer List Report Rec'd List Actions
------------ ------ ------------ ------ -----------
G_Timer == 0 A IS_IN(B) A+B (B)=GMI
G_Timer == 0 A IS_EX({}) A G_Timer=GMI
G_Timer > 0 A IS_IN(B) A+B (B)=GMI
G_Timer > 0 A IS_EX({}) A G_Timer=GMI
The above table could be further simplified since the processes are exactly the same for the two values of the G_Timer:
プロセスはG_Timerの2つの値でまったく同じであるため、上記の表はさらに簡素化される可能性があります。
Old New
Source- Source-
List Report Rec'd List Actions
------ ------------ ------ -----------
A IS_IN(B) A+B (B)=GMI
A IS_EX({}) A G_Timer=GMI
Without EXCLUDE filter-mode, a router's process on receiving a Current-State Record is simple: when a router receives an IS_IN report, it appends the reported source addresses to the previous source-list with their source timers set to GMI. Upon receiving an IS_EX({}) report, the router sets the non-source-specific receiving states by resetting the group timer value and keeps the previous source-list without modification.
フィルターモードを除外しないと、現在の状態レコードを受信するルーターのプロセスは簡単です。ルーターがIS_INレポートを受信すると、GMIに設定されたソースタイマーを使用して、報告されたソースアドレスを以前のソースリストに追加します。IS_EX（{{}）レポートを受信すると、ルーターはグループタイマーの値をリセットすることにより、非ソース固有の受信状態を設定し、以前のソースリストを変更せずに保持します。
On receiving Source-List-Change and Filter-Mode-Change Records, the LW-IGMPv3 router needs to reset its group and source timers, update its source-list within the group, or trigger group queries. The queries are sent by the router for the sources that are requested to be no longer forwarded to a group. Note that if the report type is TO_EX(x) with a non-empty source-list, the router will treat it as the same type of report with an empty source-list. The table below describes the state change and the actions that should be taken.
Source-List-ChangeおよびFilter-Mode-Changeレコードを受信すると、LW-IGMPV3ルーターは、グループとソースタイマーをリセットするか、グループ内のソースリストを更新するか、グループクエリをトリガーする必要があります。クエリは、グループに転送されなくなるように要求されるソースのルーターによって送信されます。レポートタイプが空でないソースリストを使用してto_ex（x）である場合、ルーターは空のソースリストを使用して同じタイプのレポートとして扱うことに注意してください。以下の表は、状態の変化ととるべき行動について説明しています。
Old New
Source- Source-
Group Timer List Report Rec'd List Actions
------------ ------ ------------ ------ -------------
G_Timer == 0 A ALLOW(B) A+B (B)=GMI
G_Timer == 0 A BLOCK(B) A Send Q(G,A*B)
G_Timer == 0 A TO_IN(B) A+B (B)=GMI
Send Q(G,A-B)
G_Timer == 0 A TO_EX({}) A G_Timer=GMI
G_Timer > 0 A ALLOW(B) A+B (B)=GMI
G_Timer > 0 A BLOCK(B) A Send Q(G,A*B)
G_Timer > 0 A TO_IN(B) A+B (B)=GMI
SendQ(G,A-B)
Send Q(G)
G_Timer > 0 A TO_EX({}) A G_Timer=GMI
The table could be further simplified by merging duplicate lines:
テーブルは、重複した行をマージすることでさらに簡素化できます。
Old New
Source- Source-
List Report Rec'd List Actions
------ ------------ ------ ----------------------
A ALLOW(B) A+B (B)=GMI
A BLOCK(B) A Send Q(G,A*B)
A TO_IN(B) A+B (B)=GMI
Send Q(G,A-B)
If G_Timer>0 Send Q(G)
A TO_EX({}) A G_Timer=GMI
LW-IGMPv3/LW-MLDv2 hosts and routers must interoperate with hosts and routers of the full version [2][3]. Also, LW-IGMPv3/LW-MLDv2 hosts and routers must interoperate gracefully with hosts and routers running IGMPv1/v2 or MLDv1.
LW-IGMPV3/LW-MLDV2ホストとルーターは、フルバージョンのホストとルーターと相互操作する必要があります[2] [3]。また、LW-IGMPV3/LW-MLDV2ホストとルーターは、IGMPV1/V2またはMLDV1を実行するホストとルーターと優雅に相互運用する必要があります。
LW-IGMPv3/LW-MLDv2 do not introduce any change on the message formats of the group Query and Report messages that the full version protocols use.
LW-IGMPV3/LW-MLDV2は、フルバージョンのプロトコルが使用するグループクエリのメッセージフォーマットとレポートメッセージの変更を導入しません。
An LW-IGMPv3 host's compatibility mode is determined from the Host Compatibility Mode variable, which can be in one of three states: IGMPv1, IGMPv2, or IGMPv3. When a lightweight host behaves on its interface as LW-IGMPv3, its Host Compatibility Mode of that interface is set to IGMPv3, and the host sends a subset of IGMPv3 Report messages, which can be recognized by a multicast router running the full or the lightweight IGMPv3 protocol on the same LAN.
LW-IGMPV3ホストの互換モードは、IGMPV1、IGMPV2、またはIGMPV3の3つの状態のいずれかにあるホスト互換モード変数から決定されます。軽量ホストがLW-IGMPV3としてインターフェイスで動作すると、そのインターフェイスのホスト互換性モードがIGMPV3に設定され、ホストはIGMPV3レポートメッセージのサブセットを送信します。同じLAN上のIGMPV3プロトコル。
An LW-IGMPv3 or LW-MLDv2 router does not process directly IS_EX(x) and TO_EX(x) reports that are used by the full version. When an LW-IGMPv3/LW-MLDv2 router receives these Report messages from full version hosts, it MUST translate them internally to IS_EX({}) and TO_EX({}) respectively and behave accordingly.
LW-IGMPV3またはLW-MLDV2ルーターは、フルバージョンで使用されるIS_EX（X）およびTO_EX（X）レポートを直接処理しません。LW-IGMPV3/LW-MLDV2ルーターがフルバージョンのホストからこれらのレポートメッセージを受信する場合、それぞれIS_EX（{{}）とto_ex（{{}）に内部的に翻訳し、それに応じて動作する必要があります。
Since the lightweight protocols can be treated as a parallel version of the full version of IGMPv3/MLDv2, its compatibility principle and method with the older version are generally the same as that of full IGMPv3/MLDv2.
軽量プロトコルはIGMPV3/MLDV2のフルバージョンの並列バージョンとして扱うことができるため、古いバージョンとの互換性の原則と方法は、一般に完全なIGMPV3/MLDV2の互換性と方法と同じです。
The Host Compatibility Mode of an interface is set to IGMPv2 and its IGMPv2 Querier Present timer is set to Older Version Querier Present Timeout seconds (defined in [2]) whenever an IGMPv2 General Query is received on that interface. The Host Compatibility Mode of an interface is set to IGMPv1 and its IGMPv1 Querier Present timer is set to Older Version Querier Present Timeout seconds whenever an IGMPv1 Membership Query is received on that interface.
インターフェイスのホスト互換性モードはIGMPv2に設定され、IGMPV2 Querierプレゼントタイマーは、IGMPV2一般クエリがそのインターフェイスで受信されるたびに、古いバージョンのQuerier現在のタイムアウト秒（[2]で定義）に設定されます。インターフェイスのホスト互換性モードはIGMPV1に設定され、IGMPV1 Querierプレゼントタイマーは、IGMPV1メンバーシップクエリがそのインターフェイスで受信されるたびに、古いバージョンクエリエプレゼントタイムアウト秒に設定されます。
In the presence of older version group members, LW-IGMPv3 hosts may allow its Report message to be suppressed by either an IGMPv1 or IGMPv2 membership report. However, because the transmission of IGMPv1 or v2 packets reduces the capability of the LW-IGMPv3 system, as a potential protection mechanism, the choice to enable or disable the use of backward compatibility may be configurable.
古いバージョングループメンバーの存在下で、LW-IGMPV3ホストは、IGMPV1またはIGMPV2メンバーシップレポートによってレポートメッセージを抑制することができます。ただし、IGMPV1またはV2パケットの伝送により、潜在的な保護メカニズムとしてのLW-IGMPV3システムの機能が低下するため、後方互換性の使用を有効または無効にする選択は構成できます。
The behavior of an LW-IGMPv3 router when placed on a network where there are routers that have not been upgraded to IGMPv3 is exactly the same as for a full IGMPv3 router in this situation [2].
IGMPV3にアップグレードされていないルーターがあるネットワークに配置する場合のLW-Igmpv3ルーターの動作は、この状況での完全なIgMPV3ルーターの場合とまったく同じです[2]。
A full IGMPv3 router uses Group Compatibility Mode (whose value is either of IGMPv1, IGMPv2, or IGMPv3) per group record to indicate which version of IGMP protocol it applies to the group. This value is set according to the version of the received IGMP reports. When Group Compatibility Mode is IGMPv3, the lightweight router performs the LW-IGMPv3 protocol for that group.
完全なIGMPV3ルーターは、グループレコードごとにグループ互換モード（IgMPv1、IgMPv2、またはIgMPv3のいずれか）をグループ互換モード（その値は、グループに適用されるIGMPプロトコルのバージョンを示すために使用します。この値は、受信したIGMPレポートのバージョンに従って設定されます。グループ互換モードがIGMPV3の場合、軽量ルーターはそのグループのLW-IGMPV3プロトコルを実行します。
When Group Compatibility Mode is IGMPv2, an LW-IGMPv3 router inherits this compatibility mechanism with the following rules:
グループ互換モードがIGMPV2の場合、LW-IGMPV3ルーターが次のルールでこの互換性メカニズムを継承します。
IGMP Message LW-IGMPv3 Equivalent
-------------- --------------------
v2 Report TO_EX({})
v2 Leave TO_IN({})
When Group Compatibility Mode is IGMPv1, an LW-IGMPv3 router internally translates the following IGMPv1 and IGMPv2 messages for that group to their LW-IGMPv3 equivalents:
グループ互換モードがIGMPV1の場合、LW-IGMPV3ルーターは、そのグループの次のIGMPV1およびIGMPV2メッセージを内部的にLW-IGMPV3等価物に変換します。
IGMP Message LW-IGMPv3 Equivalent
-------------- --------------------
v1 Report TO_EX({})
v2 Report TO_EX({})
LW-MLDv2 hosts and routers MUST interoperate with hosts and routers running MLDv1. The method is the same as described in Section 6.2. The difference is that when an LW-MLDv2 router has a MLDv1 listener on its network, it translates the following MLDv1 messages to their LW-MLDv2 equivalents:
LW-MLDV2ホストとルーターは、MLDV1を実行するホストとルーターと相互操作する必要があります。この方法は、セクション6.2で説明されているものと同じです。違いは、LW-MLDV2ルーターがネットワーク上にMLDV1リスナーを持っている場合、次のMLDV1メッセージをLW-MLDV2等価物に変換することです。
MLDv1 Message LW-MLDv2 Equivalent
------------- -------------------
Report TO_EX({})
Done TO_IN({})
The lightweight protocols require no additional procedure for the implementation of the related protocols or systems, e.g., IGMP/MLD snooping, multicast routing protocol, and operation of application sockets, while the processing loads on the switches and routers that run IGMPv3/MLDv2 (snooping) and multicast routing protocols may be greatly decreased.
軽量プロトコルでは、関連するプロトコルまたはシステムの実装に追加の手順を必要としません。たとえば、IGMP/MLDスヌーピング、マルチキャストルーティングプロトコル、アプリケーションソケットの動作があり、処理はIGMPV3/MLDV2を実行するスイッチとルーターの負荷（スヌーピング）を実行します。）およびマルチキャストルーティングプロトコルは大幅に減少する可能性があります。
[8] specifies the requirements for the implementation of Source-Specific Multicast (SSM) on IGMPv3/MLDv2 hosts and routers. The lightweight protocol follows the same rules as given in [8] except for the change of the message types due to the simplification.
[8] IGMPV3/MLDV2ホストとルーターにソース固有のマルチキャスト（SSM）の実装の要件を指定します。軽量プロトコルは、単純化によるメッセージタイプの変更を除き、[8]で与えられたものと同じルールに従います。
An LW-IGMPv3/LW-MLDv2 host should not invoke (*,G) join (i.e., TO_EX({})) and (*,G) leave (i.e., TO_IN({})) for applications whose multicast addresses are in the SSM address range. An upstream LW-IGMPv3/LW-MLDv2 router MUST NOT establish forwarding state and MAY log an error on reception of them as described in [7].
LW-IGMPV3/LW-MLDV2ホストは、マルチキャストアドレスがあるアプリケーションのJOIN（*、g）JOIN（つまり、to_ex（{}）および（*、g）去る（つまり、to_in（{}））ing（*、g）join（*、g）joce（*、g）を出現させないでください。SSMアドレス範囲。上流のLW-IGMPV3/LW-MLDV2ルーターは、[7]に記載されているように、転送状態を確立してはなりません。
[9] defines the following Multicast Source Filter (MSF) APIs: (1) IPv4 Basic MSF APIs, (2) IPv4 Advanced MSF APIs, (3) Protocol-Independent Basic MSF APIs, and (4) Protocol-Independent Advanced MSF APIs.
[9] 次のマルチキャストソースフィルター（MSF）APIを定義します：（1）IPv4基本MSF API、（2）IPv4 Advanced MSF API、（3）プロトコル非依存性基本MSF API、および（4）プロトコル非依存性MSF API。
According to the MSF API definition, an LW-IGMPv3 host should implement either the IPv4 Basic MSF API or the Protocol-Independent Basic MSF API, and an LW-MLDv2 host should implement the Protocol-Independent Basic MSF API. Other APIs, IPv4 Advanced MSF API and Protocol-Independent Advanced MSF API, are optional to implement in an LW-IGMPv3/LW-MLDv2 host.
MSF API定義によれば、LW-IGMPV3ホストはIPv4 Basic MSF APIまたはプロトコルに依存しない基本MSF APIのいずれかを実装する必要があり、LW-MLDV2ホストはプロトコル非依存性の基本MSF APIを実装する必要があります。その他のAPI、IPv4 Advanced MSF API、およびプロトコル非依存性Advanced MSF APIは、LW-IGMPV3/LW-MLDV2ホストに実装するためにオプションです。
The security considerations are the same as that of the full version of IGMPv3/MLDv2.
セキュリティ上の考慮事項は、IGMPV3/MLDV2のフルバージョンの考慮事項と同じです。
The authors would like to thank MBONED and MAGMA working group members. Special thanks is given to Marshall Eubanks, Guo Feng, Mark Fine, Alfred Hoenes, Prashant Jhingran, Bharat Joshi, Guo Tao, Wang Wendong, and Gong Xiangyang for their valuable suggestions and comments on this document.
著者は、MbonedとMagmaのワーキンググループのメンバーに感謝したいと思います。Marshall Eubanks、Guo Feng、Mark Fine、Alfred Hoenes、Prashant Jhingran、Bharat Joshi、Guo Tao、Wang Wendong、およびGong Xiangyangに、この文書に関する貴重な提案とコメントに感謝します。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[2] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、B。、およびA. Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC 3376、2002年10月。
[3] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[3] Vida、R。およびL. Costa、「IPv6のマルチキャストリスナーディスカバリーバージョン2（MLDV2）」、RFC 3810、2004年6月。
[4] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[4] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
[5] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[5] Fenner、W。、「インターネットグループ管理プロトコル、バージョン2」、RFC 2236、1997年11月。
[6] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[6] Deering、S.、Fenner、W。、およびB. Haberman、「IPv6のマルチキャストリスナーディスカバリー（MLD）」、RFC 2710、1999年10月。
[7] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[7] Holbrook、H。およびB. Cain、「IP用のソース固有のマルチキャスト」、RFC 4607、2006年8月。
[8] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast", RFC 4604, August 2006.
[8] Holbrook、H.、Cain、B。、およびB. Haberman、「インターネットグループ管理プロトコルバージョン3（IGMPV3）およびマルチキャストリスナーディスカバリープロトコルバージョン2（MLDV2）を使用して、ソース固有のマルチキャスト、RFC 4604、2006年8月。
[9] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface Extensions for Multicast Source Filters", RFC 3678, January 2004.
[9] Thaler、D.、Fenner、B。、およびB. Quinn、「マルチキャストソースフィルター用のソケットインターフェイス拡張」、RFC 3678、2004年1月。
Authors' Addresses
著者のアドレス
Hui Liu Huawei Technologies Co., Ltd. Huawei Bld., No.3 Xinxi Rd. Shang-Di Information Industry Base Hai-Dian Distinct, Beijing 100085 China
Hui Liu Huawei Technologies Co.、Ltd。Huawei Bld。、No.3 Xinxi Rd。Shang-Di Information Industry Base Hai-Dian Distict、北京100085中国
EMail: Liuhui47967@huawei.com
Wei Cao Huawei Technologies Co., Ltd. Huawei Bld., No.3 Xinxi Rd. Shang-Di Information Industry Base Hai-Dian Distinct, Beijing 100085 China
Wei Cao Huawei Technologies Co.、Ltd。Huawei Bld。、No.3 Xinxi Rd。Shang-Di Information Industry Base Hai-Dian Distict、北京100085中国
EMail: caowayne@huawei.com
Hitoshi Asaeda Keio University Graduate School of Media and Governance 5322 Endo Fujisawa, Kanagawa 252-8520 Japan
asaeda keio大学メディアおよびガバナンス大学大学院5322藤崎エンド、カナガワ252-8520日本
EMail: asaeda@wide.ad.jp