rfc988.txt

RFC 相关的技术文档

      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.

   7.3. Extensions to the Local Network Service Interface

      No change to the local network service interface is required to
      support the reception of multicast IP datagrams.  Incoming local
      network packets, whether multicast or unicast, are delivered to
      the IP module using the same "Receive Local" operation.




Deering                                                         [Page 7]



RFC 988                                                        July 1986
Host Extensions for IP Multicasting


   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 only receives 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.  However, an implementation must be capable of
      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 a
      point-to-point network, multicast IP datagrams will arrive as
      local network unicasts, so no change to the local network module
      should be necessary.















Deering                                                         [Page 8]



RFC 988                                                        July 1986
Host Extensions for IP Multicasting


8.  MANAGING GROUP MEMBERSHIP

   8.1. Extensions to the IP Service Interface

      To allow upper-layer protocol modules to request that their host
      create, join, or leave a host group, the IP service interface must
      be extended to offer the following three new operations:

         CreateGroup ( private, loopback )
                                  --> outcome, group-address, access-key

      The CreateGroup operation requests the creation of a new,
      transient host group, with this host as its only member.  The
      "private" argument specifies if the group is to be private or
      public.  The "loopback" argument specifies whether or not
      datagrams sent from this host to the group should be delivered
      locally as well as to other member hosts.  The "outcome" result
      indicates whether the request is granted or denied.  If it is
      granted, a new 32-bit IP host group address is returned, along
      with a 64-bit access key which is zero for public groups and
      non-zero for private groups.  The request may be denied due to
      lack of response from a multicast agent, or lack of resources.

         JoinGroup ( group-address, access-key, loopback ) --> outcome

      The JoinGroup operation requests that this host become a member of
      the host group identified by "group-address", with the specified
      access key. The "loopback" argument specifies whether or not
      datagrams sent from this host to the group should be delivered
      locally as well as to other member hosts.  The "outcome" result
      indicates whether the request is granted or denied.  The request
      may be denied due to lack of response from a multicast agent, lack
      of resources, an invalid group address, an incorrect access key,
      or already being a member.

         LeaveGroup ( group-address, access-key ) --> outcome

      The LeaveGroup operation requests that this host give up its
      membership in the host group identified by "group-address", with
      the specified access key.  The "outcome" result indicates whether
      the request is granted or denied.  The request may be denied due
      to an invalid group address, an incorrect access key, or not
      currently being a member.

      Each of these operations may take up to a minute or more to
      complete, depending on the number of IGMP retransmissions



Deering                                                         [Page 9]



RFC 988                                                        July 1986
Host Extensions for IP Multicasting


      performed within the IP module, and time required for a multicast
      agent to generate a reply. However, typical delays should be on
      the order of a few seconds.

      Besides the LeaveGroup operation, a host loses its membership in a
      group whenever the host or its IP module crashes, or, in rare
      circumstances, when a multicast agent revokes its membership.  The
      IP service interface should provide some means of informing an
      upper-layer module when its membership has been revoked.
      Membership may be revoked due to lack of resources, deallocation
      of the group address, or the discovery of another host group using
      the same group address with a different access key.  (See Appendix
      II for discussion of address recycling issues.)

      It is important to observe that IP group membership is per-host,
      rather than per-process.  An IP service interface should not allow
      multiple processes to invoke JoinGroup operations for the same
      group as a way of achieving delivery to more than process.  The IP
      module delivers each incoming datagram, whether multicast or
      unicast, to the single upper-layer protocol module identified by
      the protocol field in the datagram's IP header; it is an
      upper-layer issue whether or not to deliver incoming datagrams to
      more than one process, perhaps using the concept of "process
      groups" or "shared ports".

   8.2. Extensions to the IP Module

      Within the IP module, the membership management operations are
      supported by the Internet Group Management Protocol (IGMP),
      specified in Appendix I. As well as having messages corresponding
      to each of the operations specified above, IGMP also specifies a
      "deadman timer" procedure whereby hosts periodically confirm their
      memberships with the multicast agents.

      The IP module must maintain a data structure listing the IP
      addresses of all host groups to which the host currently belongs,
      along with each group's loopback policy, access key, and timer
      variables.  This data structure is used by the IP multicast
      transmission service to know which outgoing datagrams to loop
      back, and by the reception service to know which incoming
      datagrams to accept.  The purpose of IGMP and the management
      interface operations is to maintain this data structure.

      On hosts attached to more than one network, each membership is
      associated with a particular network interface.  On such a host
      the management interface operations above may each require an
      additional parameter specifying to which interface the create,


Deering                                                        [Page 10]



RFC 988                                                        July 1986
Host Extensions for IP Multicasting


      join, or leave request applies.  The group membership data
      structure must also be extended to associate an interface with
      each membership.  If a host joins the same host group on more than
      one network interface, it can expect to receive multiple copies of
      each datagram sent to that group.

   8.3. Extensions to the Local Network Service Interface

      To allow an IP module to control what packets should be accepted
      by the local network module, it is necessary to extend the local
      network service interface with the following two new operations:

         AcceptAddress ( group-address )

         RejectAddress ( group-address )

      where "group-address" is an IP host group address.  The
      AcceptAddress operation requests the local network module to
      accept and deliver up subsequently arriving packets destined to
      the local network address corresponding to "group-address".  The
      RejectAddress operation requests the local network module to stop
      delivering up packets destined to the local network address
      corresponding to "group-address".

      Any local network module is free to ignore RejectAddress requests,
      and may deliver up packets destined to more addresses than just
      those specified in AcceptAddress requests, if it is unable to
      filter incoming packets adequately.

   8.4. Extensions to an Ethernet Local Network Module

      An Ethernet module responds to AcceptAddress operations by adding
      the corresponding Ethernet multicast address to its acceptance
      filter for incoming packets.  A RejectAddress operation causes the
      corresponding Ethernet address to be dropped from the filter.  For
      Ethernet interfaces with a limit on the number of addresses that
      can be added to the filter, the Ethernet software module must
      detect when that threshold is exceeded and open up the filter to
      accept all multicast packets.  It should also detect when the
      number of addresses drops below the threshold and revert to
      individual address filtering.

   8.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 controlling
      address filtering.  For a pure broadcast network or a


Deering                                                        [Page 11]



RFC 988                                                        July 1986
Host Extensions for IP Multicasting


      point-to-point network, the AcceptAddress and RejectAddress
      operations may have no effect; all incoming packets could be
      passed to the IP module for IP-level filtering.














































Deering                                                        [Page 12]



RFC 988                                                        July 1986
Host Extensions for IP Multicasting


APPENDIX I.  INTERNET GROUP MANAGEMENT PROTOCOL (IGMP)

   The Internet Group Management Protocol (IGMP) is used between IP
   hosts and their immediate neighbor multicast agents to support the
   creation of transient groups, the addition and deletion of members of
   a group, and the periodic confirmation of group membership.  IGMP is
   an asymmetric protocol and is specified here from the point of view
   of a host, rather than a multicast agent.

   Like ICMP, IGMP is a integral part of IP.  It is required to be
   implemented in full 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 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  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     Type      |     Code      |           Checksum            | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          Identifier                           | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                         Group Address                         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                                               | 
   +                         Access Key                            + 
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   Type

      There are eight types of IGMP message:

         1 = Create Group Request
         2 = Create Group Reply

         3 = Join Group Request
         4 = Join Group Reply

         5 = Leave Group Request
         6 = Leave Group Reply

         7 = Confirm Group Request
         8 = Confirm Group Reply





Deering                                                        [Page 13]



RFC 988                                                        July 1986
Host Extensions for IP Multicasting


   Code

      In a Create Group Request message, the code field indicates if the
      new host group is to be public or private:

         0 = public
         1 = private

      In all other Request messages, the code field contains zero.

      In a Reply message, the Code field specifies the outcome of the
      request:

         0       = request granted
         1       = request denied,  no resources