rfc1054.txt

RFC 的详细文档！

   to provide two new operations:

                 JoinHostGroup  ( group-address, interface )

                 LeaveHostGroup ( group-address, interface )

   The JoinHostGroup operation requests that this host become a member
   of the host group identified by "group-address" on the given network
   interface.  The LeaveGroup operation requests that this host give up
   its membership in the host group identified by "group-address" on the
   given network interface.  The interface argument may be omitted on
   hosts that may be attached to only one network.  For hosts that may
   be attached to more than one network, the upper-layer protocol may
   choose to leave the interface unspecified, in which case the request
   will apply to the default interface for sending multicast datagrams
   (see section 6.1).

   It is permissible to join the same group on more than one interface,
   in which case duplicate multicast datagrams may be received.  It is
   also permissible for more than one upper-layer protocol to request
   membership in the same group.

   Both operations should return immediately (i.e., they are non-
   blocking operations), indicating success or failure.  Either
   operation may fail due to an invalid group address or interface
   identifier.  JoinHostGroup may fail due to lack of local resources.
   LeaveHostGroup may fail because the host does not belong to the given
   group on the given interface.  LeaveHostGroup may succeed, but the
   membership persist, if more than one upper-layer protocol has
   requested membership in the same group.



Deering                                                         [Page 7]

RFC 1054          Host Extensions for IP Multicasting           May 1988


7.2. Extensions to the IP Module

   To support the reception of multicast IP datagrams, the IP module
   must be extended to maintain a list of host group memberships
   associated with each network interface.  An incoming datagram
   destined to one of those groups is processed exactly the same way as
   datagrams destined to one of the host's individual addresses.

   Incoming datagrams destined to groups to which the host does not
   belong are discarded without generating any error report.  On hosts
   attached to more than one network, if a datagram arrives via one
   network interface, destined for a group to which the host belongs
   only on a different interface, the datagram is quietly discarded.
   (These cases should occur only as a result of inadequate multicast
   address filtering in a local network module.)

   An incoming datagram is not rejected for having an IP time-to-live of
   1 (i.e., the time-to-live should not automatically be decremented on
   arriving datagrams that are not being forwarded).  An incoming
   datagram is not rejected for having an IP host group address in its
   source address field or anywhere in a source routing option.  An ICMP
   error message (Destination Unreachable, Time Exceeded, Parameter
   Problem, Source Quench, or Redirect) is never generated in response
   to a datagram destined to an IP host group.

   The list of host group memberships is updated in response to
   JoinHostGroup and LeaveHostGroup requests from upper-layer protocols.
   Each membership should have an associated reference count or similar
   mechanism to handle multiple requests to join and leave the same
   group.  On the first request to join and the last request to leave a
   group on a given interface, the local network module for that
   interface is notified, so that it may update its multicast reception
   filter (see section 7.3).

   The IP module must also be extended to implement the IGMP protocol,
   specified in Appendix I. IGMP is used to keep neighboring multicast
   routers informed of the host group memberships present on a
   particular local network.  To support IGMP, every level 2 host must
   join the "all-hosts" group (address 224.0.0.1) on each network
   interface at initialization time and must remain a member for as long
   as the host is active.

   (Datagrams addressed to the all-hosts group are recognized as a
   special case by the multicast routers and are never forwarded beyond
   a single network, regardless of their time-to-live.  Thus, the all-
   hosts address may not be used as an internet-wide broadcast address.
   For the purpose of IGMP, membership in the all-hosts group is really
   necessary only while the host belongs to at least one other group.



Deering                                                         [Page 8]

RFC 1054          Host Extensions for IP Multicasting           May 1988


   However, it is specified that the host shall remain a member of the
   all-hosts group at all times because (1) it is simpler, (2) the
   frequency of reception of unnecessary IGMP queries should be low
   enough that overhead is negligible, and (3) the all-hosts address may
   serve other routing-oriented purposes, such as advertising the
   presence of gateways or resolving local addresses.)

7.3. Extensions to the Local Network Service Interface

   Incoming local network multicast packets are delivered to the IP
   module using the same "Receive Local" operation as local network
   unicast packets.  To allow the IP module to tell the local network
   module which multicast packets to accept, the local network service
   interface is extended to provide two new operations:

                      JoinLocalGroup  ( group-address )

                      LeaveLocalGroup ( group-address )

   where "group-address" is an IP host group address.  The
   JoinLocalGroup operation requests the local network module to accept
   and deliver up subsequently arriving packets destined to the given IP
   host group address.  The LeaveLocalGroup operation requests the local
   network module to stop delivering up packets destined to the given IP
   host group address.  The local network module is expected to map the
   IP host group addresses to local network addresses as required to
   update its multicast reception filter.  Any local network module is
   free to ignore LeaveLocalGroup requests, and may deliver up packets
   destined to more addresses than just those specified in
   JoinLocalGroup requests, if it is unable to filter incoming packets
   adequately.

   The local network module must not deliver up any multicast packets
   that were transmitted from that module; loopback of multicasts is
   handled at the IP layer or higher.

7.4. Extensions to an Ethernet Local Network Module

   To support the reception of multicast IP datagrams, an Ethernet
   module must be able to receive packets addressed to the Ethernet
   multicast addresses that correspond to the host's IP host group
   addresses.  It is highly desirable to take advantage of any address
   filtering capabilities that the Ethernet hardware interface may have,
   so that the host receives only those packets that are destined to it.

   Unfortunately, many current Ethernet interfaces have a small limit on
   the number of addresses that the hardware can be configured to
   recognize.  Nevertheless, an implementation must be capable of



Deering                                                         [Page 9]

RFC 1054          Host Extensions for IP Multicasting           May 1988


   listening on an arbitrary number of Ethernet multicast addresses,
   which may mean "opening up" the address filter to accept all
   multicast packets during those periods when the number of addresses
   exceeds the limit of the filter.

   For interfaces with inadequate hardware address filtering, it may be
   desirable (for performance reasons) to perform Ethernet address
   filtering within the software of the Ethernet module.  This is not
   mandatory, however, because the IP module performs its own filtering
   based on IP destination addresses.

7.5. Extensions to Local Network Modules other than Ethernet

   Other multicast networks, such as IEEE 802.2 networks, can be handled
   the same way as Ethernet for the purpose of receiving multicast IP
   datagrams.  For pure broadcast networks, such as the Experimental
   Ethernet, all incoming broadcast packets can be accepted and passed
   to the IP module for IP-level filtering.  On point-to-point or
   store-and-forward networks, multicast IP datagrams will arrive as
   local network unicasts, so no change to the local network module
   should be necessary.

APPENDIX I. INTERNET GROUP MANAGEMENT PROTOCOL (IGMP)

   The Internet Group Management Protocol (IGMP) is used by IP hosts to
   report their host group memberships to any immediately-neighboring
   multicast routers.  IGMP is an asymmetric protocol and is specified
   here from the point of view of a host, rather than a multicast
   router.  (IGMP may also be used, symmetrically or asymmetrically,
   between multicast routers.  Such use is not specified here.)

   Like ICMP, IGMP is a integral part of IP.  It is required to be
   implemented by all hosts conforming to level 2 of the IP multicasting
   specification.  IGMP messages are encapsulated in IP datagrams, with
   an IP protocol number of 2.  All IGMP messages of concern to hosts
   have the following format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Version| Type  |    Unused     |           Checksum            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Group Address                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+







Deering                                                        [Page 10]

RFC 1054          Host Extensions for IP Multicasting           May 1988


      Version

         This memo specifies version 1 of IGMP.  Version 0 is specified
         in RFC-988 and is now obsolete.

      Type

         There are two types of IGMP message of concern to hosts:

            1 = Host Membership Query
            2 = Host Membership Report

      Unused

         Unused field, zeroed when sent, ignored when received.

      Checksum

         The checksum is the 16-bit one's complement of the one's
         complement sum of the 8-octet IGMP message.  For computing
         the checksum, the checksum field is zeroed.

      Group Address

         In a Host Membership Query message, the group address field
         is zeroed when sent, ignored when received.

         In a Host Membership Report message, the group address field
         holds the IP host group address of the group being reported.

Informal Protocol Description

   Multicast routers send Host Membership Query messages (hereinafter
   called Queries) to discover which host groups have members on their
   attached local networks.  Queries are addressed to the all-hosts
   group (address 224.0.0.1), and carry an IP time-to-live of 1.

   Hosts respond to a Query by generating Host Membership Reports
   (hereinafter called Reports), reporting each host group to which they
   belong on the network interface from which the Query was received.
   In order to avoid an "implosion" of concurrent Reports and to reduce
   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



Deering                                                        [Page 11]

RFC 1054          Host Extensions for IP Multicasting           May 1988


         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.

   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-space Queries in order to quickly build
   up its knowledge of local memberships.



Deering                                                        [Page 12]

RFC 1054          Host Extensions for IP Multicasting           May 1988


   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.

      - 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: