📄 rfc824.txt
字号:
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.
11
DOS-26 Rev A Virtual Local Network
RFC 824
2.1 VLN Addressing
In the DARPA internet an 'internet address' is defined to be
a 32 bit quantity which is partitioned into two fields, a network
number and a 'local address'. VLN addresses share this basic
structure, and are perceived by hosts outside the Cronus system
as ordinary internet addresses. A sender outside a Cronus
cluster may direct an internet datagram into the cluster by
specifying the VLN network number in the network number field of
the destination address; senders in the cluster may transmit
messages to internet hosts outside the cluster in a similar way.
The VLN in a Cronus cluster, however, attaches special meaning to
the local address field of a VLN address, as explained below.
Each network in the internet community is assigned a
'class', either A, B, or C, and a network number in its class.
The partitioning of the 32 bit internet address into network
number and local address fields is a function of the class of the
network number, as follows:
12
DOS-26 Rev A Virtual Local Network
RFC 824
Width of Width of
Network Number Local Address
Class A 7 bits 24 bits
Class B 14 bits 16 bits
Class C 21 bits 8 bits
Table 1. Internet Address Formats
The bits not included in the network number or local address
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 internet
address is the responsibility of the network designated in the
network number field. In the ARPANET (a class A network, with
network number 10) the local address refers to a specific
physical host; this is the most common use of the local address
field. VLN addresses, in contrast, may refer to all hosts
(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 in
13
DOS-26 Rev A Virtual Local Network
RFC 824
the VLN local address field. (4)
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
Broadcast 65,535
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.
14
DOS-26 Rev A Virtual Local Network
RFC 824
B network, the internet local address field is fully utilized by
the VLN local address.
2.2 VLN Operations
There are seven operations defined at the VLN interface and
available to the VLN client on each host. An implementation of
the VLN interface has wide lattitude in the presentation of these
operations to the client; for example, the operations may or may
not return error codes.
A VLN implementation may define the operations to occur
synchronously or asynchronously with respect to the client's
computation. We expect that the ResetVLNInterface, MyVLNAddress,
SendVLNDatagram, PurgeMAddresses, AttendMAddress, and
IgnoreMAddress operations will usually be synchronous with
respect to the client, but ReceiveVLNDatagram will usually be
asynchronous, i.e., the client may initiate the operation,
continue to compute, and at some later time be notified that a
datagram is available. (The alternatives to asynchronous
15
DOS-26 Rev A Virtual Local Network
RFC 824
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.
VLN OPERATIONS
ResetVLNInterface
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.
function MyVLNAddress()
Returns the specific VLN address of this host; this can
always be done without communication with any other host.
SendVLNDatagram(Datagram)
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
16
DOS-26 Rev A Virtual Local Network
RFC 824
completes.
ReceiveVLNDatagram(Datagram)
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.
PurgeMAddresses()
When this operation completes, no VLN multicast addresses
are registered with the local VLN component.
function AttendMAddress(MAddress)
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.
IgnoreMAddress(MAddress)
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
17
DOS-26 Rev A Virtual Local Network
RFC 824
might enter a component's state tables. (This might happen, for
example, if the PLN address of a Cronus host were changed but its
VLN address preserved--the old VLN-to-PLN address mappings held
by other hosts would then be incorrect.) A cautious VLN client
could call ResetVLNInterface at periodic intervals (every hour,
say) to force the VLN component to reconstitute its dynamic
tables.
A VLN component will place a limit on the number of
multicast addresses to which it will simultaneously "attend"; if
the client attempts to register more addresses than this,
AttendMAddress will return False with no other effect. The
actual limit will vary among VLN components, but it will usually
be between 10 and 100 multicast addresses. Components may
implement limits as large as the entire multicast address space
(64,511 addresses).
The VLN layer does not guarantee any minimum amount of
buffering for datagrams, at either the sending or receiving
host(s). It does guarantee, however, that a SendVLNDatagram
operation invoked by a VLN client will eventually complete; this
implies that datagrams may be lost if buffering is insufficient
18
DOS-26 Rev A Virtual Local Network
RFC 824
and receiving clients are too slow. The VLN layer will do its
best to discard packets for this reason very infrequently.
2.3 Reliability Guarantees
Guarantees are never absolute--there is always some
probability, however remote, that a catastrophe will occur and a
promise be broken. Nevertheless, the concept of a guarantee is
still valuable, because the improbability of a catastrophic
failure influences the design and cost of the recovery mechanisms
needed to overcome it. In this spirit, the word "guarantee" as
used here implies only that the alternatives to correct function
(i.e., catastrophic failures) are extremely rare events.
The VLN does not attempt to guarantee reliable delivery of
datagrams, nor does it provide negative acknowlegements of
damaged or discarded datagrams. It does guarantee that received
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 given
19
DOS-26 Rev A Virtual Local Network
RFC 824
datagram is received once or not at all. (5)
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.
20
DOS-26 Rev A Virtual Local Network
RFC 824
provide the VLN sequencing guarantees. If the ARPANET were the
base for a VLN implementation, broadcast and multicast would have
to be constructed from specific addressing, and a network-wide
synchronization mechanism would be required to implement the
sequencing guarantees. Although the compatibility and
substitutability benefits might still be achieved, the
implementation would be costly, and performance poor.
A good implementation base for a Cronus VLN would be a
high-bandwidth local network with all or most of these
characteristics:
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -