Internet Engineering Task Force (IETF)                         H. Asaeda
Request for Comments: 6636                               Keio University
Category: Informational                                           H. Liu
ISSN: 2070-1721                                                    Q. Wu
                                                                May 2012
Internet Engineering Task Force (IETF)                         H. Asaeda
Request for Comments: 6636                               Keio University
Category: Informational                                           H. Liu
ISSN: 2070-1721                                                    Q. Wu
                                                                May 2012

Tuning the Behavior of the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) for Routers in Mobile and Wireless Networks




The Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) are the protocols used by hosts and multicast routers to exchange their IP multicast group memberships with each other. This document describes ways to achieve IGMPv3 and MLDv2 protocol optimization for mobility and aims to become a guideline for the tuning of IGMPv3/MLDv2 Queries, timers, and counter values.


Status of This Memo


This document is not an Internet Standards Track specification; it is published for informational purposes.


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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

本文件是互联网工程任务组(IETF)的产品。它代表了IETF社区的共识。它已经接受了公众审查,并已被互联网工程指导小组(IESG)批准出版。并非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) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.

版权所有(c)2012 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许可证中所述的无担保。

Table of Contents


   1. Introduction ....................................................2
   2. Terminology .....................................................3
   3. Explicit Tracking of Membership Status ..........................3
   4. Tuning IGMP/MLD Timers and Values ...............................4
      4.1. Tuning the IGMP/MLD General Query Interval .................4
      4.2. Tuning the IGMP/MLD Query Response Interval ................5
      4.3. Tuning the Last Member Query Timer (LMQT) and Last
           Listener Query Timer (LLQT) ................................6
      4.4. Tuning the Startup Query Interval ..........................7
      4.5. Tuning the Robustness Variable .............................7
      4.6. Tuning Scenarios for Various Mobile IP Networks ............7
   5. Destination Address of a Specific Query .........................8
   6. Interoperability ................................................9
   7. Security Considerations .........................................9
   8. Acknowledgements ................................................9
   9. References .....................................................10
      9.1. Normative References ......................................10
      9.2. Informative References ....................................10
   Appendix A. Unicasting a General Query ............................11
   1. Introduction ....................................................2
   2. Terminology .....................................................3
   3. Explicit Tracking of Membership Status ..........................3
   4. Tuning IGMP/MLD Timers and Values ...............................4
      4.1. Tuning the IGMP/MLD General Query Interval .................4
      4.2. Tuning the IGMP/MLD Query Response Interval ................5
      4.3. Tuning the Last Member Query Timer (LMQT) and Last
           Listener Query Timer (LLQT) ................................6
      4.4. Tuning the Startup Query Interval ..........................7
      4.5. Tuning the Robustness Variable .............................7
      4.6. Tuning Scenarios for Various Mobile IP Networks ............7
   5. Destination Address of a Specific Query .........................8
   6. Interoperability ................................................9
   7. Security Considerations .........................................9
   8. Acknowledgements ................................................9
   9. References .....................................................10
      9.1. Normative References ......................................10
      9.2. Informative References ....................................10
   Appendix A. Unicasting a General Query ............................11
1. Introduction
1. 介绍

The Internet Group Management Protocol (IGMP) [1] for IPv4 and the Multicast Listener Discovery (MLD) [2] protocol for IPv6 are the standard protocols for hosts to initiate joining or leaving of multicast sessions. These protocols must also be supported by multicast routers or IGMP/MLD proxies [5] that maintain multicast membership information on their downstream interfaces. Conceptually, IGMP and MLD work on both wireless and mobile networks. However, wireless access technologies operate on a shared medium or a point-to-point link with limited spectrum and bandwidth. In many wireless


regimes, it is desirable to minimize multicast-related signaling to preserve the limited resources of battery-powered mobile devices and the constrained transmission capacities of the networks. The motion of a host may cause disruption of multicast service initiation and termination in the new or previous network. Slow multicast service activation following a join may incur additional delay in receiving multicast packets and degrade reception quality. Slow service termination triggered by a rapid departure of the mobile host without first leaving the group in the previous network may waste network resources.


When IGMP and MLD are used with mobile IP protocols, the proximity of network entities should be considered. For example, when a bidirectional tunnel is used with the mobility entities described in [6] and [7], the mobile host experiences additional latency because the round-trip time using a bidirectional tunnel between mobility entities is larger compared to the case where a host and an upstream router attach to a LAN.


This document describes ways to tune IGMPv3 and MLDv2 protocol behavior -- on the multicast router and proxy side -- concentrating in particular on wireless and mobile networks, including the tuning of queries and related timers. This selective optimization provides tangible benefits to mobile hosts and routers by keeping track of the membership status of downstream hosts, and of various IGMP/MLD Query types and values, in order to appropriately tune the number of response messages. This document does not make any changes to the IGMPv3 and MLDv2 protocols and only suggests optimal settings for the configurable parameters of the protocols in mobile and wireless environments.


2. Terminology
2. 术语

In this document, "router" means both a multicast router and an IGMP/ MLD proxy.


3. Explicit Tracking of Membership Status
3. 明确跟踪成员身份

Mobile hosts use IGMP and MLD to make a request to join or leave multicast sessions. When an adjacent upstream router receives the IGMP/MLD Report messages, it recognizes the membership status on the link. To update the membership status reliably, the router sends IGMP/MLD Query messages periodically, and sends Group-Specific and/or Group-and-Source-Specific Queries when a member host reports its leave. An IGMP/MLD Query is therefore necessary to obtain up-to-date membership information, but a large number of the reply messages sent from all member hosts may cause network congestion or consume network bandwidth.


The "explicit tracking function" [8] is a possible approach to reduce the transmitted number of IGMP/MLD messages and contribute to the efficiency of mobile communications. It enables the router to keep track of the membership status of the downstream IGMPv3 or MLDv2 member hosts. That is, if a router enables the explicit tracking function, it does not always need to request transmission of a Current-State Report message from the receiver hosts, since the router implicitly recognizes the (potential) last member host when it receives the State-Change Report message reporting a leave. The router can therefore send IGMP/MLD Group-Specific and Group-and-Source-Specific Queries LMQC/LLQC times (see Section 4.3) only when it recognizes that the last member has left the network. This reduces the transmitted number of Current-State Report messages.


Enabling the explicit tracking function is advantageous for mobile multicast, but the function requires additional processing capability and, possibly, substantial memory for routers to store all membership status information. This resource requirement is potentially impacted, especially when a router needs to maintain a large number of receiver hosts. Therefore, this document recommends that adjacent upstream multicast routers enable the explicit tracking function for IP multicast communications on wireless and mobile networks, if they have enough resources. If operators think that their routers do not have enough resources, they may disable this function on their routers. Note that whether or not routers enable the explicit tracking function, they need to maintain downstream membership status by sending IGMPv3/MLDv2 General Query messages, as some IGMPv3/MLDv2 messages may be lost during transmission.


4. Tuning IGMP/MLD Timers and Values
4. 调整IGMP/MLD定时器和值
4.1. Tuning the IGMP/MLD General Query Interval
4.1. 调整IGMP/MLD通用查询间隔

IGMP and MLD are unreliable protocols; to cover the possibility of a State-Change Report being missed by one or more multicast routers, hosts retransmit the same State-Change Report messages ([Robustness Variable] - 1) more times, at intervals chosen at random from the range (0, [Unsolicited Report Interval]) [1] [2]. Although this behavior increases the protocol's robustness, it does not guarantee that the State-Change Report reaches the routers. Therefore, routers still need to refresh their downstream membership information by receiving a Current-State Report, as periodically solicited by an IGMP/MLD General Query sent in the [Query Interval] period, in order to enhance robustness of the host in case of link failures and packet loss. This procedure also supports situations where mobile hosts are powered off or moved from one network to another network managed by a different router without any notification (e.g., a leave request).

IGMP和MLD是不可靠的协议;为了解决一个或多个多播路由器丢失状态更改报告的可能性,主机以从范围(0[未经请求的报告间隔][1][2]中随机选择的间隔,将相同的状态更改报告消息([Robustness Variable]-1]重传多次。尽管这种行为增加了协议的健壮性,但并不保证状态更改报告到达路由器。因此,路由器仍然需要通过接收当前状态报告来刷新其下游成员信息,如在[查询间隔]期间发送的IGMP/MLD一般查询所定期请求的,以便在链路故障和分组丢失的情况下增强主机的健壮性。此过程还支持移动主机断电或从一个网络移动到另一个由不同路由器管理的网络而无需任何通知(例如,离开请求)的情况。

The [Query Interval] is the interval between General Queries sent by the regular IGMPv3/MLDv2 querier; the default value is 125 seconds [1] [2]. By varying the [Query Interval], multicast routers can tune the number of IGMP/MLD messages on the network; larger values cause IGMP/MLD Queries to be sent less often.

[Query Interval]是常规IGMPv3/MLDv2查询器发送的常规查询之间的间隔;默认值为125秒[1][2]。通过改变[查询间隔],多播路由器可以调整网络上IGMP/MLD消息的数量;值越大,发送IGMP/MLD查询的频率越低。

This document proposes a [Query Interval] value of 150 seconds by changing the Querier's Query Interval Code (QQIC) field in the IGMP/ MLD Query message, for the case where a router that enables the explicit tracking function potentially operates a large number of member hosts, such as more than 200 hosts on the wireless link. This longer interval value contributes to minimizing Report message traffic and battery-power consumption for mobile hosts.


On the other hand, this document also proposes a [Query Interval] value of 60 to 90 seconds for the case where a router that enables the explicit tracking function attaches to a higher-capacity wireless link. This shorter interval contributes to quick synchronization of the membership information tracked by the router but may consume battery power on mobile hosts.


If a router does not enable the explicit tracking function, the [Query Interval] value would be its default value -- 125 seconds.

如果路由器没有启用显式跟踪功能,[Query Interval]值将是其默认值——125秒。

In situations where Mobile IPv6 [7] is used, when the home agent implements multicast router functionality and multicast data packets are tunneled to and from the home agent, the home agent may want to increase the query interval. This happens, for example, when the home agent detects network congestion. In this case, the home agent starts forwarding queries with the default [Query Interval] value and increases the value in a gradual manner.

在使用移动IPv6[7]的情况下,当归属代理实现多播路由器功能并且多播数据分组通过隧道传送到归属代理和从归属代理传出时,归属代理可能希望增加查询间隔。例如,当归属代理检测到网络拥塞时,就会发生这种情况。在这种情况下,归属代理开始使用默认的[Query Interval]值转发查询,并逐渐增加该值。

4.2. Tuning the IGMP/MLD Query Response Interval
4.2. 调整IGMP/MLD查询响应间隔

The [Query Response Interval] is the Max Response Time (or Max Response Delay) used to calculate the Max Resp Code inserted into the periodic General Queries. Its default value is 10 seconds, expressed as "Max Resp Code=100" for IGMPv3 [1] and "Maximum Response Code=10000" for MLDv2 [2]. By varying the [Query Response Interval], multicast routers can tune the burstiness of IGMP/MLD messages on the network; larger values make the traffic less bursty, as the hosts' responses are spread out over a larger interval, but will increase join latency when a State-Change Report (i.e., join request) is missing.

[Query Response Interval]是用于计算插入定期常规查询的最大响应代码的最大响应时间(或最大响应延迟)。其默认值为10秒,对于IGMPv3[1],表示为“最大响应代码=100”;对于MLDv2[2],表示为“最大响应代码=10000”。通过改变[查询响应间隔],多播路由器可以调整网络上IGMP/MLD消息的突发性;值越大,流量的突发性就越小,因为主机的响应分布在更大的间隔上,但当状态更改报告(即加入请求)丢失时,会增加加入延迟。

According to our experimental analysis, this document proposes two scenarios for tuning the [Query Response Interval] value in different wireless link conditions: one scenario is for a wireless link with

根据我们的实验分析,本文提出了两种在不同无线链路条件下调整[Query Response Interval]值的方案:一种方案是针对具有

lower resource capacity or a lossy link, and the other scenario is for a wireless link with enough capacity or whose condition is reliable enough for IGMP/MLD message transmission.


Regarding the first scenario, for instance, when a multicast router attaches to a bursty IEEE 802.11b link, the router configures a longer [Query Response Interval] value, such as 10 to 20 (seconds). This configuration will reduce congestion of the Current-State Report messages on a link but may increase join latency and leave latency when the unsolicited messages (State-Change Records) are lost on the router. Note that as defined in Section 4.1.1 of [1], in IGMPv3, a Max Resp Code larger than 128 represents the exponential values and changes the granularity. For example, if one wants to set the Max Response Time to 20.0 seconds, the Max Resp Code should be expressed as "0b10001001", which is divided into "mant=0b1001" and "exp=0b000".

关于第一个场景,例如,当多播路由器连接到突发的IEEE 802.11b链路时,路由器配置更长的[Query Response Interval]值,例如10到20(秒)。此配置将减少链路上当前状态报告消息的拥塞,但在路由器上丢失未经请求的消息(状态更改记录)时,可能会增加加入延迟和离开延迟。注意,如[1]第4.1.1节所定义,在IGMPv3中,大于128的Max Resp代码表示指数值并改变粒度。例如,如果要将最大响应时间设置为20.0秒,则最大响应代码应表示为“0b10001001”,分为“mant=0b1001”和“exp=0b000”。

The second scenario may happen for a multicast router attaching to a wireless link having higher resource capacity or to a point-to-(multi-)point link such as an IEEE 802.16e link because IGMP/MLD messages do not seriously affect the condition of the link. The router can seek Current-State Report messages with a shorter [Query Response Interval] value, such as 5 to 10 (seconds). This configuration will contribute to (at some level) quickly discovering non-tracked member hosts and synchronizing the membership information.

第二种情况可能发生在多播路由器连接到具有更高资源容量的无线链路或连接到诸如IEEE 802.16e链路的点对(多)点链路,因为IGMP/MLD消息不会严重影响链路的状况。路由器可以用较短的[Query Response Interval]值(如5到10秒)查找当前状态报告消息。此配置将有助于(在某种程度上)快速发现未跟踪的成员主机并同步成员信息。

4.3. Tuning the Last Member Query Timer (LMQT) and Last Listener Query Timer (LLQT)

4.3. 调整最后一个成员查询计时器(LMQT)和最后一个侦听器查询计时器(LLQT)

Shortening the Last Member Query Timer (LMQT) for IGMPv3 and the Last Listener Query Timer (LLQT) for MLDv2 contributes to minimizing leave latency. LMQT is represented by the Last Member Query Interval (LMQI) multiplied by the Last Member Query Count (LMQC), and LLQT is represented by the Last Listener Query Interval (LLQI) multiplied by the Last Listener Query Count (LLQC).


While LMQI and LLQI are changeable, it is reasonable to use the default value (i.e., 1 second) for LMQI and LLQI in a wireless network. LMQC and LLQC, whose default value is the [Robustness Variable] value, are also tunable. Therefore, LMQC and LLQC can be set to "1" for routers that enable the explicit tracking function, and then LMQT and LLQT are set to 1 second. However, setting LMQC and LLQC to 1 increases the risk of missing the last member; LMQC and LLQC ought to be set to 1 only when network operators think that their wireless link is stable enough.

虽然LMQI和LLQI是可变的,但在无线网络中使用LMQI和LLQI的默认值(即1秒)是合理的。LMQC和LLQC的默认值是[Robustness Variable]值,它们也是可调的。因此,对于启用显式跟踪功能的路由器,可以将LMQC和LLQC设置为“1”,然后将LMQT和LLQT设置为1秒。但是,将LMQC和LLQC设置为1会增加丢失最后一个成员的风险;只有当网络运营商认为其无线链路足够稳定时,LMQC和LLQC才应设置为1。

On the other hand, if network operators think that their wireless link is lossy (e.g., due to a large number of attached hosts or limited resources), they can set LMQC and LLQC to "2" for their routers that enable the explicit tracking function. Although bigger LMQC and LLQC values may cause longer leave latency, the risk of missing the last member will be reduced.


4.4. Tuning the Startup Query Interval
4.4. 调整启动查询间隔

The [Startup Query Interval] is the interval between General Queries sent by a querier on startup. The default value is 1/4 of [Query Interval]; however, a shortened value, such as 1 second, would help contribute to shortening handover delay for mobile hosts in, for example, the base solution with Proxy Mobile IPv6 (PMIPv6) [9]. Note that the [Startup Query Interval] is a static value and cannot be changed by any external signal. Therefore, operators who maintain routers and wireless links need to properly configure this value.

[Startup Query Interval]是查询器在启动时发送的常规查询之间的间隔。默认值为【查询间隔】的1/4;然而,在例如具有代理移动IPv6(PMIPv6)的基本解决方案中,缩短的值(例如1秒)将有助于缩短移动主机的切换延迟[9]。请注意,[Startup Query Interval]是一个静态值,不能被任何外部信号更改。因此,维护路由器和无线链路的运营商需要正确配置此值。

4.5. Tuning the Robustness Variable
4.5. 调整稳健性变量

To cover the possibility of unsolicited reports being missed by multicast routers, unsolicited reports are retransmitted ([Robustness Variable] - 1) more times, at intervals chosen at random from the defined range [1] [2]. The QRV (Querier's Robustness Variable) field in the IGMP/MLD Query contains the [Robustness Variable] value used by the querier. The default [Robustness Variable] value defined in IGMPv3 [1] and MLDv2 [2] is "2".


This document proposes "2" for the [Robustness Variable] value for mobility when a router attaches to a wireless link having lower resource capacity or a large number of hosts. For a router that attaches to a higher-capacity wireless link known to be reliable, retransmitting the same State-Change Report message is not required; hence, the router sets the [Robustness Variable] to "1".


4.6. Tuning Scenarios for Various Mobile IP Networks
4.6. 各种移动IP网络的调整方案

In mobile IP networks, IGMP and MLD are used with three deployment scenarios: (1) running directly between a host and access router on a wireless network, (2) running between a host and home router through a tunnel link, and (3) running between a home router and foreign router through a tunnel link.


When a receiver host connects directly through a wireless link to a foreign access router or a home router, the tuning of the IGMP/MLD protocol parameters should be the same as suggested in the previous


sections. The example of this scenario occurs when in PMIPv6 [6], the mobile access gateway, whose role is similar to a foreign router, acts as a multicast router or proxy.


The second scenario occurs when a bidirectional tunnel established between a host and home router is used to exchange IGMP/MLD messages [7] [10]. Tuning the parameters is difficult in this situation because the condition of the tunnel link is diverse and changeable. When a host is far away from the home router, the transmission delay between the two entities may be longer and the packet delivery may be more unreliable. Thus, the effects of IGMP/MLD message transmission through a tunnel link ought to be considered when parameters are set. For example, the [Query Interval] and [Query Response Interval] could be set shorter to compensate for transmission delay, and the [Robustness Variable] could be increased to compensate for possible packet loss.

第二种情况发生在主机和家庭路由器之间建立的双向隧道用于交换IGMP/MLD消息[7][10]时。在这种情况下,调整参数是困难的,因为隧道连接的条件是多样和多变的。当主机远离家庭路由器时,两个实体之间的传输延迟可能更长,并且分组传送可能更不可靠。因此,在设置参数时,应考虑通过隧道链路传输IGMP/MLD消息的影响。例如,可以将[Query Interval]和[Query Response Interval]设置得更短以补偿传输延迟,并且可以增加[Roustness Variable]以补偿可能的分组丢失。

The third scenario occurs in [9], in which the mobile access gateway (i.e., foreign router) acts as the IGMP/MLD Proxy [5] in PMIPv6 [6]. Through the bidirectional tunnel established with the local mobility anchor (i.e., home router), the mobile access gateway sends summary reports of its downstream member hosts to the local mobility anchor. Apart from the distance factor, which influences the parameter setting, the [Query Response Interval] on the local mobility anchor could be set to a smaller value because the number of mobile access gateways is much smaller compared to the number of hosts, and the chance of packet burst is low for the same reason. Additionally, the power consumption due to a lower query interval is not an issue for the mobile access gateways because the mobile access gateways are usually not battery-powered.

第三种情况出现在[9]中,其中移动接入网关(即外部路由器)充当PMIPv6[6]中的IGMP/MLD代理[5]。通过与本地移动锚(即,家庭路由器)建立的双向隧道,移动接入网关向本地移动锚发送其下游成员主机的摘要报告。除了影响参数设置的距离因素外,本地移动性锚点上的[Query Response Interval]可以设置为较小的值,因为移动接入网关的数量比主机的数量小得多,并且出于相同的原因,数据包突发的机会较低。此外,由于较低的查询间隔而导致的功耗对于移动接入网关来说不是问题,因为移动接入网关通常不是电池供电的。

Ideally, the IGMP/MLD querier router adjusts its parameter settings according to the actual mobile IP network conditions to benefit service performance and resource utilization. It would be desirable for a home router to determine the aforementioned timers and values according to the delay between the initiating IGMP/MLD Query and the responding IGMP/MLD Report. However, describing how these timers and values can be dynamically adjusted is out of scope for this document.

理想情况下,IGMP/MLD querier路由器根据实际移动IP网络条件调整其参数设置,以提高服务性能和资源利用率。家庭路由器希望根据发起的IGMP/MLD查询和响应的IGMP/MLD报告之间的延迟来确定上述定时器和值。但是,描述如何动态调整这些计时器和值超出了本文档的范围。

5. Destination Address of a Specific Query
5. 特定查询的目标地址

IGMP/MLD Group-Specific and Group-and-Source-Specific Queries defined in [1] and [2] are sent to verify whether there are hosts that desire reception of the specified group or a set of sources, or to rebuild the desired reception state for a particular group or a set of sources. These specific queries build and refresh the multicast membership state of hosts on an attached network.


Group-Specific Queries are sent with an IP destination address equal to the multicast address of interest, as defined in [1] and [2]. Using the multicast group of interest in the specific query is preferred in this environment because hosts that do not join the multicast session do not pay attention to these specific queries, and only active member hosts that have been receiving multicast contents with the specified address reply to IGMP/MLD Reports.


6. Interoperability
6. 互操作性

IGMPv3 [1] and MLDv2 [2] provide the ability for hosts to report source-specific subscriptions. With IGMPv3/MLDv2, a mobile host can specify a channel of interest, using multicast group and source addresses in its join request. Upon its reception, the upstream router that supports IGMPv3/MLDv2 establishes the shortest-path tree toward the source without coordinating a shared tree. This function is called the source-filtering function and is required to support Source-Specific Multicast (SSM) [3].


Recently, the Lightweight IGMPv3 (LW-IGMPv3) and Lightweight MLDv2 (LW-MLDv2) [4] protocols have been defined as the proposed standard protocols in the IETF. These protocols provide protocol simplicity for mobile hosts and routers, as they eliminate a complex state machine from the full versions of IGMPv3 and MLDv2 and promote the opportunity to implement SSM in mobile communications.


This document assumes that both multicast routers and mobile hosts are IGMPv3/MLDv2 capable, regardless of whether the protocols are the full or lightweight version. This document does not consider interoperability with older protocol versions. One of the reasons for this lack of interoperability with older IGMP/MLD protocols is that the explicit tracking function does not work properly with older IGMP/MLD protocols because of a report-suppression mechanism; a host would not send a pending IGMP/MLD Report if a similar report was sent by another listener on the link.


7. Security Considerations
7. 安全考虑

This document neither provides new functions nor modifies the standard functions defined in [1], [2], and [4]. Therefore, no additional security considerations are provided.


8. Acknowledgements
8. 致谢

Luis M. Contreras, Marshall Eubanks, Gorry Fairhurst, Dirk von Hugo, Imed Romdhani, Behcet Sarikaya, Stig Venaas, Jinwei Xia, and others provided many constructive and insightful comments.


9. References
9. 工具书类
9.1. Normative References
9.1. 规范性引用文件

[1] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.

[1] Cain,B.,Deering,S.,Kouvelas,I.,Fenner,B.,和A.Thyagarajan,“互联网组管理协议,第3版”,RFC 3376,2002年10月。

[2] Vida, R., Ed., and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

[2] Vida,R.,Ed.,和L.Costa,Ed.,“IPv6的多播侦听器发现版本2(MLDv2)”,RFC 3810,2004年6月。

[3] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.

[3] Holbrook,H.和B.Cain,“IP的源特定多播”,RFC 4607,2006年8月。

[4] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, February 2010.

[4] Liu,H.,Cao,W.,和H.Asaeda,“轻量级Internet组管理协议版本3(IGMPv3)和多播侦听器发现版本2(MLDv2)协议”,RFC 57902010年2月。

9.2. Informative References
9.2. 资料性引用

[5] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, August 2006.

[5] Fenner,B.,He,H.,Haberman,B.,和H.Sandick,“基于Internet组管理协议(IGMP)/多播侦听器发现(MLD)的多播转发(“IGMP/MLD代理”)”,RFC 46052006年8月。

[6] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

[6] Gundavelli,S.,Ed.,Leung,K.,Devarapalli,V.,Chowdhury,K.,和B.Patil,“代理移动IPv6”,RFC 5213,2008年8月。

[7] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.

[7] Perkins,C.,Ed.,Johnson,D.,和J.Arkko,“IPv6中的移动支持”,RFC 62752011年7月。

[8] Asaeda, H. and N. Leymann, "IGMP/MLD-Based Explicit Membership Tracking Function for Multicast Routers", Work in Progress, April 2012.

[8] Asaeda,H.和N.Leymann,“基于IGMP/MLD的多播路由器显式成员跟踪功能”,正在进行的工作,2012年4月。

[9] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base Deployment for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) Domains", RFC 6224, April 2011.

[9] Schmidt,T.,Waehlisch,M.,和S.Krishnan,“代理移动IPv6(PMIPv6)域中支持多播侦听器的基本部署”,RFC 62242011年4月。

[10] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", RFC 5944, November 2010.

[10] Perkins,C.,编辑,“IPv4的IP移动支持,修订版”,RFC 59442010年11月。

Appendix A. Unicasting a General Query

This appendix describes the possible IGMP and MLD protocol extensions for further optimization in mobile and wireless environments. It might be beneficial to include the following considerations when a newer version or modification of IGMP and MLD protocols is considered in the future.


IGMPv3 and MLDv2 specifications [1] [2] explain that a host must accept and process any query whose IP Destination Address field contains any of the addresses (unicast or multicast) assigned to the interface on which the query arrives. In general, the all-hosts multicast address ( or link-scope all-nodes multicast address (ff02::1) is used as the IP destination address of an IGMP/ MLD General Query. On the other hand, according to [1] and [2], a router may be able to unicast a General Query to the tracked member hosts in [Query Interval], if the router keeps track of membership information (Section 3).

IGMPv3和MLDv2规范[1][2]说明,主机必须接受并处理其IP目标地址字段包含分配给查询到达接口的任何地址(单播或多播)的任何查询。通常,所有主机多播地址(或链路作用域所有节点多播地址(ff02::1)用作IGMP/MLD常规查询的IP目标地址。另一方面,根据[1]和[2],如果路由器跟踪成员信息(第3节),则路由器可以在[Query Interval]中将一般查询单播到被跟踪的成员主机。

Unicasting an IGMP/MLD General Query would reduce the drain on the battery power of mobile hosts, as only the active hosts that have been receiving multicast contents respond to the unicast IGMP/MLD General Query messages and non-active hosts do not need to pay attention to the IGMP/MLD Query messages. This also allows the upstream router to proceed with fast leaves (or shorten leave latency) by setting LMQC/LLQC smaller because, ideally, the router can immediately converge and update the membership information.


However, there is a concern regarding the unicast General Query: if a multicast router sends a General Query "only" by unicast, it cannot discover potential member hosts whose join requests were lost. Since the hosts do not retransmit the same join requests (i.e., unsolicited Report messages), they lose the chance to join the channels unless the upstream router asks for membership information by sending a multicast General Query. This concern will be solved by using both unicast and multicast General Queries and configuring the [Query Interval] timer value for multicast General Query and the [Unicast Query Interval] timer value for unicast General Query. However, using two different timers for General Queries would require a protocol extension that is beyond the scope of this document. If a router does not distinguish multicast and unicast General Query Intervals, the router should only use and enable multicast General Queries.

然而,对于单播通用查询存在一个问题:如果多播路由器“仅”通过单播发送通用查询,则它无法发现其加入请求丢失的潜在成员主机。由于主机不重新传输相同的加入请求(即,未经请求的报告消息),因此它们失去了加入通道的机会,除非上游路由器通过发送多播一般查询来请求成员信息。通过使用单播和多播常规查询并配置多播常规查询的[Query Interval]计时器值和单播常规查询的[unicast Query Interval]计时器值,可以解决此问题。但是,在常规查询中使用两个不同的计时器将需要协议扩展,这超出了本文档的范围。如果路由器不区分多播和单播常规查询间隔,则路由器应仅使用并启用多播常规查询。

Also, the unicast General Query does not remove the need for the multicast General Query. The multicast General Query is necessary for updating membership information if the information is not correctly synchronized due to missing reports. Therefore, the


unicast General Query should not be used for an implementation that does not allow the configuration of different query interval timers such as [Query Interval] and [Unicast Query Interval]. If a router does not distinguish these multicast and unicast General Query Intervals, the router should only use and enable multicast General Queries.

单播常规查询不应用于不允许配置不同查询间隔计时器(如[Query interval]和[unicast Query interval])的实现。如果路由器不区分这些多播和单播常规查询间隔,则路由器应仅使用并启用多播常规查询。

Authors' Addresses


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



Hui Liu Huawei Technologies Co., Ltd. Building Q14, No. 156, Beiqing Rd. Beijing 100095 China



Qin Wu Huawei Technologies Co., Ltd. 101 Software Avenue Yuhua District Nanjing, Jiangsu 210012 China