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およびIGMPv3およびMLDv2の標準（フル）のバージョンを簡素化する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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 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ライセンスのテキストを含める必要があり、この文書から抽出されました。
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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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.
INCLUDEおよびEXCLUDEフィルタモード、ソースフィルタリング機能をサポートするために導入されます。ホストが特定のソースから受信したい場合は、それが含まれるように設定したフィルタモードでの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.
INCLUDEとEXCLUDEフィルタモードはまたの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.
マルチキャストフィルタモードは、その欲望を表現するマルチキャスト受信機の能力を向上させることができます。 INCLUDEモードで興味深いソースアドレスを指定して、[7]ソース固有マルチキャスト（SSM）をサポートすることが有用です。ユーザーやアプリケーションは通常、所望の送信元アドレスではなく、望ましくない送信元アドレスを指定したいしかし、実用的なアプリケーションは、非常に多くの場合、ソースをブロックするようにEXCLUDEモードを使用しないでください。ユーザーが明示的に、グループ内のいくつかのソースからのトラフィックを拒否した場合でも、同一の共有ネットワーク内の他のユーザーがこれらのソースに興味を持っている場合、対応するマルチキャストトラフィックがネットワークに転送されます。そのブロックのソースフィルタリング機能をサポートするために、一般的に不要です。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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に参加したいホストによってトリガ動作は、ホストこれはASM通信において典型的であるグループGに送信するすべてのソースから受信します。
(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を指定し、ホストがグループ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.
参加する（S、G）として所望のソースSと同一の意味を指定して、フィルタモードをINCLUDE下グループGに参加したいホストによってトリガ動作を：（S、G）が参加が含まれます。
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）が参加EXCLUDE：下グループGに参加したいホストによってトリガ動作がフィルタモードをEXCLUDE。 （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.
EXCLUDE（S、G）が参加：この操作はLW-のIGMPv3 / LW-のMLDv2でサポートされていない望ましくないソースSを指定して、フィルタ・EXCLUDEモードの下でグループGに参加したいホストによってトリガ動作を制御します。
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.
MLDv2のは、同じソースフィルタリング機構を継承しますが、必要なときに、この文書はさらにMLDv2の独自の仕様を示していますので、便宜上、この文書は主に、IGMPv3のについて説明します。
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.
軽量プロトコルでは、*ホスト部分にEXCLUDEモードながら、ホスト部分にモード（示しており、ヌルソースリストを除くためにのみ保持され、参加する（S、G）を含むため、フルバージョンと同じ使い方を有するINCLUDE IGMPv2の/のIGMPv1 /のMLDv1によって使用されるように、G）が加わります。 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]の状態の説明を最適化するために定義されています。メンバーのレポートがEXCLUDEモードになったら、原則として、グループのためのルータフィルタモードを除外するように設定されます。すべてのシステムがモードのレポートをEXCLUDE送信を停止すると、そのグループのフィルタモードは、トランジットバックモードを含めることがあります。グループタイマーは、そのような遷移を識別するために使用されます。
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のでは、主にすべてのソースを含むように要求としてルータによって解釈することができる、EXCLUDE（*、G）参加要求することができ、またリクエストを含む送信、およびホスト。ルータがEXCLUDEフィルタモードを維持するための要求をEXCLUDEのより一般的な形せず、それが不要であり、マルチキャストルータの状態モデルは、のように簡略化することができます。
(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つのセットを使用しています。 Queryメッセージの定義と使用の間に違いはありません。 EXCLUDEトリガー操作（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_EXCLUDE_MODE（TO_EX）で表さフィルタモード変更レコードによって示されます、およびALLOW_NEW_SOURCES（許可）または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（A）EXCLUDE（{}）TO_EX（{}）
INCLUDE ({}) EXCLUDE ({}) TO_EX({})
INCLUDE（{}）EXCLUDE（{}）TO_EX（{}）
EXCLUDE ({}) INCLUDE (B) TO_IN(B)
EXCLUDE（{}）は、（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つまたは複数のマルチキャストルータによって見逃されている可能性をカバーするために、それは、範囲（0、[迷惑からランダムに選択された間隔で、[ロバストネス変数] -1回以上再送されますレポート間隔]）。 （これらの値は[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.
軽量バージョンのホストがクエリーを受信したときに、フルバージョンのように、それはすぐに応答しません。代わりに、[3] [2]受信したクエリメッセージにマックスRespをコードに由来する最大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レポートをスケジュールする必要があるかどうかを決定するために使用されているフルバージョンのルールを継承します。違いは、EXCLUDEフィルタモードおよび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の中で定義されたグループのレコードタイプの中で、いくつかのレコードタイプが排除されているEXCLUDEモードへのフィルタモード変更に関連するプロセスの一部として、LW-のIGMPv3で使用されていないとレポートメッセージのいくつかは、レコードに収束していますヌル送信元アドレスリストを持ちます。次のように完全かつ軽量バージョンのプロトコルで使用されるレポートメッセージのレコードタイプのすべてが表示されます：
IGMPv3 LW-IGMPv3 Comments
--------- --------- -------------------------------------
IS_EX({}) TO_EX({}) Query response for (*,G) join
IS_EX（*、G）のための（{}）TO_EX（{}）クエリー応答に参加
IS_EX(x) N/A Query response for EXCLUDE (x,G) join
IS_EX（X）N /（X、G）をEXCLUDEするためのクエリ応答に参加
IS_IN(x) ALLOW(x) Query response for INCLUDE (x,G) join
IS_IN（X）に参加（X）のためのクエリ応答が（X、G）を含むALLOW
ALLOW(x) ALLOW(x) INCLUDE (x,G) join
（X）（X）は、（X、G）が参加ALLOW ALLOW
BLOCK(x) BLOCK(x) INCLUDE (x,G) leave
BLOCK（x）は、ブロック（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_IN（{}）TO_IN（{}）（*、G）のまま
TO_EX(x) N/A Change to EXCLUDE (x,G) join
TO_EX（X）N / A変更を（X、G）を除外するために参加
TO_EX({}) TO_EX({}) (*,G) join
TO_EX（{}）TO_EX（{}）（*、G）参加
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（{}）は、そのレコードタイプヌル送信元アドレスリストと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がnull以外の送信元アドレスリストでフィルタモードをEXCLUDE使用していません。それはIS_EX（{}）またはTO_EX（{}）レコードタイプのいずれかを含む報告メッセージを受信したときにマルチキャストルータが同じ状態を作り出します。したがって、LW-のIGMPv3はTO_EX（{}）操作にIS_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ホストは、状態の問合せ応答を作成する必要がある場合（X、G）参加をINCLUDE、それは、そのメッセージタイプ代わりIS_INレコードタイプを使用する、（X）を許可して表現される応答を行います。二つのメッセージのルータの処理は全く同じであるので、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レコードは以下の状況で、例えば使用されるが、EXCLUDEモード使用していないホストは、最初のアプリケーション（AP1）が起動参加要求を（X、G）を含むこと、およびALLOW送信（X） 。次いで、ホストは、（*、G）参加する他のアプリケーション（AP2）を起動し、それが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ホストは、4つのメッセージタイプを採用しているが使用して、簡略化のために（ブロック、TO_IN、及びTO_EXを許可する）IS_EX（{}）とIS_IN代わりTO_EXのそれぞれ（X）（（{}）とALLOW（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のフルバージョンで使用されているグループタイマが含まれるようにEXCLUDE参加（*、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 ==この（*、G）のグループに0これ以上のリスナー。すべてのソースのタイマーが期限切れになっている場合は、グループレコードを削除します。まだ実行されているソース・レコード・タイマーがある場合は、ソースレコード状態としてタイマーを実行すると、それらのソースレコードを使用しています。
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のに比べていくつかの違いを有します。ソースタイマがEXCLUDEルータフィルタモードで満了した場合、グループタイマが望ましくないソースを示すための有効期限が切れるまでのフルバージョンでは、その対応するソースレコードが削除されません。ソースタイマーが満了した場合、特定のソースをブロックするため、このような記録を保持する必要がないので、軽量バージョンでは、そのソースレコードは、グループタイマのタイムアウトを待たないで、すぐに削除する必要があります。
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
現在のステートレコードを受信すると、LW-のIGMPv3ルータは、そのグループまたはソースタイマーをリセットし、グループ内でそのソース・リストを更新します。場合G_Timer == 0（ソース特定のグループの受信状態および
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.
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_IN（B）A + B（B）は、GMIを=
G_Timer == 0 A IS_EX({}) A G_Timer=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_IN（B）A + B（B）= GMI
G_Timer > 0 A IS_EX({}) A G_Timer=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の二つの値のために全く同じであるので、上記の表をさらに簡略化することができます。
Old New
Source- Source-
List Report Rec'd List Actions
------ ------------ ------ -----------
A IS_IN(B) A+B (B)=GMI
IS_IN（B）A + B（B）は、GMIを=
A IS_EX({}) A G_Timer=GMI
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.
EXCLUDEフィルタモードがなければ、現在のステートのレコードを受信すると、ルータのプロセスは簡単です：ルータは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.
ソース・リスト・変更とフィルタモード変更レコードを受信すると、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（B）A + B（B）はGMIを= ALLOW
G_Timer == 0 A BLOCK(B) A Send Q(G,A*B)
G_Timer == 0 A BLOCK（B）A Q（G、* B）を送ります
G_Timer == 0 A TO_IN(B) A+B (B)=GMI Send Q(G,A-B)
G_Timer == 0 A TO_IN（B）A + B（B）GMIはQを送る=（G、-B）
G_Timer == 0 A TO_EX({}) A G_Timer=GMI
G_Timer == 0 A TO_EX（{}）A G_Timer = GMI
G_Timer > 0 A ALLOW(B) A+B (B)=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 BLOCK（B）送信Q（G、*のB）
G_Timer > 0 A TO_IN(B) A+B (B)=GMI SendQ(G,A-B) Send Q(G)
G_Timer> 0 A TO_IN（B）A + B（B）GMI SENDQ（G、-Bを）= Q（G）を送信
G_Timer > 0 A TO_EX({}) A G_Timer=GMI
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（B）A + B（B）= GMI ALLOW
A BLOCK(B) A Send Q(G,A*B)
ブロック（B）A Q（G、* B）を送ります
A TO_IN(B) A+B (B)=GMI Send Q(G,A-B) If G_Timer>0 Send Q(G)
TO_IN（B）A + B（B）はG_Timer> 0送るQ（G）場合GMIは、Q（G、-B）を送信します=
A TO_EX({}) A G_Timer=GMI
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.
IGMPv1、IGMPv2の、またはIGMPv3の：LW-の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の一般クエリがそのインターフェイス上で受信されるたびにそのIGMPv2の問合者存在タイマは（[2]で定義された）旧バージョン問合者存在タイムアウト秒に設定されています。インタフェースのホスト互換モードはIGMPv1レポートに設定されているとのIGMPv1メンバーシップクエリーは、そのインターフェイス上で受信されるたびにその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ルータは、それがグループに適用されるIGMPプロトコルのバージョンを示すために、グループのレコードごとに（その値のIGMPv1、IGMPv2の、またはIGMPv3のいずれかである）グループの互換性モードを使用しています。この値は、受信した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報告TO_EX（{}）
v2 Leave TO_IN({})
V2脱退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ルータは、内部的に彼らのLW-のIGMPv3同等にそのグループの次のIGMPv1およびIGMPv2メッセージを変換します。
IGMP Message LW-IGMPv3 Equivalent
-------------- --------------------
v1 Report TO_EX({})
V1報告TO_EX（{}）
v2 Report TO_EX({})
V2報告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リスナーを持っているとき、それは彼らのLW-のMLDv2同等に次のMLDv1メッセージを変換することです：
MLDv1 Message LW-MLDv2 Equivalent
------------- -------------------
Report TO_EX({})
レポートTO_EX（{}）
Done TO_IN({})
行わ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.
IGMPv3 / MLDv2の実行スイッチおよびルータの処理負荷が（スヌーピングながら軽量プロトコルは、アプリケーションソケットの、例えば、IGMP / MLDスヌーピング、マルチキャストルーティングプロトコル、および操作、関連するプロトコルやシステムの実装のために追加の手順を必要としません）とマルチキャストルーティングプロトコルは大幅に減少させることができます。
[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ホストが起動してはならない（*、G）に参加（すなわち、TO_EX（{}））と、（*、G）を残す（すなわち、TO_IN（{}））マルチキャストアドレスにあるアプリケーションのために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.
（1）IPv4の基本MSF APIを、（2）のIPv4高度MSF APIを、（3）プロトコルに依存しない基本的なMSFのAPI、および（4）プロトコルに依存しない高度MSF APIの：[9]次のマルチキャストソースフィルタ（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の基本的なMSFのAPIやプロトコル独立基本MSFのAPI、およびプロトコル独立基本MSFのAPIを実装する必要がありますLW-のMLDv2ホストのいずれかを実装する必要があります。その他のAPIは、IPv4の高度MSFのAPIやプロトコルに依存しない高度な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ワーキンググループのメンバーに感謝したいと思います。特別な感謝は、このドキュメントの彼らの貴重な提案やコメントのためにマーシャルユーバンクス、郭風水、マーク・ファイン、アルフレッドHoenes、のPrashant Jhingran、バーラト・ジョシ、郭タオ、王Wendong、そしてゴング襄陽に与えられています。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[2]カイン、B.、デアリング、S.、Kouvelas、I.、フェナー、B.、およびA. Thyagarajan、 "インターネットグループ管理プロトコル、バージョン3"、RFC 3376、2002年10月。
[3] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[3]ヴィーダ、R.とL.コスタ、 "マルチキャストリスナ発見バージョン2（MLDv2の）IPv6のため"、RFC 3810、2004年6月。
[4] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[4]デアリング、S.、 "IPマルチキャスティングのためのホスト拡大"、STD 5、RFC 1112、1989年8月。
[5] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[5]フェナー、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]デアリング、S.、フェナー、W.、およびB.ハーバーマン、 "マルチキャストリスナ発見IPv6の（MLD）"、RFC 2710、1999年10月。
[7] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[7]ホルブルック、H.、およびB.カイン、 "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]ホルブルック、H.、カイン、B.、およびB.ハーバーマン、 "インターネットグループ管理プロトコルバージョン3（IGMPv3の）およびマルチキャストリスナ発見プロトコルバージョン2（MLDv2の）ソース固有のマルチキャストのための使用"、RFC 4604、8月2006。
[9] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface Extensions for Multicast Source Filters", RFC 3678, January 2004.
[9]ターラー、D.、フェナー、B.、およびB.クイン、 "マルチキャストソースフィルタのためのソケットインタフェース拡張"、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
ホイL IU HU Aは、技術の共同である。製HU A BLの、3番のX線におけるRD。シャン-DI情報産業基地H愛-Dイアンは異なる、北京100085中国
EMail: Liuhui47967@huawei.com
メールアドレス：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
ウェイCA OH UAは、技術の共同である。製HU A BLの、3番のX線におけるRD。シャン-DI情報産業基地H愛-Dイアンは異なる、北京100085中国
EMail: caowayne@huawei.com
メールアドレス：caowayne@huawei.com
Hitoshi Asaeda Keio University Graduate School of Media and Governance 5322 Endo Fujisawa, Kanagawa 252-8520 Japan
ひとし あさえだ けいお うにゔぇｒしｔｙ Ｇらづあて Ｓちょおｌ おｆ めぢあ あんｄ ごゔぇｒなんせ ５３２２ えんど ふじさわ、 かながわ ２５２ー８５２０ じゃぱん
EMail: asaeda@wide.ad.jp
メールアドレス：asaeda@wide.ad.jp