rfc1054.txt

RFC 的详细文档！

Network Working Group                                        S. Deering
Request for Comments: 1054                          Stanford University
Obsoletes: RFC 988                                             May 1988


                  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 multicasting.  It is
   proposed as a standard for IP multicasting in the Internet.  This
   specification is a major revision of RFC-988; changes from RFC-988
   are listed in an Appendix.  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 intact 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.  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.  Those IP
   multicast addresses that are not reserved for permanent groups are
   available for dynamic assignment to transient groups which exist only
   as long as they have members.

   Internetwork forwarding of IP multicast datagrams is handled by
   "multicast routers" which may be co-resident with, or separate from,
   internet gateways.  A host transmits an IP multicast datagram as a
   local network multicast which reaches all immediately-neighboring
   members of the destination host group.  If the datagram has an IP
   time-to-live greater than 1, the multicast router(s) attached to the
   local network take responsibility for forwarding it towards all other
   networks that have members of the destination group.  On those other
   member networks that are reachable within the IP time-to-live, an



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


   attached multicast router completes delivery by transmitting the
   datagram as a local multicast.

   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 acting as multicast
   routers.  The algorithms and protocols used within and between
   multicast routers are transparent to hosts and will be specified in
   separate documents.  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 described in section 4 of this memo.

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



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


   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.  Class E IP addresses, i.e.,
   those with "1111" as their high-order four bits, are reserved for
   future addressing modes.

   In Internet standard "dotted decimal" notation, host group addresses
   range from 224.0.0.0 to 239.255.255.255.  The address 224.0.0.0 is
   guaranteed not to be assigned to any group, and 224.0.0.1 is assigned
   to the permanent group of all IP hosts.  This is used to address all
   multicast hosts on the directly connected network.  There is no
   multicast address (or any other IP address) for all hosts on the
   total Internet.  The addresses of other well-known, permanent groups
   are to be published in "Assigned Numbers".

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































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


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 1 multicasting, a host IP implementation must
   support the transmission of multicast IP datagrams.  To support level
   2 IP multicasting, a host must also support the reception of
   multicast IP datagrams.  Each of these two new 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 1054          Host Extensions for IP Multicasting           May 1988


6. SENDING MULTICAST IP DATAGRAMS

6.1. Extensions to the IP Service Interface

   Multicast IP datagrams are sent using the same "Send IP" operation
   used to send unicast IP datagrams; an upper-layer protocol module
   merely specifies an IP host group address, rather than an individual
   IP address, as the destination.  However, a number of extensions may
   be necessary or desirable.

   First, the service interface should provide a way for the upper-layer
   protocol to specify the IP time-to-live of an outgoing multicast
   datagram, if such a capability does not already exist.  If the
   upper-layer protocol chooses not to specify a time-to-live, it should
   default to 1 for all multicast IP datagrams, so that an explicit
   choice is required to multicast beyond a single network.

   Second, for hosts that may be attached to more than one network, the
   service interface should provide a way for the upper-layer protocol
   to identify which network interface is be used for the multicast
   transmission.  Only one interface is used for the initial
   transmission; multicast routers are responsible for forwarding to any
   other networks, if necessary.  If the upper-layer protocol chooses
   not to identify an outgoing interface, a default interface should be
   used, preferably under the control of system management.

   Third (level 2 implementations only), for the case in which the host
   is itself a member of a group to which a datagram is being sent, the
   service interface should provide a way for the upper-layer protocol
   to inhibit local delivery of the datagram; by default, a copy of the
   datagram is looped back.  This is a performance optimization for
   upper-layer protocols that restrict the membership of a group to one
   process per host (such as a routing protocol), or that handle
   loopback of group communication at a higher layer (such as a
   multicast transport protocol).

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 )




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


   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,
   unless inhibited by the sender.  (Level 2 implementations only.)

   A host group address should not be placed in the source address field
   or anywhere in a source routing option of an outgoing IP datagram.

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



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


   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