rfc3376.txt

xorp源码hg

     Filtering of packets based upon a socket's multicast reception
     state is a new feature of this service interface.  The previous
     service interface [RFC1112] described no filtering based upon
     multicast join state; rather, a join on a socket simply caused the
     host to join a group on the given interface, and packets destined
     for that group could be delivered to all sockets whether they had
     joined or not.

     The general rules for deriving the per-interface state from the
     per-socket state are as follows:  For each distinct (interface,
     multicast-address) pair that appears in any socket state, a per-
     interface record is created for that multicast address on that
     interface.  Considering all socket records containing the same
     (interface, multicast-address) pair,

   o if *any* such record has a filter mode of EXCLUDE, then the filter
     mode of the interface record is EXCLUDE, and the source list of the
     interface record is the intersection of the source lists of all
     socket records in EXCLUDE mode, minus those source addresses that
     appear in any socket record in INCLUDE mode.  For example, if the
     socket records for multicast address m on interface i are:

        from socket s1:  ( i, m, EXCLUDE, {a, b, c, d} )
        from socket s2:  ( i, m, EXCLUDE, {b, c, d, e} )
        from socket s3:  ( i, m, INCLUDE, {d, e, f} )





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


     then the corresponding interface record on interface i is:

                         ( m, EXCLUDE, {b, c} )

     If a fourth socket is added, such as:

        from socket s4:  ( i, m, EXCLUDE, {} )

     then the interface record becomes:

                         ( m, EXCLUDE, {} )

   o if *all* such records have a filter mode of INCLUDE, then the
     filter mode of the interface record is INCLUDE, and the source list
     of the interface record is the union of the source lists of all the
     socket records.  For example, if the socket records for multicast
     address m on interface i are:

        from socket s1:  ( i, m, INCLUDE, {a, b, c} )
        from socket s2:  ( i, m, INCLUDE, {b, c, d} )
        from socket s3:  ( i, m, INCLUDE, {e, f} )

     then the corresponding interface record on interface i is:

                         ( m, INCLUDE, {a, b, c, d, e, f} )

     An implementation MUST NOT use an EXCLUDE interface record to
     represent a group when all sockets for this group are in INCLUDE
     state.  If system resource limits are reached when an interface
     state source list is calculated, an error MUST be returned to the
     application which requested the operation.

   The above rules for deriving the interface state are (re-)evaluated
   whenever an IPMulticastListen invocation modifies the socket state by
   adding, deleting, or modifying a per-socket state record.  Note that
   a change  of socket state does not necessarily result in a change of
   interface state.

4. Message Formats

   IGMP messages are encapsulated in IPv4 datagrams, with an IP protocol
   number of 2.  Every IGMP message described in this document is sent
   with an IP Time-to-Live of 1, IP Precedence of Internetwork Control
   (e.g., Type of Service 0xc0), and carries an IP Router Alert option
   [RFC-2113] in its IP header.  IGMP message types are registered by
   the IANA [IANA-REG] as described by [RFC-3228].





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


   There are two IGMP message types of concern to the IGMPv3 protocol
   described in this document:

      Type Number (hex)   Message Name
      -----------------   ------------

            0x11          Membership Query

            0x22          Version 3 Membership Report

   An implementation of IGMPv3 MUST also support the following three
   message types, for interoperation with previous versions of IGMP (see
   section 7):

           0x12          Version 1 Membership Report    [RFC-1112]

           0x16          Version 2 Membership Report    [RFC-2236]

           0x17          Version 2 Leave Group          [RFC-2236]

   Unrecognized message types MUST be silently ignored.  Other message
   types may be used by newer versions or extensions of IGMP, by
   multicast routing protocols, or for other uses.

   In this document, unless otherwise qualified, the capitalized words
   "Query" and "Report" refer to IGMP Membership Queries and IGMP
   Version 3 Membership Reports, respectively.

4.1. Membership Query Message

   Membership Queries are sent by IP multicast routers to query the
   multicast reception state of neighboring interfaces.  Queries have
   the following format:


















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


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Type = 0x11  | Max Resp Code |           Checksum            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Group Address                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Resv  |S| QRV |     QQIC      |     Number of Sources (N)     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Source Address [1]                      |
      +-                                                             -+
      |                       Source Address [2]                      |
      +-                              .                              -+
      .                               .                               .
      .                               .                               .
      +-                                                             -+
      |                       Source Address [N]                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.1.1. Max Resp Code

   The Max Resp Code field specifies the maximum time allowed before
   sending a responding report.  The actual time allowed, called the Max
   Resp Time, is represented in units of 1/10 second and is derived from
   the Max Resp Code as follows:

   If Max Resp Code < 128, Max Resp Time = Max Resp Code

   If Max Resp Code >= 128, Max Resp Code represents a floating-point
   value as follows:

       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      |1| exp | mant  |
      +-+-+-+-+-+-+-+-+

   Max Resp Time = (mant | 0x10) << (exp + 3)

   Small values of Max Resp Time allow IGMPv3 routers to tune the "leave
   latency" (the time between the moment the last host leaves a group
   and the moment the routing protocol is notified that there are no
   more members).  Larger values, especially in the exponential range,
   allow tuning of the burstiness of IGMP traffic on a network.








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


4.1.2. Checksum

   The Checksum is the 16-bit one's complement of the one's complement
   sum of the whole IGMP message (the entire IP payload).  For computing
   the checksum, the Checksum field is set to zero.  When receiving
   packets, the checksum MUST be verified before processing a packet.
   [RFC-1071]

4.1.3. Group Address

   The Group Address field is set to zero when sending a General Query,
   and set to the IP multicast address being queried when sending a
   Group-Specific Query or Group-and-Source-Specific Query (see section
   4.1.9, below).

4.1.4. Resv (Reserved)

   The Resv field is set to zero on transmission, and ignored on
   reception.

4.1.5. S Flag (Suppress Router-Side Processing)

   When set to one, the S Flag indicates to any receiving multicast
   routers that they are to suppress the normal timer updates they
   perform upon hearing a Query.  It does not, however, suppress the
   querier election or the normal "host-side" processing of a Query that
   a router may be required to perform as a consequence of itself being
   a group member.

4.1.6. QRV (Querier's Robustness Variable)

   If non-zero, the QRV field contains the [Robustness Variable] value
   used by the querier, i.e., the sender of the Query.  If the querier's
   [Robustness Variable] exceeds 7, the maximum value of the QRV field,
   the QRV is set to zero.  Routers adopt the QRV value from the most
   recently received Query as their own [Robustness Variable] value,
   unless that most recently received QRV was zero, in which case the
   receivers use the default [Robustness Variable] value specified in
   section 8.1 or a statically configured value.

4.1.7. QQIC (Querier's Query Interval Code)

   The Querier's Query Interval Code field specifies the [Query
   Interval] used by the querier.  The actual interval, called the
   Querier's Query Interval (QQI), is represented in units of seconds
   and is derived from the Querier's Query Interval Code as follows:





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


   If QQIC < 128, QQI = QQIC

   If QQIC >= 128, QQIC represents a floating-point value as follows:

       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      |1| exp | mant  |
      +-+-+-+-+-+-+-+-+

   QQI = (mant | 0x10) << (exp + 3)

   Multicast routers that are not the current querier adopt the QQI
   value from the most recently received Query as their own [Query
   Interval] value, unless that most recently received QQI was zero, in
   which case the receiving routers use the default [Query Interval]
   value specified in section 8.2.

4.1.8. Number of Sources (N)

   The Number of Sources (N) field specifies how many source addresses
   are present in the Query.  This number is zero in a General Query or
   a Group-Specific Query, and non-zero in a Group-and-Source-Specific
   Query.  This number is limited by the MTU of the network over which
   the Query is transmitted.  For example, on an Ethernet with an MTU of
   1500 octets, the IP header including the Router Alert option consumes
   24 octets, and the IGMP fields up to including the Number of Sources
   (N) field consume 12 octets, leaving 1464 octets for source
   addresses, which limits the number of source addresses to 366
   (1464/4).

4.1.9. Source Address [i]

   The Source Address [i] fields are a vector of n IP unicast addresses,
   where n is the value in the Number of Sources (N) field.

4.1.10. Additional Data

   If the Packet Length field in the IP header of a received Query
   indicates that there are additional octets of data present, beyond
   the fields described here, IGMPv3 implementations MUST include those
   octets in the computation to verify the received IGMP Checksum, but
   MUST otherwise ignore those additional octets.  When sending a Query,
   an IGMPv3 implementation MUST NOT include additional octets beyond
   the fields described here.