rfc3376.txt

xorp源码hg

      Query is canceled.




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


   3. If the received Query is a Group-Specific Query or a Group-and-
      Source-Specific Query and there is no pending response to a
      previous Query for this group, then the group timer is used to
      schedule a report.  If the received Query is a Group-and-Source-
      Specific Query, the list of queried sources is recorded to be used
      when generating a response.

   4. If there already is a pending response to a previous Query
      scheduled for this group, and either the new Query is a Group-
      Specific Query or the recorded source-list associated with the
      group is empty, then the group source-list is cleared and a single
      response is scheduled using the group timer.  The new response is
      scheduled to be sent at the earliest of the remaining time for the
      pending report and the selected delay.

   5. If the received Query is a Group-and-Source-Specific Query and
      there is a pending response for this group with a non-empty
      source-list, then the group source list is augmented to contain
      the list of sources in the new Query and a single response is
      scheduled using the group timer.  The new response is scheduled to
      be sent at the earliest of the remaining time for the pending
      report and the selected delay.

   When the timer in a pending response record expires, the system
   transmits, on the associated interface, one or more Report messages
   carrying one or more Current-State Records (see section 4.2.12), as
   follows:

   1. If the expired timer is the interface timer (i.e., it is a pending
      response to a General Query), then one Current-State Record is
      sent for each multicast address for which the specified interface
      has reception state, as described in section 3.2.  The Current-
      State Record carries the multicast address and its associated
      filter mode (MODE_IS_INCLUDE or MODE_IS_EXCLUDE) and source list.
      Multiple Current-State Records are packed into individual Report
      messages, to the extent possible.

      This naive algorithm may result in bursts of packets when a system
      is a member of a large number of groups.  Instead of using a
      single interface timer, implementations are recommended to spread
      transmission of such Report messages over the interval (0, [Max
      Resp Time]).  Note that any such implementation MUST avoid the
      "ack-implosion" problem, i.e., MUST NOT send a Report immediately
      on reception of a General Query.







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


   2. If the expired timer is a group timer and the list of recorded
      sources for the that group is empty (i.e., it is a pending
      response to a Group-Specific Query), then if and only if the
      interface has reception state for that group address, a single
      Current-State Record is sent for that address.  The Current-State
      Record carries the multicast address and its associated filter
      mode (MODE_IS_INCLUDE or MODE_IS_EXCLUDE) and source list.

   3. If the expired timer is a group timer and the list of recorded
      sources for that group is non-empty (i.e., it is a pending
      response to a Group-and-Source-Specific Query), then if and only
      if the interface has reception state for that group address, the
      contents of the responding Current-State Record is determined from
      the interface state and the pending response record, as specified
      in the following table:

                         set of sources in the
      interface state   pending response record   Current-State Record
      ---------------   -----------------------   --------------------

       INCLUDE (A)                B                   IS_IN (A*B)

       EXCLUDE (A)                B                   IS_IN (B-A)

   If the resulting Current-State Record has an empty set of source
   addresses, then no response is sent.

   Finally, after any required Report messages have been generated, the
   source lists associated with any reported groups are cleared.

6. Description of the Protocol for Multicast Routers

   The purpose of IGMP is to enable each multicast router to learn, for
   each of its directly attached networks, which multicast addresses are
   of interest to the systems attached to those networks.  IGMP version
   3 adds the capability for a multicast router to also learn  which
   *sources* are of interest to neighboring systems, for packets sent to
   any particular multicast address.  The information gathered by IGMP
   is provided to whichever multicast routing protocol is being used by
   the router, in order to ensure that multicast packets are delivered
   to all networks where there are interested receivers.

   This section describes the part of IGMPv3 that is performed by
   multicast routers.  Multicast routers may also themselves become
   members of multicast groups, and therefore also perform the group
   member part of IGMPv3, described in section 5.





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


   A multicast router performs the protocol described in this section
   over each of its directly-attached networks.  If a multicast router
   has more than one interface to the same network, it only needs to
   operate this protocol over one of those interfaces.  On each
   interface over which this protocol is being run, the router MUST
   enable reception of multicast address 224.0.0.22, from all sources
   (and MUST perform the group member part of IGMPv3 for that address on
   that interface).

   Multicast routers need to know only that *at least one* system on an
   attached network is interested in packets to a particular multicast
   address from a particular source; a multicast router is not required
   to keep track of the interests of each individual neighboring system.
   (However, see Appendix A.2 point 1 for discussion.)

   IGMPv3 is backward compatible with previous versions of the IGMP
   protocol.  In order to remain backward compatible with older IGMP
   systems, IGMPv3 multicast routers MUST also implement versions 1 and
   2 of the protocol (see section 7).

6.1. Conditions for IGMP Queries

   Multicast routers send General Queries periodically to request group
   membership information from an attached network.  These queries are
   used to build and refresh the group membership state of systems on
   attached networks.  Systems respond to these queries by reporting
   their group membership state (and their desired set of sources) with
   Current-State Group Records in IGMPv3 Membership Reports.

   As a member of a multicast group, a system may express interest in
   receiving or not receiving traffic from particular sources.  As the
   desired reception state of a system changes, it reports these changes
   using Filter-Mode-Change Records or Source-List-Change Records.
   These records indicate an explicit state change in a group at a
   system in either the group record's source list or its filter-mode.
   When a group membership is terminated at a system or traffic from a
   particular source is no longer desired, a multicast router must query
   for other members of the group or listeners of the source before
   deleting the group (or source) and pruning its traffic.

   To enable all systems on a network to respond to changes in group
   membership, multicast routers send specific queries.  A Group-
   Specific Query is sent to verify there are no systems that desire
   reception of the specified group or to "rebuild" the desired
   reception state for a particular group.  Group-Specific Queries are
   sent when a router receives a State-Change record indicating a system
   is leaving a group.




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


   A Group-and-Source Specific Query is used to verify there are no
   systems on a network which desire to receive traffic from a set of
   sources.  Group-and-Source Specific Queries list sources for a
   particular group which have been requested to no longer be forwarded.
   This query is sent by a multicast router to learn if any systems
   desire reception of packets to the specified group address from the
   specified source addresses.  Group-and-Source Specific Queries are
   only sent in response to State-Change Records and never in response
   to Current-State Records.  Section 4.1.11 describes each query in
   more detail.

6.2. IGMP State Maintained by Multicast Routers

   Multicast routers implementing IGMPv3 keep state per group per
   attached network.  This group state consists of a filter-mode, a list
   of sources, and various timers.  For each attached network running
   IGMP, a multicast router records the desired reception state for that
   network.  That state conceptually consists of a set of records of the
   form:

      (multicast address, group timer, filter-mode, (source records))

   Each source record is of the form:

      (source address, source timer)

   If all sources within a given group are desired, an empty source
   record list is kept with filter-mode set to EXCLUDE.  This means
   hosts on this network want all sources for this group to be
   forwarded.  This is the IGMPv3 equivalent to a IGMPv1 or IGMPv2 group
   join.

6.2.1. Definition of Router Filter-Mode

   To reduce internal state, IGMPv3 routers keep a filter-mode per group
   per attached network.  This filter-mode is used to condense the total
   desired reception state of a group to a minimum set such that all
   systems' memberships are satisfied.  This filter-mode may change in
   response to the reception of particular types of group records or
   when certain timer conditions occur.  In the following sections, we
   use the term "router filter-mode" to refer to the filter-mode of a
   particular group within a router.  Section 6.4 describes the changes
   of a router filter-mode per group record received.








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


   Conceptually, when a group record is received, the router filter-mode
   for that group is updated to cover all the requested sources using
   the least amount of state.  As a rule, once a group record with a
   filter-mode of EXCLUDE is received, the router filter-mode for that
   group will be EXCLUDE.

   When a router filter-mode for a group is EXCLUDE, the source record
   list contains two types of sources.  The first type is the set which
   represents conflicts in the desired reception state; this set must be
   forwarded by some router on the network.  The second type is the set
   of sources which hosts have requested to not be forwarded.  Appendix
   A describes the reasons for keeping this second set when in EXCLUDE
   mode.

   When a router filter-mode for a group is INCLUDE, the source record
   list is the list of sources desired for the group.  This is the total
   desired set of sources for that group.  Each source in the source
   record list must be forwarded by some router on the network.

   Because a reported group record with a filter-mode of EXCLUDE will
   cause a router to transition its filter-mode for that group to
   EXCLUDE, a mechanism for transitioning a router's filter-mode back to
   INCLUDE must exist.  If all systems with a group record in EXCLUDE
   filter-mode cease reporting, it is desirable for the router filter-
   mode for that group to transition back to INCLUDE mode.  This
   transition occurs when the group timer expires and is explained in
   detail in section 6.5.

6.2.2. Definition of Group Timers

   The group timer is only used when a group is in EXCLUDE mode and it
   represents the time for the *filter-mode* of the group to expire and
   switch to INCLUDE mode.  We define a group timer as a decrementing
   timer with a lower bound of zero kept per group per attached network.
   Group timers are updated according to the types of group records
   received.

   A group timer expiring when a router filter-mode for the group is
   EXCLUDE means there are no listeners on the attached network in
   EXCLUDE mode.  At this point, a router will transition to INCLUDE
   filter-mode.  Section 6.5 describes the actions taken when a group
   timer expires while in EXCLUDE mode.

   The following table summarizes the role of the group timer.  Section
   6.4 describes the details of setting the group timer per type of
   group record received.





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


      Group
      Filter-Mode      Group Timer Value      Actions/Comments
      -----------      -----------------      ----------------

      INCLUDE          Timer >= 0             All members in INCLUDE
                                              mode.

      EXCLUDE          Timer > 0              At least one member in
                                              EXCLUDE mode.

      EXCLUDE          Timer == 0             No more listeners to
                                              group.  If all source
                                              timers have expired then
                                              delete Group Record.
                                              If there are still
                                              source record timers