<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<!--<?rfc strict="yes" ?>-->
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="no"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-ietf-multimob-igmp-mld-tuning-05"
     ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)"
    RFC3978 -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters -->

    <title abbrev="Tuning the Behavior of IGMP and MLD">Tuning the Behavior of
    IGMP and MLD for Routers in Mobile and Wireless Networks</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author fullname="Hitoshi Asaeda" initials="H" surname="Asaeda">
      <organization>Keio University</organization>

      <address>
        <postal>
          <street>Graduate School of Media and Governance</street>

          <street>5322 Endo</street>

          <city>Fujisawa</city>

          <region>Kanagawa</region>

          <code>252-0882</code>

          <country>Japan</country>
        </postal>

        <email>asaeda@wide.ad.jp</email>

        <uri>http://www.sfc.wide.ad.jp/~asaeda/</uri>
      </address>
    </author>

    <author fullname="Hui Liu" initials="H" surname="Liu">
      <organization abbrev="Huawei">Huawei Technologies Co.,
      Ltd.</organization>

      <address>
        <postal>
          <street>Huawei Bld., No.3 Xinxi Rd.</street>

          <street>Shang-Di Information Industry Base</street>

          <city>Hai-Dian Distinct</city>

          <region>Beijing</region>

          <code>100085</code>

          <country>China</country>
        </postal>

        <email>helen.liu@huawei.com</email>
      </address>
    </author>

    <author fullname="Qin Wu" initials="Q" surname="Wu">
      <organization abbrev="Huawei">Huawei Technologies Co.,
      Ltd.</organization>

      <address>
        <postal>
          <street>Site B, Floor 12F, Huihong Mansion</street>

          <street>No.91 Baixia Rd.</street>

          <city>Nanjing</city>

          <region>Jiangsu</region>

          <code>21001</code>

          <country>China</country>
        </postal>

        <email>bill.wu@huawei.com</email>
      </address>
    </author>

    <date year="2012" />

    <area>Internet</area>

    <workgroup>MULTIMOB Working Group</workgroup>

    <abstract>
      <t>IGMP and MLD are the protocols used by hosts and multicast routers to
      exchange their IP multicast group memberships with each other. This
      document describes the ways of IGMPv3 and MLDv2 protocol optimization
      for mobility, and aims to become a guideline for tuning of IGMPv3/MLDv2
      Queries and timer and counter values.</t>
    </abstract>
  </front>

  <middle>
    <!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->

    <section anchor="sec.intro" title="Introduction">
      <t>The Internet Group Management Protocol <xref
      target="refs.IGMPv3">(IGMP)</xref> for IPv4 and the Multicast Listener
      Discovery Protocol <xref target="refs.MLDv2">(MLD)</xref> for IPv6 are
      the standard protocols for hosts to initiate joining or leaving of
      multicast sessions. These protocols must be also supported by multicast
      routers or <xref target="refs.Proxy">IGMP/MLD proxies</xref> 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 a multicast service initiation
      and termination in the new or previous network upon its movement. 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 leaving the group in the previous network may waste network
      resources.</t>

      <t>When IGMP and MLD are used with mobile IP protocols, the proximity of
      network entities should be considered. For example, when bi-directional
      tunnel is used with the mobility entities described in <xref
      target="refs.PMIPv6"></xref><xref target="refs.MIPv6"></xref>, the
      mobile host experiences additional latency, because the round-trip time
      using bi-directional tunnel between mobility entities is larger
      comparing to the case that a host and an upstream router attach to a
      LAN.</t>

      <t>This document describes the ways of tuning the IGMPv3 and MLDv2
      protocol behavior on multicast router and proxy side for wireless and
      mobile networks, including query and related timers tuning. The
      selective optimization that provides tangible benefits to the mobile
      hosts and routers is given by keeping track of downstream hosts'
      membership status and varying IGMP/MLD Query types and values to tune
      the number of responses. The proposed behavior interoperates with the
      IGMPv3 and MLDv2 protocols.</t>
    </section>

    <!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->

    <section title="Terminology">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref
      target="refs.KEYWORDS">RFC 2119</xref>.</t>

      <t>In this document, "router" means both multicast router and IGMP/MLD
      proxy.</t>
    </section>

    <!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->

    <section anchor="sec.track" title="Explicit Tracking of Membership Status">
      <t>Mobile hosts use IGMP and MLD to 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. IGMP/MLD Query is
      therefore necessary to obtain the 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.</t>

      <t>The "explicit tracking function" <xref target="refs.explicit"></xref>
      is the 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 ask
      Current-State Report message's transmission from the receiver hosts
      since the router implicitly recognizes the (potential) last member host
      when it receives the State-Change Report reporting a leave. The router
      can therefore send IGMP/MLD Group-Specific and Group-and-Source Specific
      Queries LMQC/LLQC times (see <xref target="sec.llqt"></xref> for
      LMQC/LLQC) only when it recognizes the last member has left from the
      network. This reduces the transmitted number of Current-State Report
      messages.</t>

      <t>Enabling the explicit tracking function is advantageous for mobile
      multicast, but the function requires additional processing capability
      and possibly a large memory for routers to keep all membership status.
      Especially when a router needs to maintain a large number of receiver
      hosts, this resource requirement is potentially impacted. Therefore, in
      this document it is recommended 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 routers
      enable the explicit tracking function or not, they need to maintain
      downstream membership status by sending IGMPv3/MLDv2 General Query
      messages as some IGMPv3/MLDv2 messages MAY be lost during
      transmission.</t>
    </section>

    <!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->

    <section anchor="sec.query" title="Tuning IGMP/MLD Timers and Values">
      <!-- ============================================================ -->

      <section anchor="sec.genquery"
               title="Tuning IGMP/MLD General Query Interval">
        <t>IGMP and MLD are non-reliable 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]) <xref
        target="refs.IGMPv3"></xref><xref target="refs.MLDv2"></xref>.
        Although this behavior increases the protocol robustness, it does not
        guarantee that the State-Change Report reaches the routers. Therefore,
        routers still need to refresh the downstream membership information by
        receiving Current-State Report periodically solicited by 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. It
        also supports the situation that mobile hosts turn off or move from a
        network to other network managed by a different router without any
        notification (e.g., leave request).</t>

        <t>The [Query Interval] is the interval between General Queries sent
        by the regular IGMPv3/MLDv2 querier, and the default value is 125
        seconds <xref target="refs.IGMPv3"></xref><xref
        target="refs.MLDv2"></xref>. 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.</t>

        <t>This document proposes 150 seconds for the [Query Interval] value
        by changing the Querier's Query Interval Code (QQIC) field specified
        in the IGMP/MLD Query message, for the case that a router enabling 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 traffic of Report messages and battery power consumption
        for mobile hosts.</t>

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

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

        <t>In situations where <xref target="refs.MIPv6">Mobile IPv6</xref> 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 slow down Query periodicity. It 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.</t>
      </section>

      <!-- ============================================================ -->

      <section anchor="sec.queryresp"
               title="Tuning IGMP/MLD Query Response Interval">
        <t>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 by
        "Max Resp Code=100" for IGMPv3 <xref target="refs.IGMPv3"></xref> and
        "Maximum Response Code=10000" for MLDv2 <xref
        target="refs.MLDv2"></xref>. 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 host's
        responses are spread out over a larger interval, but will increase
        join latency when State-Change Report (i.e., join request) is
        missing.</t>

        <t>According to our experimental analysis, this document proposes two
        tuning scenarios for tuning the [Query Response Interval] value in
        different wireless link conditions; one scenario is for a wireless
        link with a lower capacity of network resource or a lossy link, and
        the other scenario is for a wireless link with enough capacity or
        reliable condition for IGMP/MLD message transmission.</t>

        <t>Regarding the first scenario, for instance, when a multicast router
        attaches to a bursty IEEE 802.11b link, the router configures the
        longer [Query Response Interval] value, such as 10 to 20 (sec). 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 Record) are lost on the
        router.</t>

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

      <!-- ============================================================ -->

      <section anchor="sec.llqt"
               title="Tuning Last Member Query Timer (LMQT) and Last Listener Query Timer (LLQT)">
        <t>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).</t>

        <t>While LMQI and LLQI are changeable, it is reasonable to use the
        default values (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 MAY be set
        to "1" for routers enabling 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 SHOULD be
        set to 1 only when network operators think that their wireless link is
        stable enough.</t>

        <!-- XXX by Clair: whose values defer by the [Robustness Variable] value -->

        <t>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 MAY set LMQC and LLQC to "2" for their
        routers enabling 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.</t>
      </section>

      <!-- ============================================================ -->

      <section anchor="sec.startup" title="Tuning Startup Query Interval">
        <t>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, in this document it is RECOMMENDED that the
        use of its shortened value such as 1 second since the shorter value
        would contribute to shortening handover delay for mobile hosts in,
        e.g., the base solution with PMIPv6 <xref target="refs.base"></xref>.
        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 MUST properly configure this value.</t>
      </section>

      <!-- ============================================================ -->

      <section anchor="sec.robvar" title="Tuning Robustness Variable">
        <t>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 <xref target="refs.IGMPv3"></xref><xref
        target="refs.MLDv2"></xref>. The QRV (Querier's Robustness Variable)
        field in IGMP/MLD Query contains the [Robustness Variable] value used
        by the querier. The default [Robustness Variable] value defined in
        <xref target="refs.IGMPv3">IGMPv3</xref> and <xref
        target="refs.MLDv2">MLDv2</xref> is "2".</t>

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

      <!-- ============================================================ -->

      <section anchor="sec.mobility"
               title="Tuning Scenarios for Various Mobile IP Networks">
        <t>In mobile IP networks, IGMP and MLD are used either with three
        deployment scenarios; (1) running directly between host and access
        router on a wireless network, (2) running between host and home router
        through a tunnel link, and (3) running between home router and foreign
        router through a tunnel link.</t>

        <t>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 <xref target="refs.PMIPv6">Proxy Mobile IPv6 (PMIPv6)</xref>, the mobile access gateway, whose
        role is similar to a foreign router, acts as a multicast router or proxy.</t>

        <t>The second scenario occurs when bi-directional tunnel established
        between host and home router is used to exchange IGMP/MLD messages
        such as in <xref target="refs.MIPv6"></xref><xref
        target="refs.MIP"></xref>. There are difficulties in tuning the
        parameters in this situation, because the tunnel link condition 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 the
        IGMP/MLD message transmission through a tunnel link SHOULD be
        considered during the parameter setting. For example, the [Query
        Interval] and [Query Response Interval] could be set shorter to
        compensate the transmission delay, and the [Robustness Variable] could
        be increased for possible packet loss.</t>

        <t>The third scenario occurs in <xref target="refs.base"></xref>, in
        which the mobile access gateway (i.e., foreign router) acts as the
        IGMP/MLD Proxy <xref target="refs.Proxy"></xref> in PMIPv6 <xref
        target="refs.PMIPv6"></xref>. Through the bi-directional 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
        that influences the parameter setting, the [Query Response Interval]
        on the local mobility anchor could be set to a smaller value because
        the number of the mobile access gateways is much smaller compared to
        that of the host and the chances of packet burst is low for the same
        reason. And the power consumption due to a lower query interval is not
        an issue for the moble access gateways because the mobile access
        gateways are usually not battery-powered.</t>

        <t>Ideally, the IGMP/MLD querier router adjusts its parameter setting
        according to the actual mobile IP network conditions to benefit
        service performance and resource utilization. It would be desirable
        that a home router determines aforementioned timers and values
        according to the delay between the initiating IGMP/MLD Query and the
        responding IGMP/MLD Report, while describing such mechanism
        dynamically adjusting these timers and values is out of scope of this
        document.</t>
      </section>
    </section>

    <!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->

    <section anchor="sec.specificquery"
             title="Destination Address of Specific Query">
      <t>IGMP/MLD Group-Specific and Group-and-Source Specific Queries defined
      in <xref target="refs.IGMPv3"></xref><xref target="refs.MLDv2"></xref>
      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 multicast membership state of hosts on an attached
      network. These specific Queries SHOULD be sent to all desired hosts with
      specific multicast address (not the all-hosts/all-nodes multicast
      address) as their IP destination addresses, 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 IGMP/MLD reports.</t>
    </section>

    <!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->

    <section anchor="sec.interop" title="Interoperability">
      <t>IGMPv3 <xref target="refs.IGMPv3"></xref> and MLDv2 <xref
      target="refs.MLDv2"></xref> 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 <xref
      target="refs.SSM">Source-Specific Multicast (SSM)</xref>.</t>

      <t>Recently, the Lightweight-IGMPv3 (LW-IGMPv3) and Lightweight-MLDv2
      (LW-MLDv2) <xref target="refs.LW"></xref> 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.</t>

      <t>This document assumes that both multicast routers and mobile hosts
      MUST be IGMPv3/MLDv2 capable, regardless whether the protocols are the
      full or lightweight version. And this document does not consider
      interoperability with older version protocols. One of the reasons not being
      interoperable 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.</t>
    </section>

    <!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->

    <section title="IANA Considerations">
      <t>This document has no actions for IANA.</t>
    </section>

    <section title="Security Considerations">
      <t>This document neither provides new functions or modifies the standard
      functions defined in <xref target="refs.IGMPv3"></xref><xref
      target="refs.MLDv2"></xref><xref target="refs.LW"></xref>. Therefore
      there is no additional security consideration provided.</t>
    </section>

    <!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->

    <section title="Acknowledgements">
      <t>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.</t>
    </section>

    <!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
  </middle>

  <back>
    <references title="Normative References">
      <reference anchor="refs.KEYWORDS">
        <front>
          <title abbrev="RFC Key Words">Key words for use in RFCs to Indicate
          Requirement Levels</title>

          <author fullname="Scott Bradner" initials="S." surname="Bradner">
            <organization>Harvard University</organization>

            <address>
              <postal>
                <street>1350 Mass. Ave.</street>

                <street>Cambridge</street>

                <street>MA 02138</street>
              </postal>

              <phone>- +1 617 495 3864</phone>

              <email>sob@harvard.edu</email>
            </address>
          </author>

          <date month="March" year="1997" />

          <area>General</area>

          <keyword>keyword</keyword>

          <abstract>
            <t>In many standards track documents several words are used to
            signify the requirements in the specification. These words are
            often capitalized. This document defines these words as they
            should be interpreted in IETF documents. Authors who follow these
            guidelines should incorporate this phrase near the beginning of
            their document: <list>
                <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
                "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
                "OPTIONAL" in this document are to be interpreted as described
                in RFC 2119.</t>
              </list></t>

            <t>Note that the force of these words is modified by the
            requirement level of the document in which they are used.</t>
          </abstract>
        </front>
      </reference>

      <reference anchor="refs.IGMPv3">
        <front>
          <title>Internet Group Management Protocol, Version 3</title>

          <author initials="B" surname="Cain"></author>

          <author initials="S" surname="Deering"></author>

          <author initials="I" surname="Kouvelas"></author>

          <author initials="B" surname="Fenner"></author>

          <author initials="A" surname="Thyagarajan"></author>

          <date month="October" year="2002" />
        </front>

        <seriesInfo name="RFC" value="3376" />
      </reference>

      <reference anchor="refs.MLDv2">
        <front>
          <title>Multicast Listener Discovery Version 2 (MLDv2) for
          IPv6</title>

          <author initials="R" surname="Vida"></author>

          <author initials="L" surname="Costa"></author>

          <date month="June" year="2004" />
        </front>

        <seriesInfo name="RFC" value="3810" />
      </reference>

      <reference anchor="refs.LW">
        <front>
          <title>Lightweight Internet Group Management Protocol Version 3
          (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2)
          Protocols</title>

          <author initials="H" surname="Liu"></author>

          <author initials="W" surname="Cao"></author>

          <author initials="H" surname="Asaeda"></author>

          <date month="February" year="2010" />
        </front>

        <seriesInfo name="RFC" value="5790" />
      </reference>

      <reference anchor="refs.SSM">
        <front>
          <title>Source-Specific Multicast for IP</title>

          <author initials="H" surname="Holbrook"></author>

          <author initials="B" surname="Cain"></author>

          <date month="August" year="2006" />
        </front>

        <seriesInfo name="RFC" value="4607" />
      </reference>
    </references>

    <references title="Informative References">
      <reference anchor="refs.explicit">
        <front>
          <title>IGMP/MLD-Based Explicit Membership Tracking Function for
          Multicast Routers</title>

          <author initials="H" surname="Asaeda"></author>

          <author initials="N" surname="Leymann"></author>

          <date month="October" year="2011" />
        </front>

        <seriesInfo name="draft-ietf-pim-explicit-tracking-00.txt"
                    value="(work in progress)" />
      </reference>

      <reference anchor="refs.Proxy">
        <front>
          <title>Internet Group Management Protocol (IGMP) / Multicast
          Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD
          Proxying")</title>

          <author initials="B" surname="Fenner"></author>

          <author initials="H" surname="He"></author>

          <author initials="B" surname="Haberman"></author>

          <author initials="H" surname="Sandick"></author>

          <date month="August" year="2006" />
        </front>

        <seriesInfo name="RFC" value="4605" />
      </reference>

      <reference anchor="refs.PMIPv6">
        <front>
          <title>Proxy Mobile IPv6</title>

          <author initials="S, Ed." surname="Gundavelli"></author>

          <author initials="K" surname="Leung"></author>

          <author initials="V" surname="Devarapalli"></author>

          <author initials="K" surname="Chowdhury"></author>

          <author initials="B" surname="Patil"></author>

          <date month="August" year="2008" />
        </front>

        <seriesInfo name="RFC" value="5213" />
      </reference>

      <reference anchor="refs.base">
        <front>
          <title>Base Deployment for Multicast Listener Support in Proxy
          Mobile IPv6 (PMIPv6) Domains</title>

          <author initials="T" surname="Schmidt"></author>

          <author initials="M" surname="Waehlisch"></author>

          <author initials="S" surname="Krishnan"></author>

          <date month="April" year="2011" />
        </front>

        <seriesInfo name="RFC" value="6224" />
      </reference>

      <reference anchor="refs.MIPv6">
        <front>
          <title>Mobility Support in IPv6</title>

          <author initials="D" surname="Johnson"></author>

          <author initials="C" surname="Perkins"></author>

          <author initials="J" surname="Arkko"></author>

          <date month="July" year="2011" />
        </front>

        <seriesInfo name="RFC" value="6275" />
      </reference>

      <reference anchor="refs.MIP">
        <front>
          <title>IP Mobility Support for IPv4, Revised</title>

          <author initials="C" surname="Perkins, Ed."></author>

          <date month="November" year="2010" />
        </front>

        <seriesInfo name="RFC" value="5944" />
      </reference>
    </references>

    <!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->

    <section anchor="sec.uniquery" title="Unicasting General Query">
      <t>IGMPv3 and MLDv2 specifications <xref
      target="refs.IGMPv3"></xref><xref target="refs.MLDv2"></xref> describe
      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
      IGMP/MLD General Query. On the other hand, according to <xref
      target="refs.IGMPv3"></xref><xref target="refs.MLDv2"></xref>, a router
      MAY be able to unicast General Query to the tracked member hosts in
      [Query Interval], if the router keeps track of membership information
      (<xref target="sec.track"></xref>).</t>

      <t>Unicasting IGMP/MLD General Query would reduce the drain on battery
      power of mobile hosts as only the active hosts that have been receiving
      multicast contents respond 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 fast leaves
      (or shorten leave latency) by setting LMQC/LLQC smaller, because the
      router can immediately converge and update the membership information,
      ideally.</t>

      <t>However, there is a concern in unicast General Query. If a multicast
      router sends 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 the membership information by sending General Query by
      multicast. It 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 the protocol extension this document does not focus on. If
      a router does not distinguish the multicast and unicast General Query
      Intervals, the router SHOULD only use and enable multicast General
      Query.</t>

      <t>Also, unicasting General Query does not remove multicasting General
      Query. Multicast General Query is necessary to update membership
      information if it is not correctly synchronized due to missing Reports.
      Therefore, enabling unicast General Query SHOULD NOT be used for the
      implementation that does not allow to configure different query interval
      timers 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
      Query.</t>
    </section>

    <!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
  </back>
</rfc>
