rfc1112.txt

windows 网络编程。pdf文档

   packets.  All that is needed to support the sending of multicast IP
   datagrams is a procedure for mapping IP host group addresses to
   Ethernet multicast addresses.

   An IP host group address is mapped to an Ethernet multicast address
   by placing the low-order 23-bits of the IP address into the low-order
   23 bits of the Ethernet multicast address 01-00-5E-00-00-00 (hex).
   Because there are 28 significant bits in an IP host group address,
   more than one host group address may map to the same Ethernet
   multicast address.

6.5. Extensions to Local Network Modules other than Ethernet

   Other networks that directly support multicasting, such as rings or
   buses conforming to the IEEE 802.2 standard, may be handled the same



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


   way as Ethernet for the purpose of sending multicast IP datagrams.
   For a network that supports broadcast but not multicast, such as the
   Experimental Ethernet, all IP host group addresses may be mapped to a
   single local broadcast address (at the cost of increased overhead on
   all local hosts).  For a point-to-point link joining two hosts (or a
   host and a multicast router), multicasts should be transmitted
   exactly like unicasts.  For a store-and-forward network like the
   ARPANET or a public X.25 network, all IP host group addresses might
   be mapped to the well-known local address of an IP multicast router;
   a router on such a network would take responsibility for completing
   multicast delivery within the network as well as among networks.

7. RECEIVING MULTICAST IP DATAGRAMS

7.1. Extensions to the IP Service Interface

   Incoming multicast IP datagrams are received by upper-layer protocol
   modules using the same "Receive IP" operation as normal, unicast
   datagrams.  Selection of a destination upper-layer protocol is based
   on the protocol field in the IP header, regardless of the destination
   IP address.  However, before any datagrams destined to a particular
   group can be received, an upper-layer protocol must ask the IP module
   to join that group.  Thus, the IP service interface must be extended
   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 support only one interface.  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



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


   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.

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 or log
   entry.  On hosts with more than one network interface, if a datagram
   arrives via one 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 with an IP host group address in its source address field is
   quietly discarded.  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.




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


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



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


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
























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


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

      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



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


         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