RFC relevance of multicast

As per Relevance of the word multicast, we have this rfc below:

DOS-26 Rev A Virtual Local
RFC 824

THE CRONUS VIRTUAL LOCAL

William I.
Daniel C.
Bolt Beranek and Newman Inc

25 August 1982

[The purpose of this note is to describe the CRONUS
Local Network, especially the addressing related features
These features include a method for mapping between
Addresses and Local Network addresses. This is a topic of
current concern in the ARPA Internet community. This note
intended to stimulate discussion. This is not a
of an Internet Standard.]

1 Purpose and

This note defines the Cronus (1) Virtual Local

(VLN), a facility which provides interhost message transport

the Cronus Distributed Operating System. The VLN consists of

'client interface specification' and an 'implementation';

client interface is expected to be available on every

host. Client processes can send and receive datagrams

specific, broadcast, or multicast addressing as defined in

interface specification

_______________
(1) The Cronus Distributed Operating System is being designed
Bolt Beranek and Newman Inc., as a component of the
Systems Technology Program sponsored by Rome Air
Center. This work is supported by the DOS Design/
contract, F30602-81-C-0132.

1

DOS-26 Rev A Virtual Local
RFC 824

From the viewpoint of other Cronus system software

application programs, the VLN stands in place of a

interface to the physical local network (PLN). This

level of abstraction is defined to meet two major

objectives

* COMPATIBILITY. The VLN defines a communication
which is compatible with the Internet Protocol (IP
developed by DARPA; by implication the VLN is
with higher-level protocols such as the Transmission
Protocol (TCP) based on IP

* SUBSTITUTABILITY. Cronus software built above the VLN
dependent only upon the VLN interface and not
implementation. It is possible to substitute one
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

and terminology of the DARPA Internet Program; reference [6] is

compilation of the important protocol specifications and

documents. Documents in [6] of special significance here are [5]

and [4].)

The compatibility goal is motivated by factors relating

the Cronus design and its development environment. A large

of software has evolved, and continues to evolve, in the

community fostered by DARPA. For example, the compatibility

2

DOS-26 Rev A Virtual Local
RFC 824

permits the Cronus design to assimilate existing

components providing electronic mail, remote terminal access,

file transfer in a straightforward manner. In addition to

roles of such services in the Cronus system, they are needed

support for the design and development process. The

Cronus cluster, called the Advanced Development Model (ADM),

be connected to the ARPANET, and it is important that the

conform to the standards and conventions of the DARPA

community

The substitutability goal reflects the belief that

instances of the Cronus cluster will utilize different

local networks. Substitution may be desirable for reasons

cost, performance, or other properties of the physical

network such as mechanical and electrical ruggedness.

existence of the VLN interface definition suggests a

for physical local network substitution, namely, re

implementation of the VLN interface on each Cronus host.

implementations will be functionally equivalent but can

expected to differ along dimensions not specified by the

interface definition. Since different physical local

3

DOS-26 Rev A Virtual Local
RFC 824

are often quite similar, the task of "re-implementing" the VLN

probably much less difficult than building the

implementation; small modifications to an existing,

implementation may suffice

The concepts of the Cronus VLN, and in particular the

implementation based on Ethernet described in Section 4,

significance beyond their application in the Cronus system.

organizations are now beginning to install local networks

immediately confront the compatibility issue. For a number

universities, for example, the compatibility problem is

the interoperability of the Ethernet and the DARPA internet

Although perhaps less immediate, the substitutability issue

also be faced by other organizations as local network

advances, and the transfer of existing system and

software to a new physical local network base becomes an

necessity

Figure 1 shows the position of the VLN in the lowest

of the Cronus protocol hierarchy. The VLN

specification given in the next section is actually a meta

specification, like the specifications of IP and TCP, in that

4

DOS-26 Rev A Virtual Local
RFC 824

programming details of the interface are host-dependent

unspecified. The precise representation of the VLN

structures and operations can be expected to vary from machine

machine, but the functional capabilities of the interface are

same regardless of the host

.
.
| . |
|-----------------------------------|
| Transmission | User | |
| Control | Datagram | ... |
| Protocol | Protocol | |
|-----------------------------------|
| Internet Protocol |
| (IP) |
|-----------------------------------|
| Virtual Local Network |
| (VLN) |
|-----------------------------------|
| Physical Local Network |
| (PLN, e.g. Ethernet) |
-----------------------------------

Figure 1 . Cronus Protocol

The VLN is completely compatible with the Internet

as defined in [5], i.e., no changes or extensions to IP

5

DOS-26 Rev A Virtual Local
RFC 824

required to implement IP above the VLN. In fact, this was

requirement on the VLN design; a consequence was the

completion of the VLN design and avoidance of the lengthy

which often accompany attempts to change or extend a widely

accepted standard

The following sections define the VLN client interface

illustrate how the VLN implementation might be organized for

Ethernet PLN

2 The VLN-to-Client

The VLN layer provides a datagram transport service

hosts in a Cronus 'cluster', and between these hosts and

hosts in the DARPA internet. The hosts belonging to a

are directly attached to the same physical local network, but

VLN hides the peculiarities of the PLN from other

software. Communication with hosts outside the cluster

achieved through some number of 'internet gateways', shown

Figure 2, connected to the cluster. The VLN layer is

6

DOS-26 Rev A Virtual Local
RFC 824

for routing datagrams to a gateway if they are addressed to

outside the cluster, and for delivering incoming datagrams to

appropriate VLN host. A VLN is viewed as a network in

internet, and thus has an internet network number. (2)

_______________
(2) The PLN could possess its own network number, different
the network number of the VLN it implements, or the
numbers could be the same. Different numbers would
the gateways somewhat, but are consistent with the VLN
internet models

7

DOS-26 Rev A Virtual Local
RFC 824

to
network
|
|
----- ----- ----- -----
|host1| |gtwyA| |host2| |host3|
----- ----- ----- -----
| | | |
--------------------------------------------------
| | | |
----- ----- ----- -----
|host4| |host5| |gtwyB| |host6|
----- ----- ----- -----
|
|
to
network

Figure 2 . A Virtual Local Network

The VLN interface will have one client process on each host

normally the host's IP implementation. The one "client process

may, in fact, be composed of several host processes; but the

layer will not distinguish among them, i.e., it performs

multiplexing/demultiplexing function. (3)
_______________
(3) In the Cronus system, multiplexing/demultiplexing of
datagram stream will be performed above the IP level,

8

DOS-26 Rev A Virtual Local
RFC 824

The structure of messages which pass through the

interface between client processes and the VLN implementation

identical to the structure of internet datagrams constructed

accordance with the Internet Protocol. Any representation

internet datagrams is also a satisfactory representation for

datagrams, and in practice this representation will vary

host to host. The VLN definition merely asserts that there

ONE well-defined representation for internet datagrams, and

VLN datagrams, on any host supporting the VLN interface.

argument name "Datagram" in the VLN operation definitions

refers to this well-defined but host-dependent

representation

The VLN guarantees that a datagram of 576 or fewer

(i.e., the Total Length field of its internet header is less

or equal to 576) can be transferred between any two VLN clients

Larger datagrams may be transferred between some client pairs

Clients should generally avoid sending datagrams exceeding 576

octets unless there is clear need to do so, and the sender

certain that all hosts involved can process the
_______________
in conjunction with Cronus object management

9

DOS-26 Rev A Virtual Local
RFC 824

datagrams

The representation of an VLN datagram is unconstrained

the VLN specification, and the VLN implementor has

reasonable alternatives. Perhaps the simplest representation

a contiguous block of memory locations, either passed

reference or copied across the VLN-to-client interface. It

be beneficial to represent a datagram as a linked list instead

however, in order to reduce the number of times datagram text

copied as the datagram passes through the protocol hierarchy

the sending and receiving hosts. When a message is passing

(towards the physical layer) it is successively "wrapped" by

protocol layers. Addition of the "wrapper"--header and

fields--can be done without copying the message text if

header and trailer can be linked into the message representation

In the particular, when an IP implementation is the client of

VLN layer a linked structure is also desirable to

'reassembly' of datagrams (the merger of several 'fragment

datagrams into one larger datagram) inside the IP layer

copying data repeatedly. If properly designed, one linked

structure can speed up both wrapping/unwrapping and

10

DOS-26 Rev A Virtual Local
RFC 824

reassembly in the IP layer

Although the structure of internet and VLN datagrams

identical, the VLN-to-client interface places its

interpretation on internet header fields, and differs from

IP-to-client interface in significant respects

1. The VLN layer utilizes only the Source Address,
Address, Total Length, and Header Checksum fields in
internet datagram; other fields are accurately
from the sending to the receiving client

2. Internet datagram fragmentation and reassembly is
performed in the VLN layer, nor does the VLN
implement any aspect of internet datagram
processing

3. At the VLN interface, a special interpretation is
upon the Destination Address in the internet header,
allows VLN broadcast and multicast addresses to be
in the internet address structure

4. With high probability, duplicate delivery of datagrams
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
the sequence sent by S to R; a stronger sequencing
holds for broadcast and multicast addressing

11

DOS-26 Rev A Virtual Local
RFC 824

2.1 VLN

In the DARPA internet an 'internet address' is defined to

a 32 bit quantity which is partitioned into two fields, a

number and a 'local address'. VLN addresses share this

structure, and are perceived by hosts outside the Cronus

as ordinary internet addresses. A sender outside a

cluster may direct an internet datagram into the cluster

specifying the VLN network number in the network number field

the destination address; senders in the cluster may

messages to internet hosts outside the cluster in a similar way

The VLN in a Cronus cluster, however, attaches special meaning

the local address field of a VLN address, as explained below

Each network in the internet community is assigned

'class', either A, B, or C, and a network number in its class

The partitioning of the 32 bit internet address into

number and local address fields is a function of the class of

network number, as follows

12

DOS-26 Rev A Virtual Local
RFC 824

Width of Width
Network Number Local

Class A 7 bits 24

Class B 14 bits 16

Class C 21 bits 8

Table 1. Internet Address

The bits not included in the network number or local

fields encode the network class, e.g., a 3 bit prefix of 110

designates a class C address (see [4]).

The interpretation of the local address field of an

address is the responsibility of the network designated in

network number field. In the ARPANET (a class A network,

network number 10) the local address refers to a

physical host; this is the most common use of the local

field. VLN addresses, in contrast, may refer to all

(broadcast) or groups of hosts (multicast) in a Cronus cluster

as well as specific hosts inside or outside of the Cluster

Specific, broadcast, and multicast addresses are all encoded

13

DOS-26 Rev A Virtual Local
RFC 824

the VLN local address field. (4)

The meaning of the local address field of a VLN address

defined in the table below

ADDRESS MODES VLN LOCAL ADDRESS

Specific Host 0 to 1,023

Multicast 1,024 to 65,534

Broadcast 65,535

Table 2. VLN Local Address

In order to represent the full range of specific, broadcast,

multicast addresses in the local address field, a VLN

should be either class A or class B. If a VLN is a class

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
_______________
(4) The ability of hosts outside a Cronus cluster to
datagrams with VLN broadcast or multicast destination
into the cluster may be restricted by the cluster gateway(s),
reasons of system security

14

DOS-26 Rev A Virtual Local
RFC 824

B network, the internet local address field is fully utilized

the VLN local address

2.2 VLN

There are seven operations defined at the VLN interface

available to the VLN client on each host. An implementation

the VLN interface has wide lattitude in the presentation of

operations to the client; for example, the operations may or

not return error codes

A VLN implementation may define the operations to

synchronously or asynchronously with respect to the client'

computation. We expect that the ResetVLNInterface, MyVLNAddress

SendVLNDatagram, PurgeMAddresses, AttendMAddress,

IgnoreMAddress operations will usually be synchronous

respect to the client, but ReceiveVLNDatagram will usually

asynchronous, i.e., the client may initiate the operation

continue to compute, and at some later time be notified that

datagram is available. (The alternatives to

15

DOS-26 Rev A Virtual Local
RFC 824

ReceiveVLNDatagram are A) a blocking receive operation; and B)

non-blocking but synchronous receive operation, which returns

failure code immediately if a datagram is not available.

alternative may satisfy particular requirements, but

asynchronous receive subsumes these and is more

useful.) At a minimum, the client must have fully

access to each of the operations; more elaborate mechanisms

be provided at the option of the VLN implementation

VLN

The VLN layer for this host is reset (e.g., for
Ethernet VLN implementation the operation ClearVPMap
performed, and a frame of type "Cronus VLN" and
"Mapping Update" is broadcast; see Section 4.2).
operation does not affect the set of attended
multicast addresses

function MyVLNAddress()

Returns the specific VLN address of this host; this
always be done without communication with any other host

SendVLNDatagram(Datagram

When this operation completes, the VLN layer has
the Datagram and it is either "in transmission"
"delivered", i.e., the transmitting process cannot
that the message has been delivered when

16

DOS-26 Rev A Virtual Local
RFC 824

completes

ReceiveVLNDatagram(Datagram

When this operation completes, Datagram is
representation of a VLN datagram sent by a VLN client
not previously received by the client
ReceiveVLNDatagram

PurgeMAddresses()

When this operation completes, no VLN multicast
are registered with the local VLN component

function AttendMAddress(MAddress

If this operation returns True then MAddress, which
be a VLN multicast address, is registered as an "alias
for this host, and messages addressed to MAddress by
clients will be delivered to the client on this host

IgnoreMAddress(MAddress

When this operation completes, MAddress is not
as a multicast address for the client on this host

Whenever a Cronus host comes up, ResetVLNInterface

PurgeMAddresses are performed implicitly by the VLN layer

it will accept a request from the client or incoming traffic

the PLN. They may also be invoked by the client during

operation. As described in Section 4.2 below, a VLN

may depend upon state information obtained dynamically from

hosts, and there is a possibility that incorrect

17

DOS-26 Rev A Virtual Local
RFC 824

might enter a component's state tables. (This might happen,

example, if the PLN address of a Cronus host were changed but

VLN address preserved--the old VLN-to-PLN address mappings

by other hosts would then be incorrect.) A cautious VLN

could call ResetVLNInterface at periodic intervals (every hour

say) to force the VLN component to reconstitute its

tables

A VLN component will place a limit on the number

multicast addresses to which it will simultaneously "attend";

the client attempts to register more addresses than this

AttendMAddress will return False with no other effect.

actual limit will vary among VLN components, but it will

be between 10 and 100 multicast addresses. Components

implement limits as large as the entire multicast address

(64,511 addresses).

The VLN layer does not guarantee any minimum amount

buffering for datagrams, at either the sending or

host(s). It does guarantee, however, that a

operation invoked by a VLN client will eventually complete;

implies that datagrams may be lost if buffering is

18

DOS-26 Rev A Virtual Local
RFC 824

and receiving clients are too slow. The VLN layer will do

best to discard packets for this reason very infrequently

2.3 Reliability

Guarantees are never absolute--there is always

probability, however remote, that a catastrophe will occur and

promise be broken. Nevertheless, the concept of a guarantee

still valuable, because the improbability of a

failure influences the design and cost of the recovery

needed to overcome it. In this spirit, the word "guarantee"

used here implies only that the alternatives to correct

(i.e., catastrophic failures) are extremely rare events

The VLN does not attempt to guarantee reliable delivery

datagrams, nor does it provide negative acknowlegements

damaged or discarded datagrams. It does guarantee that

datagrams are accurate representations of transmitted datagrams

The VLN also guarantees that datagrams will not "replicate

during transmission, i.e., for each intended receiver, a

19

DOS-26 Rev A Virtual Local
RFC 824

datagram is received once or not at all. (5)

Between two VLN clients S and R in the same cluster,

sequence of datagrams received by R is a subsequence of

sequence sent by S to R, i.e., datagrams are received in order

possibly with omissions

A stronger sequencing property holds for broadcast

multicast transmissions. If receivers R1 and R2 both

broadcast or multicast datagrams D1 and D2, either they

receive D1 before D2, or they both receive D2 before D1.

3 Desirable Characteristics of a Physical Local

While it is conceivable that a VLN could be implemented on

long-haul or virtual-circuit-oriented PLN, these networks

generally ill-suited to the task. The ARPANET, for example,

not support broadcast or multicast addressing modes, nor does
_______________
(5) A protocol operating above the VLN layer (e.g., TCP)
employ a retransmission strategy; the VLN layer does nothing
filter duplicates arising in this way

20

DOS-26 Rev A Virtual Local
RFC 824

provide the VLN sequencing guarantees. If the ARPANET were

base for a VLN implementation, broadcast and multicast would

to be constructed from specific addressing, and a network-

synchronization mechanism would be required to implement

sequencing guarantees. Although the compatibility

substitutability benefits might still be achieved,

implementation would be costly, and performance poor

A good implementation base for a Cronus VLN would be

high-bandwidth local network with all or most of

characteristics

1. The ability to encapsulate a VLN datagram in a single
datagram

2. An efficient broadcast addressing mode

3. Natural resistance to datagram replication
transmission

4. Sequencing guarantees like those of the VLN interface

5. A strong error-detecting code (datagram checksum).

Good candidates include Ethernet, the Flexible Intraconnect,

Pronet, among others

21

DOS-26 Rev A Virtual Local
RFC 824

4 A VLN Implementation Based on

The Ethernet local network specification is the result of

collaborative effort by Digital Equipment Corp., Intel Corp.,

Xerox Corp. The Version 1.0 specification [3] was released

September, 1980. Useful background information on the

internetworking model is supplied in [2].

The Ethernet VLN implementation begins with the assumption

in accordance with the model developed in [2], that the

of specific Ethernet hosts are arbitrary, 48 bit quantities,

under the control of DOS Design/Implementation Project. The

implementation must, therefore, develop a strategy to map

addresses to specific Ethernet addresses

A second important assumption is that the VLN-address-to

Ethernet-address mapping should not be maintained manually

each VLN host. Manual procedures are too cumbersome and error

prone when a local network may consist of hundreds of hosts,

hosts may join and leave the network frequently. A protocol

described below which allows hosts to dynamically construct

mapping, beginning only with knowledge of their own VLN

22

DOS-26 Rev A Virtual Local
RFC 824

Ethernet host addresses

The succeeding sections discuss the VLN implementation

on the Ethernet PLN in detail, as designed for the

prototype currently being assembled by Bolt Beranek and Newman

Inc

4.1 Datagram

An internet datagram is encapsulated in an Ethernet frame

placing the internet datagram in the Ethernet frame data field

and setting the Ethernet type field to "DoD IP".

To guarantee agreement by the sending and receiving

components on the ordering of internet datagram octets within

encapsulating Ethernet frame, the Ethernet octet ordering

required to be consistent with the IP octet ordering

Specifically, if IP(i) and IP(j) are internet datagram octets

iEthernet frame octets

represent IP(i) and IP(j) once encapsulated, then k

23

DOS-26 Rev A Virtual Local
RFC 824

orderings within octets must also be consistent. (6)

4.2 VLN Specific Addressing

Each VLN component maintains a virtual-to-physical

map (the VPMap) which translates a 32 bit specific VLN

address (7) in this cluster to a 48 bit Ethernet address. (8)

The VPMap data structure and the operations on it can

efficiently implemented using standard hashing techniques.

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

controller will respond, determined by Xerox and the

manufacturer (see Section 4.5.2). At host initialization time
_______________
(6) See [1] for a lively discussion of the problems arising
the failure of communicants to agree upon consistent orderings
(7) Since the high-order 22 bits of the address are constant
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
address is always 0, since these are not broadcast or
addresses

24

DOS-26 Rev A Virtual Local
RFC 824

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address (contd.) | Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address (contd.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type ("DoD IP") |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total Length | Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Flags| Fragment Offset | Time to Live | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header Checksum | Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address (contd.) | Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address (contd.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. Data .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame Check Sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Table 3. An Encapsulated Internet

25

DOS-26 Rev A Virtual Local
RFC 824

the local VLN component establishes a second host address,

multicast host address (MHA), constructed from the host's

address. Represented as a sequence of octets in hexadecimal,

MHA has the form

A B C D E

09-00-08-00-hh-

A is the first octet transmitted, and F the last. The two

E and F contain the host local address

E

000000hh
^ ^
MSB

When the VLN client invokes SendVLNDatagram to send

specifically addressed datagram, the local VLN

encapsulates the datagram in an Ethernet frame and transmits

without delay. The Source Address in the Ethernet frame is

EHA of the sending host. The Ethernet Destination Address

formed from the destination VLN address in the datagram, and

either

26

DOS-26 Rev A Virtual Local
RFC 824

- the EHA of the destination host, if the
operation on the VPMap succeeds

- the MHA formed from the host number in the destination
address, as described above

When a VLN component receives an Ethernet frame with

"DoD IP", it decapsulates the internet datagram and delivers

to its client. If the frame was addressed to the EHA of

receiving host, no further action is taken, but if the frame

addressed to the MHA of the receiving host the VLN component

broadcast an update for the VPMaps of the other hosts. This

permit the other hosts to use the EHA of this host for

traffic. The type field of the Ethernet frame containing

update is "Cronus VLN", and the format of the data octets in

frame is

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype ("Mapping Update") | Host VLN Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host VLN Address (contd.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

When a local VLN component receives an Ethernet frame with

27

DOS-26 Rev A Virtual Local
RFC 824

"Cronus VLN" and subtype "Mapping Update", it performs

StoreVPPair operation using the Ethernet Source Address field

the host VLN address sent as frame data

This multicast mechanism could be extended to perform

address mapping functions, for example, to discover the

of a cluster's gateways. Suppose all gateways register the

Multicast Gateway Address (MGA, analogous to MHA) with

Ethernet controllers; the MGA then becomes a "logical name"

the gateway function in a Cronus cluster. If a host needs

send a datagram out of the cluster and doesn't know what

gateway address to use, the host can multicast the datagram

all gateways by sending to MGA. One or more of the gateways

forward the datagram, and transmit a "Gateway Mapping Update

(containing the gateway's specific Ethernet address) back to

originating host. Specific gateway addresses could be cached

a structure similar to the VPMap, keyed to the

network number. (9)

_______________
(9) Because the Cronus Advanced Development Model will
only one gateway, a simpler mechanism will be
initially; the specific Ethernet address of the gateway will
"well-known" to all VLN components

28

DOS-26 Rev A Virtual Local
RFC 824

The approach just outlined suggests that all knowledge

the existence and connectivity of gateways would be isolated

the VLN layer of cluster hosts. Other mechanisms, e.g., based

the ICMP component of the Internet Protocol, could be

instead to disseminate information about gateways to

hosts (see [7]). These would require, however, specific

addresses to be visible above the VLN layer, a situation

current design avoids

4.3 VLN Broadcast and Multicast Addressing

A VLN datagram will be transmitted in broadcast mode if

argument to SendVLNDatagram specifies the VLN broadcast

(local address = 65,535, decimal) as the destination.

is implemented in the most straightforward way: the VLN

is encapsulated in an Ethernet frame with type "DoD IP", and

frame destination address is set to the Ethernet

address. The receiving VLN component merely decapsulates

delivers the VLN datagram

29

DOS-26 Rev A Virtual Local
RFC 824

The implementation of the VLN multicast addressing mode

more complex, for several reasons. Typically, each VLN host

define a constant called Max_Attended, equal to the

number of VLN multicast addresses which can be

"attended" by this host. Max_Attended should not be a

of the particular Ethernet controller(s) the host may be using

but only of the software resources (buffer space and

time) that the host dedicates to VLN multicast processing.

protocol below permits a host to attend any number of

multicast addresses, from 0 to 64,511 (the entire VLN

address space), independent of the controller in use

Understanding of the VLN multicast protocol requires

knowledge of the behavior of existing Ethernet controllers.

Ethernet specification does not specify whether a controller

perform multicast address recognition, or if it does, how

multicast addresses it must be prepared to recognize. As

result Ethernet controller designs vary widely in their behavior

For example, the 3COM Model 3C400 controller follows the

pattern and performs no multicast address recognition,

passing all multicast frames to the host for further processing

30

DOS-26 Rev A Virtual Local
RFC 824

The Intel Model iSBC 550 controller permits the host to

a maximum of 8 multicast addresses with the controller, and

Interlan Model NM10 controller permits a maximum of 63

addresses

It would be possible to implement the VLN multicast

using only the Ethernet broadcast mechanism. This would imply

however, that every VLN host would receive and process every

multicast, often only to discard the datagram because it

misaddressed. More efficient operation is possible if at

some Ethernet multicast addresses are used, since

controllers with multicast recognition can discard

frames more rapidly than their hosts, reducing both the

time and buffer space demands upon the host

The protocol specified below satisfies the

constraints and is especially simple

A VLN-wide constant, Min_Attendable, is equal to

smallest number of Ethernet multicast addresses that can

simultaneously attended by any host in the VLN, or 64,511,

whichever is smaller. A network composed of hosts with the

31

DOS-26 Rev A Virtual Local
RFC 824

and Interlan controllers mentioned above, for example, would

Min_Attendable equal to 7; (10) a network composed only of

with 3COM Model 3C400 controllers would have Min_Attendable

to 64,511, since the controller itself does not restrict

number of Ethernet multicast addresses to which a host

attend. (11)

The local address field of a VLN multicast address can

represented in two octets, in hexadecimal

mm-

From Table 1, mm-mm considered as a decimal integer M is in

range 1,024 to 65,534. When SendVLNDatagram is invoked with

VLN multicast datagram, there are two cases

1. (M - 1,023) <= Min_Attendable. In this case, the
is encapsulated in a "DoD IP" Ethernet frame, and
with the Ethernet

09-00-08-00-mm-

A VLN component which attends VLN multicast addresses
_______________
(10) Min_Attendable is 7, rather than 8, because one
slot in the controller must be reserved for the host's MHA,
described in Section 4.2.
(11) For the Cronus Advanced Development Model, Min_Attendable
currently defined to be 60.

32

DOS-26 Rev A Virtual Local
RFC 824

this range should receive Ethernet multicast addresses
this format, if necessary by registering the addresses
its Ethernet controller

2. (M - 1,023) > Min_Attendable. The datagram is
in a "DoD IP" Ethernet frame, and transmitted to
Ethernet broadcast address. A VLN component which
VLN multicast addresses in this range must receive
broadcast frames, and filter them on the basis of
type and VLN destination address (found in the
destination address field).

There are two drawbacks to this protocol that might induce

more complex design: 1) because Min_Attendable is the "

common denominator" for the ability of Ethernet controllers

recognize multicast addresses, some controller capabilities

be wasted; 2) small VLN addresses (less than Max_Attendable +

1,024) will probably be handled more efficiently than large

multicast addresses. The second factor complicates

assignment of VLN multicast addresses to functions, since

particular assignment affects multicast performance

33

DOS-26 Rev A Virtual Local
RFC 824

4.4 Reliability

Delivered datagrams are accurate copies of

datagrams because VLN components do not deliver

datagrams with invalid Frame Check Sequences. The 32 bit

error detecting code applied to Ethernet frames is very powerful

and the probability of an undetected error occuring "on the wire

is very small. The probability of an error being

before the checksum is computed or after it is checked

comparable to the probability of an error in a disk

before a write operation or after a read; often, but not always

it can be ignored

Datagram duplication does not occur because the VLN

does not perform datagram retransmissions, the primary source

duplicates in other networks. Ethernet controllers do

retransmission as a result of "collisions" on the channel,

the "collision enforcement" or "jam" assures that no

receives a valid frame if a collision occurs

The sequencing guarantees hold because mutually

access to the transmission medium defines a total ordering

34

DOS-26 Rev A Virtual Local
RFC 824

Ethernet transmissions, and because a VLN component buffers

datagrams in FIFO order, if it buffers more than one datagram

4.5 Use of Assigned

On a philosophical note, protocols such as IP and TCP

to provide communication services to extensible sets of clients

new clients and usages continue to emerge over the life of

protocol. Because a protocol implementation must have

unambiguous knowledge of the "names" of the clients, sockets

hosts, networks, etc., with which it interacts, a need arises

the continuing administration of the 'assigned numbers'

to the protocol. Typically the organization which declares

protocol to be a standard also becomes the administrator for

assigned numbers. The organization will designate an office

assign numbers to the clients, sockets, hosts, networks, etc.,

that emerge over time. The office will also prepare lists

number assignments that are distributed to protocol users;

reference [4] is a list of this kind

35

DOS-26 Rev A Virtual Local
RFC 824

There are three organizations responsible for

assignment related to the Ethernet-based VLN implementation

DARPA, Xerox, and the DOS Design/Implementation Project;

respective roles are described below

4.5.1

DARPA administers the internet network number and

protocol number assignments. The Ethernet-based

implementation does not involve DARPA assigned numbers, but

particular 'instance' of a Cronus VLN is expected to have a

A or B internet network number assigned by DARPA. For example

the prototype Cronus system (the Advanced Development Model

being constructed at Bolt Beranek and Newman, Inc., has class

network number 128.011.xxx.xxx

Protocols built above the VLN will make use of other

assigned numbers, e.g., the Cronus object-operation

requires an internet protocol number

36

DOS-26 Rev A Virtual Local
RFC 824

4.5.2 The Xerox Ethernet Address Administration

The Ethernet Address Administration Office at Xerox Corp

administers Ethernet specific and multicast address assignments

and Ethernet frame type assignments

It is the intent of the Xerox internetworking model

every Ethernet host have a distinct specific address, and

the address space be large enough to accomodate a very

population of inexpensive hosts (e.g., personal workstations).

They have therefore chosen to delegate the authority to

specific addresses to the manufacturers of Ethernet controllers

by granting them large blocks of addresses on request

Manufacturers are expected to assign specific addresses

these blocks densely, e.g., sequentially, one per controller,

to consume all of them before requesting another block

The preceding paragraph explains the Xerox

assignment policy not because the DOS Design/

Project intends to manufacture Ethernet controllers (!),

because Xerox has chosen to couple the assignment of specific

multicast Ethernet addresses. An assigned block is defined by

37

DOS-26 Rev A Virtual Local
RFC 824

23-bit constant, which specifies the contents of the first

octets of an Ethernet address, except for the broadcast/

bit (the least significant bit of the first octet).

possessor of an assigned block thus has in hand 2**24

addresses and 2**24 multicast addresses, to parcel out

necessary

The block assigned for use in the Cronus system is

by the octets 08-00-08 (hex). The specific addresses in

block range from 08-00-08-00-00-00 to 08-00-08-FF-FF-FF (hex),

and the multicast addresses range from 09-00-08-00-00-00 to 09-

00-08-FF-FF-FF (hex). Only a fraction of the multicast

are actually utilized, as explained in Sections 4.2 and 4.3.

The Ethernet Address Administration Office has designated

public frame type, "DoD IP", 08-00 (hex), to be used

encapsulated internet protocol datagrams. The Ethernet

implementation uses this frame type exclusively for

encapsulation. In addition, the Cronus system uses two

Ethernet frame types, assigned by the Ethernet

Administration Office

38

DOS-26 Rev A Virtual Local
RFC 824

NAME

Cronus VLN 80-03
Cronus Direct 80-04

(The use of the "Cronus Direct" frame type is not described

this note.)

The same Ethernet address and frame type assignments will

used by every instance of a Cronus VLN; no further

from the Ethernet Address Administration Office are anticipated

4.5.3 The DOS Design/Implementation

The DOS Design/Implementation Project assumes

for the assignment of subtypes of the Ethernet frame type "

VLN". No assignments of subtypes for purposes unrelated to

Cronus system design are expected, nor are assignments to

organizations. The subtypes currently assigned are

39

DOS-26 Rev A Virtual Local
RFC 824

NAME

Mapping Update 00-01

40

DOS-26 Rev A Virtual Local
RFC 824

[1]
"On holy wars and a plea for peace," Danny Cohen, Computer
V 14 N 10, October 1981, pp. 48-54.

[2]
"48-bit absolute internet and Ethernet host numbers,"
K. Dalal and Robert S. Printis, Proc. of the 7th
Communications Symposium, October 1981.

[3]
"The Ethernet: a local area network, data link layer
physical layer specifications," Digital Equipment Corp.,
Corp., and Xerox Corp., Version 1.0, September 1980.

[4]
"Assigned numbers," Jon Postel, RFC 790, USC/
Sciences Institute, September 1981.

[5]
"Internet Protocol - DARPA internet program
specification," Jon Postel, ed., RFC 791, USC/
Sciences Institute, September 1981.

[6]
"Internet protocol transition workbook," Network
Center, SRI International, Menlo Park, California, March 1982.

[7]
"IP - Local Area Network Addressing Issues," Robert
and Robert Hinden, Bolt Beranek and Newman Inc., (draft
August 1982.

41

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX