doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc5790.txt b/doc/rfc/rfc5790.txt
new file mode 100644
index 0000000..0f4e3ac
--- /dev/null
+++ b/doc/rfc/rfc5790.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                            H. Liu
+Request for Comments: 5790                                        W. Cao
+Category: Standards Track                            Huawei Technologies
+ISSN: 2070-1721                                                H. Asaeda
+                                                         Keio University
+                                                           February 2010
+
+
+ Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and
+        Multicast Listener Discovery Version 2 (MLDv2) Protocols
+
+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.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc5790.
+
+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.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+Liu, et al.                  Standards Track                    [Page 1]
+
+RFC 5790              Lightweight IGMPv3 and MLDv2         February 2010
+
+
+   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.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Terminology .....................................................4
+   3. Simplification Method Overview ..................................4
+      3.1. Behavior of Group Members ..................................5
+      3.2. Behavior of Multicast Routers ..............................5
+   4. LW-IGMPv3 Protocol for Group Members ............................6
+      4.1. Query and Report Messages ..................................6
+      4.2. Action on Change of Interface State ........................6
+      4.3. Action on Reception of a Query .............................7
+      4.4. LW-IGMPv3 Group Record Types ...............................7
+   5. LW-IGMPv3 Protocol for Multicast Routers ........................9
+      5.1. Group Timers and Source Timers in the Lightweight Version ..9
+      5.2. Source-Specific Forwarding Rules ..........................10
+      5.3. Reception of Current-State Records ........................10
+      5.4. Reception of Source-List-Change and
+           Filter-Mode-Change Records ................................12
+   6. Interoperability ...............................................13
+      6.1. Interoperation with the Full Version of IGMPv3/MLDv2 ......13
+           6.1.1. Behavior of Group Members ..........................13
+           6.1.2. Behavior of Multicast Routers ......................13
+      6.2. Interoperation with IGMPv1/IGMPv2 .........................14
+           6.2.1. Behavior of Group Members ..........................14
+           6.2.2. Behavior of Multicast Routers ......................14
+      6.3. Interoperation with MLDv1 .................................15
+   7. Implementation Considerations ..................................15
+      7.1. Implementation of Source-Specific Multicast ...............15
+      7.2. Implementation of Multicast Source Filter (MSF) APIs ......16
+   8. Security Considerations ........................................16
+   9. Acknowledgements ...............................................16
+   10. References ....................................................16
+      10.1. Normative References .....................................16
+      10.2. Informative References ...................................17
+
+
+
+
+
+Liu, et al.                  Standards Track                    [Page 2]
+
+RFC 5790              Lightweight IGMPv3 and MLDv2         February 2010
+
+
+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 that are of interest or that are
+   not of interest 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 explicitly refuses
+   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 will still be 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.                  Standards Track                    [Page 3]
+
+RFC 5790              Lightweight IGMPv3 and MLDv2         February 2010
+
+
+   They support both Any-Source Multicast (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.
+
+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 a group G.  In
+   this case, the host receives from all sources sending to group G.
+   This is typical in ASM communication.
+
+   (S,G) join:
+   An operation triggered by a host that wants to join a group G,
+   specifying a desired source S.  In this case, the host receives
+   traffic 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, specifying a desired source S.  Same meaning as
+   (S,G) join.
+
+   EXCLUDE (*,G) join:
+   An operation triggered by a host that wants to join a group G under
+   EXCLUDE filter-mode.  Same meaning as (*,G) join.
+
+   EXCLUDE (S,G) join:
+   An operation triggered by a host that wants to join a group G under
+   EXCLUDE filter-mode, specifying an undesired source S.  This
+   operation is not supported by LW-IGMPv3/LW-MLDv2.
+
+3.  Simplification Method Overview
+
+   The principle is to simplify the host's 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.
+
+
+
+Liu, et al.                  Standards Track                    [Page 4]
+
+RFC 5790              Lightweight IGMPv3 and MLDv2         February 2010
+
+
+   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
+
+   LW-IGMPv3 inherits the service interface model of IGMPv3.
+
+     IPMulticastListen ( socket, interface, multicast-address,
+                         filter-mode, source-list )
+
+   In the lightweight protocol, INCLUDE mode on the host part has the
+   same usage as 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].  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.  The group timer is used to identify such a 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 routers 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,
+   the router may change to reception of the listed sources only.  The
+   definition of the source record is the same as in the full version.
+
+   The elimination of the filter-mode will greatly simplify the router
+   behavior.  The details of router operation are described in
+   Section 5.
+
+
+
+
+
+Liu, et al.                  Standards Track                    [Page 5]
+
+RFC 5790              Lightweight IGMPv3 and MLDv2         February 2010
+
+
+4.  LW-IGMPv3 Protocol for Group Members
+
+4.1.  Query and Report Messages
+
+   LW-IGMPv3 uses the same two sets of messages, Query and Report
+   messages, 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: the
+   Current-State Record denoted by MODE_IS_INCLUDE (referred to as
+   IS_IN) or MODE_IS_EXCLUDE (IS_EX), the Filter-Mode-Change Record
+   denoted by CHANGE_TO_INCLUDE_MODE (TO_IN) or CHANGE_TO_EXCLUDE_MODE
+   (TO_EX), and the Source-List-Change Record denoted by
+   ALLOW_NEW_SOURCES (ALLOW) or BLOCK_OLD_SOURCES (BLOCK).  LW-IGMPv3
+   inherits the actions on change of interface state and on reception of
+   a query, but the IS_IN and IS_EX record types are eliminated and
+   Current-State Records are replaced 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 for the computation are the same as for the
+   full version, in a 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 Report 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)
+
+
+
+
+
+
+
+Liu, et al.                  Standards Track                    [Page 6]
+
+RFC 5790              Lightweight IGMPv3 and MLDv2         February 2010
+
+
+   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
+   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 the 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 into a record having a
+   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.                  Standards Track                    [Page 7]
+
+RFC 5790              Lightweight IGMPv3 and MLDv2         February 2010
+
+
+      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 a null source address list.  For instance, IS_EX({}) means
+   a report whose record type is IS_EX with a 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 an 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 exactly the
+   same, the IS_IN(x) type is eliminated for simplification.
+
+   An LW-IGMPv3 host does not use EXCLUDE mode, while TO_IN and TO_EX
+   records are used for example in 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.                  Standards Track                    [Page 8]
+
+RFC 5790              Lightweight IGMPv3 and MLDv2         February 2010
+
+
+   Although an LW-IGMPv3 host adopts the four message types (ALLOW,
+   BLOCK, TO_IN, and TO_EX) for simplification, using IS_EX({}) and
+   IS_IN(x) (respectively, instead of TO_EX({}) and ALLOW(x)) in
+   response to queries is not inhibited.  This will not introduce the
+   interoperation problem because the router process is, respectively,
+   the same for the mentioned two message set, as long as the router
+   implementation follows the rules given by full IGMPv3.
+
+5.  LW-IGMPv3 Protocol for Multicast Routers
+
+   The major difference between the full and lightweight version
+   protocols on the router part is that in 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 source and needs
+   to be referred to 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 state maintained 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 only.  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.
+
+
+
+
+
+Liu, et al.                  Standards Track                    [Page 9]
+
+RFC 5790              Lightweight IGMPv3 and MLDv2         February 2010
+
+
+   The operation related to the group and source timers has some
+   differences compared to 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.
+
+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, 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 forwarding
+                                            traffic from 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
+
+
+
+Liu, et al.                  Standards Track                   [Page 10]
+
+RFC 5790              Lightweight IGMPv3 and MLDv2         February 2010
+
+
+   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 messages of
+   the full version, the LW-IGMPv3 router should be able to process as
+   many messages as possible to be compatible with the full version
+   host.  Note that if the report type is IS_EX(x) with a non-empty
+   source-list, the router will treat it as the same type of report with
+   an 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 those 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 since the processes are
+   exactly the 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 a
+   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.
+
+
+
+
+Liu, et al.                  Standards Track                   [Page 11]
+
+RFC 5790              Lightweight IGMPv3 and MLDv2         February 2010
+
+
+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 a non-empty source-list, the router will treat it as
+   the same type of report with an empty source-list.  The table below
+   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:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Liu, et al.                  Standards Track                   [Page 12]
+
+RFC 5790              Lightweight IGMPv3 and MLDv2         February 2010
+
+
+          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
+
+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 formats
+   of the group Query and Report messages that the full version
+   protocols use.
+
+6.1.1.  Behavior of Group Members
+
+   An 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
+
+   An LW-IGMPv3 or LW-MLDv2 router does not process directly IS_EX(x)
+   and TO_EX(x) reports that are used by the full version.  When an LW-
+   IGMPv3/LW-MLDv2 router receives these Report messages from full
+   version hosts, it MUST translate them internally to IS_EX({}) and
+   TO_EX({}) respectively and behave accordingly.
+
+
+
+
+
+
+Liu, et al.                  Standards Track                   [Page 13]
+
+RFC 5790              Lightweight IGMPv3 and MLDv2         February 2010
+
+
+6.2.  Interoperation with IGMPv1/IGMPv2
+
+   Since the lightweight protocols can be treated as a parallel version
+   of the 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.
+
+   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 an LW-IGMPv3 router when placed on a network where
+   there are routers that have not been upgraded to IGMPv3 is exactly
+   the same as for 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 applies to the group.  This value
+   is set according to the version of the received IGMP reports.  When
+   Group Compatibility Mode is IGMPv3, the lightweight router performs
+   the LW-IGMPv3 protocol for that group.
+
+   When Group Compatibility Mode is IGMPv2, an LW-IGMPv3 router inherits
+   this compatibility mechanism with the following rules:
+
+                 IGMP Message          LW-IGMPv3 Equivalent
+                --------------         --------------------
+
+                  v2 Report                 TO_EX({})
+
+                  v2 Leave                  TO_IN({})
+
+
+
+
+
+Liu, et al.                  Standards Track                   [Page 14]
+
+RFC 5790              Lightweight IGMPv3 and MLDv2         February 2010
+
+
+   When Group Compatibility Mode is IGMPv1, an 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 hosts and routers
+   running MLDv1.  The method is the same as described in Section 6.2.
+   The difference is that when an LW-MLDv2 router has a MLDv1 listener
+   on its network, it translates the following MLDv1 messages to their
+   LW-MLDv2 equivalents:
+
+                 MLDv1 Message         LW-MLDv2 Equivalent
+                 -------------         -------------------
+
+                   Report                  TO_EX({})
+
+                   Done                    TO_IN({})
+
+7.  Implementation Considerations
+
+   The lightweight protocols require no additional procedure for 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
+   run IGMPv3/MLDv2 (snooping) and multicast routing protocols may be
+   greatly decreased.
+
+7.1.  Implementation of Source-Specific Multicast
+
+   [8] specifies the requirements for the implementation of Source-
+   Specific Multicast (SSM) on IGMPv3/MLDv2 hosts and routers.  The
+   lightweight protocol follows the same rules as given in [8] except
+   for the change of the message types due to the simplification.
+
+   An LW-IGMPv3/LW-MLDv2 host should not invoke (*,G) join (i.e.,
+   TO_EX({})) and (*,G) leave (i.e., TO_IN({})) for applications whose
+   multicast addresses are in the SSM address range.  An upstream LW-
+   IGMPv3/LW-MLDv2 router MUST NOT establish forwarding state and MAY
+   log an error on reception of them as described in [7].
+
+
+
+
+Liu, et al.                  Standards Track                   [Page 15]
+
+RFC 5790              Lightweight IGMPv3 and MLDv2         February 2010
+
+
+7.2.  Implementation of Multicast Source Filter (MSF) APIs
+
+   [9] defines the following Multicast Source Filter (MSF) APIs: (1)
+   IPv4 Basic MSF APIs, (2) IPv4 Advanced MSF APIs, (3) Protocol-
+   Independent Basic MSF APIs, and (4) Protocol-Independent Advanced MSF
+   APIs.
+
+   According to the MSF API definition, an LW-IGMPv3 host should
+   implement either the IPv4 Basic MSF API or the Protocol-Independent
+   Basic MSF API, and an LW-MLDv2 host should implement the Protocol-
+   Independent Basic MSF API.  Other APIs, IPv4 Advanced MSF API and
+   Protocol-Independent Advanced MSF API, are optional to implement in
+   an LW-IGMPv3/LW-MLDv2 host.
+
+8.  Security Considerations
+
+   The security considerations are the same as that of the full version
+   of IGMPv3/MLDv2.
+
+9.  Acknowledgements
+
+   The authors would like to thank MBONED and MAGMA working group
+   members.  Special thanks is given to Marshall Eubanks, Guo Feng, Mark
+   Fine, Alfred Hoenes, Prashant Jhingran, Bharat Joshi, Guo Tao, Wang
+   Wendong, and Gong Xiangyang for their valuable suggestions and
+   comments on this document.
+
+10.  References
+
+10.1.  Normative References
+
+   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, 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", STD 5,
+        RFC 1112, August 1989.
+
+   [5]  Fenner, W., "Internet Group Management Protocol, Version 2",
+        RFC 2236, November 1997.
+
+
+
+
+
+Liu, et al.                  Standards Track                   [Page 16]
+
+RFC 5790              Lightweight IGMPv3 and MLDv2         February 2010
+
+
+   [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.
+
+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.                  Standards Track                   [Page 17]
+