Internet Engineering Task Force (IETF) H. Asaeda
Request for Comments: 6636 Keio University
Category: Informational H. Liu
ISSN: 2070-1721 Q. Wu
Huawei
May 2012
Internet Engineering Task Force (IETF) H. Asaeda
Request for Comments: 6636 Keio University
Category: Informational H. Liu
ISSN: 2070-1721 Q. Wu
Huawei
May 2012
Tuning the Behavior of the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) for Routers in Mobile and Wireless Networks
调整移动和无线网络中路由器的Internet组管理协议（IGMP）和多播侦听器发现（MLD）的行为
Abstract
摘要
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.
Internet组管理协议（IGMP）和多播侦听器发现（MLD）是主机和多播路由器用来相互交换IP多播组成员身份的协议。本文档描述了为移动性实现IGMPv3和MLDv2协议优化的方法，旨在成为调整IGMPv3/MLDv2查询、计时器和计数器值的指南。
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 http://www.rfc-editor.org/info/rfc6636.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6636.
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 (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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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
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
IPv4的Internet组管理协议（IGMP）[1]和IPv6的多播侦听器发现（MLD）[2]协议是主机启动加入或退出多播会话的标准协议。这些协议还必须得到多播路由器或IGMP/MLD代理[5]的支持，这些代理在其下游接口上维护多播成员信息。从概念上讲，IGMP和MLD可以在无线和移动网络上工作。然而，无线接入技术在有限频谱和带宽的共享介质或点对点链路上运行。在许多无线网络中
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.
当IGMP和MLD与移动IP协议一起使用时，应考虑网络实体的邻近性。例如，当双向隧道与[6]和[7]中描述的移动实体一起使用时，移动主机经历额外的延迟，因为与主机和上游路由器连接到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.
本文档描述了在多播路由器和代理端调优IGMPv3和MLDv2协议行为的方法，特别关注无线和移动网络，包括查询和相关计时器的调优。这种选择性优化通过跟踪下游主机的成员状态以及各种IGMP/MLD查询类型和值，从而适当地调整响应消息的数量，从而为移动主机和路由器提供切实的好处。本文档不对IGMPv3和MLDv2协议进行任何更改，仅建议在移动和无线环境中对协议的可配置参数进行最佳设置。
In this document, "router" means both a multicast router and an IGMP/ MLD proxy.
在本文件中，“路由器”指多播路由器和IGMP/MLD代理。
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.
移动主机使用IGMP和MLD请求加入或退出多播会话。当相邻的上游路由器接收到IGMP/MLD报告消息时，它识别链路上的成员身份状态。为了可靠地更新成员身份，路由器定期发送IGMP/MLD查询消息，并在成员主机报告其离开时发送特定于组和/或特定于组和源的查询。因此，IGMP/MLD查询对于获取最新的成员信息是必要的，但从所有成员主机发送的大量回复消息可能会导致网络拥塞或消耗网络带宽。
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.
“显式跟踪功能”[8]是减少IGMP/MLD消息传输数量并提高移动通信效率的一种可能方法。它使路由器能够跟踪下游IGMPv3或MLDv2成员主机的成员状态。也就是说，如果路由器启用显式跟踪功能，它并不总是需要从接收方主机请求传输当前状态报告消息，因为路由器在接收到报告休假的状态更改报告消息时隐式识别（潜在）最后一个成员主机。因此，路由器只有在识别到最后一个成员已离开网络时，才能发送特定于IGMP/MLD组以及特定于组和源的查询LMQC/LLQC时间（见第4.3节）。这减少了当前状态报告消息的传输数量。
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.
启用显式跟踪功能对于移动多播是有利的，但是该功能需要额外的处理能力，并且可能需要路由器大量的内存来存储所有成员身份信息。这一资源需求可能会受到影响，特别是当路由器需要维护大量接收器主机时。因此，本文件建议相邻上游多播路由器在无线和移动网络上启用IP多播通信的显式跟踪功能（如果它们有足够的资源）。如果运营商认为他们的路由器没有足够的资源，他们可能会在路由器上禁用此功能。请注意，无论路由器是否启用显式跟踪功能，它们都需要通过发送IGMPv3/MLDv2通用查询消息来维护下游成员身份状态，因为一些IGMPv3/MLDv2消息可能在传输过程中丢失。
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.
本文件通过更改IGMP/MLD查询消息中查询者的查询间隔代码（QQIC）字段，提出150秒的[查询间隔]值，用于启用显式跟踪功能的路由器可能操作大量成员主机的情况，例如无线链路上的200多台主机。此较长的间隔值有助于最小化移动主机的报告消息流量和电池功耗。
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.
另一方面，本文件还建议，对于启用显式跟踪功能的路由器连接到更高容量的无线链路的情况，将[查询间隔]值设置为60到90秒。此较短的间隔有助于路由器跟踪的成员身份信息的快速同步，但可能会消耗移动主机上的电池电量。
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]值转发查询，并逐渐增加该值。
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.
较低的资源容量或有损链路，另一种情况是具有足够容量的无线链路或其条件对于IGMP/MLD消息传输足够可靠的无线链路。
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).
缩短IGMPv3的最后一个成员查询计时器（LMQT）和MLDv2的最后一个侦听器查询计时器（LLQT）有助于最小化离开延迟。LMQT由最后一个成员查询间隔（LMQI）乘以最后一个成员查询计数（LMQC）表示，LLQT由最后一个侦听器查询间隔（LLQI）乘以最后一个侦听器查询计数（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.
另一方面，如果网络运营商认为其无线链路有损（例如，由于大量连接的主机或有限的资源），他们可以将其路由器的LMQC和LLQC设置为“2”，以启用显式跟踪功能。虽然较大的LMQC和LLQC值可能会导致更长的离开延迟，但丢失最后一个成员的风险将降低。
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]是一个静态值，不能被任何外部信号更改。因此，维护路由器和无线链路的运营商需要正确配置此值。
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".
为了避免多播路由器遗漏未经请求的报告的可能性，未经请求的报告将以从定义范围[1][2]中随机选择的间隔重新传输（[鲁棒性变量]-1）次以上。IGMP/MLD查询中的QRV（查询器的稳健性变量）字段包含查询器使用的[稳健性变量]值。IGMPv3[1]和MLDv2[2]中定义的默认[稳健性变量]值为“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".
本文件建议当路由器连接到具有较低资源容量或大量主机的无线链路时，移动性的[鲁棒性变量]值为“2”。对于连接到已知可靠的更高容量无线链路的路由器，不需要重新传输相同的状态变化报告消息；因此，路由器将[稳健性变量]设置为“1”。
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.
在移动IP网络中，IGMP和MLD用于三种部署场景：（1）直接在无线网络上的主机和接入路由器之间运行，（2）通过隧道链路在主机和家庭路由器之间运行，以及（3）通过隧道链路在家庭路由器和外部路由器之间运行。
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
当接收器主机通过无线链路直接连接到外部接入路由器或家庭路由器时，IGMP/MLD协议参数的调整应与前一节中建议的相同
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.
部分。此场景的示例发生在PMIPv6[6]中，移动接入网关（其角色类似于外部路由器）充当多播路由器或代理时。
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报告之间的延迟来确定上述定时器和值。但是，描述如何动态调整这些计时器和值超出了本文档的范围。
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.
发送[1]和[2]中定义的IGMP/MLD特定于组以及特定于组和源的查询，以验证是否存在希望接收指定组或一组源的主机，或者为特定组或一组源重建所需的接收状态。这些特定查询构建并刷新连接网络上主机的多播成员状态。
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.
根据[1]和[2]中的定义，发送特定于组的查询时，IP目标地址等于感兴趣的多播地址。在此环境中，首选在特定查询中使用感兴趣的多播组，因为未加入多播会话的主机不关注这些特定查询，并且只有接收到具有指定地址的多播内容的活动成员主机才会回复IGMP/MLD报告。
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].
IGMPv3[1]和MLDv2[2]为主机提供了报告源特定订阅的能力。使用IGMPv3/MLDv2，移动主机可以在其加入请求中使用多播组和源地址来指定感兴趣的信道。接收后，支持IGMPv3/MLDv2的上游路由器建立指向源的最短路径树，而不协调共享树。此函数称为源过滤函数，是支持源特定多播（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.
最近，轻量级IGMPv3（LW-IGMPv3）和轻量级MLDv2（LW-MLDv2）[4]协议被定义为IETF中提出的标准协议。这些协议为移动主机和路由器提供了简单的协议，因为它们从IGMPv3和MLDv2的完整版本中消除了复杂的状态机，并促进了在移动通信中实现SSM的机会。
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.
本文档假设多播路由器和移动主机都支持IGMPv3/MLDv2，无论协议是完整版本还是轻量级版本。此文档不考虑与旧协议版本的互操作性。与旧的IGMP/MLD协议缺乏互操作性的原因之一是，由于报告抑制机制，显式跟踪功能不能与旧的IGMP/MLD协议正常工作；如果链接上的另一个侦听器发送了类似的报告，则主机不会发送挂起的IGMP/MLD报告。
This document neither provides new functions nor modifies the standard functions defined in [1], [2], and [4]. Therefore, no additional security considerations are provided.
本文件既不提供新功能，也不修改[1]、[2]和[4]中定义的标准功能。因此，不提供额外的安全注意事项。
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.
路易斯·孔特雷拉斯、马歇尔·尤班克斯、戈里·费尔赫斯特、德克·冯·雨果、伊德·隆达尼、贝塞特·萨里卡亚、斯蒂格·维纳斯、夏金伟和其他人提供了许多建设性和深刻的评论。
[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月。
[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月。
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.
本附录描述了可能的IGMP和MLD协议扩展，以进一步优化移动和无线环境。当将来考虑IGMP和MLD协议的更新版本或修改时，包括以下注意事项可能是有益的。
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 (224.0.0.1) 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目标地址字段包含分配给查询到达接口的任何地址（单播或多播）的任何查询。通常，所有主机多播地址（224.0.0.1）或链路作用域所有节点多播地址（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.
单播IGMP/MLD通用查询将减少移动主机的电池电量消耗，因为只有一直在接收多播内容的活动主机响应单播IGMP/MLD通用查询消息，而非活动主机不需要注意IGMP/MLD查询消息。这还允许上游路由器通过将LMQC/LLQC设置得更小来继续快速离开（或缩短离开延迟），因为理想情况下，路由器可以立即聚合并更新成员信息。
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
日本神奈川藤泽仁多5322浅田庆应大学媒体与治理研究生院252-0882
EMail: asaeda@wide.ad.jp
URI: http://www.sfc.wide.ad.jp/~asaeda/
EMail: asaeda@wide.ad.jp
URI: http://www.sfc.wide.ad.jp/~asaeda/
Hui Liu Huawei Technologies Co., Ltd. Building Q14, No. 156, Beiqing Rd. Beijing 100095 China
中国北京市北青路156号汇柳华为技术有限公司Q14号楼100095
EMail: helen.liu@huawei.com
EMail: helen.liu@huawei.com
Qin Wu Huawei Technologies Co., Ltd. 101 Software Avenue Yuhua District Nanjing, Jiangsu 210012 China
中国江苏省南京市雨花区软件大道101号秦武华为技术有限公司210012
EMail: bill.wu@huawei.com
EMail: bill.wu@huawei.com