📄 rfc824.txt
字号:
1. The ability to encapsulate a VLN datagram in a single PLN
datagram.
2. An efficient broadcast addressing mode.
3. Natural resistance to datagram replication during
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, and
Pronet, among others.
21
DOS-26 Rev A Virtual Local Network
RFC 824
4 A VLN Implementation Based on Ethernet
The Ethernet local network specification is the result of a
collaborative effort by Digital Equipment Corp., Intel Corp., and
Xerox Corp. The Version 1.0 specification [3] was released in
September, 1980. Useful background information on the Ethernet
internetworking model is supplied in [2].
The Ethernet VLN implementation begins with the assumption,
in accordance with the model developed in [2], that the addresses
of specific Ethernet hosts are arbitrary, 48 bit quantities, not
under the control of DOS Design/Implementation Project. The VLN
implementation must, therefore, develop a strategy to map VLN
addresses to specific Ethernet addresses.
A second important assumption is that the VLN-address-to-
Ethernet-address mapping should not be maintained manually in
each VLN host. Manual procedures are too cumbersome and error-
prone when a local network may consist of hundreds of hosts, and
hosts may join and leave the network frequently. A protocol is
described below which allows hosts to dynamically construct the
mapping, beginning only with knowledge of their own VLN and
22
DOS-26 Rev A Virtual Local Network
RFC 824
Ethernet host addresses.
The succeeding sections discuss the VLN implementation based
on the Ethernet PLN in detail, as designed for the Cronus
prototype currently being assembled by Bolt Beranek and Newman,
Inc.
4.1 Datagram Encapsulation
An internet datagram is encapsulated in an Ethernet frame by
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 VLN
components on the ordering of internet datagram octets within an
encapsulating Ethernet frame, the Ethernet octet ordering is
required to be consistent with the IP octet ordering.
Specifically, if IP(i) and IP(j) are internet datagram octets and
i<j, and EF(k) and EF(l) are the Ethernet frame octets which
represent IP(i) and IP(j) once encapsulated, then k<l. Bit
23
DOS-26 Rev A Virtual Local Network
RFC 824
orderings within octets must also be consistent. (6)
4.2 VLN Specific Addressing Mode
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 [1] 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.
24
DOS-26 Rev A Virtual Local Network
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 Datagram
25
DOS-26 Rev A Virtual Local Network
RFC 824
the local VLN component establishes a second host address, the
multicast host address (MHA), constructed from the host's VLN
address. Represented as a sequence of octets in hexadecimal, the
MHA has the form:
A B C D E F
09-00-08-00-hh-hh
A is the first octet transmitted, and F the last. The two octets
E and F contain the host local address:
E F
000000hh hhhhhhhh
^ ^
MSB LSB
When the VLN client invokes SendVLNDatagram to send a
specifically addressed datagram, the local VLN component
encapsulates the datagram in an Ethernet frame and transmits it
without delay. The Source Address in the Ethernet frame is the
EHA of the sending host. The Ethernet Destination Address is
formed from the destination VLN address in the datagram, and is
either:
26
DOS-26 Rev A Virtual Local Network
RFC 824
- the EHA of the destination host, if the TranslateVtoP
operation on the VPMap succeeds,
or
- the MHA formed from the host number in the destination VLN
address, as described above.
When a VLN component receives an Ethernet frame with type
"DoD IP", it decapsulates the internet datagram and delivers it
to its client. If the frame was addressed to the EHA of the
receiving host, no further action is taken, but if the frame was
addressed to the MHA of the receiving host the VLN component will
broadcast an update for the VPMaps of the other hosts. This will
permit the other hosts to use the EHA of this host for future
traffic. The type field of the Ethernet frame containing the
update is "Cronus VLN", and the format of the data octets in the
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 type
27
DOS-26 Rev A Virtual Local Network
RFC 824
"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.
28
DOS-26 Rev A Virtual Local Network
RFC 824
The approach just outlined suggests that all knowledge of
the existence and connectivity of gateways would be isolated in
the VLN layer of cluster hosts. Other mechanisms, e.g., based on
the ICMP component of the Internet Protocol, could be used
instead to disseminate information about gateways to cluster
hosts (see [7]). These would require, however, specific Ethernet
addresses to be visible above the VLN layer, a situation the
current design avoids.
4.3 VLN Broadcast and Multicast Addressing Modes
A VLN datagram will be transmitted in broadcast mode if the
argument to SendVLNDatagram specifies the VLN broadcast address
(local address = 65,535, decimal) as the destination. Broadcast
is implemented in the most straightforward way: the VLN datagram
is encapsulated in an Ethernet frame with type "DoD IP", and the
frame destination address is set to the Ethernet broadcast
address. The receiving VLN component merely decapsulates and
delivers the VLN datagram.
29
DOS-26 Rev A Virtual Local Network
RFC 824
The implementation of the VLN multicast addressing mode is
more complex, for several reasons. Typically, each VLN host will
define a constant called Max_Attended, equal to the maximum
number of VLN multicast addresses which can be simultaneously
"attended" by this host. Max_Attended should not be a function
of the particular Ethernet controller(s) the host may be using,
but only of the software resources (buffer space and processor
time) that the host dedicates to VLN multicast processing. The
protocol below permits a host to attend any number of VLN
multicast addresses, from 0 to 64,511 (the entire VLN multicast
address space), independent of the controller in use.
Understanding of the VLN multicast protocol requires some
knowledge of the behavior of existing Ethernet controllers. The
Ethernet specification does not specify whether a controller must
perform multicast address recognition, or if it does, how many
multicast addresses it must be prepared to recognize. As a
result Ethernet controller designs vary widely in their behavior.
For example, the 3COM Model 3C400 controller follows the first
pattern and performs no multicast address recognition, instead
passing all multicast frames to the host for further processing.
30
DOS-26 Rev A Virtual Local Network
RFC 824
The Intel Model iSBC 550 controller permits the host to register
a maximum of 8 multicast addresses with the controller, and the
Interlan Model NM10 controller permits a maximum of 63 registered
addresses.
It would be possible to implement the VLN multicast mode
using only the Ethernet broadcast mechanism. This would imply,
however, that every VLN host would receive and process every VLN
multicast, often only to discard the datagram because it is
misaddressed. More efficient operation is possible if at least
some Ethernet multicast addresses are used, since Ethernet
controllers with multicast recognition can discard misaddressed
frames more rapidly than their hosts, reducing both the processor
time and buffer space demands upon the host.
The protocol specified below satisfies the design
constraints and is especially simple.
A VLN-wide constant, Min_Attendable, is equal to the
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -