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

Versions: 00 01 02 03 04 05 06 RFC 5790

MBONED Working Group                                              H. Liu
Internet-Draft                                                    W. Cao
Intended status: Standards Track                     Huawei Technologies
Expires: April 17, 2010                                        H. Asaeda
                                                         Keio University
                                                        October 14, 2009


                 Lightweight IGMPv3 and MLDv2 Protocols
             draft-ietf-mboned-lightweight-igmpv3-mldv2-06

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 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 April 17, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.



Liu, et al.              Expires April 17, 2010                 [Page 1]

Internet-Draft        Lightweight IGMPv3 and MLDv2          October 2009


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.














































Liu, et al.              Expires April 17, 2010                 [Page 2]

Internet-Draft        Lightweight IGMPv3 and MLDv2          October 2009


Abstract

   This document describes lightweight IGMPv3 and MLDv2 protocols (LW-
   IGMPv3 and LW-MLDv2), which simplify the standard (full) versions of
   IGMPv3 and MLDv2.  The interoperability with the full versions and
   the previous versions of IGMP and MLD is also taken into account.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Simplification Method Overview . . . . . . . . . . . . . . . .  7
     3.1.  Behavior of Group Members  . . . . . . . . . . . . . . . .  7
     3.2.  Behavior of Multicast Routers  . . . . . . . . . . . . . .  7
   4.  LW-IGMPv3 Protocol for Group Members . . . . . . . . . . . . .  9
     4.1.  Query and Report Messages  . . . . . . . . . . . . . . . .  9
     4.2.  Action on Change of Interface State  . . . . . . . . . . .  9
     4.3.  Action on Reception of a Query . . . . . . . . . . . . . . 10
     4.4.  LW-IGMPv3 Group Record Types . . . . . . . . . . . . . . . 10
   5.  LW-IGMPv3 Protocol for Multicast Routers . . . . . . . . . . . 12
     5.1.  Group Timers and Source Timers in the Lightweight
           Version  . . . . . . . . . . . . . . . . . . . . . . . . . 12
     5.2.  Source-Specific Forwarding Rules . . . . . . . . . . . . . 13
     5.3.  Reception of Current-State Records . . . . . . . . . . . . 13
     5.4.  Reception of Source-List-Change and Filter-Mode-Change
           Records  . . . . . . . . . . . . . . . . . . . . . . . . . 14
   6.  Interoperability . . . . . . . . . . . . . . . . . . . . . . . 16
     6.1.  Interoperation with the Full Version of IGMPv3/MLDv2 . . . 16
       6.1.1.  Behavior of Group Members  . . . . . . . . . . . . . . 16
       6.1.2.  Behavior of Multicast Routers  . . . . . . . . . . . . 16
     6.2.  Interoperation with IGMPv1/IGMPv2  . . . . . . . . . . . . 16
       6.2.1.  Behavior of Group Members  . . . . . . . . . . . . . . 16
       6.2.2.  Behavior of Multicast Routers  . . . . . . . . . . . . 17
     6.3.  Interoperation with MLDv1  . . . . . . . . . . . . . . . . 17
   7.  Implementation Considerations  . . . . . . . . . . . . . . . . 19
     7.1.  Implementation of Source-Specific Multicast  . . . . . . . 19
     7.2.  Implementation of Multicast Source Filter (MSF) APIs . . . 19
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
     10.2. Informative References . . . . . . . . . . . . . . . . . . 22
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23







Liu, et al.              Expires April 17, 2010                 [Page 3]

Internet-Draft        Lightweight IGMPv3 and MLDv2          October 2009


1.  Introduction

   IGMP version 3 [2] and MLD version 2 [3] implement source filtering
   capabilities that are not supported by their earlier versions, IGMPv1
   [4], IGMPv2 [5] and MLDv1 [6].  An IGMPv3 or MLDv2 capable host can
   tell its upstream router which group it would like to join by
   specifying which sources it does or does not intend to receive
   multicast traffic from.  IGMPv3 and MLDv2 add the capability for a
   multicast router to learn sources which are of interest or which are
   of not interested for a particular multicast address.  This
   information is used during forwarding of multicast data packets.

   INCLUDE and EXCLUDE filter-modes are introduced to support the source
   filtering function.  If a host wants to receive from specific
   sources, it sends an IGMPv3 or MLDv2 report with filter-mode set to
   INCLUDE.  If the host does not want to receive from some sources, it
   sends a report with filter-mode set to EXCLUDE.  A source list for
   the given sources shall be included in the report message.

   INCLUDE and EXCLUDE filter modes are also defined in a multicast
   router to process the IGMPv3 or MLDv2 reports.  When a multicast
   router receives the report messages from its downstream hosts, it
   forwards the corresponding multicast traffic by managing requested
   group and source addresses.  Group timers and source timers are used
   to maintain the forwarding state of desired groups and sources under
   certain filter modes.  When a group report arrives or a certain timer
   expires, a multicast router may update the desired or undesired
   source lists, reset related timer values, change filter mode, or
   trigger group queries.  With all of the above factors correlating
   with each other, the determination rules become relatively complex,
   as the interface states could be frequently changed.

   The multicast filter-mode improves the ability of the multicast
   receiver to express its desires.  It is useful to support Source-
   Specific Multicast (SSM) [7] by specifying interesting source
   addresses with INCLUDE mode.  However, practical applications do not
   use EXCLUDE mode to block sources very often, because a user or
   application usually wants to specify desired source addresses, not
   undesired source addresses.  Even if a user wants to explicitly
   refuse traffic from some sources in a group, when other users in the
   same shared network have an interest in these sources, the
   corresponding multicast traffic is forwarded to the network.  It is
   generally unnecessary to support the filtering function that blocks
   sources.

   This document proposes simplified versions of IGMPv3 and MLDv2, named
   Lightweight IGMPv3 and Lightweight MLDv2 (or LW-IGMPv3 and LW-MLDv2).
   LW-IGMPv3 and LW-MLDv2 are subsets of the standard IGMPv3 and MLDv2.



Liu, et al.              Expires April 17, 2010                 [Page 4]

Internet-Draft        Lightweight IGMPv3 and MLDv2          October 2009


   These protocols support both ASM and SSM communications without a
   filtering function that blocks sources.  Not only are they compatible
   with the standard IGMPv3 and MLDv2, but also the protocol operations
   made by hosts and routers or switches (performing IGMPv3/MLDv2
   snooping) are simplified to reduce the complicated operations.  Since
   LW-IGMPv3 and LW-MLDv2 are fully compatible with IGMPv3 and MLDv2,
   hosts or routers that have implemented the full version do not need
   to implement or modify anything to cooperate with LW-IGMPv3/LW-MLDv2
   hosts or routers.










































Liu, et al.              Expires April 17, 2010                 [Page 5]

Internet-Draft        Lightweight IGMPv3 and MLDv2          October 2009


2.  Terminology

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

   In addition, the following terms are used in this document.

   (*,G) join:
   An operation triggered by a host that wants to join the group G. In
   this case, the host receives from all sources sending to group G.
   This is typical in the ASM communication.

   (S,G) join:
   An operation triggered by a host that wants to join the group G, with
   specifying desired source S. In this case, the host receives only
   from source S sending to group G.

   INCLUDE (S,G) join:
   An operation triggered by a host that wants to join a group G under
   INCLUDE filter-mode, with specifying desired source S. The same
   meaning of (S,G) join.

   EXCLUDE (*,G) join:
   An operation triggered by a host that wants to join a group G under
   EXCLUDE filter-mode.  The same meaning of (*,G) join.

   EXCLUDE (S,G) join:
   An operation triggered by a host that wants to join a group G under
   EXCLUDE filter-mode, with specifying undesired source S. This
   operation is not supported by LW-IGMPv3/LW-MLDv2.




















Liu, et al.              Expires April 17, 2010                 [Page 6]

Internet-Draft        Lightweight IGMPv3 and MLDv2          October 2009


3.  Simplification Method Overview

   The principle is to simplify the host and router's behavior as much
   as possible to improve efficiency, while guaranteeing
   interoperability with the full versions, and introducing no side
   effects on applications.

   For convenience, this document mainly discusses IGMPv3, since MLDv2
   inherits the same source filtering mechanism, but this document
   additionally shows MLDv2's unique specifications when needed.

3.1.  Behavior of Group Members

   In LW-IGMPv3, the same service interface model as that of IGMPv3 is
   inherited:

      IPMulticastListen ( socket, interface, multicast-address,
                          filter-mode, source-list )

   In the lightweight protocol, INCLUDE mode on the host part has the
   same usage with the full version for INCLUDE (S,G) join, while
   EXCLUDE mode on the host part is preserved only for excluding null
   source-lists, which denotes a (*,G) join as used by IGMPv2/IGMPv1/
   MLDv1.  The detailed host operation of LW-IGMPv3/LW-MLDv2 is
   described in Section 4.

3.2.  Behavior of Multicast Routers

   In IGMPv3, router filter-mode is defined to optimize the state
   description of a group membership [2][3].  As a rule, once a member
   report is in EXCLUDE mode, the router filter-mode for the group will
   be set to EXCLUDE.  When all systems cease sending EXCLUDE mode
   reports, the filter-mode for that group may transit back to INCLUDE
   mode.  Group timer is used to identify such transition.

   In LW-IGMPv3, hosts primarily send INCLUDE requests, and also can
   request an EXCLUDE (*,G) join, which can be interpreted by the router
   as a request to include all sources.  Without the more general form
   of EXCLUDE requests, it is unnecessary for the router to maintain the
   EXCLUDE filter-mode, and the state model for multicast router can be
   simplified as:

      (multicast address, group timer, (source records))

   Here a group timer is kept to represent a (*,G) join.  Its basic
   behavior is: when a router receives a (*,G) join, it will set its
   group timer and keep the source list for sources specified in the
   previously received source records.  When the group timer expires,



Liu, et al.              Expires April 17, 2010                 [Page 7]

Internet-Draft        Lightweight IGMPv3 and MLDv2          October 2009


   the router may change to the reception for the listed sources.  The
   definition of the source record is the same as that of full version.

   The elimination of the filter-mode will greatly simplify the router
   behavior.  The detailed operation of router operation is described in
   Section 5.













































Liu, et al.              Expires April 17, 2010                 [Page 8]

Internet-Draft        Lightweight IGMPv3 and MLDv2          October 2009


4.  LW-IGMPv3 Protocol for Group Members

4.1.  Query and Report Messages

   LW-IGMPv3 uses two sets of messages, i.e., Query and Report messages,
   being the same as the full version protocols.  There is no difference
   between the definition and usage of the Query message.  But the
   report types in lightweight protocols are reduced because an
   operation that triggers EXCLUDE (S,G) join is omitted.

   There are three Group Record Types defined in the full IGMPv3:
   Current-State Record noted by MODE_IS_INCLUDE (referred to as IS_IN)
   or MODE_IS_EXCLUDE (IS_EX), Filter-Mode-Change Record noted by
   CHANGE_TO_INCLUDE_MODE (TO_IN) or CHANGE_TO_EXCLUDE_MODE (TO_EX), and
   Source-List-Change Record noted by ALLOW_NEW_SOURCES (ALLOW) or
   BLOCK_OLD_SOURCES (BLOCK).  LW-IGMPv3 inherits the action on change
   of interface state and reception of a Query, but IS_IN and IS_EX
   record types are eliminated and Current-State Records are noted by
   other records.  The following sections explain the details.

4.2.  Action on Change of Interface State

   When the state of an interface of a group member host is changed, a
   State-Change Report for that interface is immediately transmitted
   from that interface.  The type and contents of the Group Record(s) in
   that Report are determined by comparing the filter mode and source
   list for the affected multicast address before and after the change.
   While the requirements are the same as the full version for the
   computation, in the lightweight version host, the interface state
   change rules are simplified due to the reduction of message types.
   The contents of the new transmitted report are calculated as follows
   (Group Record Types are described in Section 4.4):

         Old State        New State        State-Change Record Sent
         -----------      -----------      ------------------------

         INCLUDE (A)      INCLUDE (B)      ALLOW(B-A), BLOCK(A-B)

         INCLUDE (A)      EXCLUDE ({})     TO_EX({})

         INCLUDE ({})     EXCLUDE ({})     TO_EX({})

         EXCLUDE ({})     INCLUDE (B)      TO_IN(B)

   As in the full version, to cover the possibility of the State-Change
   Report being missed by one or more multicast routers, it is
   retransmitted [Robustness Variable]-1 more times, at intervals chosen
   at random from the range (0, [Unsolicited Report Interval]).  (These



Liu, et al.              Expires April 17, 2010                 [Page 9]

Internet-Draft        Lightweight IGMPv3 and MLDv2          October 2009


   values are defined in [2][3].)

4.3.  Action on Reception of a Query

   As in the full version, when a lightweight version host receives a
   Query, it does not respond immediately.  Instead, it delays its
   response by a random amount of time, bounded by the Max Resp Time
   value derived from the Max Resp Code in the received Query message
   [2][3].  The system may receive a variety of Queries on different
   interfaces and of different kinds (e.g., General Queries, Group-
   Specific Queries, and Group-and-Source-Specific Queries), each of
   which may require its own delayed response.

   Before scheduling a response to a Query, the system must first
   consider previously scheduled pending responses and in many cases
   schedule a combined response.  Therefore, the lightweight version
   host must be able to maintain the following state:

    o A timer per interface for scheduling responses to General Queries.

    o A per-group and interface timer for scheduling responses to Group-
      Specific and Group-and-Source-Specific Queries.

    o A per-group and interface list of sources to be reported in the
      response to a Group-and-Source-Specific Query.

   LW-IGMPv3 inherits the full version's rules that are used to
   determine if a Report needs to be scheduled.  The difference is
   regarding the simplification of EXCLUDE filter-mode and the type of
   Report as detailed in Section 4.4.

4.4.  LW-IGMPv3 Group Record Types

   Among Group Record Types defined in the full IGMPv3, several record
   types are not used in LW-IGMPv3 as some of the processes related to
   the filter mode change to the EXCLUDE mode are eliminated and some of
   the report messages are converged with a record having null source
   address list.  All of the record types of report messages used by the
   full and lightweight version protocols are shown as follows:












Liu, et al.              Expires April 17, 2010                [Page 10]

Internet-Draft        Lightweight IGMPv3 and MLDv2          October 2009


      IGMPv3       LW-IGMPv3    Comments
      ---------    ---------    -------------------------------------

      IS_EX({})    TO_EX({})    Query response for (*,G) join

      IS_EX(x)     N/A          Query response for EXCLUDE (x,G) join

      IS_IN(x)     ALLOW(x)     Query response for INCLUDE (x,G) join

      ALLOW(x)     ALLOW(x)     INCLUDE (x,G) join

      BLOCK(x)     BLOCK(x)     INCLUDE (x,G) leave

      TO_IN(x)     TO_IN(x)     Change to INCLUDE (x,G) join

      TO_IN({})    TO_IN({})    (*,G) leave

      TO_EX(x)     N/A          Change to EXCLUDE (x,G) join

      TO_EX({})    TO_EX({})    (*,G) join

   where "x" represents a non-null source address list and "({})"
   represents null source address list.  For instance, IS_EX({}) means a
   report whose record type is IS_EX with null source address list.
   "N/A" represents not applicable (or no use) because the corresponding
   operation should not occur in the lightweight version protocols.

   LW-IGMPv3 does not use EXCLUDE filter-mode with a non-null source
   address list.  A multicast router creates the same state when it
   receives a report message containing either IS_EX({}) or TO_EX({})
   record types.  Therefore, LW-IGMPv3 integrates the IS_EX({})
   operation with the TO_EX({}) operation.

   When a LW-IGMPv3 host needs to make a query response for the state of
   INCLUDE (x,G) join, it makes a response whose message type is
   expressed with ALLOW(x), instead of using the IS_IN record type.
   Because the router's processing of the two messages is completely
   same, the IS_IN(x) type is eliminated for simplification.

   A LW-IGMPv3 host does not use EXCLUDE mode, while TO_IN record is
   used the following situation: the host first launches an application
   (AP1) that requests INCLUDE (x,G) join, and sends ALLOW(x).  Then the
   host launches another application (AP2) that joins (*,G), and it
   sends TO_EX({}).  In this condition, when AP2 terminates but AP1
   keeps working on the lightweight version host, the host sends a
   report with TO_IN(x) record type for [Robustness Variable] times.





Liu, et al.              Expires April 17, 2010                [Page 11]

Internet-Draft        Lightweight IGMPv3 and MLDv2          October 2009


5.  LW-IGMPv3 Protocol for Multicast Routers

   The major difference between the full and lightweight version
   protocols on the router part is that for the lightweight version
   filter-mode is discarded and the function of the group timer is
   redefined.  The states maintained by the lightweight router are
   reduced and the protocol operation is greatly simplified.

5.1.  Group Timers and Source Timers in the Lightweight Version

   In lightweight and full IGMPv3 routers, a source timer is kept for
   each source record and it is updated when the source is present in a
   received report.  It indicates the validity of the sources and needs
   to be referred when the router takes its forwarding decision.

   The group timer being used in the full version of IGMPv3 for
   transitioning the router's filter-mode from EXCLUDE to INCLUDE, is
   redefined in the lightweight protocols to identify the non-source-
   specific receiving states maintaining for (*,G) join.  Once a group
   record of TO_EX({}) is received, the group timer is set to represent
   this (*,G) group join.  The expiration of the group timer indicates
   that there are no more listeners on the attached network for this
   (*,G) group.  Then if at this moment there are unexpired sources
   (whose source timers are greater than zero), the router will change
   to receiving traffic for those sources.  The role of the group timer
   can be summarized as follows:

       Group Timer Value      Actions/Comments
       ------------------     --------------------------------------

       G_Timer > 0            All members in this group.

       G_Timer == 0           No more listeners to this (*,G) group.
                              If all source timers have expired then
                              delete group record.  If there are
                              still source record timers running,
                              use those source records with running
                              timers as the source record state.

   The operation related to the group and source timers has some
   difference compared with the full IGMPv3.  In the full version, if a
   source timer expires under the EXCLUDE router filter-mode, its
   corresponding source record is not deleted until the group timer
   expires for indicating undesired sources.  In the lightweight
   version, since there is no need to keep such records for blocking
   specific sources, if a source timer expires, its source record should
   be deleted immediately, not waiting for the time-out of the group
   timer.



Liu, et al.              Expires April 17, 2010                [Page 12]

Internet-Draft        Lightweight IGMPv3 and MLDv2          October 2009


5.2.  Source-Specific Forwarding Rules

   A full version multicast router needs to consult IGMPv3 state
   information when it makes decisions on forwarding a datagram from a
   source or its upstream router to its attached network, based on the
   router filter-mode and source timer.  In LW-IGMPv3, because of the
   absence of the router filter-mode, the group timer and source timer
   could be used for such decisions.  The forwarding suggestion made by
   LW-IGMPv3 to the routing protocols is summarized as follows:

       Group Timer    Source Timer          Action
       ------------   ------------------    -----------------------

       G_Timer == 0   S_TIMER > 0           Suggest forwarding
                                            traffic from source

       G_Timer == 0   S_TIMER == 0          Suggest stopping
                                            forwarding traffic from
                                            source and remove
                                            source record.  If there
                                            are no more source
                                            records for the group,
                                            delete group record

       G_Timer == 0   No Source Elements    Suggest not to forward
                                            traffic from the source

       G_Timer > 0    S_TIMER >= 0          Suggest forwarding
                                            traffic from source

       G_Timer > 0    No Source Elements    Suggest forwarding
                                            traffic from source

5.3.  Reception of Current-State Records

   When receiving Current-State Records, the LW-IGMPv3 router resets its
   group or source timers and updates its source list within the group.
   For source-specific group reception state (when G_Timer==0 and
   S_Timer > 0), the source list contains sources whose traffic will be
   forwarded by the router, while in non-source-specific group reception
   (when G_Timer>0), the source list remembers the valid sources to
   receive traffic from after toggling to source-specific reception
   state.

   Although the LW-IGMPv3 host only sends a subset of the message of
   that of the full version, the LW-IGMPv3 router should be able to
   process as much messages as possible to be compatible with the full
   version host.  Note that if the report type is IS_EX(x) with non-



Liu, et al.              Expires April 17, 2010                [Page 13]

Internet-Draft        Lightweight IGMPv3 and MLDv2          October 2009


   empty source-list, the router will treat it as the same type of
   report with empty source list.  The following table describes the
   action taken by a multicast router after receiving Current-State
   Records.  The notations have the same meaning as that in the full
   IGMPv3 protocol.

                       Old                     New
                       Source                  Source
        Group Timer    List     Report Rec'd   List     Actions
        ------------   ------   ------------   ------   -----------

        G_Timer == 0     A       IS_IN(B)       A+B     (B)=GMI

        G_Timer == 0     A       IS_EX({})       A      G_Timer=GMI

        G_Timer > 0      A       IS_IN(B)       A+B     (B)=GMI

        G_Timer > 0      A       IS_EX({})       A      G_Timer=GMI

   The above table could be further simplified for the processes that
   are completely same for the two values of the G_Timer:

               Old                      New
               Source                   Source
               List     Report Rec'd    List     Actions
               ------   ------------    ------   -----------

                 A       IS_IN(B)        A+B     (B)=GMI

                 A       IS_EX({})        A      G_Timer=GMI

   Without EXCLUDE filter-mode, a router's process on receiving Current-
   State Record is simple: when a router receives an IS_IN report, it
   appends the reported source addresses to the previous source list
   with their source timers set to GMI.  Upon receiving an IS_EX({})
   report, the router sets the non-source-specific receiving states by
   resetting the group timer value and keeps the previous source list
   without modification.

5.4.  Reception of Source-List-Change and Filter-Mode-Change Records

   On receiving Source-List-Change and Filter-Mode-Change Records, the
   LW-IGMPv3 router needs to reset its group and source timers, update
   its source list within the group, or trigger group queries.  The
   queries are sent by the router for the sources that are requested to
   be no longer forwarded to a group.  Note that if the report type is
   TO_EX(x) with non-empty source-list, the router will treat it as the
   same type of report with empty source list.  The table below



Liu, et al.              Expires April 17, 2010                [Page 14]

Internet-Draft        Lightweight IGMPv3 and MLDv2          October 2009


   describes the state change and the actions that should be taken.

                      Old                     New
                      Source                  Source
       Group Timer    List     Report Rec'd   List     Actions
       ------------   ------   ------------   ------   -------------

       G_Timer == 0     A       ALLOW(B)       A+B     (B)=GMI

       G_Timer == 0     A       BLOCK(B)        A      Send Q(G,A*B)

       G_Timer == 0     A       TO_IN(B)       A+B     (B)=GMI
                                                       Send Q(G,A-B)

       G_Timer == 0     A       TO_EX({})       A      G_Timer=GMI

       G_Timer > 0      A       ALLOW(B)       A+B     (B)=GMI

       G_Timer > 0      A       BLOCK(B)        A      Send Q(G,A*B)

       G_Timer > 0      A       TO_IN(B)       A+B     (B)=GMI
                                                       SendQ(G,A-B)
                                                       Send Q(G)

       G_Timer > 0      A       TO_EX({})       A      G_Timer=GMI

   The table could be further simplified by merging duplicate lines:

          Old                     New
          Source                  Source
          List     Report Rec'd   List     Actions
          ------   ------------   ------   ----------------------

            A       ALLOW(B)       A+B     (B)=GMI

            A       BLOCK(B)        A      Send Q(G,A*B)

            A       TO_IN(B)       A+B     (B)=GMI
                                           Send Q(G,A-B)
                                           If G_Timer>0 Send Q(G)
            A       TO_EX({})       A      G_Timer=GMI










Liu, et al.              Expires April 17, 2010                [Page 15]

Internet-Draft        Lightweight IGMPv3 and MLDv2          October 2009


6.  Interoperability

   LW-IGMPv3/LW-MLDv2 hosts and routers must interoperate with hosts and
   routers of the full version [2][3].  Also, LW-IGMPv3/LW-MLDv2 hosts
   and routers must interoperate gracefully with hosts and routers
   running IGMPv1/v2 or MLDv1.

6.1.  Interoperation with the Full Version of IGMPv3/MLDv2

   LW-IGMPv3/LW-MLDv2 do not introduce any change on the message format
   of the group query and report messages the full version protocols
   use.

6.1.1.  Behavior of Group Members

   A LW-IGMPv3 host's compatibility mode is determined from the Host
   Compatibility Mode variable which can be in one of three states:
   IGMPv1, IGMPv2, or IGMPv3.  When a lightweight host behaves on its
   interface as LW-IGMPv3, its Host Compatibility Mode of that interface
   is set to IGMPv3, and the host sends a subset of IGMPv3 report
   messages, which can be recognized by a multicast router running the
   full or the lightweight IGMPv3 protocol on the same LAN.

6.1.2.  Behavior of Multicast Routers

   A LW-IGMPv3 or LW-MLDv2 router does not process directly IS_EX(x) and
   TO_EX(x) records that are used by the full version.  When a LW-
   IGMPv3/LW-MLDv2 router receives these report messages from the full
   version host, it MUST translate them internally to IS_EX({}) and
   TO_EX({}) respectively and behaves accordingly.

6.2.  Interoperation with IGMPv1/IGMPv2

   Since the lightweight protocols can be treated as the parallel
   version of full version of IGMPv3/MLDv2, its compatibility principle
   and method with the older version are generally the same as that of
   full IGMPv3/MLDv2.

6.2.1.  Behavior of Group Members

   The Host Compatibility Mode of an interface is set to IGMPv2 and its
   IGMPv2 Querier Present timer is set to Older Version Querier Present
   Timeout seconds (defined in [2]) whenever an IGMPv2 General Query is
   received on that interface.  The Host Compatibility Mode of an
   interface is set to IGMPv1 and its IGMPv1 Querier Present timer is
   set to Older Version Querier Present Timeout seconds whenever an
   IGMPv1 Membership Query is received on that interface.




Liu, et al.              Expires April 17, 2010                [Page 16]

Internet-Draft        Lightweight IGMPv3 and MLDv2          October 2009


   In the presence of older version group members, LW-IGMPv3 hosts may
   allow its report message to be suppressed by either an IGMPv1 or
   IGMPv2 membership report.  However, because the transmission of
   IGMPv1 or v2 packets reduces the capability of the LW-IGMPv3 system,
   as a potential protection mechanism, the choice to enable or disable
   the use of backward compatibility may be configurable.

6.2.2.  Behavior of Multicast Routers

   The behavior of a LW-IGMPv3 router when placed on a network where
   there are routers that have not been upgraded to IGMPv3, is
   completely the same with a full IGMPv3 router in this situation [2].

   A full IGMPv3 router uses Group Compatibility Mode (whose value is
   either of IGMPv1, IGMPv2, or IGMPv3) per group record to indicate
   which version of IGMP protocol it behaves for the group.  This value
   is set according to the version of the received IGMP report.  When
   Group Compatibility Mode is IGMPv3, the lightweight router acts with
   LW-IGMPv3 protocol for that group.

   When Group Compatibility mode is IGMPv2, a LW-IGMPv3 router inherits
   this compatibility mechanism with the following rules:

                 IGMP Message          LW-IGMPv3 Equivalent
                --------------         --------------------

                  v2 Report                  TO_EX({})

                  v2 Leave                   TO_IN({})

   When Group Compatibility mode is IGMPv1, a LW-IGMPv3 router
   internally translates the following IGMPv1 and IGMPv2 messages for
   that group to their LW-IGMPv3 equivalents:

                 IGMP Message          LW-IGMPv3 Equivalent
                --------------         --------------------

                  v1 Report                  TO_EX({})

                  v2 Report                  TO_EX({})

6.3.  Interoperation with MLDv1

   LW-MLDv2 hosts and routers MUST interoperate with the hosts and
   routers running MLDv1.  The method is the same as described in
   Section 6.2.  The difference is that when a LW-MLDv2 router has a
   MLDv1 listener on its network, it translates the following MLDv1
   messages to their LW-MLDv2 equivalents:



Liu, et al.              Expires April 17, 2010                [Page 17]

Internet-Draft        Lightweight IGMPv3 and MLDv2          October 2009


                 MLDv1 Message         LW-MLDv2 Equivalent
                 -------------         -------------------

                    Report                  TO_EX({})

                    Done                    TO_IN({})













































Liu, et al.              Expires April 17, 2010                [Page 18]

Internet-Draft        Lightweight IGMPv3 and MLDv2          October 2009


7.  Implementation Considerations

   The lightweight protocols require no additional procedure on the
   implementation of the related protocols or systems, e.g.  IGMP/MLD
   snooping, multicast routing protocol, and operation of application
   sockets, while the processing loads on the switches and routers that
   running IGMPv3/MLDv2 (snooping) and multicast routing protocols may
   be greatly decreased.

   In the following sections, the implementation related aspects are
   described for the lightweight version protocols.

7.1.  Implementation of Source-Specific Multicast

   [8] illustrates the requirements of implementation of Source-Specific
   Multicast (SSM) on IGMPv3/MLDv2 hosts and routers.  The lightweight
   protocol follows the same rule given in [8] except the changing of
   the message types due to the simplification.

   A LW-IGMPv3/LW-MLDv2 host should not invoke (*,G) join (i.e.,
   TO_EX({})) and (*,G) leave (i.e., TO_IN({})) for the application
   whose multicast address is in the SSM address range.  The upstream
   LW-IGMPv3/LW-MLDv2 router will ignore the these messages and may log
   an error on reception of them.  Other types of messages should be
   processed as [8] describes.

7.2.  Implementation of Multicast Source Filter (MSF) APIs

   Multicast Source Filter (MSF) APIs [9] defines (1) IPv4 Basic MSF
   API, (2) IPv4 Advanced MSF API, (3) Protocol-Independent Basic MSF
   API, and (4) Protocol-Independent Advanced MSF API.

   According to the MSF APIs definition, a LW-IGMPv3 host should
   implement either IPv4 Basic MSF API or Protocol-Independent Basic MSF
   API, and a LW-MLDv2 host should implement Protocol-Independent Basic
   MSF API.  Other APIs, IPv4 Advanced MSF API and Protocol-Independent
   Advanced MSF API, are optional to implement in a LW-IGMPv3/LW-MLDv2
   host.













Liu, et al.              Expires April 17, 2010                [Page 19]

Internet-Draft        Lightweight IGMPv3 and MLDv2          October 2009


8.  Security Considerations

   The security considerations are the same as that of the full version
   of IGMPv3/MLDv2.















































Liu, et al.              Expires April 17, 2010                [Page 20]

Internet-Draft        Lightweight IGMPv3 and MLDv2          October 2009


9.  Acknowledgements

   The authors would like to appreciate MBONED and MAGMA working group
   members.  Special thanks is given to Marshall Eubanks, Guo Feng, Mark
   Fine, Prashant Jhingran, Bharat Joshi, Guo Tao, Wang Wendong, and
   Gong Xiangyang for their valuable comments and suggestions on this
   document.












































Liu, et al.              Expires April 17, 2010                [Page 21]

Internet-Draft        Lightweight IGMPv3 and MLDv2          October 2009


10.  References

10.1.  Normative References

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

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

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

   [4]  Deering, S., "Host Extensions for IP Multicasting", RFC 1112,
        August 1989.

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

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

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

   [8]  Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group
        Management Protocol Version 3 (IGMPv3) and Multicast Listener
        Discovery Protocol Version 2 (MLDv2) for Source-Specific
        Multicast", RFC 4604, August 2006.

10.2.  Informative References

   [9]  Thaler, D., Fenner, B., and B. Quinn, "Socket Interface
        Extensions for Multicast Source Filters", RFC 3678,
        January 2004.















Liu, et al.              Expires April 17, 2010                [Page 22]

Internet-Draft        Lightweight IGMPv3 and MLDv2          October 2009


Authors' Addresses

   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


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

   Email: caowayne@huawei.com


   Hitoshi Asaeda
   Keio University
   Graduate School of Media and Governance
   5322 Endo
   Fujisawa, Kanagawa  252-8520
   Japan

   Email: asaeda@wide.ad.jp





















Liu, et al.              Expires April 17, 2010                [Page 23]


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