[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

Network working group                                             Q. Wu
Internet Draft                                                   H. Liu
Category: Informational                                          Huawei
Created: October 25, 2010
Expires: April 2011

     Proposal for Tuning IGMPv3/MLDv2 Protocol Behavior in Wireless and
                              Mobile networks

                   draft-wu-multimob-igmp-mld-tuning-03


Abstract

   This document proposes a variety of optimization approaches for
   tuning IGMPv3 and MLDv2 protocols. It aims to provide useful
   guideline to allow efficient multicast communication in wireless and
   mobile networks using the current IGMP/MLD protocols.

Conventions used in this document

   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 [RFC2119].

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with
   the provisions of BCP 78 and BCP 79.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008. The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents




Wu,et al               Expires April 25, 2011                 [Page 1]

Internet-Draft  Tuning IGMPv3/MLDv2 Protocol Behavior      October 2010


   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on August 15, 2009.

Copyright Notice

   Copyright (c) 2010 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.

Table of Contents

   1. Introduction..................................................3
   2. Impact of wireless and mobility on IGMP/MLD...................3
      2.1. Comparison analysis between wired and wireless multicast.4
      2.2. Link models analysis for wireless multicast..............5
      2.3. Requirements of wireless and mobile multicast on IGMP/MLD8
   3. Evaluation of IGMP/MLD on wireless and mobile multicast.......9
   4. IGMP/MLD tuning optimization for Wireless or Mobile Network..11
      4.1. Explicit Tracking and Query Suppression.................11
      4.2. Report Suppression for the hosts........................13
      4.3. Query Suppression for the routers.......................13
      4.4. Minimizing Query Frequency by increasing interval each time
       ............................................................14
      4.5. Switching Between Unicast Query and Multicast Query.....15
      4.6. Using General Query with Unicast Query..................16
      4.7. Retransmission of General Queries.......................16
      4.8. General Query Suppression with no receiver..............17
      4.9. Tuning Response Delay according to link type and status.17
      4.10. Triggering reports and queries quickly during handover.18
   5. Security Considerations......................................19
   6. Acknowledgement..............................................19
   7. References...................................................19



Wu,et al               Expires April 25, 2011                 [Page 2]

Internet-Draft  Tuning IGMPv3/MLDv2 Protocol Behavior      October 2010


      7.1. Normative References...................................19
      7.2. Informative Referencess................................20
   Authors' Addresses............................................21



1. Introduction

   Multicasting is more efficient a method of supporting group
   communication than unicasting.  With the wide deployment of
   different wireless networks, multicast communication over wireless
   network comes to attract more and more interests from content and
   service providers, but still faces great challenges when considering
   dynamic group membership and constant update of delivery path due to
   node movement, which is highly required in the wireless or mobile
   network.  On the other hand, unlike wired network, some of wireless
   networks often offer limited reliability, consume more power and
   cost more transmission overhead, thus in worse case are more prone
   to loss and congestion.

   Multicast network is generally constructed by IGMP/MLD group
   management protocol to track valid receivers and by multicast
   routing protocol to build multicast delivery paths.  This document
   focuses only on IGMP/MLD protocols, which are used by a mobile user
   to subscribe a multicast group and are most possibly to be exposed
   to wireless link to support terminal mobility.  As IGMP and MLD are
   designed for fixed users using wired link, they does not work
   perfectly for wireless link types.  They should be enhanced or tuned
   to adapt to wireless and mobile environment to meet the reliability
   and efficiency requirements in the scenarios described in
   [REQUIRE][RFC 5757].

   This memo proposes a variety of optimization approaches for tuning
   IGMP/MLD protocols in wireless or mobile communication environment.
   It aims to make the minimum tuning on the protocol behavior without
   introducing interoperability issues, and to improve the performance
   of wireless and mobile multicast networks.  These solutions can also
   be used in wired network when efficiency and reliability are
   required.  They are discussed in detail in Section 4.

2. Impact of wireless and mobility on IGMP/MLD

   This section analyzes the impact of wireless or mobility on IGMP/MLD
   by comparing wireless multicast with wired multicast and comparing
   different wireless link models. It then gives the requirements of




Wu,et al               Expires April 25, 2011                 [Page 3]

Internet-Draft  Tuning IGMPv3/MLDv2 Protocol Behavior      October 2010


   wireless and mobile multicast on IGMP/MLD protocols according to the
   analysis.

2.1. Comparison analysis between wired and wireless multicast

   Existing multicast support for fixed user can be extended to mobile
   users in wireless environments. However applying such support to
   wireless multicast is difficult for the following five reasons.

   O Limited Bandwidth: In contrast with wired link, wireless link
      usually has limited bandwidth.  This situation will be made even
      worse if wireless link has to carry high volume video multicast
      data.  Also the bandwidth available in upstream direction and
      downstream direction may not be equal.

   O Large packets Loss: In contrast with wired multicast, wireless
      multicast has packet loss that range between 1% and 30%, based on
      the links types and conditions.  And when packets have to travel
      between home and access networks e.g. through tunnel, the packets
      are prone to be lost if the distance between the two networks is
      long.

   O Frequent Membership change: In fixed multicast, membership change
      only happens when a user leave or joins a group while in the
      mobile multicast, membership changes may also occur when a user
      changes its location.

   O Prone to performance degradation: Due to possible unwanted
      interaction of protocols across layers and user movement, the
      wireless network may be overwhelmed with more excessive traffic
      than wired network. In worse case, this may lead to network
      performance degrading and network connection complete loss.

   O Increased Leave Latency: Unlike fixed multicast, the leave latency
      in the mobile multicast will be increased due to user movement.
      And if the traffic has to be transmitted between access network
      and the home network, or if the handshake is required between
      these two networks, the Leave Latency will be increased further
      more.

   Figure 1 shows the details for the difference between wired/fixed
   multicast and wireless/mobile multicast.







Wu,et al               Expires April 25, 2011                 [Page 4]

Internet-Draft  Tuning IGMPv3/MLDv2 Protocol Behavior      October 2010


  +--------------+---------------------+----------------------------+
  |              |   Wired or fixed    |      Wireless/mobile       |
  |    Issues    |     Multicast       |         multicast          |
  +--------------+---------------------+----------------------------+
  |              |                     |   Limited and variable     |
  | Bandwidth    |    Plentiful        |   possibly asymmetric      |
  +--------------+---------------------+----------------------------+
  |              |                     |                            |
  |  Loss of     |   Infrequent(<1%)   |  Frequent and variable     |
  |  Packets     |                     |  (1%-30% based on links)   |
  +--------------+---------------------+----------------------------+
  |              |                     |                            |
  | Membership   |  Only when a user   |   Also when a user moves   |
  | Changes      |  leaves and joins   |   to another location      |
  |              |  a group            |                            |
  +--------------+---------------------+----------------------------+
  |              |                     | More complex due to        |
  |              | Possible use of a   | wireless links and user    |
  | Reliability  | transport-layer     | mobility; possible unwanted|
  |              | protocol(such as the| interaction of protocols   |
  |              | Multicast File      | at transport and link      |
  |              | Transfer Protocol)  | layers                     |
  +--------------+---------------------+----------------------------+
  |              |                     |     Increased due to       |
  |Leave Latency |   not changed by    |     user movement          |
  |              |   user movement     |     and lost packet        |
  -------------------------------------+----------------------------
          Figure 1. Comparison between wired/fixed multicast
                    and wireless/mobile multicast


2.2. Link models analysis for wireless multicast

   There are various types of wireless links, each with different
   feature and performance. In this document, we according to the
   transmission mode categorize the wireless link type into three
   typical link models:

    O Point To Point (PTP) link model
    O Point To Multipoint (PTMP) link model
    O Broadcast link model


   PTP link model is the model with one dedicated link that connects
   exactly two communication facilities. For multicast transmission,
   each PTP link has only one receiver and the bandwidth is dedicated



Wu,et al               Expires April 25, 2011                 [Page 5]

Internet-Draft  Tuning IGMPv3/MLDv2 Protocol Behavior      October 2010


   for each receiver. Also one unique prefix or set of unique prefixes
   will be assigned to each receiver. Such link model can be
   accomplished by running PPP on the link or having separate VLAN for
   each receiver.

   PTMP link model is the model with multipoint link which consists of
   a series of receivers and one centralized transmitter. Unlike P2P
   link model, PTMP provide downlink common channels and dedicated
   uplink channel for each user.  Bandwidth and prefix in this model
   are shared by all the receivers on the same link. Therefore
   Duplicate Address Detection (DAD) should be performed to check
   whether the assigned address is used by other receivers.

   Broadcast link model is the model with the link connecting two or
   more nodes and supporting broadcast transmission. Such link model is
   quite similar to fixed Ethernet link model and its link resource is
   shared in both uplink and downlink directions.  The bandwidth and
   prefix are shared by all the receivers and DAD is required to avoid
   address collision.

   Figure 2 shows the details for the difference between different
   wireless link models.


























Wu,et al               Expires April 25, 2011                 [Page 6]

Internet-Draft  Tuning IGMPv3/MLDv2 Protocol Behavior      October 2010


  +---------------+-----------------+---------------+---------------+
  |   Features    |      PTP        |      PTMP     |  Broadcast    |
  |               |   link model    |   link model  |  link model   |
  +---------------+-----------------+---------------+---------------|
  |               |                 | Common        |               |
  | Shared link/  |Dedicated uplink | downlink      |               |
  | Dedicated link|and downlink     | channels and  |common downlink|
  |               |channels for each| dedicated     | Channel for   |
  |               |user             | uplink        |each user      |
  |               |                 | channels for  |               |
  |               |                 | each          |               |
  |               |                 | user          |               |
  +---------------+-----------------+---------------+---------------|
  |               |                 | Prefix shared | Prefix shared |
  | Shared Prefix | Per Prefix for  | by all        | by all        |
  |  /Dedicated   | each receiver   | receivers     | receivers     |
  |  Prefix       |  No need DAD    |DAD is required|DAD is required|
  +---------------+-----------------+---------------+---------------|
  |               |                 |               |               |
  |Shared Service |                 |               |               |
  |   Support     |  Not Support    |    Support    |    Support    |
  |               |                 |               |               |
  +---------------+-----------------+---------------+---------------|
  |               |   Only one node |   Link Layer  |  Broadcast    |
  |               |   On the link   |   Multicast   |   Support     |
  |               |   Forward       |   Support     |   at L2       |
  |  link layer   |   multicast     |   using       | using switch  |
  |  Broadcast    |   packets to    |   Backend     |               |
  |  Multicast    |   the only      |   (e.g.,AR)   |   IGMP/MLD    |
  |  Support      |   receiver      |   IGMP/MLD    |   Snooping    |
  |               |   on the        |   Snooping    |   at switch   |
  |               |   link          |   at AR       |               |
  +---------------+-----------------+---------------+---------------|
  |               |                 |               |               |
  |               |                 |               |  Ethernet     |
  |   Ethernet    |   Not support   |   Not support |  Support By   |
  | link Support  |                 |               |  Implementing |
  |               |                 |               |  Bridge       |
  |               |                 |               |               |
  +---------------+-----------------+---------------+---------------+
              Figure 2. Wireless Link Models Analysis








Wu,et al               Expires April 25, 2011                 [Page 7]

Internet-Draft  Tuning IGMPv3/MLDv2 Protocol Behavior      October 2010


2.3. Requirements of wireless and mobile multicast on IGMP/MLD

   Due to the characteristics of wireless and mobile multicast
   described in the 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 [REQUIRE]:

   o Adaptive to different link characteristics:  IGMP and MLD are
   originally designed for wired multicast and some of their processing
   is not applicable to wireless multicast for its asymmetrical link,
   limited bandwidth, larger packet loss rate, increased leave latency,
   and etc.  Also Wireless network has various link types, each of them
   has different bandwidth and performance. These require IGMP/MLD
   protocol behavior should be tuned to adapt to different link model
   and link conditions.

   o Minimal Join and Leave Latency:  Fast join and leave of a
   subscriber helps to improve the user's experience during channel
   join and channel zapping.  Fast leave also facilitates releasing of
   unused network resources quickly.  Besides, mobility and handover
   may cause a user to join and leave a multicast group frequently,
   which also require fast join and leave to accelerate service
   activation and to optimize resource usages.

   o Robustness to packet loss:  Wireless link has the characteristic
   that packet transmission is unreliable due to instable link
   conditions and limited bandwidth.  For mobile IP network, packets
   sometimes have to travel between home network and foreign network
   and have the possibility of being lost due to long distance
   transmission.  These network scenarios have more strict robustness
   requirement on delivery of IGMP and MLD protocol messages.

   o Minimum packet transmission:  Wireless link resources are usually
   more precious and limited compared to their wired counterpart, and
   are prone to be congested when carrying high volume multicast stream.
   Minimizing packet exchange without degrading general protocol
   performance should also be emphasized to improve efficiency and make
   good use of network capacity and processing capability.

   o Avoiding packet burst:  Large number of packets generated within a
   short time interval may have the tendency to deteriorate wireless
   network conditions.  IGMP and MLD when using in wireless and mobile
   networks should be optimized if their protocol message generation
   has the potential of introducing packet burst.





Wu,et al               Expires April 25, 2011                 [Page 8]

Internet-Draft  Tuning IGMPv3/MLDv2 Protocol Behavior      October 2010


   According to these requirements, in the following parts of the
   document, current versions of IGMP/MLD protocols are evaluated
   whether their various protocol aspects are applicable to wireless
   and mobile multicast communications.  They will be optimized to meet
   these requirements without new features introduced on the wire or
   link, without new message type defined, and without interoperability
   issues introduced, which is referred to as "tuning" of IGMP/MLD
   protocols.

3. Evaluation of IGMP/MLD on wireless and mobile multicast

   This section analyzes the applicability of IGMP and MLD to wireless
   communication in the following aspects:

   O General evaluation of different versions: IGMPv2 [RFC2236] and
      MLDv1 [RFC2710] only support ASM communication mode. They do not
      support SSM subscription and explicit tracking. IGMPv3 [RFC3376]
      and MLDv2 [RFC3810] and their lightweight version LW-IGMPv3/LW-
      MLDv2 [RFC5760] support all the features of ASM/SSM communication
      modes and explicit tracking. Because SSM is more efficient and
      secure than ASM for IPTV application, and explicit tracking
      enables faster channel zapping and better manageability capability,
      IGMPv3/MLDv2 and LW-IGMPv3/MLDv2 are more promising to be deployed
      widely than IGMPv2 and MLDv1.

   O Robustness: IGMP/MLD actively sends unsolicited Report or Leave
      message to join or leave a group, and solicited Report to respond
      to Queries.  Unsolicited Report and Leave messages are more
      important for ensuring satisfactory user experience and should be
      guaranteed to improve service performance. Current IGMP and MLD
      provide the reliability for these messages by non responsive
      retransmission, which is not adequate from both the robustness and
      efficiency aspects when they are used on unreliable wireless link
      or have to be exchanged over the tunnel between home network and
      access network separated by long distance [ROBUST][ACK]. For
      IGMPv3/MLDv2, because unsolicited report and leave messages will
      not be suppressed by report from other host, it is possible to
      adopt acknowledgement-retransmission to improve reliability and
      reduce superfluous packet transmission [IGMP-ACK].

      Besides, for IGMPv3/MLDv2, because the router could by explicit
      tracking establishes membership database recording each valid
      receiver, it is possible to deduce the possible loss of some
      protocol messages according to the feedback after their
      transmission, and to take some remedies (e.g. by retransmission)




Wu,et al               Expires April 25, 2011                 [Page 9]

Internet-Draft  Tuning IGMPv3/MLDv2 Protocol Behavior      October 2010


      to enable more reliable transmission of these messages in bad
      conditions.

   O Efficiency: IGMPv2 and MLDv1 use host suppression to suppress
      duplicated membership reports on the link. In IGMPv3 and MLDv2,
      because host suppression is not adopted, the report count will be
      numerous if the number of valid receivers on the network is large.
      IGMPv3 and MLDv2 should be optimized to try to minimize
      unnecessary packet transmission to compensate this drawback. As an
      example, because an IGMPv3/MLDv2 router has record of each user in
      its state database by explicit tracking, it is possible to
      eliminate the need for query timeouts when receiving leave
      messages and to improve the efficiency by reducing both the
      unnecessary Queries and reports generated on a network.

   And as described in [REQUIRE] and [RFC5757], the default timer
   values and counter values specified in IGMP and MLD were not
   designed for the mobility context. This may result in a slow
   reaction following a client join or leave, in possible packet loss
   under worse conditions, or in overburdening the wireless link by
   excessive packets exchange than necessary. These issues can be
   addressed by tuning these parameters for the expected packet loss on
   a link to optimize service performance and resource usage.

   The comparison between IGMPv2/MLDv1 and IGMPv3/MLDv2 is illustrated
   in figure 3.  In summary, it is desirable to choose IGMPv3/MLDv2 or
   LW-IGMPv3/MLDv2 as the group management protocol for wireless or
   mobile multicast. They should be optimized to adapt to wireless and
   mobile networks to meet the efficiency and reliability requirement
   for these networks. These optimizations range from the tuning of the
   parameters (e.g. the Query Interval and other variables), to the
   tuning of protocol behavior without introducing interoperability
   issues. Considering an enhancement in one direction might introduce
   side effects in another one, balances should be taken carefully to
   avoid defects and improve protocol performance as a whole.













Wu,et al               Expires April 25, 2011                [Page 10]

Internet-Draft  Tuning IGMPv3/MLDv2 Protocol Behavior      October 2010


   +---------------------+----------------------+-------------------+
   |      Issues         |     IGMPv2/MLDv1     |     IGMPv3/MLDv2  |
   +---------------------+----------------------+-------------------+
   |Default Timer and    |   Not designed for   |   Not designed for|
   |Robustness Variable  |   Mobility context   |   Mobility context|
   |                     |   Need to be tuned   |   Need to be tuned|
   +---------------------+----------------------+-------------------+
   |                     |                      |                   |
   | Explicit Tracking   |     Not Support      |        Support    |
   |                     |                      |                   |
   +---------------------+----------------------+-------------------+
   |   ASM and SSM       |   Only Support ASM   |                   |
   |   Subscription      |     Subscription     |     Both Support  |
   +---------------------+----------------------+-------------------+
   |                     |                      |                   |
   |   Explicit Join     |                      |                   |
   |    and Leave        |      Support         |       Support     |
   |                     |                      |                   |
   +---------------------+----------------------+-------------------+
   |                     |                      |                   |
   |Host Suppression     |      Support         |     Not Support   |
   +---------------------+----------------------+-------------------+
        Figure 3. Comparison between IGMPv2/MLDv1 and IGMPv3/MLDv2


4. IGMP/MLD tuning optimization for Wireless or Mobile Network

   As mentioned in section 2, IGMPv3/MLDv2 or LW-IGMPv3/MLDv2 is
   recommended to be used as the basis for optimization of IGMP/MLD to
   adapt to wireless and mobile networks.  In this section, taking
   these characteristics requirement into account, we will discuss
   several optimization approaches for tuning of IGMPv3 and MLDv2 in
   wireless environment.  The optimizations try to minimize the packet
   transmission for both the Reports and Queries, and at the meanwhile
   take the factor of improving reliability into account, with minimum
   cost.  Different link types are also considered for the tuning
   behavior.

4.1. Explicit Tracking and Query Suppression

   In IGMPv2/MLDv1, the member reports are suppressed if the same
   report has already been sent by another host in the network which is
   also referred to as host suppression. As described in the A.2 of
   [RFC3810], the suppression of multicast listener reports has been
   removed in MLDv2 due to the following reasons:




Wu,et al               Expires April 25, 2011                [Page 11]

Internet-Draft  Tuning IGMPv3/MLDv2 Protocol Behavior      October 2010


   O Routers may want to track per-host multicast listener status on an
      interface. This enables the router to track each individual host
      that is joined to a particular group or channel and allow minimal
      leave latencies when a host leaves a multicast group or channel.

   o Multicast Listener Report suppression does not work well on
      bridged LANs.  Many bridges and Layer2/Layer3 switches that
      implement MLD snooping do not forward MLD messages across LAN
      segments in order to prevent multicast listener report suppression.

   o By eliminating multicast listener report suppression, hosts have
      fewer messages to process; this leads to a simpler state machine
      implementation.

   o In MLDv2, a single multicast listener report now bundles multiple
      multicast address records to decrease the number of packets sent.
      In comparison, the previous version of MLD required that each
      multicast address be reported in a separate message.

   Without host suppression, it is possible to enable explicit tracking
   on a router by which the local replication can be used by the router
   to inspect incoming join and leave requests, record or refresh the
   membership state for each host on the interface, and take
   appropriate action to each received report. In the meanwhile, the
   router builds a table to track which channel being forwarded to each
   port. If the channel being requested to view is already being
   received at the router, it can replicate the stream and forward to
   this new requester which ensure good response time.

   By using the tracking table mentioned above, the router has the
   capability to learn if a particular multicast address has any
   members on an attached link or if any of the sources from the
   specified list for the particular multicast address has any members
   on an attached link or not. Such capability makes Group specific
   Query or Source-and-Group Specific Queries, which are sent to query
   other members when a member leaves, unnecessary to be used because
   the router has already known who are active on the interface using
   explicit tracking. Therefore it is desirable that these two Queries
   are eliminated when explicit tracking is used. But General
   periodical Query by a router to solicit current state reports to
   refresh existing membership state database should still be used to
   prevent incorrectness of the database due to the possible loss of
   explicit join and leave message in some cases.

   The main benefits of using explicit tracking without Group specific
   Query or Source-and-Group Specific Queries are that it provides:



Wu,et al               Expires April 25, 2011                [Page 12]

Internet-Draft  Tuning IGMPv3/MLDv2 Protocol Behavior      October 2010


   O minimizing packet number and packet burst: Elimination of Group and
     Source-Group specific Queries when a member leaves a group will
     reduce the number of transmitted Group Specific Queries. And
     finally the total number of Reports in response to Group Specific
     Queries can be drastically reduced.

   O Minimal leave latencies: an IGMPv3/MLDv2 router configured with
     explicit tracking can immediately stop forwarding traffic if the
     last host to request to receive traffic from the router indicates
     its leave from the group.

   O Faster channel changing: The channel change time of the receiver
     application depends on the leave latency, that is to say, single
     host can not receive the new multicast stream before forwarding of
     the old stream has stopped.

   O Reducing Power consumption: Due to elimination of the suppression
     of membership reports, the host does not need to spend processing
     power to hear and determine if the same report has already been
     sent by another host in the network, which is beneficial to mobile
     hosts that do not have enough battery power.

4.2. Report Suppression for the hosts

   The large number of Reports and bad link condition may result in
   packets burst. This packet burst can be mitigated by having the
   router aggregate the responses (membership reports) from multiple
   clients. The router can intercept IGMP/MLD reports coming from hosts,
   and forwards a summarized version to the upstream router only when
   necessary. Typically this means that the router will forward IGMP/MLD
   membership reports as follows:

   - Unsolicited membership reports (channel change requests) are
   forwarded only when the first subscriber joins a multicast group, or
   the last subscriber leaves a multicast group. This tells the upstream
   router to begin or stop sending this channel to this router.

   - Solicited membership reports (sent in response to a query) are
   forwarded once per multicast group. The router may also aggregate
   multiple responses together into a single membership report.

4.3. Query Suppression for the routers

   The large number of Queries and bad link condition may result in
   packets burst. This packet burst can be mitigated by having the
   downstream router stop forwarding IGMP/MLD Queries packets sent to



Wu,et al               Expires April 25, 2011                [Page 13]

Internet-Draft  Tuning IGMPv3/MLDv2 Protocol Behavior      October 2010


   the hosts and respond with report as proxy to the upstream router.
   Typically this means that the router will:

   - Never send a specific query to any client, and

   - Send general queries only to those clients receiving at least one
   multicast group

4.4. Minimizing Query Frequency by increasing interval each time

   In IGMPv3/MLDv2, Group Specific Queries and Source and Group
   specific Queries are sent for [Last Member Query Count] times with
   short fixed [Last Member Query Interval], to learn whether there are
   valid members from an attached link.  If the network is undergoing
   congestion, the multiple transmissions of the queries may further
   deteriorate the bad conditions.  To eliminate the bad effects for
   this, these Queries can be slowed down when a router can not collect
   successfully expected members' report responses in the mean while it
   detects the network congestion is going to happen.  The slowing down
   process of the Queries could be arranged in a prolonged time
   interval as described in [ADAPTIVE].

   The slow down behavior is: a router after sending a Query, if
   acquires the expected responses from the receivers, refreshes its
   state database and stop the querying retransmission process, or if
   after a time interval fails to get the expected report responses,
   resends a Query with an increased (e.g. double) interval.  This
   process can be repeated, for each time the retransmission is
   arranged in a prolonged time interval, till the router receives the
   expected responses, or determines the receiver is unreachable and
   then stops the sending of the Query ultimately.  The router can make
   judgment on not getting expected response from the Queries in the
   following cases:

   O When Group Specific Query and Source and Group Specific Queries
      are used to track other numbers, the router can not collect any
      response from the link.

   O When all group members leave the group or move out of scope, the
      General Query sent by the router can not solicit any responses
      from the link, as mentioned in section 4.9.

   O When General Query is retransmitted due to possible loss deducing
      from no responses from valid members in the database.





Wu,et al               Expires April 25, 2011                [Page 14]

Internet-Draft  Tuning IGMPv3/MLDv2 Protocol Behavior      October 2010


   O When General Query is retransmitted by a router on startup
     [RFC3376][RFC3810], it gets no membership response from the
     interface.

   O When unicast Query is sent to solicit a particular receiver, if
      the router can not get responses from the receiver, as described
      in section 4.5 and 4.6.

   In the above cases, if the router fails to get expected response
   from the network, and if the link condition is bad or in congestion,
   the router could retransmit the Queries in increased interval.  This
   query retransmission with incremental interval enables the router to
   reduce the total packet retransmission times in the same time period
   comparing with retransmission for multiple times with fixed interval,
   and at the mean time gain some degree of reliability.  The variable
   time interval and the termination condition should be configurable
   and could be set according to actual network condition, which is out
   the scope of this document.

4.5. Switching Between Unicast Query and Multicast Query

    IGMP/MLD protocols define the use of multicast Queries whose
    destination addresses are multicast addresses and also allow use of
    unicast Queries with unicast destination.  The unicast Query is sent
    only for one destination and has the advantages of not affecting
    other host on the same link.  This is especially desirable for
    wireless communication because the mobile terminal often has limited
    battery power. But if the number of valid receivers is large, using
    unicast Query instead of multicast Query will introduce large number
    of Queries because each Query will be generated for each member,
    which will not be an efficient use of link resources.  In this case
    the normal multicast Query will be a good choice because only one
    Query needs to be sent. On the other hand of the number of receivers
    to be queried is small, the unicast Query is advantageous over
    multicast one.

    The router can choose to switch between unicast and multicast Query
    according to the practical network conditions.  For example, if the
    receiver number is small, the router could send unicast Queries
    respectively to each receiver to solicit their membership states,
    without arousing other host which is in the dormant state. When the
    receiver number reaches a predefined level, the router could change
    to use multicast Queries.  The router could make the switching
    flexibly according to practical conditions to improve the efficiency.





Wu,et al               Expires April 25, 2011                [Page 15]

Internet-Draft  Tuning IGMPv3/MLDv2 Protocol Behavior      October 2010


4.6. Using General Query with Unicast Query

   Unicast Query also can be used in addition to General Query to
   improve the robustness of solicited reports when General Query fails
   to collect its valid members. It requires the explicit tracking to
   be enabled on the router. Its basic behavior is: a router after
   sending a periodical Query collects successfully all the members'
   report responses except for one or two which are currently still
   valid in its database.  This may be because the non-respondent ones
   silently leave the network without any notification, or because
   their reports are lost due to some unknown reason.  The router in
   this case could choose to unicast a Query respectively to each non-
   respondent 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 for [Last Member Query Count] times, following the
   same rule of [3376] or [3810], or  could be resent in incremental
   interval, as described in section 4.4.

4.7. Retransmission of General Queries

   In IGMPv3 and MLDv2, apart from the continuously periodical
   transmission, General Query is also transmitted during a router's
   startup. It will be transmitted for [Startup Query Count] times with
   [Startup Query Interval], to improve reliability of General Query
   during startup.  There are some other cases where retransmission of
   General Query is beneficial which are not covered by current
   IGMPv3/MLDv2 protocols as shown in the following.

   For example, a router which keeps track of all its active receivers,
   if after sending a General Query, may fail to get any response from
   the receivers which are still valid in its membership database. This
   may be because all the valid receivers leaves the groups or moves out
   of the range of the link at the moment, or because all the responses
   of the receivers are lost, or because the sent Query does not arrive
   at the other side of the link.  If current database indicates the
   number of the valid receiver is not small, the router could choose to
   compensate this situation by retransmitting the General Query to
   solicit its active members.

   This compensating General Query could be sent several times, if the
   router can not get any feedback from the receivers which are previous
   in the database.  The repetition of the transmission could in fixed



Wu,et al               Expires April 25, 2011                [Page 16]

Internet-Draft  Tuning IGMPv3/MLDv2 Protocol Behavior      October 2010


   interval such as [Last Member Query Interval], or could in prolonged
   interval if the link condition is not good.

4.8. General Query Suppression with no receiver

   In IGMPv3 and MLDv2, General Query is multicast sent periodically
   and continuously without any limitations.  It helps solicit the
   state of current valid member but has influence on all terminals,
   whether they are valid multicast receivers or not.  When there is no
   receiver on the link, the transmission of the General Query is a
   waste of resources for both terminals and the router.

   The IGMPv3/MLDv2 router could suppress its transmission of General
   Query if there is no valid multicast receiver on the link, e.g. in
   the following cases:

   O If 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 sending Group and
   Source Group Specific Queries;

   O If the only member on a PTP link reports its leaving;

   O If the router after retransmission of General Queries on startup
      fails to get any response from any member;

   O If the router previously has valid members but fails to get any
      response from any member after several rounds of General Queries
      or Unicast Queries;

   In these cases the router could make a decision that no member is on
   this link and totally stop its transmission of periodical General
   Queries. If afterwards there is valid multicast receiver joins a
   group, the router could resume the original cycle of transmission of
   General Queries. Because General Query has influences on all the
   terminals on the link, suppressing it when it is not needed is
   beneficial for both the link efficiency and terminal power saving.

4.9. Tuning Response Delay according to link type and status

   IGMPv3 and MLDv2 use delayed response mechanism to spread Report
   messages from different hosts over a longer interval which can
   greatly reduce possibility of packet burstiness. This is implemented
   by the host responding to a Query in a specific time randomly chosen
   between 0 and [Maximum Response Delay]. The value of [Maximum
   Response Delay] parameter is determined by the router and is carried


Wu,et al               Expires April 25, 2011                [Page 17]

Internet-Draft  Tuning IGMPv3/MLDv2 Protocol Behavior      October 2010


   in Query messages to inform the valid hosts to make the selection.
   A long delay will lessen the burstiness but will increase leave
   latency (the time between when the last listener stops listening to
   a source or multicast address and when the traffic stops flowing).

   In order to avoid burstiness of MLD messages and reduce leave
   latency, explicit tracking with Group Specific Query eliminated is
   recommended to be used first to reduce leave latency. Then the
   Response Delay may be dynamically calculated based on the expected
   number of Reporters for each Query and link type and link status.

    O If the expected number of Reporters is large and link condition is
      bad, the system administrator MUST choose the longer Maximum
      Response Delay; if the expected number of Reporters is small and
      the link condition is good, the administrator may choose the
      smaller Maximum response Delay. In this case, the IGMP/MLD packet
      burstiness can be reduced.

    o Another case is if the link type is PTP which means the resource
      is dedicated for one receiver on each link, then the Maximum
      Response Delay can be chosen smaller, if the link type is shared
      medium link or P2MP, then the Maximum Response Delay can be
      configured larger.

    The Maximum Response Delay can be configured by the administrator as
    mentioned above, or be calculated automatically by software tool
    implemented according to experiential model on different link modes.
    As the router arrives at a value appropriate for current link type
    and conditions, it will encode the value in Query messages to inform
    the host to make the response.  The determination of the instant
    Maximum Response Delay value is out of this document's scope.

4.10. Triggering reports and queries quickly during handover

    As a mobile terminal is moving from one network to another, if it is
    a multicast receiver from a group, its new access network should try
    to deliver the content to the receiver without disruption or
    performance deterioration.  For the smooth switching between
    networks, the terminal's membership should be acquired as quickly as
    possible by the new access network.

   For the access router, it could trigger a Query to the terminal as
   soon as it detects a new terminal on its link.  This could be a
   General Query if the router does not know whether or not the
   terminal is a valid receiver or if the number of the entering
   terminals is not small. Or this Query could also be a unicast Query



Wu,et al               Expires April 25, 2011                [Page 18]

Internet-Draft  Tuning IGMPv3/MLDv2 Protocol Behavior      October 2010


   for only a small quantity of terminals to prevent unnecessary action
   of other terminals in the switching area.

   For the terminal, it could trigger a report if it is currently in
   the multicast reception state.  This helps establish more quickly
   the membership states and enable faster multicast stream injection
   because active report from the host does not requires the router to
   wait for the query-response round in the passive reporting cases.

5. Security Considerations

   They will be described in the later version of this draft.

6. Acknowledgement

   The authors would like to thank Stig,Venaas, Gorry Fairhurst, Thomas
   C. Schmidt, Marshall Eubanks, Suresh Krishnan, J.William Atwood,
   WeeSan Lee, Imed Romdhani,  Hitoshi Asaeda, Liu Yisong and Wei Yong
   for their valuable comments and suggestions on this document.

7. References

7.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to indicate
   requirement levels", RFC 2119, March 1997.

   [RFC1112] Deering, S. "Host Extensions for IP Multicasting", RFC1112,
   August 1989.

   [RFC2236] Fenner, W., "Internet Group Management Protocol, Version
   2", RFC 2236, November 1997.

   [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
   Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.

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

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

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




Wu,et al               Expires April 25, 2011                [Page 19]

Internet-Draft  Tuning IGMPv3/MLDv2 Protocol Behavior      October 2010


   [RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight IGMPv3 and
   MLDv2 Protocols", RFC5790, February 2010.

7.2. Informative Referencess

   [REQUIRE] H. Liu, Q. Wu, H. Asaeda and TM. Eubanks, "Mobile and
   Wireless Multicast Requirements on IGMP/MLD Protocols", draft-liu-
   multimob-igmp-mld-mobility-req-03.txt, March 2010.

   [ROBUST] A. Sen Mazumder, "Facilitating Robust Multicast Group
   Management", NOSSDAV'05, June 13-14, 2005, Stevenson, Washington,
   USA.

   [ACK] Nikaein, N. and Bonnet, C. "Wireless multicasting in an IP
   environment" In Proceedings of the 5th International Workshop on
   Mobile Multimedia Communication MoMuc'98 (Berlin, Germany, Oct. 12-
   14). IEEE Computer Society Press, 1998.

   [IGMP-ACK] H. Liu, Q, Wu, "Reliable IGMP and MLD Protocols in
   Wireless Environment", draft-liu-multimob-reliable-igmp-mld-00.txt,
   February 2010.

   [ADAPTIVE] I. Romdhani, J. Munoz, H. Bettahar, and A. Bouabdallah,
   "Adaptive Multicast Membership Management for Mobile Multicast
   Receivers", IEEE, 2006.

   [RFC5757] Schmidt, T., Waehlisch, M., and G. Fairhurst, "Multicast
   Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief
   Survey", RFC 5757, February 2010.



















Wu,et al               Expires April 25, 2011                [Page 20]

Internet-Draft  Tuning IGMPv3/MLDv2 Protocol Behavior      October 2010


Authors' Addresses

   Qin Wu
   Huawei Technologies Co., Ltd.
   Site B, Floor 12, Huihong Mansion,No.91 Baixia Rd.
   Nanjing, Jiangsu  21001
   China
   Phone: +86-25-84565892

   EMail: sunseawq@huawei.com


   Hui Liu
   Huawei Technologies Co., Ltd.
   Huawei Bld., No.3 Xinxi Rd.
   Shang-Di Information Industry Base
   Hai-Dian Distinct, Beijing 100085
   China

   EMail: Liuhui47967@huawei.com




























Wu,et al               Expires April 25, 2011                [Page 21]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/