<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-liu-multimob-igmp-mld-wireless-mobile-04"
     ipr="trust200902">
  <front>
    <title abbrev="IGMP/MLD in wireless/mobile network">IGMP/MLD Optimizations
    in Wireless and Mobile Networks</title>

    <author fullname="Hui Liu" initials="H." surname="Liu">
      <organization></organization>

      <address>
        <postal>
          <street></street>

          <city></city>

          <code></code>

          <country></country>
        </postal>

        <email>liu_helen@126.com</email>
      </address>
    </author>

    <author fullname="Mike McBride" initials="M." surname="McBride">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>2330 Central Expressway</street>

          <city>Santa Clara</city>

          <code>CA 95050</code>

          <country>USA</country>
        </postal>

        <email>michael.mcbride@huawei.com</email>
      </address>
    </author>
    
  <author fullname="Hitoshi Asaeda" initials="H" surname="Asaeda">
      <organization abbrev="NICT">National Institute of Information and Communications Technology (NICT)</organization>
      <address>
	<postal>
	  <street>Network Architecture Laboratory</street>	  
	  <street>4-2-1 Nukui-Kitamachi</street>
	  <city>Koganei</city> <region>Tokyo</region>
	  <code>184-8795</code>
	  <country>Japan</country>
	</postal>
	<email>asaeda@nict.go.jp</email>
      </address>
    </author>

    <date day="7" month="July" year="2013"/>

    <area>Internet Area</area>

    <workgroup>Multimob Working Group</workgroup>

    <abstract>
      <t>This document proposes a variety of optimization approaches for IGMP
      and MLD in wireless and mobile networks. It aims to provide useful
      guidelines to allow efficient multicast communication in these networks
      using IGMP or MLD protocols.</t>
    </abstract>

    <note title="Requirements Language">
      <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 [RFC2119].</t>
    </note>
  </front>

  <middle>
    <section anchor="Intro" title="Introduction">
      <t>The deployments of various wireless access techniques are being combined with
      the use of video and other applications which rely upon IP Multicast. Wireless and mobile 
      multicast are attracting increasing interest from content and service providers. Multicast faces 
      challenges with dynamic group membership management being under the constant update of
      delivery paths introduced by node movement. There is a high probability of loss
      and congestion due to limited reliability and capacity of wireless links.</t>

      <t>Multicast networks are generally constructed by the IGMP and MLD group
      management protocols (respectively for IPv4 and IPv6 networks) to track
      valid receivers and by multicast routing protocol building multicast
      delivery paths. This document focuses only on IGMP and MLD, the
      protocols used by a host to subscribe to a multicast group and the protocols that are most likely to
      be exposed to wireless links when supporting terminal mobility. As IGMP and
      MLD were designed for fixed users on a wired link, they do not
      necessarily work well for different wireless link types and mobile
      scenarios. IGMP/MLD should be enhanced to be more
      applicable in these mobile/wireless environments.</t>

      <t>This memo proposes a variety of optimizations for IGMP and MLD, in
      wireless and mobile networks, to improve network performance, with
      minimum changes on the protocol behavior and without introducing
      interoperability issues. These solutions can also be applied in wired
      networks when efficiency or reliability is required.</t>

      <t>For generality, this memo does not put limitations on the type of
      wireless techniques running below IGMP or MLD. They could be cellular,
      WiMAX, WiFi and etc, and are modeled as different abstract link models
      as described in section 2.2. Even though some of them (such as WiFi)
      have multicast limitations, it is probable that IGMP/MLD is enabled on
      the wireless terminal and multicast is supported across the network. The
      mobile IP protocol adopted on the core side, upstream from the access
      router, could be PMIP, MIPv4, or MIPv6.</t>
    </section>

    <section title="Requirements">
      <section title="Characteristics of Wireless and Mobile Multicast">
        <t>Several limitations should be considered when supporting IP
        multicast in wireless and mobile networks, including:</t>

        <t>O Limited link bandwidth: wireless links usually have limited
        bandwidth, and the situation will be made even worse if a high volume of
        video multicast data has to be carried. Additionally, the bandwidth available
        in the upstream and downstream directions may be asymmetrical.</t>

        <t>O High loss rate: wireless links usually have packet loss ranging
        from 1% to 30% according to different links types and conditions. Also
        when packets have to travel between home and access networks (e.g.
        through a tunnel), they are prone to loss if the two networks are
        distant from each other.</t>

        <t>O Frequent membership change: in fixed multicast, membership change
        only happens when a user leaves or joins a group, while in mobile
        scenario membership may also change when a user changes its
        location.</t>

        <t>O Prone to performance degradation: the possible increased
        interaction of protocols across layers for mobility management, and
        the limitation of link capacity, may lead to network performance
        degradation and even to complete connection loss.</t>

        <t>O Increased Leave Latency: the leave latency in mobile multicast
        might be increased due to user movement, especially if the traffic has
        to be transmitted between access and home networks, or if there is a
        handshake between networks.</t>
      </section>

      <section title="Wireless Link Model">
        <t>Wireless links can typically be categorized into three models: point-to-point (PTP), point-to-
        multipoint (PTMP), and broadcast link models.</t>

        <t>In the PTP model, one link is dedicated for two communication
        facilities. For multicast transmission, each PTP link normally has
        only one receiver and the bandwidth is dedicated for that receiver.
        Such link model may be implemented by running PPP on the link or
        having separate VLAN assignment for each receiver. In a mobile network,
        a tunnel between entities of home and foreign networks should be
        recognized as a PTP link.</t>

        <t>PTMP is the model for multipoint transmission wherein there is one
        centralized transmitter and multiple distributed receivers. PTMP
        provides common downlink channels for all receivers and dedicated
        uplink channel for each receiver. Bandwidth downstream is shared by
        all receivers on the same link.</t>

        <t>Broadcast links can connect two or more nodes and support broadcast
        transmissions. It is quite similar to fixed Ethernet link model and its
        link resource is shared in both uplink and downlink directions.</t>
      </section>

      <section title="Requirements on IGMP and MLD">
        <t>IGMP and MLD are usually run between mobile or wireless terminals
        and their first-hop access routers (i.e. home or foreign routers) to
        subscribe to a IP multicast channel. Currently the version in-use
        includes IGMPv2 [RFC2236] and its IPv6 counterpart MLDv1 [RFC2710],
        IGMPv3 [RFC3376] and its IPv6 counterpart MLDv2 [RFC3810], and LW-
        IGMPv3/MLDv2 [RFC5790]. All these versions have basic group management
        capability required by a multicast subscription. The differences lie
        in that IGMPv2 and MLDv1 can only join and leave a non-source-specific
        group, while IGMPv3 and MLDv2 can select including and excluding
        specific sources for their join and leave operation, and
        LW-IGMPv3/MLDv2 simplifies IGMPv3/MLDv2 procedures by discarding
        excluding-source function. Among these versions, (LW-) IGMPv3/MLDv2
        has the capability of explicitly tracking each host member.</t>

        <t>From the illustration given in section 2.1 and 2.2, it is desirable
        for IGMP and MLD to have the following characteristics when used in
        wireless and mobile networks:</t>

        <t>o Adaptive to link conditions: wireless networks have various link
        types, each with different bandwidth and performance features. IGMP or
        MLD should be able to be adaptive to different link models and link
        conditions to optimize its protocol operation.</t>

        <t>o Minimal group join/leave latency: because mobility and handover
        may cause a user to join and leave a multicast group frequently, fast
        join and leave by the user helps to accelerate service activation and
        to release unnecessary resources quickly to optimize resource
        utilization.</t>

        <t>o Robust to packet loss: the unreliable packet transmission due to
        instable wireless link conditions and limited bandwidth, or long
        distance transmission in mobile network put more strict robustness
        requirement on delivery of IGMP and MLD protocol messages.</t>

        <t>o Reducing packet exchange: wireless link resources are usually
        more limited, precious, and congested compared to their wired
        counterpart. This requires packet exchange be minimized without
        degrading protocol performance.</t>

        <t>o Packet burst avoidance: large number of packets generated in a
        short time interval may have the tendency to deteriorate wireless
        network conditions. IGMP and MLD should be optimized to reduce the
        probability of packet burst.</t>
      </section>
    </section>

    <section title="IGMP/MLD Optimization for Wireless and Mobile Networks">
      <t>This section introduces several optimizations for IGMP and MLD
      in wireless or mobile environment. The aim is to meet the requirements
      described in section 2.3. It should be noted that because an enhancement
      in one direction might result in weakening effect in another, balances
      should be taken cautiously to realize overall performance elevation.</t>

      <section title="Switching Between Unicast and Multicast Queries">
        <t>IGMP/MLD protocols use multicast Queries whose destinations are
        multicast addresses and also allows use of unicast Query with unicast
        destination to be sent only to one host. Unicast Query has the
        advantage of not affecting other hosts on the same link, and is
        desirable for wireless communication because a mobile terminal often
        has limited battery power [RFC6636]. But if the number of valid
        receivers is large, using unicast Query for each receiver is
        inefficient because large number of Unicast Queries have to be
        generated, in which situation normal multicast Query will be a good
        choice because only one General Query is needed. If the number of
        receivers to be queried is small, unicast Query is advantageous over
        the multicast one.</t>

        <t>More flexibly, the router can choose to switch between unicast and
        multicast Queries according to the practical network conditions. For
        example, if the receiver number is small, the router could send
        unicast Queries respectively to each receiver, without arousing other
        non-member terminal which is in dormant state. When the receiver
        number reaches a predefined level, the router could change to use
        multicast Queries. To have the knowledge of the number of the valid
        receivers, a router is required to enable explicit tracking, and
        because Group-Specific Query and Group-and-Source-Specific Query are
        usually not used under explicit tracking [RFC6636], the switching
        operation mostly applies to General Queries.</t>
      </section>

      <section title="General Query Supplemented with Unicast Query">
        <t>The Unicast Query can be used in assistance to General Query to
        improve the robustness of solicited reports when General Query fails
        to collect all of its valid members. It requires the explicit tracking
        to be enabled and can be used when a router after sending a periodical
        General Query collects successfully most of the valid members'
        responses while losing some of which are still valid in its database.
        This may be because these reports are not generated or generated but
        lost for some unknown reasons. The router could choose to unicast a
        Query respectively to each non-respondent valid receiver to check
        whether they are still alive for the multicast reception, without
        affecting the majority of receivers that have already responded.
        Unicast Queries under this condition could be sent at the end of the
        [Maximum Response Delay] after posting a General Query, and be
        retransmitted for [Last Member Query Count] times, at an interval of
        [Last Member Query Interval].</t>
      </section>

      <section title="Retransmission of Queries">
        <t>In IGMP and MLD, apart from the continuously periodical
        transmission, General Query is also transmitted during a router's
        startup. It is transmitted for [Startup Query Count] times by [Startup
        Query Interval]. There are some other cases where retransmission of
        General Query is beneficial which are not covered by current IGMP and
        MLD protocols as shown as following.</t>

        <t>For example, a router which keeps track of all its active
        receivers, if after sending a General Query, fails to get any response
        from the receivers which are still valid in its membership database.
        This may be because all the responses of the receivers happen to be
        lost, or the sent Query does not arrive at the other side of the link
        to the receivers. The router could compensate this situation by
        retransmitting the General Query to solicit its active members. The
        retransmission can also be applied to Group-Specific or
        Group-and-Source-Specific Query on a router without explicit tracking
        capability, when these Specific Queries cannot collect valid response,
        to prevent missing valid members caused by lost Queries and
        Reports.</t>

        <t>The above compensating Queries could be sent [Last Member Query
        Count] times, at the interval of [Last Member Query Interval], if the
        router cannot get any feedback from the receivers.</t>
      </section>

      <section title="General Query Suppression">
        <t>In IGMP and MLD, the General Query is sent periodically and
        continuously without any limitation. It helps soliciting the state of
        current valid member but has to be processed by all hosts on the link,
        whether they are valid multicast receivers or not. When there is no
        receiver, the transmission of the General Query is a waste of
        resources for both the host and the router.</t>

        <t>An IGMP/MLD router could suppress its transmission of General Query
        if it knows there is no valid multicast receiver on an interface, e.g.
        in the following cases:</t>

        <t>O When the last member reports its leave for a group. This could be
        judged by an explicit tracking router checking its membership
        database, or by a non-explicit-tracking router getting no response
        after sending Group-Specific or Group-and-Source-Specific Query.</t>

        <t>O When the only member on a PTP link reports its leaving</t>

        <t>O When a router after retransmitting General Queries on startup
        fails to get any response</t>

        <t>O When a router previously has valid members but fails to get any
        response after several rounds of General Queries.</t>

        <t>In these cases the router could make the decision that no member is
        on the interface and totally stop its transmission of periodical
        General Queries. If afterwards any valid member joins a
        group, the router could resume the original cycle of general Querying.
        Because General Query influences all hosts on a link,
        suppressing it when it is not needed is beneficial for both the link
        efficiency and terminal power saving.</t>
      </section>

      <section title="Tuning Response Delay According to Link Type and Status  ">
        <t>IGMP and MLD use delayed response to spread unsolicited Reports
        from different hosts to reduce possibility of packet burst. This is
        implemented by a host responding to a Query in a specific time
        randomly chosen between 0 and [Maximum Response Delay], the latter of
        which is determined by the router and is carried in Query messages to
        inform the hosts for calculation of the response delay. A larger value
        will lessen the burst better but will increase leave latency (the time
        taken to cease the traffic flowing after the last member requests the
        escaping of a channel).</t>

        <t>In order to avoid message burst and reduce leave latency, the
        Response Delay may be dynamically calculated based on the expected
        number of responders, and link type and status, as shown in the
        following:</t>

        <t>O If the expected number of reporters is large and link condition
        is bad, longer Maximum Response Delay is recommended; if the expected
        number of reporters is small and the link condition is good, smaller
        Maximum response Delay should be set.</t>

        <t>o If the link type is PTP, the Maximum Response Delay can be chosen
        smaller, whereas if the link is PTMP or broadcast medium, the Maximum
        Response Delay can be configured larger.</t>

        <t>The Maximum Response Delay could be configured by the administrator
        as mentioned above, or be calculated automatically by a software tool
        implemented according to experiential model for different link modes.
        The measures to determine the instant value of Maximum Response Delay
        are out of this document's scope.</t>
      </section>

      <section title="Triggering Reports and Queries Quickly During Handover">
        <t>When a mobile terminal is moving from one network to another, if it
        is receiving multicast content, its new access network should try to
        deliver the content to the receiver without disruption or performance
        deterioration. In order to implement smooth handover between networks,
        the terminal's membership should be acquired as quickly as possible by
        the new access network.</t>

        <t>An access router could trigger a Query to a terminal as soon as it
        detects the terminal's attaching on its link. This could be a General
        Query if the number of the entering terminals is not small (e.g when
        they are simultaneously in a moving train). Or this Query could also
        be a unicast Query for this incoming terminal to prevent unnecessary
        action of other terminals in the switching area.</t>

        <t>For the terminal, it could send a report immediately if it is
        currently in the multicast reception state, when it begins to connect
        the new network. This helps establishing more quickly the membership
        state and enable faster multicast stream injection, because with the
        active report the router does not need to wait for the query period to
        acquire the terminal's newest state.</t>
      </section>
    </section>
    
        <section anchor="Apply"
             title="Applicability and Interoperability Considerations">
      <t>Among the optimizations listed above, 'Switching between unicast and
      multicast Queries'(3.1) and 'General Query Supplemented with Unicast
      Query'(3.2) requires a router to know beforehand the valid members
      connected through an interface, thus require explicit tracking
      capability. An IGMP/MLD implementation could choose any combination of
      the methods listed from 3.1 to 3.6 to optimize multicast communication
      on a specific wireless or mobile network.</t>

      <t>For example, an explicit-tracking IGMPv3 router, can switch to
      unicast General Queries if the number of members on a link is small
      (3.1), can trigger unicast Query to a previously valid receiver if
      failing to get expected responses from it (3.2), can retransmit a
      General Query if after the previous one cannot collect reports from all
      valid members (3.3), and can stop sending a General Query when the last
      member leaves the group (3.4), and etc.</t>

      <t>For interoperability, it is required if multiple multicast routers
      are connected to the same network for redundancy, each router are
      configured with the same optimization policy to synchronize the
      membership states among the routers.</t>
    </section>  

    <section anchor="IANA" title="IANA Considerations">
      <t>This document makes no request of IANA.</t>

      <t>Note to RFC Editor: this section may be removed on publication as an
      RFC.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>Since the methods only involve the tuning of protocol behavior by
      e.g. retransmission, changing delay parameter, or other compensating
      operations, they do not introduce additional security weaknesses. The
      security consderations described in [RFC2236], [RFC3376], [RFC2710] and
      [RFC3810] can be reused. And to achieve some security level in insecure
      wireless network, it is possible to take stronger security procedures
      during IGMP/MLD message exchange, which are out of the scope of this
      memo.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to thank Behcet Sarikaya, Qin Wu, Stig Venaas, Gorry Fairhurst,
      Thomas C. Schmidt, Marshall Eubanks, Suresh Krishnan, J.William Atwood,
      WeeSan Lee, Imed Romdhani, Liu Yisong and Wei Yong for
      their valuable comments and suggestions on this document.</t>
    </section>
  </middle>

 <back>
    <references title="Normative References">
    
    	<reference anchor="refs.KEYWORDS">
	    <front>
	      <title>Key words for use in RFCs to indicate requirement levels</title>
	      <author initials="S" surname="Bradner" />
	      <date month="March" year="1997" />
	    </front>
	    <seriesInfo name="RFC" value="2119" />
	  </reference>

	  <reference anchor="refs.IGMPv3">
	    <front>
	      <title>Internet Group Management Protocol, Version 3</title>
	      <author initials="B" surname="Cain" />
	      <author initials="S" surname="Deering" />
	      <author initials="I" surname="Kouvelas" />
	      <author initials="B" surname="Fenner" />
	      <author initials="A" surname="Thyagarajan" />
	      <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 initials="L" surname="Costa" />
	      <date month="June" year="2004" />
	    </front>
	    <seriesInfo name="RFC" value="3810" />
	  </reference>

	  <reference anchor="refs.PIM">
	    <front>
	      <title>Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)</title>
	      <author initials="B" surname="Fenner" />
	      <author initials="M" surname="Handley" />
	      <author initials="H" surname="Holbrook" />
	      <author initials="I" surname="Kouvelas" />
	      <date month="August" year="2006" />
	    </front>
	    <seriesInfo name="RFC" value="4601" />
	  </reference>

	  <reference anchor="refs.IGMPv1">
	    <front>
	      <title>Host Extensions for IP Multicasting</title>
	      <author initials="S" surname="Deering" />
	      <date month="August" year="1989" />
	    </front>
	    <seriesInfo name="RFC" value="1112" />
	  </reference>

	  <reference anchor="refs.IGMPv2">
	    <front>
	      <title>Internet Group Management Protocol, Version 2</title>
	      <author initials="W" surname="Fenner" />
	      <date month="July" year="1997" />
	    </front>
	    <seriesInfo name="RFC" value="2373" />
	  </reference>

	  <reference anchor="refs.MLDv1">
	    <front>
	      <title>Multicast Listener Discovery (MLD) for IPv6</title>
	      <author initials="S" surname="Deering" />
	      <author initials="W" surname="Fenner" />
	      <author initials="B" surname="Haberman" />
	      <date month="October" year="1999" />
	    </front>
	    <seriesInfo name="RFC" value="2710" />
	  </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 initials="H" surname="He" />
	      <author initials="B" surname="Haberman" />
	      <author initials="H" surname="Sandick" />
	      <date month="August" year="2006" />
	    </front>
	    <seriesInfo name="RFC" value="4605" />
	  </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 initials="W" surname="Cao" />
	      <author initials="H" surname="Asaeda" />
	      <date month="February" year="2010" />
	    </front>
	    <seriesInfo name="RFC" value="5790" />
	  </reference>
	  
	   <?rfc include="reference.RFC.2119"?>

      <?rfc include='reference.RFC.2236'?>

      <?rfc include='reference.RFC.2710'?>

      <?rfc include='reference.RFC.3376'?>

      <?rfc include='reference.RFC.3810'?>

      <?rfc include='reference.RFC.5790'?>

      <?rfc include='reference.RFC.6636'?>
 	
 </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" />
	      <date month="January" year="2013" />
	    </front>
	    <seriesInfo name="draft-ietf-pim-explicit-tracking-04.txt" value="(work in progress)" />
	  </reference>

	  <reference anchor="refs.MIPv6">
	    <front>
	      <title>Mobility Support in IPv6</title>
	      <author initials="D" surname="Johnson" />
	      <author initials="C" surname="Perkins" />
	      <author initials="J" surname="Arkko" />
	      <date month="June" year="2004" />
	    </front>
	    <seriesInfo name="RFC" value="3775" />
	  </reference>

	  <reference anchor="refs.PMIPv6">
	    <front>
	      <title>Proxy Mobile IPv6</title>
	      <author initials="S, Ed." surname="Gundavelli" />
	      <author initials="K" surname="Leung" />
	      <author initials="V" surname="Devarapalli" />
	      <author initials="K" surname="Chowdhury" />
	      <author initials="B" surname="Patil" />
	      <date month="August" year="2008" />
	    </front>
	    <seriesInfo name="RFC" value="5213" />
	  </reference>

	  <reference anchor="refs.Noel">
	    <front>
	      <title>Multicast for Mobile Hosts in IP Networks: Progress and Challenges</title>
	      <author initials="C" surname="Jelger" />
	      <author initials="T" surname="Noel" />
	      <date month="October" year="2002" />
	    </front>
	    <seriesInfo name="IEEE Wireless Comm." value="pp.58-64" />
	  </reference>

	</references>

</back>
</rfc>
