doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc6636.txt b/doc/rfc/rfc6636.txt
new file mode 100644
index 0000000..6376539
--- /dev/null
+++ b/doc/rfc/rfc6636.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+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
+
+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.
+
+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.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Asaeda, et al.                Informational                     [Page 1]
+
+RFC 6636           Tuning the Behavior of IGMP and MLD          May 2012
+
+
+Copyright Notice
+
+   Copyright (c) 2012 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   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.
+
+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
+
+   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
+
+
+
+Asaeda, et al.                Informational                     [Page 2]
+
+RFC 6636           Tuning the Behavior of IGMP and MLD          May 2012
+
+
+   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
+
+   In this document, "router" means both a multicast router and an IGMP/
+   MLD proxy.
+
+3.  Explicit Tracking of Membership Status
+
+   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.
+
+
+
+Asaeda, et al.                Informational                     [Page 3]
+
+RFC 6636           Tuning the Behavior of IGMP and MLD          May 2012
+
+
+   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.1.  Tuning the IGMP/MLD General Query Interval
+
+   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).
+
+
+
+
+Asaeda, et al.                Informational                     [Page 4]
+
+RFC 6636           Tuning the Behavior of IGMP and MLD          May 2012
+
+
+   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.
+
+   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.
+
+   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.
+
+4.2.  Tuning the IGMP/MLD Query Response 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.
+
+   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
+
+
+
+Asaeda, et al.                Informational                     [Page 5]
+
+RFC 6636           Tuning the Behavior of IGMP and MLD          May 2012
+
+
+   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".
+
+   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.
+
+4.3.  Tuning the Last Member Query Timer (LMQT) and Last Listener Query
+      Timer (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.
+
+
+
+
+
+
+Asaeda, et al.                Informational                     [Page 6]
+
+RFC 6636           Tuning the Behavior of IGMP and MLD          May 2012
+
+
+   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
+
+   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.
+
+4.5.  Tuning the Robustness Variable
+
+   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
+
+   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
+
+
+
+
+
+Asaeda, et al.                Informational                     [Page 7]
+
+RFC 6636           Tuning the Behavior of IGMP and MLD          May 2012
+
+
+   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.
+
+   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.
+
+   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.
+
+5.  Destination Address of a Specific Query
+
+   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.
+
+
+
+
+Asaeda, et al.                Informational                     [Page 8]
+
+RFC 6636           Tuning the Behavior of IGMP and MLD          May 2012
+
+
+   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
+
+   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
+
+   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
+
+   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.
+
+
+
+
+Asaeda, et al.                Informational                     [Page 9]
+
+RFC 6636           Tuning the Behavior of IGMP and MLD          May 2012
+
+
+9.  References
+
+9.1.  Normative References
+
+   [1]   Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
+         Thyagarajan, "Internet Group Management Protocol, Version 3",
+         RFC 3376, October 2002.
+
+   [2]   Vida, R., Ed., and L. Costa, Ed., "Multicast Listener Discovery
+         Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
+
+   [3]   Holbrook, H. and B. Cain, "Source-Specific Multicast for IP",
+         RFC 4607, August 2006.
+
+   [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.
+
+9.2.  Informative References
+
+   [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.
+
+   [6]   Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K.,
+         and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
+
+   [7]   Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support
+         in IPv6", RFC 6275, July 2011.
+
+   [8]   Asaeda, H. and N. Leymann, "IGMP/MLD-Based Explicit Membership
+         Tracking Function for Multicast Routers", Work in Progress,
+         April 2012.
+
+   [9]   Schmidt, T., Waehlisch, M., and S. Krishnan, "Base Deployment
+         for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6)
+         Domains", RFC 6224, April 2011.
+
+   [10]  Perkins, C., Ed., "IP Mobility Support for IPv4, Revised",
+         RFC 5944, November 2010.
+
+
+
+
+
+
+
+
+
+Asaeda, et al.                Informational                    [Page 10]
+
+RFC 6636           Tuning the Behavior of IGMP and MLD          May 2012
+
+
+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 (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).
+
+   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.
+
+   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
+
+
+
+Asaeda, et al.                Informational                    [Page 11]
+
+RFC 6636           Tuning the Behavior of IGMP and MLD          May 2012
+
+
+   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.
+
+Authors' Addresses
+
+   Hitoshi Asaeda
+   Keio University
+   Graduate School of Media and Governance
+   5322 Endo
+   Fujisawa, Kanagawa  252-0882
+   Japan
+
+   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
+
+   EMail: helen.liu@huawei.com
+
+
+   Qin Wu
+   Huawei Technologies Co., Ltd.
+   101 Software Avenue
+   Yuhua District
+   Nanjing, Jiangsu  210012
+   China
+
+   EMail: bill.wu@huawei.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Asaeda, et al.                Informational                    [Page 12]
+