A broadcast packet is for delivery to all nodes of a network. Algorithms for accomplishing this delivery through a store-and-forward packet switching computer network include (1) transmission of separately addressed packets, (2) multidestination addressing, (3) hot potato forwarding, (4) spanning tree forwarding, and (5) source based forwarding. To this list of algorithms we add (6) reverse path forwarding, a broadcast routing method which exploits routing procedures and data structures already available for packet switching. Reverse path forwarding is a practical algorithm for broadcast routing in store-and-forward packet switching computer networks. The algorithm is described as being practical because it is not optimal according to metrics developed for its analysis in this paper, and also because it can be implemented in existing networks with less complexity than that required for the known alternatives.

Version early phases of the design work, R. Metcalfe, A. McKenzie, H. Zimmerman, G. LeLann, and M. Elie were most helpful in explicating the various issues to be resolved. Of course, we remain responsible for the remaining errors and misstatements which no doubt lurk in the nooks and crannies of the text. Processes are viewed as the active elements of all HOST computers in a network. Even terminals and files or other I/O media are viewed as communicating through the use of processes. Thus, all network communication is viewed as inter-process communication. Since a process may need to distinguish among several communication streams between itself and another process [or processes], we imagine that each process may have a number of PORTs through which it communicates with the ports of other processes. Since port names are selected independently by each operating system, TCP, or user, they may not be unique. To provide for unique names at each TCP, we concatenate a NETWORK identifier, and a TCP identifier with a port name to create a SOCKET name which will be unique throughout all networks connected together.

The Pilot operating system provides a single-user, single-language environment for higher level software on a powerful personal computer. Its features include virtual memory, a large "flat" file system, streams, network communication facilities, and concurrent programming support. Pilot thus provides rather more powerful facilities than are normally associated with personal computers. The exact facilities provided display interesting similarities to and differences from corresponding facilities provided in large multi-user systems. Pilot is implemented entirely in Mesa, a highlevel system programming language. The modularization of the implementation displays some interesting aspects in terms of both the static structure and dynamic interactions of the various components.

AgentThe problem of naming and locating objects in a distributed environment is considered, and the clearinghouse, a decentralized agent for supporting the naming of these "network-visible" objects, is described. The objects "known" to the clearinghouse are of many types and include workstations, file servers, print servers, mail servers, clearinghouse servers, and human user. All objects known to the clearinghouse are named using the same convention, and the clearinghouse provides information about objects in a uniform fashion, regardless of their type. The clearinghouse also supports aliases.The clearinghouse binds a name to a set of properties of various types. For instance, the name of a user may be associated with the location of his local workstation, mailbox, and nonlocation information such as password and comments.The clearinghouse is decentralized and replicated. That is, instead of one global clearinghouse server, there are many local clearinghouse servers, each storing a copy of a portion of the global database. The totality of services supplied by these clearinghouse servers is called "the clearinghouse." Decentralization and replication increase efficiency, security, and reliability.A request to the clearinghouse to bind a name to its set of properties may originate anywhere in the system and be directed to any clearinghouse server. A clearinghouse client need not be concerned with the question of which clearinghouse server actually contains the binding--the clearinghouse stub in the client in conjunction with distributed clearinghouse servers automatically fmds the mapping ff it exists. Updates to the various copies of a mapping may occur asynchronously and be interleaved with requests for bindings of names to properties; updates to the various copies are not treated as indivisible transactions. Any resulting inconsistency between the various copies is only transient: the clearinghouse automatically arbitrates between conflicting updates to restore consistency.

No abstract