rfc966.txt

RFC 的详细文档！

Network Working Group                                      S. E. Deering
Request for Comments: 966                                 D. R. Cheriton
                                                     Stanford University
                                                           December 1985

                              Host Groups:
             A Multicast Extension to the Internet Protocol


1. Status of this Memo

   This RFC defines a model of service for Internet multicasting and
   proposes an extension to the Internet Protocol (IP) to support such a
   multicast service.  Discussion and suggestions for improvements are
   requested.  Distribution of this memo is unlimited.

2. Acknowledgements

   This memo was adapted from a paper [7] presented at the Ninth Data
   Communications Symposium.  This work was sponsored in part by the
   Defense Advanced Research Projects Agency under contract N00039-83-
   K-0431 and National Science Foundation Grant DCR-83-52048.

   The Internet task force on end-to-end protocols, headed by Bob
   Braden, has provided valuable input in the development of the host
   group model.

3. Introduction

   In this paper, we describe a model of multicast service we call host
   groups and propose this model as a way to support multicast in the
   DARPA Internet environment [14].  We argue that it is feasible to
   implement this facility as an extension of the existing "unicast" IP
   datagram model and mechanism.

   Multicast is the transmission of a datagram packet to a set of zero
   or more destination hosts in a network or internetwork, with a single
   address specifying the set of destination hosts.  For example, hosts
   A, B, C and D may be associated with multicast address X. On
   transmission, a packet with destination address X is delivered with
   datagram reliability to hosts A, B, C and D.

   Multicast has two primary uses, namely distributed binding and
   multi-destination delivery.  As a binding mechanism, multicast is a
   robust and often more efficient alternative to the use of name
   servers for finding a particular object or service when a particular
   host address is not known.  For example, in a distributed file
   system, all the file servers may be associated with one well-known
   multicast address.  To bind a file name to a particular server, a
   client sends a query packet containing the file name to the file
   server multicast address, for delivery to all the file servers.  The


Deering & Cheriton                                              [Page 1]



RFC 966                                                    December 1985
Host Groups: A Multicast Extension to the Internet Protocol


   server that recognizes the file name then responds to the client,
   allowing subsequent interaction directly with that server host.  Even
   when name servers are employed, multicast can be used as the first
   step in the binding process, that is, finding a name server.

   Multi-destination delivery is useful to several applications,
   including:

      - distributed, replicated databases [6,9].

      - conferencing [11].

      - distributed parallel computation, including distributed
        gaming [2].

   Ideally, multicast transmission to a set of hosts is not more
   complicated or expensive for the sender than transmission to a single
   host.  Similarly, multicast transmission should not be more expensive
   for the networks and gateways than traversing the shortest path tree
   that connects the sending host to the hosts identified by the
   multicast address.

   Multicast, transmission to a set of hosts, is properly distinguished
   from broadcast, transmission to all hosts on a network or
   internetwork. Broadcast is not a generally useful facility since
   there are few reasons for communicating with all hosts.

   A variety of local network applications and systems make use of
   multicast.  For instance, the V distributed system [8] uses
   network-level multicast for implementing efficient operations on
   groups of processes spanning multiple machines.  Similar use is being
   made for replicated databases [6] and other distributed applications
   [4]. Providing multicast in the Internet environment would allow
   porting such local network distributed applications to the Internet,
   as well as making some existing Internet applications more robust and
   portable (by, for example, removing "wired-in" lists of addresses,
   such as gateway addresses).

   At present, an Internet application logically requiring multicast
   must send individually addressed packets to each recipient.  There
   are two problems with this approach.  Firstly, requiring the sending
   host to know the specific addresses of all the recipients defeats its
   use as a binding mechanism.  For example, a diskless workstation
   needs on boot to determine the network address of a disk server and
   it is undesirable to "wire in" specific network addresses.  With a
   multicast facility, the multicast address of the boot servers (or



Deering & Cheriton                                              [Page 2]



RFC 966                                                    December 1985
Host Groups: A Multicast Extension to the Internet Protocol


   name servers that hold the addresses of the boot servers) can be
   well-known, allowing the workstation to transmit its initial queries
   to this address.

   Secondly, transmitting multiple copies of the same packet makes
   inefficient use of network bandwidth, gateway resources and sender
   resources.  For instance, the same packet may repeatedly traverse the
   same network links and pass through the same gateways.  Furthermore,
   the local network level cannot recognize multi-destination delivery
   to take advantage of multicast facilities that the underlying network
   technologies may provide.  For example, local-area bus, ring, or
   radio networks, as well as satellite-based wide-area networks, can
   provide efficient multicast delivery directly.  Besides using
   excessive communication resources, the use of multiple transmissions
   to effect multicast severely limits the amount of parallelism in
   transmission and processing that can be achieved compared to an
   integrated multicast facility.

   The next section describes the host group model of multicast service.
   Section 5 describes the extensions to IP to support the host group
   model.  Section 6 discusses the implementation of multicast within
   the networks and gateways making up the Internet.  Section 7 relates
   this model to other proposals.  Finally, we conclude with remarks on
   our experimental prototype implementation of host groups and comments
   on future directions for investigation.

4. The Host Group Model

   The Internet architecture defines a name space of individual host
   addresses.  The host group model extends that name space to include
   addresses of host groups.  A host group is a set of zero or more
   Internet hosts <1>.   When an IP packet is sent with a host group
   address as its destination, it is delivered with "best effort"
   datagram reliability to all members of that host group.

   The sender need not be a member of the destination group.  We refer
   to such a group as open, in contrast to a closed group where only
   members are allowed to send to the group.  We chose to provide open
   groups because they are more flexible and more consistent as an
   extension of conventional unicast models (even though they may harder
   to implement).

   Dynamic management of group membership provides flexible binding of
   Internet addresses to hosts.  Hosts may join and leave groups over
   time. A host may also belong to more than one group at a time.
   Finally, a host may belong to no groups at times, during which that
   host is unreachable within the Internet architecture.  In fact, a


Deering & Cheriton                                              [Page 3]



RFC 966                                                    December 1985
Host Groups: A Multicast Extension to the Internet Protocol


   host need not have an individual Internet address at all.  Some hosts
   may only be associated with multi-host group addresses.  For
   instance, there may be no reason to contact an individual time server
   in the Internet, so time servers would not require individual
   addresses.

   Internet addresses are dynamically allocated for transient groups,
   groups that often last only as long as the execution of a single
   distributed program.  In addition, a range of host group identifiers
   is reserved for identifying permanent groups.  One use of permanent
   host groups identifiers is for host groups with standard logical
   meanings such as "name server group", "boot server group", "Internet
   monitor group", etc.

   In the current Internet architecture, addresses are bound to single
   hosts.  The host group model generalizes the binding of Internet
   addresses to hosts by allowing one address to bind to multiple hosts
   on multiple networks, more than one address to be bound (in part) to
   one host, and the binding of an address to host to be dynamic, i.e.
   possible to be modified under application control.  Within this more
   general model, the current architecture is supported as a special
   case, retaining its current semantics and implementation.

   The following subsections provide further details of the model.

   4.1. Host Group Management

      Dynamic binding of Internet addresses to hosts is managed by the
      following three operations which are made available to clients of
      the Internet Protocol <2>:

         CreateGroup ( type ) --> outcome, group-address, access-key

      requests the creation of a new transient host group with the
      invoking host as its only member.  The type argument specifies
      whether the group is restricted or unrestricted.  A restricted
      group restricts membership based on the access-key.  Only hosts
      presenting a valid host access-key are allowed to join.  All
      unrestricted host groups have a null access-key.  outcome
      indicates whether the request is approved or denied.  If it is
      approved, a new transient group address is returned in
      group-address.  access-key is the protection key (or password)
      associated with the new group.  This should fail only if there are
      no free transient group addresses.

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



Deering & Cheriton                                              [Page 4]



RFC 966                                                    December 1985
Host Groups: A Multicast Extension to the Internet Protocol


      requests that the invoking host become a member of the identified
      host group (permanent or transient).  outcome indicates whether
      the request is approved or denied.  A request is denied if the
      access key is invalid.

         LeaveGroup ( group-address ) --> outcome

      requests that the invoking host be dropped from membership in the
      identified group (permanent or transient).  outcome indicates
      whether the request is approved or denied.

      There is no operation to destroy a transient host group because a
      transient host group is deemed to no longer exist when its
      membership goes to zero.

      Permanent host group addresses are allocated and published by
      Internet administrators, in the same way as well-known TCP and UDP
      port numbers.  That is, they are published in future editions of
      the "Assigned Numbers" document [17].

   4.2. Packet Transmission

      Transmission of a packet in the host group model is controlled by
      two parameters of scope, one being the destination internetwork
      address and the other being the "distance" to the destination
      host(s).  In particular,

         Send ( dest-address, source-address, data, distance )

      transmits the specified data in an internetwork datagram to the
      host(s) identified by dest-address that are within the specified
      distance.  The destination address is thus similar to conventional
      networks except that delivery may be to multiple hosts; the
      distance parameter requires further discussion.

      Distance may be measured in several ways, including number of
      network hops, time to deliver and what might be called
      administrative distance. Administrative distance refers to the
      distance between the administrations of two different networks.
      For example, in a company the networks of the research group and
      advanced development group might be considered quite close to each
      other, networks of the corporate management more distant, and
      networks of other companies much more distant.  One may wish to
      restrict a query to members within one's own administrative domain
      because servers outside that domain may not be trusted.
      Similarly, error reporting outside of an administrative domain may
      not be productive and may in fact be confusing.


Deering & Cheriton                                              [Page 5]



RFC 966                                                    December 1985
Host Groups: A Multicast Extension to the Internet Protocol


      Besides limiting the scope of transmission, the distance parameter
      can be used to control the scope of multicast as a binding
      mechanism and to implement an expanding scope of search for a
      desired service.  For instance, to locate a name server familiar
      with a given name, one might check with nearby name servers and
      expand the distance (by incrementing the distance on
      retransmission) to include more distant name servers until the
      name is found.

      To reach all members of a group, a sender specifies the maximum
      value for the distance parameter.  This maximum must exceed the
      "diameter" of the Internet.

      Packet reception is the same as conventional architectures.  That
      is,

         Receive () --> dest-address, source-address, data

      returns the next internetwork datagram that is, or has been,
      received.

   4.3. Delivery Requirements

      We identify several requirements for the packet delivery mechanism
      that are essential to host groups being a useful and used
      facility.

      Firstly, given the predominance of broadcast local-area networks
      and the locality of communication to individual networks, the
      delivery mechanism must be able to exploit the hardware's
      capability for very efficient multicast within a single local-area
      network.

      Secondly, the delivery mechanism must scale in sophistication to
      efficient delivery across the Internet as it acquires high-speed
      wide-area communication links and higher performance gateways.
      The former are being provided by the introduction of high-speed
      satellite channels and long-haul fiber optic links.  The latter
      are made feasible by the falling cost of memory and processing
      power plus the increasing importance in controlling access to
      relatively unprotected local network environments.  A host group
      delivery mechanism must be able to take advantage of these trends
      as they materialize.

      Finally, the delivery mechanism must avoid "systematic errors" in
      delivery to members of the host group.  That is, a small number of
      repeated transmissions must result in delivery to all group


Deering & Cheriton                                              [Page 6]



RFC 966                                                    December 1985
Host Groups: A Multicast Extension to the Internet Protocol


      members within the specified distance, unless a member is
      disconnected or has failed.  We refer to this property as
      coverage.  In general, most reliable protocols make this basic
      assumption for unicast delivery.  It is important to guarantee
      this assumption for multicast as well or else applications using
      multicast may fail in unexpected ways when coverage is not
      provided.  For efficiency, the multicast delivery mechanism should
      also avoid regularly delivering multiple copies of a packet to
      individual hosts.

      Failure notification is not viewed as an essential requirement,
      given the datagram semantics of delivery.  However, a host group
      extension to IP should provide "hint"-level failure notification
      as the natural extension of the failure notification for unicast.

5. Extensions to IP

   This section discusses the specific extensions to the DARPA Internet
   Protocol required to support the host group model.  The extensions
   need be implemented only on those hosts that wish to join host groups
   or send to host groups; existing implementations are not affected by
   the proposed changes.

   5.1. Group Addresses

      A portion of the 32-bit IP address space is reserved for host
      group addresses.  The range of group addresses is chosen to be
      easily recognized and to not conflict with existing individual
      addresses. Either Class A addresses with a distinguished
      (currently unused) network number or Class D addresses (those
      starting with 111) would be suitable. The range of group addresses
      is further subdivided into a set of permanent group addresses and
      a set of temporary group addresses.

      Host group addresses may be used in the same way as individual
      addresses in the source, destination, and options fields of IP
      datagrams.  An IP implementation adds to the list of its own
      individual addresses, the addresses of all groups to which it
      belongs.  The source addresses of locally originated datagrams are