rfc3376.txt

xorp源码hg

               [i] fields in this Group Record contain a list of the
               sources that the system no longer wishes to
               hear from, for packets sent to the specified
               multicast address.  If the change was to an INCLUDE
               source list, these are the addresses that were
               deleted from  the list; if the change was to an
               EXCLUDE source list, these are the addresses that
               were added to the list.

   If a change of source list results in both allowing new sources and
   blocking old sources, then two Group Records are sent for the same
   multicast address, one of type ALLOW_NEW_SOURCES and one of type
   BLOCK_OLD_SOURCES.

   We use the term "State-Change Record" to refer to either a Filter-
   Mode-Change Record or a Source-List-Change Record.

   Unrecognized Record Type values MUST be silently ignored.

4.2.13. IP Source Addresses for Reports

   An IGMP report is sent with a valid IP source address for the
   destination subnet.  The 0.0.0.0 source address may be used by a
   system that has not yet acquired an IP address.  Note that the
   0.0.0.0 source address may simultaneously be used by multiple systems
   on a LAN.  Routers MUST accept a report with a source address of
   0.0.0.0.





Cain, et. al.               Standards Track                    [Page 17]

RFC 3376                         IGMPv3                     October 2002


4.2.14. IP Destination Addresses for Reports

   Version 3 Reports are sent with an IP destination address of
   224.0.0.22, to which all IGMPv3-capable multicast routers listen.  A
   system that is operating in version 1 or version 2 compatibility
   modes sends version 1 or version 2 Reports to the multicast group
   specified in the Group Address field of the Report.  In addition, a
   system MUST accept and process any version 1 or version 2 Report
   whose IP Destination Address field contains *any* of the addresses
   (unicast or multicast) assigned to the interface on which the Report
   arrives.

4.2.15. Notation for Group Records

   In the rest of this document, we use the following notation to
   describe the contents of a Group Record pertaining to a particular
   multicast address:

      IS_IN ( x )  -  Type MODE_IS_INCLUDE, source addresses x
      IS_EX ( x )  -  Type MODE_IS_EXCLUDE, source addresses x
      TO_IN ( x )  -  Type CHANGE_TO_INCLUDE_MODE, source addresses x
      TO_EX ( x )  -  Type CHANGE_TO_EXCLUDE_MODE, source addresses x
      ALLOW ( x )  -  Type ALLOW_NEW_SOURCES, source addresses x
      BLOCK ( x )  -  Type BLOCK_OLD_SOURCES, source addresses x

   where x is either:

   o a capital letter (e.g., "A") to represent the set of source
     addresses, or

   o a set expression (e.g., "A+B"), where "A+B" means the union of sets
     A and B, "A*B" means the intersection of sets A and B, and "A-B"
     means the removal of all elements of set B from set A.

4.2.16. Membership Report Size

   If the set of Group Records required in a Report does not fit within
   the size limit of a single Report message (as determined by the MTU
   of the network on which it will be sent), the Group Records are sent
   in as many Report messages as needed to report the entire set.

   If a single Group Record contains so many source addresses that it
   does not fit within the size limit of a single Report message, if its
   Type is not MODE_IS_EXCLUDE or CHANGE_TO_EXCLUDE_MODE, it is split
   into multiple Group Records, each containing a different subset of
   the source addresses and each sent in a separate Report message.  If
   its Type is MODE_IS_EXCLUDE or CHANGE_TO_EXCLUDE_MODE, a single Group
   Record is sent, containing as many source addresses as can fit, and



Cain, et. al.               Standards Track                    [Page 18]

RFC 3376                         IGMPv3                     October 2002


   the remaining source addresses are not reported; though the choice of
   which sources to report is arbitrary, it is preferable to report the
   same set of sources in each subsequent report, rather than reporting
   different sources each time.

5. Description of the Protocol for Group Members

   IGMP is an asymmetric protocol, specifying separate behaviors for
   group members -- that is, hosts or routers that wish to receive
   multicast packets -- and multicast routers.  This section describes
   the part of IGMPv3 that applies to all group members.  (Note that a
   multicast router that is also a group member performs both parts of
   IGMPv3, receiving and responding to its own IGMP message
   transmissions as well as those of its neighbors.  The multicast
   router part of IGMPv3 is described in section 6.)

   A system performs the protocol described in this section over all
   interfaces on which multicast reception is supported, even if more
   than one of those interfaces is connected to the same network.

   For interoperability with multicast routers running older versions of
   IGMP, systems maintain a MulticastRouterVersion variable for each
   interface on which multicast reception is supported.  This section
   describes the behavior of group member systems on interfaces for
   which MulticastRouterVersion = 3.  The algorithm for determining
   MulticastRouterVersion, and the behavior for versions other than 3,
   are described in section 7.

   The all-systems multicast address, 224.0.0.1, is handled as a special
   case.  On all systems -- that is all hosts and routers, including
   multicast routers -- reception of packets destined to the all-systems
   multicast address, from all sources, is permanently enabled on all
   interfaces on which multicast reception is supported.  No IGMP
   messages are ever sent regarding the all-systems multicast address.

   There are two types of events that trigger IGMPv3 protocol actions on
   an interface:

   o a change of the interface reception state, caused by a local
     invocation of IPMulticastListen.

   o reception of a Query.

   (Received IGMP messages of types other than Query are silently
   ignored, except as required for interoperation with earlier versions
   of IGMP.)





Cain, et. al.               Standards Track                    [Page 19]

RFC 3376                         IGMPv3                     October 2002


   The following subsections describe the actions to be taken for each
   of these two cases.  In those descriptions, timer and counter names
   appear in square brackets.  The default values for those timers and
   counters are specified in section 8.

5.1. Action on Change of Interface State

   An invocation of IPMulticastListen may cause the multicast reception
   state of an interface to change, according to the rules in section
   3.2.  Each such change affects the per-interface entry for a single
   multicast address.

   A change of interface state causes the system to immediately transmit
   a State-Change Report 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, according to the table below.  If no interface
   state existed for that multicast address before the change (i.e., the
   change consisted of creating a new per-interface record), or if no
   state exists after the change (i.e., the change consisted of deleting
   a per-interface record), then the "non-existent" state is considered
   to have a filter mode of INCLUDE and an empty source list.

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

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

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

     INCLUDE (A)       EXCLUDE (B)       TO_EX (B)

     EXCLUDE (A)       INCLUDE (B)       TO_IN (B)

   If the computed source list for either an ALLOW or a BLOCK State-
   Change Record is empty, that record is omitted from the Report
   message.

   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]).

   If more changes to the same interface state entry occur before all
   the retransmissions of the State-Change Report for the first change
   have been completed, each such additional change triggers the
   immediate transmission of a new State-Change Report.




Cain, et. al.               Standards Track                    [Page 20]

RFC 3376                         IGMPv3                     October 2002


   The contents of the new transmitted report are calculated as follows.
   As was done with the first report, the interface state for the
   affected group before and after the latest change is compared.  The
   report records expressing the difference are built according to the
   table above.  However these records are not transmitted in a message
   but instead merged with the contents of the pending report, to create
   the new State-Change report.  The rules for merging the difference
   report resulting from the state change and the pending report are
   described below.

   The transmission of the merged State-Change Report terminates
   retransmissions of the earlier State-Change Reports for the same
   multicast address, and becomes the first of [Robustness Variable]
   transmissions of State-Change Reports.

   Each time a source is included in the difference report calculated
   above, retransmission state for that source needs to be maintained
   until [Robustness Variable] State-Change reports have been sent by
   the host.  This is done in order to ensure that a series of
   successive state changes do not break the protocol robustness.

   If the interface reception-state change that triggers the new report
   is a filter-mode change, then the next [Robustness Variable] State-
   Change Reports will include a Filter-Mode-Change record.  This
   applies even if any number of source-list changes occur in that
   period.  The host has to maintain retransmission state for the group
   until the [Robustness Variable] State-Change reports have been sent.
   When [Robustness Variable] State-Change reports with Filter-Mode-
   Change records have been transmitted after the last filter-mode
   change, and if source-list changes to the interface reception have
   scheduled additional reports, then the next State-Change report will
   include Source-List-Change records.

   Each time a State-Change Report is transmitted, the contents are
   determined as follows.  If the report should contain a Filter-Mode-
   Change record, then if the current filter-mode of the interface is
   INCLUDE, a TO_IN record is included in the report, otherwise a TO_EX
   record is included.  If instead the report should contain Source-
   List-Change records, an ALLOW and a BLOCK record are included.  The
   contents of these records are built according to the table below.

      Record   Sources included
      ------   ----------------
      TO_IN    All in the current interface state that must be forwarded
      TO_EX    All in the current interface state that must be blocked
      ALLOW    All with retransmission state that must be forwarded
      BLOCK    All with retransmission state that must be blocked




Cain, et. al.               Standards Track                    [Page 21]

RFC 3376                         IGMPv3                     October 2002


   If the computed source list for either an ALLOW or a BLOCK record is
   empty, that record is omitted from the State-Change report.

   Note: When the first State-Change report is sent, the non-existent
   pending report to merge with, can be treated as a source-change
   report with empty ALLOW and BLOCK records (no sources have
   retransmission state).

5.2. Action on Reception of a Query

   When a system 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.  A 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 system 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.

   When a new Query with the Router-Alert option arrives on an
   interface, provided the system has state to report, a delay for a
   response is randomly selected in the range (0, [Max Resp Time]) where
   Max Resp Time is derived from Max Resp Code in the received Query
   message.  The following rules are then used to determine if a Report
   needs to be scheduled and the type of Report to schedule.  The rules
   are considered in order and only the first matching rule is applied.

   1. If there is a pending response to a previous General Query
      scheduled sooner than the selected delay, no additional response
      needs to be scheduled.

   2. If the received Query is a General Query, the interface timer is
      used to schedule a response to the General Query after the
      selected delay.  Any previously pending response to a General