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




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.


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


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 ( 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ドキュメント(に関連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.


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
1. Introduction
1. はじめに

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


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ホストまたはルータに協力するために何かを実装したり、変更する必要はありません。

2. Terminology

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.


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


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.


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に参加したいホストによってトリガ動作を制御します。

3. Simplification Method Overview

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.


3.1. Behavior of Group Members
3.1. グループメンバーの行動

LW-IGMPv3 inherits the service interface model of IGMPv3.


IPMulticastListen ( socket, interface, multicast-address, filter-mode, source-list )


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に記載されています。

3.2. Behavior of Multicast Routers
3.2. マルチキャストルータの挙動

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.


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:


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


The elimination of the filter-mode will greatly simplify the router behavior. The details of router operation are described in Section 5.


4. LW-IGMPv3 Protocol for Group Members
4. LW-のIGMPv3グループメンバーのためのプロトコル
4.1. Query and Report Messages
4.1. クエリとレポートメッセージ

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レコードタイプが排除され、現在のステートレコードが他のレコードに置き換えられます。次のセクションでは、詳細を説明します。

4.2. Action on Change of Interface State
4.2. インタフェースの状態の変化に関するアクション

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









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]。)

4.3. Action on Reception of a Query
4.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 A per-group and interface timer for scheduling responses to Group-Specific and Group-and-Source-Specific Queries.


o A per-group and interface list of sources to be reported in the response to a Group-and-Source-Specific Query.


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.


4.4. LW-IGMPv3 Group Record Types
4.4. LW-のIGMPv3グループレコードタイプ

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    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 /(X、G)をEXCLUDEするためのクエリ応答に参加

IS_IN(x) ALLOW(x) Query response for INCLUDE (x,G) join


ALLOW(x) ALLOW(x) INCLUDE (x,G) join


BLOCK(x) BLOCK(x) INCLUDE (x,G) leave


TO_IN(x) TO_IN(x) Change to INCLUDE (x,G) join


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({})は、そのレコードタイプヌル送信元アドレスリストと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.


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.


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つのメッセージセットについて同じであるので、これは相互運用性の問題を導入しないであろう。

5. LW-IGMPv3 Protocol for Multicast Routers
5. LW-IGMPv3のマルチキャストルータのためのプロトコル

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.


5.1. Group Timers and Source Timers in the Lightweight Version
5.1. 軽量バージョンでグループタイマーとソースタイマ

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.


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.


5.2. Source-Specific Forwarding Rules
5.2. ソース固有の転送ルール

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いいえソース要素のソースからの転送トラフィックを提案します

5.3. Reception of Current-State Records
5.3. 現在のステートレコードのレセプション

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.


                       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:


               Old                      New
               Source-                  Source-
               List     Report Rec'd    List     Actions
               ------   ------------    ------   -----------


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({})レポートを受信すると、ルータは、グループタイマ値をリセットすることで、非ソース固有の受信状態を設定し、変更せずに前のソースリストを維持します。

5.4. Reception of Source-List-Change and Filter-Mode-Change Records
5.4. ソース・リスト・変更とフィルタモード変更レコードのレセプション

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.


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

6. Interoperability

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をを実行しているホストとルータで優雅に相互運用しなければなりません。

6.1. Interoperation with the Full Version of IGMPv3/MLDv2
6.1. IGMPv3 / MLDv2のフルバージョンとの相互運用性

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は、フルバージョンのプロトコルを使用してグループクエリとレポートメッセージのメッセージフォーマットの変更を導入しません。

6.1.1. Behavior of Group Members
6.1.1. グループメンバーの行動

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.


6.1.2. Behavior of Multicast Routers
6.1.2. マルチキャストルータの挙動

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({})にそれらを翻訳し、それに応じて動作する必要があります。

6.2. Interoperation with IGMPv1/IGMPv2
6.2. IGMPv1 / IGMPv2の相互運用

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のと同様です。

6.2.1. Behavior of Group Members
6.2.1. グループメンバーの行動

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.


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のシステムの能力を低下させるためしかし、後方互換性の使用を有効または無効にする選択が設定可能です。

6.2.2. Behavior of Multicast Routers
6.2.2. マルチキャストルータの挙動

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


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.


When Group Compatibility Mode is IGMPv2, an LW-IGMPv3 router inherits this compatibility mechanism with the following rules:


                 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:


                 IGMP Message          LW-IGMPv3 Equivalent
                --------------         --------------------

v1 Report TO_EX({})


v2 Report TO_EX({})


6.3. Interoperation with MLDv1
6.3. MLDv1との相互運用

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:


                 MLDv1 Message         LW-MLDv2 Equivalent
                 -------------         -------------------

Report TO_EX({})


Done TO_IN({})


7. Implementation Considerations

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スヌーピング、マルチキャストルーティングプロトコル、および操作、関連するプロトコルやシステムの実装のために追加の手順を必要としません)とマルチキャストルーティングプロトコルは大幅に減少させることができます。

7.1. Implementation of Source-Specific Multicast
7.1. ソース固有のマルチキャストの実装

[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]に記載のようにそれらの受信にエラーを記録することがあり。

7.2. Implementation of Multicast Source Filter (MSF) APIs
7.2. マルチキャストソースフィルタ(MSF)のAPIの実装

[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のホストで実装するオプションです。

8. Security Considerations

The security considerations are the same as that of the full version of IGMPv3/MLDv2.

セキュリティの考慮事項のIGMPv3 / MLDv2のフルバージョンのものと同じです。

9. Acknowledgements

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、そしてゴング襄陽に与えられています。

10. References
10.1. Normative References
10.1. 引用規格

[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。

10.2. Informative References
10.2. 参考文献

[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中国



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中国



Hitoshi Asaeda Keio University Graduate School of Media and Governance 5322 Endo Fujisawa, Kanagawa 252-8520 Japan

ひとし あさえだ けいお うにゔぇrしty Gらづあて Sちょおl おf めぢあ あんd ごゔぇrなんせ 5322 えんど ふじさわ、 かながわ 252ー8520 じゃぱん