rfc1112.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   the total number of Reports transmitted, two techniques are used:

      1. When a host receives a Query, rather than sending Reports
         immediately, it starts a report delay timer for each of its
         group memberships on the network interface of the incoming
         Query.  Each timer is set to a different, randomly-chosen
         value between zero and D seconds.  When a timer expires, a
         Report is generated for the corresponding host group.  Thus,
         Reports are spread out over a D second interval instead of
         all occurring at once.

      2. A Report is sent with an IP destination address equal to the
         host group address being reported, and with an IP
         time-to-live of 1, so that other members of the same group on
         the same network can overhear the Report.  If a host hears a
         Report for a group to which it belongs on that network, the
         host stops its own timer for that group and does not generate
         a Report for that group.  Thus, in the normal case, only one
         Report will be generated for each group present on the
         network, by the member host whose delay timer expires first.
         Note that the multicast routers receive all IP multicast
         datagrams, and therefore need not be addressed explicitly.
         Further note that the routers need not know which hosts
         belong to a group, only that at least one host belongs to a
         group on a particular network.

   There are two exceptions to the behavior described above.  First, if
   a report delay timer is already running for a group membership when a
   Query is received, that timer is not reset to a new random value, but
   rather allowed to continue running with its current value.  Second, a
   report delay timer is never set for a host's membership in the all-
   hosts group (224.0.0.1), and that membership is never reported.



Deering                                                        [Page 12]

RFC 1112          Host Extensions for IP Multicasting        August 1989


   If a host uses a pseudo-random number generator to compute the
   reporting delays, one of the host's own individual IP address should
   be used as part of the seed for the generator, to reduce the chance
   of multiple hosts generating the same sequence of delays.

   A host should confirm that a received Report has the same IP host
   group address in its IP destination field and its IGMP group address
   field, to ensure that the host's own Report is not cancelled by an
   erroneous received Report.  A host should quietly discard any IGMP
   message of type other than Host Membership Query or Host Membership
   Report.

   Multicast routers send Queries periodically to refresh their
   knowledge of memberships present on a particular network.  If no
   Reports are received for a particular group after some number of
   Queries, the routers assume that that group has no local members and
   that they need not forward remotely-originated multicasts for that
   group onto the local network.  Queries are normally sent infrequently
   (no more than once a minute) so as to keep the IGMP overhead on hosts
   and networks very low.  However, when a multicast router starts up,
   it may issue several closely-spaced Queries in order to build up its
   knowledge of local memberships quickly.

   When a host joins a new group, it should immediately transmit a
   Report for that group, rather than waiting for a Query, in case it is
   the first member of that group on the network.  To cover the
   possibility of the initial Report being lost or damaged, it is
   recommended that it be repeated once or twice after short delays.  (A
   simple way to accomplish this is to act as if a Query had been
   received for that group only, setting the group's random report delay
   timer.  The state transition diagram below illustrates this
   approach.)

   Note that, on a network with no multicast routers present, the only
   IGMP traffic is the one or more Reports sent whenever a host joins a
   new group.

State Transition Diagram

   IGMP behavior is more formally specified by the state transition
   diagram below.  A host may be in one of three possible states, with
   respect to any single IP host group on any single network interface:

      - Non-Member state, when the host does not belong to the group
        on the interface.  This is the initial state for all
        memberships on all network interfaces; it requires no storage
        in the host.




Deering                                                        [Page 13]

RFC 1112          Host Extensions for IP Multicasting        August 1989


      - Delaying Member state, when the host belongs to the group on
        the interface and has a report delay timer running for that
        membership.

      - Idle Member state, when the host belongs to the group on the
        interface and does not have a report delay timer running for
        that membership.

   There are five significant events that can cause IGMP state
   transitions:

      - "join group" occurs when the host decides to join the group on
        the interface.  It may occur only in the Non-Member state.

      - "leave group" occurs when the host decides to leave the group
        on the interface.  It may occur only in the Delaying Member
        and Idle Member states.

      - "query received" occurs when the host receives a valid IGMP
        Host Membership Query message.  To be valid, the Query message
        must be at least 8 octets long, have a correct IGMP
        checksum and have an IP destination address of 224.0.0.1.
        A single Query applies to all memberships on the
        interface from which the Query is received.  It is ignored for
        memberships in the Non-Member or Delaying Member state.

      - "report received" occurs when the host receives a valid IGMP
        Host Membership Report message.  To be valid, the Report
        message must be at least 8 octets long, have a correct IGMP
        checksum, and contain the same IP host group address in its IP
        destination field and its IGMP group address field.  A Report
        applies only to the membership in the group identified by the
        Report, on the interface from which the Report is received.
        It is ignored for memberships in the Non-Member or Idle Member
        state.

      - "timer expired" occurs when the report delay timer for the
        group on the interface expires.  It may occur only in the
        Delaying Member state.

   All other events, such as receiving invalid IGMP messages, or IGMP
   messages other than Query or Report, are ignored in all states.

   There are three possible actions that may be taken in response to the
   above events:

      - "send report" for the group on the interface.




Deering                                                        [Page 14]

RFC 1112          Host Extensions for IP Multicasting        August 1989


      - "start timer" for the group on the interface, using a random
        delay value between 0 and D seconds.

      - "stop timer" for the group on the interface.

   In the following diagram, each state transition arc is labelled with
   the event that causes the transition, and, in parentheses, any
   actions taken during the transition.

                              ________________
                             |                |
                             |                |
                             |                |
                             |                |
                   --------->|   Non-Member   |<---------
                  |          |                |          |
                  |          |                |          |
                  |          |                |          |
                  |          |________________|          |
                  |                   |                  |
                  | leave group       | join group       | leave group
                  | (stop timer)      |(send report,     |
                  |                   | start timer)     |
          ________|________           |          ________|________
         |                 |<---------          |                 |
         |                 |                    |                 |
         |                 |<-------------------|                 |
         |                 |   query received   |                 |
         | Delaying Member |    (start timer)   |   Idle Member   |
         |                 |------------------->|                 |
         |                 |   report received  |                 |
         |                 |    (stop timer)    |                 |
         |_________________|------------------->|_________________|
                                timer expired
                                (send report)

   The all-hosts group (address 224.0.0.1) is handled as a special case.
   The host starts in Idle Member state for that group on every
   interface, never transitions to another state, and never sends a
   report for that group.

Protocol Parameters

   The maximum report delay, D, is 10 seconds.







Deering                                                        [Page 15]

RFC 1112          Host Extensions for IP Multicasting        August 1989


APPENDIX II. HOST GROUP ADDRESS ISSUES

   This appendix is not part of the IP multicasting specification, but
   provides background discussion of several issues related to IP host
   group addresses.

Group Address Binding

   The binding of IP host group addresses to physical hosts may be
   considered a generalization of the binding of IP unicast addresses.
   An IP unicast address is statically bound to a single local network
   interface on a single IP network.  An IP host group address is
   dynamically bound to a set of local network interfaces on a set of IP
   networks.

   It is important to understand that an IP host group address is NOT
   bound to a set of IP unicast addresses.  The multicast routers do not
   need to maintain a list of individual members of each host group.
   For example, a multicast router attached to an Ethernet need
   associate only a single Ethernet multicast address with each host
   group having local members, rather than a list of the members'
   individual IP or Ethernet addresses.

Allocation of Transient Host Group Addresses

   This memo does not specify how transient group address are allocated.
   It is anticipated that different portions of the IP transient host
   group address space will be allocated using different techniques.
   For example, there may be a number of servers that can be contacted
   to acquire a new transient group address.  Some higher-level
   protocols (such as VMTP, specified in RFC-1045) may generate higher-
   level transient "process group" or "entity group" addresses which are
   then algorithmically mapped to a subset of the IP transient host
   group addresses, similarly to the way that IP host group addresses
   are mapped to Ethernet multicast addresses.  A portion of the IP
   group address space may be set aside for random allocation by
   applications that can tolerate occasional collisions with other
   multicast users, perhaps generating new addresses until a suitably
   "quiet" one is found.

   In general, a host cannot assume that datagrams sent to any host
   group address will reach only the intended hosts, or that datagrams
   received as a member of a transient host group are intended for the
   recipient.  Misdelivery must be detected at a level above IP, using
   higher-level identifiers or authentication tokens.  Information
   transmitted to a host group address should be encrypted or governed
   by administrative routing controls if the sender is concerned about
   unwanted listeners.



Deering                                                        [Page 16]

RFC 1112          Host Extensions for IP Multicasting        August 1989


Author's Address

   Steve Deering
   Stanford University
   Computer Science Department
   Stanford, CA 94305-2140

   Phone: [phone]

   EMail: [e-mail]









































Deering                                                        [Page 17]