[The purpose of this note is to describe the CRONUS Virtual Local Network, especially the addressing related features. These features include a method for mapping between Internet Addresses and Local Network addresses. This is a topic of current concern in the ARPA Internet community. This note is intended to stimulate discussion. This is not a specification of an Internet Standard.]
This note defines the Cronus (1) Virtual Local Network
(VLN), a facility which provides interhost message transport to
the Cronus Distributed Operating System. The VLN consists of a
'client interface specification' and an 'implementation'; the
client interface is expected to be available on every Cronus
host. Client processes can send and receive datagrams using
specific, broadcast, or multicast addressing as defined in the
_______________ (1) The Cronus Distributed Operating System is being designed by Bolt Beranek and Newman Inc., as a component of the Distributed Systems Technology Program sponsored by Rome Air Development Center. This work is supported by the DOS Design/Implementation contract, F30602-81-C-0132.
From the viewpoint of other Cronus system software and
application programs, the VLN stands in place of a direct
interface to the physical local network (PLN). This additional
level of abstraction is defined to meet two major system
* COMPATIBILITY. The VLN defines a communication facility which is compatible with the Internet Protocol (IP) developed by DARPA; by implication the VLN is compatible with higher-level protocols such as the Transmission Control Protocol (TCP) based on IP.
* SUBSTITUTABILITY. Cronus software built above the VLN is dependent only upon the VLN interface and not its implementation. It is possible to substitute one physical local network for another in the VLN implementation, provided that the VLN interface semantics are maintained.
(This note assumes the reader is familiar with the concepts
and terminology of the DARPA Internet Program; reference  is a
compilation of the important protocol specifications and other
documents. Documents in  of special significance here are 
The compatibility goal is motivated by factors relating to
the Cronus design and its development environment. A large body
of software has evolved, and continues to evolve, in the internet
community fostered by DARPA. For example, the compatibility goal
for routing datagrams to a gateway if they are addressed to hosts
outside the cluster, and for delivering incoming datagrams to the
appropriate VLN host. A VLN is viewed as a network in the
internet, and thus has an internet network number. (2)
_______________ (2) The PLN could possess its own network number, different from the network number of the VLN it implements, or the network numbers could be the same. Different numbers would complicate the gateways somewhat, but are consistent with the VLN and internet models.
Although the structure of internet and VLN datagrams is
identical, the VLN-to-client interface places its own
interpretation on internet header fields, and differs from the
IP-to-client interface in significant respects:
1. The VLN layer utilizes only the Source Address, Destination Address, Total Length, and Header Checksum fields in the internet datagram; other fields are accurately transmitted from the sending to the receiving client.
2. Internet datagram fragmentation and reassembly is not performed in the VLN layer, nor does the VLN layer implement any aspect of internet datagram option processing.
3. At the VLN interface, a special interpretation is placed upon the Destination Address in the internet header, which allows VLN broadcast and multicast addresses to be encoded in the internet address structure.
4. With high probability, duplicate delivery of datagrams sent between hosts on the same VLN does not occur.
5. Between two VLN clients S and R in the same Cronus cluster, the sequence of datagrams received by R is a subsequence of the sequence sent by S to R; a stronger sequencing property holds for broadcast and multicast addressing.
The meaning of the local address field of a VLN address is
defined in the table below.
ADDRESS MODES VLN LOCAL ADDRESS VALUES
Specific Host 0 to 1,023
Multicast 1,024 to 65,534
Table 2. VLN Local Address Modes
In order to represent the full range of specific, broadcast, and
multicast addresses in the local address field, a VLN network
should be either class A or class B. If a VLN is a class A
internet network, a VLN local address occupies the low-order 16
bits of the 24 bit internet local address field, and the upper 8
bits of the internet local address are zero. If a VLN is a class _______________ (4) The ability of hosts outside a Cronus cluster to transmit datagrams with VLN broadcast or multicast destination addresses into the cluster may be restricted by the cluster gateway(s), for reasons of system security.
ReceiveVLNDatagram are A) a blocking receive operation; and B) a
non-blocking but synchronous receive operation, which returns a
failure code immediately if a datagram is not available. Either
alternative may satisfy particular requirements, but an
asynchronous receive subsumes these and is more generally
useful.) At a minimum, the client must have fully synchronous
access to each of the operations; more elaborate mechanisms may
be provided at the option of the VLN implementation.
The VLN layer for this host is reset (e.g., for the Ethernet VLN implementation the operation ClearVPMap is performed, and a frame of type "Cronus VLN" and subtype "Mapping Update" is broadcast; see Section 4.2). This operation does not affect the set of attended VLN multicast addresses.
Returns the specific VLN address of this host; this can always be done without communication with any other host.
When this operation completes, the VLN layer has copied the Datagram and it is either "in transmission" or "delivered", i.e., the transmitting process cannot assume that the message has been delivered when SendVLNDatagram
When this operation completes, Datagram is a representation of a VLN datagram sent by a VLN client and not previously received by the client invoking ReceiveVLNDatagram.
When this operation completes, no VLN multicast addresses are registered with the local VLN component.
If this operation returns True then MAddress, which must be a VLN multicast address, is registered as an "alias" for this host, and messages addressed to MAddress by VLN clients will be delivered to the client on this host.
When this operation completes, MAddress is not registered as a multicast address for the client on this host.
Whenever a Cronus host comes up, ResetVLNInterface and
PurgeMAddresses are performed implicitly by the VLN layer before
it will accept a request from the client or incoming traffic from
the PLN. They may also be invoked by the client during normal
operation. As described in Section 4.2 below, a VLN component
may depend upon state information obtained dynamically from other
hosts, and there is a possibility that incorrect information
Between two VLN clients S and R in the same cluster, the
sequence of datagrams received by R is a subsequence of the
sequence sent by S to R, i.e., datagrams are received in order,
possibly with omissions.
A stronger sequencing property holds for broadcast and
multicast transmissions. If receivers R1 and R2 both receive
broadcast or multicast datagrams D1 and D2, either they both
receive D1 before D2, or they both receive D2 before D1.
3 Desirable Characteristics of a Physical Local Network
While it is conceivable that a VLN could be implemented on a
long-haul or virtual-circuit-oriented PLN, these networks are
generally ill-suited to the task. The ARPANET, for example, does
not support broadcast or multicast addressing modes, nor does it _______________ (5) A protocol operating above the VLN layer (e.g., TCP) may employ a retransmission strategy; the VLN layer does nothing to filter duplicates arising in this way.
Each VLN component maintains a virtual-to-physical address
map (the VPMap) which translates a 32 bit specific VLN host
address (7) in this cluster to a 48 bit Ethernet address. (8)
The VPMap data structure and the operations on it can be
efficiently implemented using standard hashing techniques. Only
three operations defined on the VPMap are discussed in this note:
ClearVPMap, TranslateVtoP, and StoreVPPair.
Each host has an Ethernet host address (EHA) to which its
controller will respond, determined by Xerox and the controller
manufacturer (see Section 4.5.2). At host initialization time, _______________ (6) See  for a lively discussion of the problems arising from the failure of communicants to agree upon consistent orderings. (7) Since the high-order 22 bits of the address are constant for all specific host addresses in a cluster, only the low-order 10 bits of the address are significant. (8) The least significant bit of the first octet of the Ethernet address is always 0, since these are not broadcast or multicast addresses.
"Cronus VLN" and subtype "Mapping Update", it performs a
StoreVPPair operation using the Ethernet Source Address field and
the host VLN address sent as frame data.
This multicast mechanism could be extended to perform other
address mapping functions, for example, to discover the addresses
of a cluster's gateways. Suppose all gateways register the same
Multicast Gateway Address (MGA, analogous to MHA) with their
Ethernet controllers; the MGA then becomes a "logical name" for
the gateway function in a Cronus cluster. If a host needs to
send a datagram out of the cluster and doesn't know what specific
gateway address to use, the host can multicast the datagram to
all gateways by sending to MGA. One or more of the gateways can
forward the datagram, and transmit a "Gateway Mapping Update"
(containing the gateway's specific Ethernet address) back to the
originating host. Specific gateway addresses could be cached in
a structure similar to the VPMap, keyed to the destination
network number. (9)
_______________ (9) Because the Cronus Advanced Development Model will contain only one gateway, a simpler mechanism will be implemented initially; the specific Ethernet address of the gateway will be "well-known" to all VLN components.
and Interlan controllers mentioned above, for example, would have
Min_Attendable equal to 7; (10) a network composed only of hosts
with 3COM Model 3C400 controllers would have Min_Attendable equal
to 64,511, since the controller itself does not restrict the
number of Ethernet multicast addresses to which a host may
The local address field of a VLN multicast address can be
represented in two octets, in hexadecimal:
From Table 1, mm-mm considered as a decimal integer M is in the
range 1,024 to 65,534. When SendVLNDatagram is invoked with a
VLN multicast datagram, there are two cases:
1. (M - 1,023) <= Min_Attendable. In this case, the datagram is encapsulated in a "DoD IP" Ethernet frame, and multicast with the Ethernet address
A VLN component which attends VLN multicast addresses in _______________ (10) Min_Attendable is 7, rather than 8, because one multicast slot in the controller must be reserved for the host's MHA, as described in Section 4.2. (11) For the Cronus Advanced Development Model, Min_Attendable is currently defined to be 60.
this range should receive Ethernet multicast addresses in this format, if necessary by registering the addresses with its Ethernet controller.
2. (M - 1,023) > Min_Attendable. The datagram is encapsulated in a "DoD IP" Ethernet frame, and transmitted to the Ethernet broadcast address. A VLN component which attends VLN multicast addresses in this range must receive all broadcast frames, and filter them on the basis of frame type and VLN destination address (found in the IP destination address field).
There are two drawbacks to this protocol that might induce a
more complex design: 1) because Min_Attendable is the "lowest
common denominator" for the ability of Ethernet controllers to
recognize multicast addresses, some controller capabilities may
be wasted; 2) small VLN addresses (less than Max_Attendable +
1,024) will probably be handled more efficiently than large VLN
multicast addresses. The second factor complicates the
assignment of VLN multicast addresses to functions, since the