home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 900s / rfc922.txt < prev    next >
Text File  |  1992-09-21  |  24KB  |  686 lines
  1.  
  2.  
  3. Network Working Group                                      Jeffrey Mogul
  4. Request for Comments: 922                    Computer Science Department
  5.                                                      Stanford University
  6.                                                             October 1984
  7.  
  8.        BROADCASTING INTERNET DATAGRAMS IN THE PRESENCE OF SUBNETS
  9.  
  10.  
  11. Status of this Memo
  12.  
  13.    We propose simple rules for broadcasting Internet datagrams on local
  14.    networks that support broadcast, for addressing broadcasts, and for
  15.    how gateways should handle them.
  16.  
  17.    This RFC suggests a proposed protocol for the ARPA-Internet
  18.    community, and requests discussion and suggestions for improvements.
  19.    Distribution of this memo is unlimited.
  20.  
  21. Acknowledgement
  22.  
  23.    This proposal here is the result of discussion with several other
  24.    people, especially J. Noel Chiappa and Christopher A. Kent, both of
  25.    whom both pointed me at important references.
  26.  
  27. 1. Introduction
  28.  
  29.    The use of broadcasts, especially on high-speed local area networks,
  30.    is a good base for many applications.  Since broadcasting is not
  31.    covered in the basic IP specification [12], there is no agreed-upon
  32.    way to do it, and so protocol designers have not made use of it. (The
  33.    issue has been touched upon before, e.g. [6], but has not been the
  34.    subject of a standard.)
  35.  
  36.    We consider here only the case of unreliable, unsequenced, possibly
  37.    duplicated datagram broadcasts (for a discussion of TCP broadcasting,
  38.    see [10].) Even though unreliable and limited in length, datagram
  39.    broadcasts are quite useful [1].
  40.  
  41.    We assume that the data link layer of the local network supports
  42.    efficient broadcasting.  Most common local area networks do support
  43.    broadcast; for example, Ethernet [7, 5], ChaosNet [9], token ring
  44.    networks [2], etc.
  45.  
  46.    We do not assume, however, that broadcasts are reliably delivered.
  47.    (One might consider providing a reliable datagram broadcast protocol
  48.    as a layer above IP.) It is quite expensive to guarantee delivery of
  49.    broadcasts; instead, what we assume is that a host will receive most
  50.    of the broadcasts that are sent.  This is important to avoid
  51.    excessive use of broadcasts; since every host on the network devotes
  52.    at least some effort to every broadcast, they are costly.
  53.  
  54.  
  55.  
  56. Mogul                                                           [Page 1]
  57.  
  58.  
  59.  
  60. RFC 922                                                     October 1984
  61. Broadcasting Internet Datagrams in the Presence of Subnets
  62.  
  63.  
  64.    When a datagram is broadcast, it imposes a cost on every host that
  65.    hears it.  Therefore, broadcasting should not be used
  66.    indiscriminately, but rather only when it is the best solution to a
  67.    problem.
  68.  
  69. 2. Terminology
  70.  
  71.    Because broadcasting depends on the specific data link layer in use
  72.    on a local network, we must discuss it with reference to both
  73.    physical networks and logical networks.
  74.  
  75.    The terms we will use in referring to physical networks are, from the
  76.    point of view of the host sending or forwarding a broadcast:
  77.  
  78.    Local Hardware Network
  79.  
  80.       The physical link to which the host is attached.
  81.  
  82.    Remote Hardware Network
  83.  
  84.       A physical network which is separated from the host by at least
  85.       one gateway.
  86.  
  87.    Collection of Hardware Networks
  88.  
  89.       A set of hardware networks (transitively) connected by gateways.
  90.  
  91.    The IP world includes several kinds of logical network.  To avoid
  92.    ambiguity, we will use the following terms:
  93.  
  94.    Internet
  95.  
  96.       The DARPA Internet collection of IP networks.
  97.  
  98.    IP Network
  99.  
  100.       One or a collection of several hardware networks that have one
  101.       specific IP network number.
  102.  
  103.    Subnet
  104.  
  105.       A single member of the collection of hardware networks that
  106.       compose an IP network.  Host addresses on a given subnet share an
  107.       IP network number with hosts on all other subnets of that IP
  108.       network, but the local-address part is divided into subnet-number
  109.  
  110.  
  111.  
  112.  
  113. Mogul                                                           [Page 2]
  114.  
  115.  
  116.  
  117. RFC 922                                                     October 1984
  118. Broadcasting Internet Datagrams in the Presence of Subnets
  119.  
  120.  
  121.       and host-number fields to indicate which subnet a host is on.  We
  122.       do not assume a particular division of the local-address part;
  123.       this could vary from network to network.
  124.  
  125.    The introduction of a subnet level in the addressing hierarchy is at
  126.    variance with the IP specification [12], but as the use of
  127.    addressable subnets proliferates it is obvious that a broadcasting
  128.    scheme should support subnetting.  For more on subnets, see [8].
  129.  
  130.    In this paper, the term "host address" refers to the host-on-subnet
  131.    address field of a subnetted IP network, or the host-part field
  132.    otherwise.
  133.  
  134.    An IP network may consist of a single hardware network or a
  135.    collection of subnets; from the point of view of a host on another IP
  136.    network, it should not matter.
  137.  
  138. 3. Why Broadcast?
  139.  
  140.    Broadcasts are useful when a host needs to find information without
  141.    knowing exactly what other host can supply it, or when a host wants
  142.    to provide information to a large set of hosts in a timely manner.
  143.  
  144.    When a host needs information that one or more of its neighbors might
  145.    have, it could have a list of neighbors to ask, or it could poll all
  146.    of its possible neighbors until one responds.  Use of a wired-in list
  147.    creates obvious network management problems (early binding is
  148.    inflexible).  On the other hand, asking all of one's neighbors is
  149.    slow if one must generate plausible host addresses, and try them
  150.    until one works.  On the ARPANET, for example, there are roughly 65
  151.    thousand plausible host numbers.  Most IP implementations have used
  152.    wired-in lists (for example, addresses of "Prime" gateways.)
  153.    Fortunately, broadcasting provides a fast and simple way for a host
  154.    to reach all of its neighbors.
  155.  
  156.    A host might also use a broadcast to provide all of its neighbors
  157.    with some information; for example, a gateway might announce its
  158.    presence to other gateways.
  159.  
  160.    One way to view broadcasting is as an imperfect substitute for
  161.    multicasting, the sending of messages to a subset of the hosts on a
  162.    network.  In practice, broadcasts are usually used where multicasts
  163.    are what is wanted; datagrams are broadcast at the hardware level,
  164.    but filtering software in the receiving hosts gives the effect of
  165.    multicasting.
  166.  
  167.    For more examples of broadcast applications, see [1, 3].
  168.  
  169.  
  170. Mogul                                                           [Page 3]
  171.  
  172.  
  173.  
  174. RFC 922                                                     October 1984
  175. Broadcasting Internet Datagrams in the Presence of Subnets
  176.  
  177.  
  178. 4. Broadcast Classes
  179.  
  180.    There are several classes of IP broadcasting:
  181.  
  182.       - Single-destination datagrams broadcast on the local hardware
  183.         net: A datagram is destined for a specific IP host, but the
  184.         sending host broadcasts it at the data link layer, perhaps to
  185.         avoid having to do routing.  Since this is not an IP broadcast,
  186.         the IP layer is not involved, except that a host should discard
  187.         datagram not meant for it without becoming flustered (i.e.,
  188.         printing an error message).
  189.  
  190.       - Broadcast to all hosts on the local hardware net: A
  191.         distinguished value for the host-number part of the IP address
  192.         denotes broadcast instead of a specific host.  The receiving IP
  193.         layer must be able to recognize this address as well as its own.
  194.         However, it might still be useful to distinguish at higher
  195.         levels between broadcasts and non-broadcasts, especially in
  196.         gateways.  This is the most useful case of broadcast; it allows
  197.         a host to discover gateways without wired-in tables, it is the
  198.         basis for address resolution protocols, and it is also useful
  199.         for accessing such utilities as name servers, time servers,
  200.         etc., without requiring wired-in addresses.
  201.  
  202.       - Broadcast to all hosts on a remote hardware network: It is
  203.         occasionally useful to send a broadcast to all hosts on a
  204.         non-local network; for example, to find the latest version of a
  205.         hostname database, to bootload a host on a subnet without a
  206.         bootserver, or to monitor the timeservers on the subnet.  This
  207.         case is the same as local-network broadcasts; the datagram is
  208.         routed by normal mechanisms until it reaches a gateway attached
  209.         to the destination hardware network, at which point it is
  210.         broadcast.  This class of broadcasting is also known as
  211.         "directed broadcasting", or quaintly as sending a "letter bomb"
  212.         [1].
  213.  
  214.       - Broadcast to all hosts on a subnetted IP network (Multi-subnet
  215.         broadcasts): A distinguished value for the subnet-number part of
  216.         the IP address is used to denote "all subnets".  Broadcasts to
  217.         all hosts of a remote subnetted IP network are done just as
  218.         directed broadcasts to a single subnet.
  219.  
  220.       - Broadcast to the entire Internet: This is probably not useful,
  221.         and almost certainly not desirable.
  222.  
  223.  
  224.  
  225.  
  226.  
  227. Mogul                                                           [Page 4]
  228.  
  229.  
  230.  
  231. RFC 922                                                     October 1984
  232. Broadcasting Internet Datagrams in the Presence of Subnets
  233.  
  234.  
  235.    For reasons of performance or security, a gateway may choose not to
  236.    forward broadcasts; especially, it may be a good idea to ban
  237.    broadcasts into or out of an autonomous group of networks.
  238.  
  239. 5. Broadcast Methods
  240.  
  241.    A host's IP receiving layer must be modified to support broadcasting.
  242.    In the absence of broadcasting, a host determines if it is the
  243.    recipient of a datagram by matching the destination address against
  244.    all of its IP addresses.  With broadcasting, a host must compare the
  245.    destination address not only against the host's addresses, but also
  246.    against the possible broadcast addresses for that host.
  247.  
  248.    The problem of how best to send a broadcast has been extensively
  249.    discussed [1, 3, 4, 13, 14].  Since we assume that the problem has
  250.    already been solved at the data link layer, an IP host wishing to
  251.    send either a local broadcast or a directed broadcast need only
  252.    specify the appropriate destination address and send the datagram as
  253.    usual.  Any sophisticated algorithms need only reside in gateways.
  254.  
  255.    The problem of broadcasting to all hosts on a subnetted IP network is
  256.    apparently somewhat harder.  However, even in this case it turns out
  257.    that the best known algorithms require no additional complexity in
  258.    non-gateway hosts.  A good broadcast method will meet these
  259.    additional criteria:
  260.  
  261.       - No modification of the IP datagram format.
  262.  
  263.       - Reasonable efficiency in terms of the number of excess copies
  264.         generated and the cost of paths chosen.
  265.  
  266.       - Minimization of gateway modification, in both code and data
  267.         space.
  268.  
  269.       - High likelihood of delivery.
  270.  
  271.    The algorithm that appears best is the Reverse Path Forwarding (RPF)
  272.    method [4].  While RPF is suboptimal in cost and reliability, it is
  273.    quite good, and is extremely simple to implement, requiring no
  274.    additional data space in a gateway.
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282.  
  283.  
  284. Mogul                                                           [Page 5]
  285.  
  286.  
  287.  
  288. RFC 922                                                     October 1984
  289. Broadcasting Internet Datagrams in the Presence of Subnets
  290.  
  291.  
  292. 6. Gateways and Broadcasts
  293.  
  294.    Most of the complexity in supporting broadcasts lies in gateways.  If
  295.    a gateway receives a directed broadcast for a network to which it is
  296.    not connected, it simply forwards it using the usual mechanism.
  297.    Otherwise, it must do some additional work.
  298.  
  299.    6.1. Local Broadcasts
  300.  
  301.       When a gateway receives a local broadcast datagram, there are
  302.       several things it might have to do with it.  The situation is
  303.       unambiguous, but without due care it is possible to create
  304.       infinite loops.
  305.  
  306.       The appropriate action to take on receipt of a broadcast datagram
  307.       depends on several things: the subnet it was received on, the
  308.       destination network, and the addresses of the gateway.
  309.  
  310.          - The primary rule for avoiding loops is "never broadcast a
  311.            datagram on the hardware network it was received on". It is
  312.            not sufficient simply to avoid repeating datagram that a
  313.            gateway has heard from itself; this still allows loops if
  314.            there are several gateways on a hardware network.
  315.  
  316.          - If the datagram is received on the hardware network to which
  317.            it is addressed, then it should not be forwarded.  However,
  318.            the gateway should consider itself to be a destination of the
  319.            datagram (for example, it might be a routing table update.)
  320.  
  321.          - Otherwise, if the datagram is addressed to a hardware network
  322.            to which the gateway is connected, it should be sent as a
  323.            (data link layer) broadcast on that network.  Again, the
  324.            gateway should consider itself a destination of the datagram.
  325.  
  326.          - Otherwise, the gateway should use its normal routing
  327.            procedure to choose a subsequent gateway, and send the
  328.            datagram along to it.
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338.  
  339.  
  340.  
  341. Mogul                                                           [Page 6]
  342.  
  343.  
  344.  
  345. RFC 922                                                     October 1984
  346. Broadcasting Internet Datagrams in the Presence of Subnets
  347.  
  348.  
  349.    6.2. Multi-subnet broadcasts
  350.  
  351.       When a gateway receives a broadcast meant for all subnets of an IP
  352.       network, it must use the Reverse Path Forwarding algorithm to
  353.       decide what to do.  The method is simple: the gateway should
  354.       forward copies of the datagram along all connected links, if and
  355.       only if the datagram arrived on the link which is part of the best
  356.       route between the gateway and the source of the datagram.
  357.       Otherwise, the datagram should be discarded.
  358.  
  359.       This algorithm may be improved if some or all of the gateways
  360.       exchange among themselves additional information; this can be done
  361.       transparently from the point of view of other hosts and even other
  362.       gateways.  See [4, 3] for details.
  363.  
  364.    6.3. Pseudo-Algol Routing Algorithm
  365.  
  366.       This is a pseudo-Algol description of the routing algorithm a
  367.       gateway should use.  The algorithm is shown in figure 1.  Some
  368.       definitions are:
  369.  
  370.       RouteLink(host)
  371.  
  372.          A function taking a host address as a parameter and returning
  373.          the first-hop link from the gateway to the host.
  374.  
  375.       RouteHost(host)
  376.  
  377.          As above but returns the first-hop host address.
  378.  
  379.       ResolveAddress(host)
  380.  
  381.          Returns the hardware address for an IP host.
  382.  
  383.       IncomingLink
  384.  
  385.          The link on which the packet arrived.
  386.  
  387.       OutgoingLinkSet
  388.  
  389.          The set of links on which the packet should be sent.
  390.  
  391.       OutgoingHardwareHost
  392.  
  393.          The hardware host address to send the packet to.
  394.  
  395.  
  396.  
  397.  
  398. Mogul                                                           [Page 7]
  399.  
  400.  
  401.  
  402. RFC 922                                                     October 1984
  403. Broadcasting Internet Datagrams in the Presence of Subnets
  404.  
  405.  
  406.       Destination.host
  407.  
  408.          The host-part of the destination address.
  409.  
  410.       Destination.subnet
  411.  
  412.          The subnet-part of the destination address.
  413.  
  414.       Destination.ipnet
  415.  
  416.          The IP-network-part of the destination address.
  417.  
  418.  
  419.  
  420.  
  421.  
  422.  
  423.  
  424.  
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450.  
  451.  
  452.  
  453.  
  454.  
  455. Mogul                                                           [Page 8]
  456.  
  457.  
  458.  
  459. RFC 922                                                     October 1984
  460. Broadcasting Internet Datagrams in the Presence of Subnets
  461.  
  462. BEGIN
  463.    IF Destination.ipnet IN AllLinks THEN
  464.       BEGIN
  465.          IF IsSubnetted(Destination.ipnet) THEN
  466.             BEGIN
  467.                IF Destination.subnet = BroadcastSubnet THEN
  468.                   BEGIN      /* use Reverse Path Forwarding algorithm */
  469.                      IF IncomingLink = RouteLink(Source) THEN
  470.                         BEGIN IF Destination.host = BroadcastHost THEN
  471.                               OutgoingLinkSet <- AllLinks -
  472.                            IncomingLink;
  473.                            OutgoingHost <- BroadcastHost;
  474.                            Examine packet for possible internal use;
  475.                         END
  476.                      ELSE  /* duplicate from another gateway, discard */
  477.                         Discard;
  478.                   END
  479.                ELSE
  480.                   IF Destination.subnet = IncomingLink.subnet THEN
  481.                      BEGIN           /* forwarding would cause a loop */
  482.                         IF Destination.host = BroadcastHost THEN
  483.                            Examine packet for possible internal use;
  484.                         Discard;
  485.                      END
  486.                   ELSE BEGIN    /* forward to (possibly local) subnet */
  487.                         OutgoingLinkSet <- RouteLink(Destination);
  488.                         OutgoingHost <- RouteHost(Destination);
  489.                      END
  490.             END
  491.          ELSE BEGIN         /* destined for one of our local networks */
  492.                IF Destination.ipnet = IncomingLink.ipnet THEN
  493.                   BEGIN              /* forwarding would cause a loop */
  494.                      IF Destination.host = BroadcastHost THEN
  495.                         Examine packet for possible internal use;
  496.                      Discard;
  497.                   END
  498.                ELSE BEGIN                     /* might be a broadcast */
  499.                      OutgoingLinkSet <- RouteLink(Destination);
  500.                      OutgoingHost <- RouteHost(Destination);
  501.                   END
  502.             END
  503.       END
  504.    ELSE BEGIN                    /* forward to a non-local IP network */
  505.          OutgoingLinkSet <- RouteLink(Destination);
  506.          OutgoingHost <- RouteHost(Destination);
  507.       END
  508.    OutgoingHardwareHost <- ResolveAddress(OutgoingHost);
  509. END
  510.  
  511. Figure 1: Pseudo-Algol algorithm for routing broadcasts by gateways
  512.  
  513. Mogul                                                           [Page 9]
  514.  
  515.  
  516.  
  517. RFC 922                                                     October 1984
  518. Broadcasting Internet Datagrams in the Presence of Subnets
  519.  
  520.  
  521. 7. Broadcast IP Addressing - Conventions
  522.  
  523.    If different IP implementations are to be compatible, there must be
  524.    convention distinguished number to denote "all hosts" and "all
  525.    subnets".
  526.  
  527.    Since the local network layer can always map an IP address into data
  528.    link layer address, the choice of an IP "broadcast host number" is
  529.    somewhat arbitrary.  For simplicity, it should be one not likely to
  530.    be assigned to a real host.  The number whose bits are all ones has
  531.    this property; this assignment was first proposed in [6].  In the few
  532.    cases where a host has been assigned an address with a host-number
  533.    part of all ones, it does not seem onerous to require renumbering.
  534.  
  535.    The "all subnets" number is also all ones; this means that a host
  536.    wishing to broadcast to all hosts on a remote IP network need not
  537.    know how the destination address is divided up into subnet and host
  538.    fields, or if it is even divided at all.  For example, 36.255.255.255
  539.    may denote all the hosts on a single hardware network, or all the
  540.    hosts on a subnetted IP network with 1 byte of subnet field and 2
  541.    bytes of host field, or any other possible division.
  542.  
  543.    The address 255.255.255.255 denotes a broadcast on a local hardware
  544.    network that must not be forwarded.  This address may be used, for
  545.    example, by hosts that do not know their network number and are
  546.    asking some server for it.
  547.  
  548.    Thus, a host on net 36, for example, may:
  549.  
  550.       - broadcast to all of its immediate neighbors by using
  551.         255.255.255.255
  552.  
  553.       - broadcast to all of net 36 by using 36.255.255.255
  554.  
  555.    without knowing if the net is subnetted; if it is not, then both
  556.    addresses have the same effect. A robust application might try the
  557.    former address, and if no response is received, then try the latter.
  558.    See [1] for a discussion of such "expanding ring search" techniques.
  559.  
  560.    If the use of "all ones" in a field of an IP address means
  561.    "broadcast", using "all zeros" could be viewed as meaning
  562.    "unspecified".  There is probably no reason for such addresses to
  563.    appear anywhere but as the source address of an ICMP Information
  564.    Request datagram.  However, as a notational convention, we refer to
  565.    networks (as opposed to hosts) by using addresses with zero fields.
  566.    For example, 36.0.0.0 means "network number 36" while 36.255.255.255
  567.    means "all hosts on network number 36".
  568.  
  569.  
  570. Mogul                                                          [Page 10]
  571.  
  572.  
  573.  
  574. RFC 922                                                     October 1984
  575. Broadcasting Internet Datagrams in the Presence of Subnets
  576.  
  577.  
  578.    7.1. ARP Servers and Broadcasts
  579.  
  580.       The Address Resolution Protocol (ARP) described in [11] can, if
  581.       incorrectly implemented, cause problems when broadcasts are used
  582.       on a network where not all hosts share an understanding of what a
  583.       broadcast address is.  The temptation exists to modify the ARP
  584.       server so that it provides the mapping between an IP broadcast
  585.       address and the hardware broadcast address.
  586.  
  587.       This temptation must be resisted.  An ARP server should never
  588.       respond to a request whose target is a broadcast address.  Such a
  589.       request can only come from a host that does not recognize the
  590.       broadcast address as such, and so honoring it would almost
  591.       certainly lead to a forwarding loop.  If there are N such hosts on
  592.       the physical network that do not recognize this address as a
  593.       broadcast, then a datagram sent with a Time-To-Live of T could
  594.       potentially give rise to T**N spurious re-broadcasts.
  595.  
  596. 8. References
  597.  
  598.    1.   David Reeves Boggs.  Internet Broadcasting.  Ph.D. Th., Stanford
  599.         University, January 1982.
  600.  
  601.    2.   D.D. Clark, K.T. Pogran, and D.P. Reed.  "An Introduction to
  602.         Local Area Networks".  Proc. IEEE 66, 11, pp1497-1516,
  603.         November 1978.
  604.  
  605.    3.   Yogan Kantilal Dalal.  Broadcast Protocols in Packet Switched
  606.         Computer Networks.  Ph.D. Th., Stanford University, April 1977.
  607.  
  608.    4.   Yogan K. Dalal and Robert M. Metcalfe.  "Reverse Path Forwarding
  609.         of Broadcast Packets".  Comm. ACM 21, 12, pp1040-1048,
  610.         December 1978.
  611.  
  612.    5.   The Ethernet, A Local Area Network: Data Link Layer and Physical
  613.         Layer Specifications.  Version 1.0, Digital Equipment
  614.         Corporation, Intel, Xerox, September 1980.
  615.  
  616.    6.   Robert Gurwitz and Robert Hinden.  IP - Local Area Network
  617.         Addressing Issues.  IEN-212, BBN, September 1982.
  618.  
  619.    7.   R.M. Metcalfe and D.R. Boggs.  "Ethernet: Distributed Packet
  620.         Switching for Local Computer Networks".  Comm. ACM 19, 7,
  621.         pp395-404, July 1976.  Also CSL-75-7, Xerox Palo Alto Research
  622.         Center, reprinted in CSL-80-2.
  623.  
  624.  
  625.  
  626.  
  627. Mogul                                                          [Page 11]
  628.  
  629.  
  630.  
  631. RFC 922                                                     October 1984
  632. Broadcasting Internet Datagrams in the Presence of Subnets
  633.  
  634.  
  635.    8.   Jeffrey Mogul.  Internet Subnets.  RFC-917, Stanford University,
  636.         October 1984.
  637.  
  638.    9.   David A. Moon.  Chaosnet.  A.I. Memo 628, Massachusetts
  639.         Institute of Technology Artificial Intelligence Laboratory,
  640.         June 1981.
  641.  
  642.    10.  William W. Plummer.  Internet Broadcast Protocols.  IEN-10, BBN,
  643.         March 1977.
  644.  
  645.    11.  David Plummer.  An Ethernet Address Resolution Protocol.
  646.         RFC-826, Symbolics, September 1982.
  647.  
  648.    12.  Jon Postel.  Internet Protocol.  RFC-791, ISI, September 1981.
  649.  
  650.    13.  David W. Wall.  Mechanisms for Broadcast and Selective
  651.         Broadcast.  Ph.D. Th., Stanford University, June 1980.
  652.  
  653.    14.  David W. Wall and Susan S. Owicki.  Center-based Broadcasting.
  654.         Computer Systems Lab Technical Report TR189, Stanford
  655.         University, June 1980.
  656.  
  657.  
  658.  
  659.  
  660.  
  661.  
  662.  
  663.  
  664.  
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674.  
  675.  
  676.  
  677.  
  678.  
  679.  
  680.  
  681.  
  682.  
  683.  
  684. Mogul                                                          [Page 12]
  685.  
  686.