rfc988.txt

RFC 相关的技术文档

Network Working Group                                      S. E. Deering
Request for Comments: 988                            Stanford University
                                                               July 1986

                  Host Extensions for IP Multicasting


1.  STATUS OF THIS MEMO

   This memo specifies the extensions required of a host implementation
   of the Internet Protocol (IP) to support internetwork multicasting.
   This specification supersedes that given in RFC-966, and constitutes
   a proposed protocol standard for IP multicasting in the
   ARPA-Internet.  The reader is directed to RFC-966 for a discussion of
   the motivation and rationale behind the multicasting extension
   specified here.  Distribution of this memo is unlimited.

2.  INTRODUCTION

   IP multicasting is defined as the transmission of an IP datagram to a
   "host group", a set of zero or more hosts identified by a single IP
   destination address.  A multicast datagram is delivered to all
   members of its destination host group with the same "best-efforts"
   reliability as regular unicast IP datagrams, i.e. the datagram is not
   guaranteed to arrive at all members of the destination group or in
   the same order relative to other datagrams.

   The membership of a host group is dynamic; that is, hosts may join
   and leave groups at any time.  There is no restriction on the
   location or number of members in a host group, but membership in a
   group may be restricted to only those hosts possessing a private
   access key.  A host may be a member of more than one group at a time.
   A host need not be a member of a group to send datagrams to it.

   A host group may be permanent or transient.  A permanent group has a
   well-known, administratively assigned IP address.  It is the address,
   not the membership of the group, that is permanent; at any time a
   permanent group may have any number of members, even zero.  A
   transient group, on the other hand, is assigned an address
   dynamically when the group is created, at the request of a host.  A
   transient group ceases to exist, and its address becomes eligible for
   reassignment, when its membership drops to zero.

   The creation of transient groups and the maintenance of group
   membership information is the responsibility of "multicast agents",
   entities that reside in internet gateways or other special-purpose
   hosts.  There is at least one multicast agent directly attached to
   every IP network or subnetwork that supports IP multicasting.  A host
   requests the creation of new groups, and joins or leaves existing
   groups, by exchanging messages with a neighboring agent.



Deering                                                         [Page 1]



RFC 988                                                        July 1986
Host Extensions for IP Multicasting


   Multicast agents are also responsible for internetwork delivery of
   multicast IP datagrams.  When sending a multicast IP datagram, a host
   transmits it to a local network multicast address which identifies
   all neighboring members of the destination host group.  If the group
   has members on other networks, a multicast agent becomes an
   additional recipient of the local multicast and relays the datagram
   to agents on each of those other networks, via the internet gateway
   system.  Finally, the agents on the other networks each transmit the
   datagram as a local multicast to their own neighboring members of the
   destination group.

   This memo specifies the extensions required of a host IP
   implementation to support IP multicasting, where a "host" is any
   internet host or gateway other than those serving as multicast
   agents.  The algorithms and protocols used within and between
   multicast agents are transparent to non-agent hosts and will be
   specified in a separate document.  This memo also does not specify
   how local network multicasting is accomplished for all types of
   network, although it does specify the required service interface to
   an arbitrary local network and gives an Ethernet specification as an
   example.  Specifications for other types of network will be the
   subject of future memos.

3.  LEVELS OF CONFORMANCE

   There are three levels of conformance to this specification:

   Level 0: no support for IP multicasting.

      There is, at this time, no requirement that all IP implementations
      support IP multicasting.  Level 0 hosts will, in general, be
      unaffected by multicast activity.  The only exception arises on
      some types of local network, where the presence of level 1 or 2
      hosts may cause misdelivery of multicast IP datagrams to level 0
      hosts.  Such datagrams can easily be identified by the presence of
      a class D IP address in their destination address field; they
      should be quietly discarded by hosts that do not support IP
      multicasting.  Class D addresses are defined in section 4 of this
      memo.










Deering                                                         [Page 2]



RFC 988                                                        July 1986
Host Extensions for IP Multicasting


   Level 1: support for sending but not receiving multicast IP
   datagrams.

      Level 1 allows a host to partake of some multicast-based services,
      such as resource location or status reporting, but it does not
      allow a host to create or join any host groups.  An IP
      implementation may be upgraded from level 0 to level 1 very easily
      and with little new code.  Only sections 4, 5, and 6 of this memo
      are applicable to level 1 implementations.

   Level 2: full support for IP multicasting.

      Level 2 allows a host to create, join and leave host groups, as
      well as send IP datagrams to host groups.  It requires
      implementation of the Internet Group Management Protocol (IGMP)
      and extension of the IP and local network service interfaces
      within the host.  All of the following sections of this memo are
      applicable to level 2 implementations.

4.  HOST GROUP ADDRESSES

   Host groups are identified by class D IP addresses, i.e. those with
   "1110" as their high-order four bits.  The remaining 28 bits are
   unstructured as far as hosts are concerned.  The addresses of
   well-known, permanent groups are to be published in "Assigned
   Numbers". Class E IP addresses, i.e. those with "1111" as their
   high-order four bits, are reserved for future addressing modes.

   Appendix II contains some background discussion of several issues
   related to host group addresses.



















Deering                                                         [Page 3]



RFC 988                                                        July 1986
Host Extensions for IP Multicasting


5.  MODEL OF A HOST IP IMPLEMENTATION

   The multicast extensions to a host IP implementation are specified in
   terms of the layered model illustrated below.  In this model, ICMP
   and (for level 2 hosts) IGMP are considered to be implemented within
   the IP module, and the mapping of IP addresses to local network
   addresses is considered to be the responsibility of local network
   modules.  This model is for expository purposes only, and should not
   be construed as constraining an actual implementation.

      |                                                          |    
      |              Upper-Layer Protocol Modules                |    
      |__________________________________________________________|    
                                    
   --------------------- IP Service Interface ----------------------- 
       __________________________________________________________     
      |                            |              |              |    
      |                            |     ICMP     |     IGMP     |    
      |             IP             |______________|______________|    
      |           Module                                         |    
      |                                                          |    
      |__________________________________________________________|    
                                    
   ---------------- Local Network Service Interface ----------------- 
       __________________________________________________________     
      |                            |                             |    
      |           Local            | IP-to-local address mapping |    
      |          Network           |         (e.g. ARP)          |    
      |          Modules           |_____________________________|    
      |      (e.g. Ethernet)                                     |    
      |                                                          |    

   To support level 2 IP multicasting, a host IP implementation must
   provide three new services:  (1) sending multicast IP datagrams, (2)
   receiving multicast IP datagrams, and (3) managing group membership.
   Only the first service need be provided in level 1 hosts.  Each of
   these services is described in a separate section, below.  For each
   service, extensions are specified for the IP service interface, the
   IP module, the local network service interface, and an Ethernet local
   network module.  Extensions to local network modules other than
   Ethernet are mentioned briefly, but are not specified in detail.








Deering                                                         [Page 4]



RFC 988                                                        July 1986
Host Extensions for IP Multicasting


6.  SENDING MULTICAST IP DATAGRAMS

   6.1. Extensions to the IP Service Interface

      No change to the IP service interface is required to support the
      sending of multicast IP datagrams.  An upper-layer protocol module
      merely specifies an IP host group destination, rather than an
      individual IP destination, when it invokes the existing "Send IP"
      operation.

   6.2. Extensions to the IP Module

      To support the sending of multicast IP datagrams, the IP module
      must be extended to recognize IP host group addresses when routing
      outgoing datagrams.  Most IP implementations include the following
      logic:

         if IP-destination is on the same local network,
            send datagram locally to IP-destination
         else
            send datagram locally to GatewayTo(IP-destination)

      To allow multicast transmissions, the routing logic must be
      changed to:

         if IP-destination is on the same local network
         or IP-destination is a host group,
            send datagram locally to IP-destination
         else
            send datagram locally to GatewayTo(IP-destination)

      If the sending host is itself a member of the destination group, a
      copy of the outgoing datagram must be looped-back for local
      delivery if and only if loopback was requested when the host
      joined the group (see section 8.1).  (This issue does not arise in
      level 1 implementations.)

      On hosts attached to more than one network, each multicast IP
      datagram must be transmitted via one network interface only,
      leaving it to the multicast agents to effect delivery to any other
      required networks.

      A host group address should not be placed in the source address
      field of an outgoing IP datagram.  A host group address may be
      used in a source routing option as the last element only.

      It should be noted that a small IP time-to-live (TTL) value can


Deering                                                         [Page 5]



RFC 988                                                        July 1986
Host Extensions for IP Multicasting


      prevent delivery to some members of a destination group.  Thus, a
      large TTL value should be used to reach all members.  Conversely,
      a small TTL value can be used to advantage to reach only "nearby"
      members of a widely-dispersed group.  In clusters of low-delay
      local area networks, the TTL field acts as a hop limit; thus, one
      can perform expanding-ring searches by starting with a TTL of 1
      and incrementing on each retransmission, up to some limit defined
      by the diameter of the cluster.

   6.3. Extensions to the Local Network Service Interface

      No change to the local network service interface is required to
      support the sending of multicast IP datagrams.  The IP module
      merely specifies an IP host group destination, rather than an
      individual IP destination, when it invokes the existing "Send
      Local" operation.

   6.4. Extensions to an Ethernet Local Network Module

      The Ethernet directly supports the sending of local multicast
      packets by allowing multicast addresses in the destination field
      of Ethernet 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 28-bits of the IP address into
      the low-order 28 bits of an Ethernet address.  The high-order 20
      bits of the Ethernet address are set to a well-known value, to be
      published in "Assigned Numbers".

      [At time of publication of this memo, a block of Ethernet
      multicast addresses with 28 unspecified bits had not yet been
      obtained from the allocating authority.  If such a block of
      addresses cannot be obtained, an alternative mapping scheme will
      be specified.]

   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, can be handled the
      same 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 can be mapped to a single local broadcast address (at
      the cost of increased overhead on all local hosts).  For a
      point-to-point networks like the ARPANET or a public data network


Deering                                                         [Page 6]



RFC 988                                                        July 1986
Host Extensions for IP Multicasting


      (X.25), all IP host group addresses might be mapped to the
      well-known local address of an IP multicast agent; an agent 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

      No change to the IP service interface is required to support the
      reception of multicast IP datagrams.  Incoming multicast IP
      datagrams are delivered to upper-layer protocol modules using the
      same "Receive IP" operation as normal, unicast datagrams.

   7.2. Extensions to the IP Module

      To support the reception of multicast IP datagrams, the IP module
      must be extended to recognize the addresses of IP host groups to
      which the host currently belongs, in addition to the host's
      individual IP address(es).  An incoming datagram destined to one
      of those group addresses 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.  (This should occur only as a result of inadequate
      multicast address filtering in the local network module.)

      An incoming datagram is not rejected for having an IP host group
      address in its source address field or anywhere in a source