Multi-network broadcasting within the Internet
RFC 947
|
Document |
Type |
|
RFC - Unknown
(June 1985; No errata)
|
|
Authors |
|
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
Legacy stream
|
|
Formats |
|
plain text
html
pdf
htmlized (tools)
htmlized
bibtex
|
Stream |
Legacy state
|
|
(None)
|
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
IESG |
IESG state |
|
RFC 947 (Unknown)
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Network Working Group Ken Lebowitz
Request for Comments: 947 David Mankins
BBN Laboratories
June 1985
Multi-network Broadcasting within the Internet
1. Status of this Memo
This RFC describes the extension of a network's broadcast domain to
include more than one physical network through the use of a broadcast
packet repeater.
The following paper will present the problem of multi-network
broadcasting and our motivation for solving this problem which is in
the context of developing a distributed operating system. We discuss
different solutions to extending a broadcast domain and why we chose
the one that has been implemented. In addition, there is information
on the implementation itself and some notes on its performance.
It is hoped that the ideas presented here will help people in the
Internet who have applications which make use of broadcasting and
have come up against the limitation of only being able to broadcast
within a single network.
The information presented here is accurate as of the date of
publication but specific details, particularly those regarding our
implementation, may change in the future. Distribution of this memo
is unlimited.
2. The Problem
Communication between hosts on separate networks has been addressed
largely through the use of Internet protocols and gateways. One
aspect of internetwork communication that hasn't been solved in the
Internet is extending broadcasting to encompass two or more networks.
Broadcasting is an efficient way to send information to many hosts
while only having to transmit a single packet. Many of the current
local area network (LAN) architectures directly support a broadcast
mechanism. Unfortunately, this broadcast mechanism has a shortcoming
when it is used in networking environments which include multiple
LANs connected by gateways such as in the DARPA Internet. This
shortcoming is that broadcasted packets are only received by hosts on
the physical network on which the packet was broadcast. As a result,
any application which takes advantage of LAN broadcasting can only
broadcast to those hosts on its physical network.
We took advantage of broadcasting in developing the Cronus
Distributed Operating System [1]. Cronus provides services and
communication to processes distributed among a variety of different
Lebowitz & Mankins [Page 1]
RFC 947 June 1985
Multi-network Broadcasting within the Internet
types of computer systems. Cronus is built around logical clusters
of hosts connected to one or more high-speed LANs. Communication in
Cronus is built upon the TCP and UDP protocols. Cronus makes use of
broadcasting for dynamically locating resources on other hosts and
collecting status information from a collection of servers. Since
Cronus's broadcast capabilities are not intended to be limited to the
boundaries of a single LAN, we needed to find some way to extend our
broadcasting domain to include hosts on distant LANs in order to
experiment with clusters that span several physical networks. Cronus
predominantly uses broadcasting to communicate with a subset of the
hosts that actually receive the broadcasted message. A multicast
mechanism would be more appropriate, but was unavailable in some of
our network implementations, so we chose broadcast for the initial
implementation of Cronus utilities.
3. Our Solution
The technique we chose to experiment with the multi-network
broadcasting problem can be described as a "broadcast repeater". A
broadcast repeater is a mechanism which transparently relays
broadcast packets from one LAN to another, and may also forward
broadcast packets to hosts on a network which doesn't support
broadcasting at the link-level. This mechanism provides flexibility
while still taking advantage of the convenience of LAN broadcasts.
Our broadcast repeater is a process on a network host which listens
for broadcast packets. These packets are picked up and
retransmitted, using a simple repeater-to-repeater protocol, to one
or more repeaters that are connected to distant LANs. The repeater
on the receiving end will rebroadcast the packet on its LAN,
retaining the original packet's source address. The broadcast
repeater can be made very intelligent in its selection of messages to
be forwarded. We currently have the repeater forward only broadcast
messages sent using the UDP ports used by Cronus, but messages may be
selected using any field in the UDP or IP headers, or all IP-level
broadcast messages may be forwarded.
Show full document text