📄 rfc824.txt
字号:
DOS-26 Rev A Virtual Local Network
RFC 824
THE CRONUS VIRTUAL LOCAL NETWORK
William I. MacGregor
Daniel C. Tappan
Bolt Beranek and Newman Inc.
25 August 1982
[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.]
1 Purpose and Scope
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
interface specification.
_______________
(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.
1
DOS-26 Rev A Virtual Local Network
RFC 824
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
objectives:
* 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 [6] is a
compilation of the important protocol specifications and other
documents. Documents in [6] of special significance here are [5]
and [4].)
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
2
DOS-26 Rev A Virtual Local Network
RFC 824
permits the Cronus design to assimilate existing software
components providing electronic mail, remote terminal access, and
file transfer in a straightforward manner. In addition to the
roles of such services in the Cronus system, they are needed as
support for the design and development process. The prototype
Cronus cluster, called the Advanced Development Model (ADM), will
be connected to the ARPANET, and it is important that the ADM
conform to the standards and conventions of the DARPA internet
community.
The substitutability goal reflects the belief that different
instances of the Cronus cluster will utilize different physical
local networks. Substitution may be desirable for reasons of
cost, performance, or other properties of the physical local
network such as mechanical and electrical ruggedness. The
existence of the VLN interface definition suggests a procedure
for physical local network substitution, namely, re-
implementation of the VLN interface on each Cronus host. The
implementations will be functionally equivalent but can be
expected to differ along dimensions not specified by the VLN
interface definition. Since different physical local networks
3
DOS-26 Rev A Virtual Local Network
RFC 824
are often quite similar, the task of "re-implementing" the VLN is
probably much less difficult than building the first
implementation; small modifications to an existing, exemplary
implementation may suffice.
The concepts of the Cronus VLN, and in particular the VLN
implementation based on Ethernet described in Section 4, have
significance beyond their application in the Cronus system. Many
organizations are now beginning to install local networks and
immediately confront the compatibility issue. For a number of
universities, for example, the compatibility problem is precisely
the interoperability of the Ethernet and the DARPA internet.
Although perhaps less immediate, the substitutability issue will
also be faced by other organizations as local network technology
advances, and the transfer of existing system and application
software to a new physical local network base becomes an economic
necessity.
Figure 1 shows the position of the VLN in the lowest layers
of the Cronus protocol hierarchy. The VLN interface
specification given in the next section is actually a meta-
specification, like the specifications of IP and TCP, in that the
4
DOS-26 Rev A Virtual Local Network
RFC 824
programming details of the interface are host-dependent and
unspecified. The precise representation of the VLN data
structures and operations can be expected to vary from machine to
machine, but the functional capabilities of the interface are the
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 Layering
The VLN is completely compatible with the Internet Protocol
as defined in [5], i.e., no changes or extensions to IP are
5
DOS-26 Rev A Virtual Local Network
RFC 824
required to implement IP above the VLN. In fact, this was a
requirement on the VLN design; a consequence was the timely
completion of the VLN design and avoidance of the lengthy delays
which often accompany attempts to change or extend a widely-
accepted standard.
The following sections define the VLN client interface and
illustrate how the VLN implementation might be organized for an
Ethernet PLN.
2 The VLN-to-Client Interface
The VLN layer provides a datagram transport service among
hosts in a Cronus 'cluster', and between these hosts and other
hosts in the DARPA internet. The hosts belonging to a cluster
are directly attached to the same physical local network, but the
VLN hides the peculiarities of the PLN from other Cronus
software. Communication with hosts outside the cluster is
achieved through some number of 'internet gateways', shown in
Figure 2, connected to the cluster. The VLN layer is responsible
6
DOS-26 Rev A Virtual Local Network
RFC 824
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.
7
DOS-26 Rev A Virtual Local Network
RFC 824
to internet
network X
|
|
----- ----- ----- -----
|host1| |gtwyA| |host2| |host3|
----- ----- ----- -----
| | | |
--------------------------------------------------
| | | |
----- ----- ----- -----
|host4| |host5| |gtwyB| |host6|
----- ----- ----- -----
|
|
to internet
network Y
Figure 2 . A Virtual Local Network Cluster
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 VLN
layer will not distinguish among them, i.e., it performs no
multiplexing/demultiplexing function. (3)
_______________
(3) In the Cronus system, multiplexing/demultiplexing of the
datagram stream will be performed above the IP level, primarily
8
DOS-26 Rev A Virtual Local Network
RFC 824
The structure of messages which pass through the VLN
interface between client processes and the VLN implementation is
identical to the structure of internet datagrams constructed in
accordance with the Internet Protocol. Any representation for
internet datagrams is also a satisfactory representation for VLN
datagrams, and in practice this representation will vary from
host to host. The VLN definition merely asserts that there is
ONE well-defined representation for internet datagrams, and thus
VLN datagrams, on any host supporting the VLN interface. The
argument name "Datagram" in the VLN operation definitions below
refers to this well-defined but host-dependent datagram
representation.
The VLN guarantees that a datagram of 576 or fewer octets
(i.e., the Total Length field of its internet header is less than
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 is
certain that all hosts involved can process the outsize
_______________
in conjunction with Cronus object management.
9
DOS-26 Rev A Virtual Local Network
RFC 824
datagrams.
The representation of an VLN datagram is unconstrained by
the VLN specification, and the VLN implementor has many
reasonable alternatives. Perhaps the simplest representation is
a contiguous block of memory locations, either passed by
reference or copied across the VLN-to-client interface. It may
be beneficial to represent a datagram as a linked list instead,
however, in order to reduce the number of times datagram text is
copied as the datagram passes through the protocol hierarchy at
the sending and receiving hosts. When a message is passing down
(towards the physical layer) it is successively "wrapped" by the
protocol layers. Addition of the "wrapper"--header and trailer
fields--can be done without copying the message text if the
header and trailer can be linked into the message representation.
In the particular, when an IP implementation is the client of the
VLN layer a linked structure is also desirable to permit
'reassembly' of datagrams (the merger of several 'fragment'
datagrams into one larger datagram) inside the IP layer without
copying data repeatedly. If properly designed, one linked list
structure can speed up both wrapping/unwrapping and datagram
10
DOS-26 Rev A Virtual Local Network
RFC 824
reassembly in the IP layer.
Although the structure of internet and VLN datagrams is
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -