rfc966.txt

RFC 相关的技术文档

      validated against the list, and incoming datagrams which are not
      destined to an address on the list are discarded.  The addresses
      on the list change dynamically as IP users create, join and leave
      groups.






Deering & Cheriton                                              [Page 7]



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


   5.2. Group Management

      To support the group management operations of CreateGroup,
      JoinGroup and LeaveGroup, an IP module must interact with one or
      more multicast agents which reside in neighbouring gateways or
      other special-purpose hosts.  These interaction are handled by an
      Internet Group Management Protocol (IGMP) which, like ICMP [15],
      is an integral part of the IP implementation.  A proposed
      specification for IGMP is given in Appendix I.

   5.3. Multicast Delivery

      In order to transmit a datagram destined to a host group, an IP
      module must map the destination group address into a local network
      address.  As with individual IP addresses, the mapping algorithm
      is local-network- specific.  On networks that directly support
      multicast, the IP host group address is mapped to a local network
      multicast address that includes all local members of the host
      group plus one or more multicast agents.  For networks that do not
      directly support multicast, the mapping may be to a more general
      broadcast address, to a list of local unicast addresses, or
      perhaps to the address of a single machine that handles
      multi-destination relaying.

   5.4. Distance Control

      The existing Time to Live field in the IP header can be used for
      crude control over the delivery radius of multicast datagrams.  To
      provide finer-grain control, a new IP option is defined to specify
      the maximum delivery distance in "administrative units", such as
      "this network", "this department", "this company", "this country",
      etc.  The set of units and their encoding is to be determined.

6. Implementation

   In this section, we sketch a design for implementing the host group
   model within the Internet.  This description of the design is given
   to further support the feasibility of the host group model as well as
   point out some of the problems yet to be addressed.

   Implementation of host groups involves implementing a binding
   mechanism (binding Internet addresses to zero or more hosts) and a
   packet delivery mechanism (delivering a packet to each host to which
   its destination address binds).  This facility fits most naturally
   into the gateways of the Internet and the switching nodes of the
   constituent point-to-point networks (as opposed to separate machines)
   because multicast binding and delivery is a natural extension of the


Deering & Cheriton                                              [Page 8]



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


   unicast binding and delivery (i.e. routing plus store-and-forward).
   That is, a multicast packet is routed and transmitted to multiple
   destinations, rather than to a single destination.

   In the following description, we start with a basic, simple
   implementation that provides coverage and then refine this mechanism
   with various optimizations to improve efficiency of delivery and
   group management.

   6.1. Basic Implementation

      A host group defines a network group, which is the set of networks
      containing current members of the host group.  When a packet is
      sent to a host group, a copy is delivered to each network in the
      corresponding network group.  Then, within each network, a copy is
      delivered to each host belonging to the group.

      To support such multicast delivery, every Internet gateway
      maintains the following data structures:

         - routing table: conventional Internet routing information,
           including the distance and direction to the nearest gateway
           on every network.

         - network membership table:  A set of records, one for every
           currently existing host group.  The network membership record
           for a group lists the network group, i.e. the networks that
           contain members of the group.

         - local host membership table:  A set of records, one for each
           host group that has members on directly attached networks.
           Each local host membership record indicates the local hosts
           that are members of the associated host group.  For networks
           that support multicast or broadcast, the record may contain
           only the local network-specific multicast address used by the
           group plus a count of local members.  Otherwise, local group
           members may be identified by a list of unicast addresses to
           be used in the software implementation of multicast within
           the network.

      A host invokes the multicast delivery service by sending a
      group-destined IP datagram to an immediate neighbour gateway (i.e.
      a gateway that is directly attached to the same network as the
      sending host).  Upon receiving a group-destined datagram from a
      directly attached network, a gateway looks up the network
      membership record corresponding to the destination address of the
      datagram.  For each of the networks listed in the membership


Deering & Cheriton                                              [Page 9]



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


      record, the gateway consults its routing table.  If, according to
      the routing table, a member network is directly attached, the
      gateway transmits a copy of the datagram on that network, using
      the network-specific multicast address allocated for the group on
      that network.  For a member network that is not directly attached
      the gateway creates a copy of the datagram with an additional
      inter-gateway header identifying the destination network.  This
      inter-gateway datagram is forwarded to the nearest gateway on the
      destination network, using conventional store-and-forward routing
      techniques.  At the gateway on the destination network, the
      datagram is stripped of its inter-gateway header and transmitted
      to the group's multicast address on that network.  The datagram is
      dropped by the relaying gateways whenever it exceeds its distance
      limit.

      The network membership records and the network-specific multicast
      structures are updated in response to group management requests
      from hosts.  A host sends a request to create, join, or leave a
      group to an immediate neighbour gateway.  If the host requests
      creation of a group, a new network membership record is created by
      the serving gateway and distributed to all other gateways.  If the
      host is the first on its network to join a group, or if the host
      is the last on its network to leave a group, the group's network
      membership record is updated in all gateways.  The updates need
      not be performed atomically at all gateways, due to the datagram
      delivery semantics; hosts can tolerate misrouted and lost packets
      caused by temporary gateway inconsistencies, as long as the
      inconsistencies are resolved within normal host retransmission
      periods. In this respect, the network membership data is similar
      to the network reachability data maintained by conventional
      routing algorithms, and can be handled by similar mechanisms.

      In many cases, a host joins a group that already has members on
      the same network, or leaves a group that has remaining members on
      the same network.  This is then a local matter between the hosts
      and gateways on a single network:  only the local host membership
      table needs to be updated to include or exclude the host.

      This basic implementation strategy meets the delivery requirements
      stated at the end of Section 4.  However, it is far from optimal,
      in terms of either delivery efficiency or group management
      overhead. Below, we discuss some further refinements to the basic
      implementation.






Deering & Cheriton                                             [Page 10]



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


   6.2. Multicast Routing Between Networks

      Multicast routing among the Internet gateways is similar to
      store-and-forward routing in a point-to-point network.  The main
      difference is that the links between the nodes (gateways) can be a
      mixture of broadcast and unicast-type networks with widely
      different throughput and delay characteristics.  In addition,
      packets are addressed to networks rather than hosts (at the
      gateway level).

      We intend to use the extended reverse path forwarding algorithm of
      Dalal and Metcalfe [10].  Although originally designed for
      broadcast, it is a simple and efficient technique that can serve
      well for multicast delivery if network membership records in each
      gateway are augmented with information from neighbouring gateways.
      This algorithm uses the source network identifier, rather than a
      destination network identifier to make routing decisions.  Since
      the source address of a datagram may be a group address, it cannot
      be used to identify the source network of the datagram; the first
      gateway must add a header specifying the source network.  This
      approach minimizes redundant transmissions when multiple
      destination networks are reachable across a common intergateway
      link, a problem with the basic implementation described above.

      Note that we eliminate from consideration techniques that fail to
      deliver along the branches of the shortest delay tree rooted at
      the source, such as Wall's center-based forwarding [16] because
      this compromises the meaning of the multicast distance parameter
      and detracts from multicast performance in general.  We also
      rejected the approach of having a multicast packet carry more than
      one network identifier in its inter-gateway header to indicate
      multiple destination networks because the resulting variable
      length headers would cause buffering and fragmentation problems in
      the gateways.

   6.3. Multicasting Within Networks

      A simple optimization within a network is to have the sender use
      the local multicast address of a host group for its initial
      transmission. This allows the local host group members to receive
      the transmission immediately along with the gateways (which must
      now "eavesdrop" on all multicast transmissions).  A gateway only
      forwards the datagram if the destination host group includes
      members on other networks.  This scheme reduces the cost to reach
      local group members to one packet transmission from two required




Deering & Cheriton                                             [Page 11]



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


      in the basic implementation <3> so transmission to local members
      is basically as efficient as the local multicast support provided
      by the network.

      A similar opportunity for reducing packet traffic arises when a
      datagram must traverse a network to get from one gateway to
      another, and that network also holds members of the destination
      group.  Again, use of a network-specific multicast address which
      includes member hosts plus gateways can achieve the desired
      effect.  However, in this case, hosts must be prepared to accept
      datagrams that include an inter-gateway header or, alternatively,
      every datagram must include a spare field in its header for use by
      gateways in lieu of an additional inter-gateway header.

   6.4. Distributing Membership Information

      A refinement to host group membership maintenance is to store the
      host group membership record for a group only in those gateways
      that are directly connected to member networks.  Information about
      other groups is cached in the gateway only while it is required to
      route to those other groups.  When a gateway receives a datagram
      to be forwarded to a group for which it has no network membership
      record (which can only happen if the gateway is not directly
      connected to a member network), it takes the following action.
      The gateway assumes temporarily that the destination group has
      members on every network in the internetwork, except those
      directly attached to the sending gateway, and routes the datagram
      accordingly.  In the inter-gateway header of the outgoing packet,
      the gateway sets a bit indicating that it wishes to receive a copy
      of the network membership record for the destination host group.
      When such a datagram reaches a gateway on a member network, that
      gateway sends a copy of the membership record back to the
      requesting gateway and clears the copy request bit in the
      datagram.

      Copies of network membership records sent to gateways outside of a
      group's member networks are cached for use in subsequent
      transmissions by those gateways.  That raises the danger of a
      stale cache entry leading to systematic delivery failures.  To
      counter that problem, the inter-gateway header contains a field
      which is a hash value or checksum on the network membership record
      used to route the datagram.  Gateways on member networks compare
      the checksum on incoming datagrams with their up-to-date records.
      If the checksums don't match, an up-to-date copy of the record is
      returned to the gateway with the bad record.

      This caching strategy minimizes intergateway traffic for groups


Deering & Cheriton                                             [Page 12]



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


      that are only used within one network or within the set of
      networks on which members reside, the expected common cases.
      Partial replication with caching also reduces the overhead for
      network traffic to disseminate updates and keep all copies
      consistent.  Finally, it also reduces the total space required in
      all the gateways to support a large number of host groups.

      We have not addressed here the problem of maintaining up-to-date,
      consistent network membership records within the set of gateways
      connected to members of a group.  This can be viewed as a
      distributed database problem which has been well studied in other
      contexts.  The loose consistency requirements on network
      membership records suggest that the techniques used in Grapevine
      [3] might be useful for this application.

7. Related Work

   The use of unreliable multicast by higher-level protocols and the
   implementation of multicast within various individual networks have
   been well-studied (see [7] for references and discussion).  However,
   there is relatively little published work on the use or
   implementation of internetwork multicasting.

   Boggs, in his thesis [4], describes a number of distributed
   applications that are impossible or very awkward to support without
   the flexible binding nature of broadcast addressing.  Although he
   recognizes that almost all of his applications would be best served
   by a multicast mechanism, he advocates the use of "directed
   broadcast" because it is easy to implement within many kinds of
   networks and can be extended across an internetwork without placing
   any new burden on internetwork gateways.  In RFC-919 [13], Mogul
   proposes adopting directed broadcast for the DARPA Internet.

   Broadcasting has the undesirable side effect of delivering packets to
   more hosts than necessary, thus incurring overhead on uninvolved
   parties and possibly creating security problems.  As more and more
   applications take advantage of broadcasting, the overhead on all
   hosts continues to rise.  Clearly, broadcast does not scale up to a
   large internetwork.  As an attempt to handle the scaling problem,
   directed broadcast is less attractive than true multicast because the
   set of hosts that can be reached by a single "send" operation is an
   artifact of the internetwork topology, rather than a grouping that is
   meaningful to the sender.

   In RFC-947 [12], Lebowitz and Mankins propose the use of broadcast




Deering & Cheriton                                             [Page 13]



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


   repeaters that pick up broadcast datagrams from one network and relay
   them to other networks for broadcast there.  This technique is even
   less selective of its targets than Bogg's directed broadcast method.

   Aguilar [1] suggests allowing an IP datagram to carry multiple
   destination addresses, which are used by the gateways to route the
   datagram to each recipient.  Such a facility would alleviate some of
   the inefficiencies of sending individual datagrams to a group, but it
   would not be able to take advantage of local network multicast
   facilities. More seriously, Aguilar's scheme requires the sender to
   know the individual IP addresses of all members of the destination
   group and thus lacks the flexible binding nature of true multicast or
   broadcast.

8. Concluding Remarks

   We have described a model of multicast communication for the
   Internet. As an extension of the existing Internet architecture, it
   views unicast communication and time-to-live constraints as special
   cases of the more general form of communication arising with
   multicast.  We have argued that this model is implementable in the
   Internet and that it provides a powerful facility for a variety of
   applications.  In some cases, it provides a facility that is required
   for certain applications to work in the Internet environment.  In
   other cases, it provides a more efficient, robust and possibly more