rfc1054.txt

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

      - "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 and have a correct IGMP
        checksum.  A single Query applies to all memberships on the
        interface from which the Query is received.  It is ignored for



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


        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.

      - "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.























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


   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 1054          Host Extensions for IP Multicasting           May 1988


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.

Group Addresses as Logical Addresses

   Host group addresses have been defined specifically for use in the
   destination address field of multicast IP datagrams.  However, the
   fact that group addresses are location-independent (they are not
   statically bound to a single network interface) suggests possible
   uses as more general "logical addresses", both in the source as well
   as the destination address field of datagrams.  For example, a mobile
   IP host might have a host group address as its only identity, used as
   the source of datagrams it sends.  Whenever the mobile host moved
   from one network to another, it would join its own group on the new
   network and depart from the group on the old network.  Other hosts
   communicating with the mobile one would deal only with the group
   address and would be unaware of, and unaffected by, the changing
   network location of the mobile host.

   Host group addresses cannot, however, be used to solve all problems
   of internetwork logical addressing, such as delivery to the "nearest"
   or the "least loaded" network interface of a multi-homed host.
   Furthermore, there are hazards in using group addresses in the source
   address field of datagrams when the group actually contains more than
   one host.  For instance, the IP datagram reassembly algorithm relies
   on every host using a different source address.  Also, errors in a
   datagram sent with a group source address may result in error reports
   being returned to all members of the group, not just the sender.  In



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


   view of these hazards, this memo specifies the use of host group
   addresses only in the IP destination address field.  However, it is
   recommended that datagrams with a group source address, or a group
   address as part of a source routing option, be accepted without
   complaint, thereby allowing other implementations to experiment with
   logical addressing applications of host group 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.

APPENDIX III. CHANGES FROM RFC-988

   The IP multicast extensions specified in this memo are significantly
   different from those specified in RFC-988.  Most of the changes are
   due to a shift of responsibility away from the multicast routers
   (called "multicast agents" in RFC-988) and onto the hosts.  This new
   distribution of responsibility is consistent with the lightweight,
   soft-state gateway architecture of the Internet, and it allows the IP
   multicast services (in the same way as the IP unicast services) to be
   used among hosts on a single network when no router is up or present
   on the network.  Thus, current single-network IP broadcast
   applications may be migrated to the use of IP multicast before
   multicast routers are widely available.  The following changes are a
   consequence of this shift of responsibility:




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


      - Private hosts groups and access keys have been eliminated.
        The multicast routers are no longer considered trustworthy
        controllers of group membership; it is up to hosts and their
        administrators to provide their own mechanisms to prevent
        unwanted eavesdropping on group communication, perhaps by
        using end-to-end encryption or by imposing restrictions on the
        flow of IP multicast datagrams into and out of particular
        administrative domains.

      - The CreateHostGroup operation has been eliminated.  The
        responsibility for allocating transient host groups has been
        moved from multicast routers to the hosts.  See Appendix II
        for a brief discussion of some ways in which hosts might do
        their own transient group allocation.

      - The JoinHostGroup and LeaveHostGroup operations have become
        non-blocking, because it is no longer necessary to await
        approval from a multicast router when changing membership.  It
        is also no longer possible for a host to have its membership
        revoked by a multicast router.

      - The IGMP protocol is substantially different from that in
        RFC-988, reflecting the changed roles of hosts and multicast
        routers.

      - The new IGMP requires that there be an "all-hosts" group.
        There is no longer a need for an "all-multicast-agents" group.

   Other changes that are not related to the shift of responsibility
   are:

      - The decision whether or not to loop back a multicast datagram
        sent from a member of the destination group is now made at the
        time the datagram is sent, rather than at the time the group
        is joined.  This gives the sender another degree of scope
        control, beyond the IP time-to-live.

      - The handling of IP time-to-live, and of multiple network
        interfaces, has been more precisely specified.

      - Hosts are no longer allowed to place an IP host group address
        in a source routing option.

      - The AcceptAddress and RejectAddress operations at the local
        network service interface have been renamed JoinLocalGroup and
        LeaveLocalGroup to emphasize their semantic similarity to the
        JoinHostGroup and LeaveHostGroup operations at the IP service
        interface.



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


      - A new mapping algorithm for Ethernet multicast addresses has
        been specified.

      - The organization of the memo has been changed somewhat, and a
        state transition diagram has been added to the IGMP
        specification.













































Deering                                                        [Page 19]