summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc824.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc824.txt')
-rw-r--r--doc/rfc/rfc824.txt2379
1 files changed, 2379 insertions, 0 deletions
diff --git a/doc/rfc/rfc824.txt b/doc/rfc/rfc824.txt
new file mode 100644
index 0000000..2aad68c
--- /dev/null
+++ b/doc/rfc/rfc824.txt
@@ -0,0 +1,2379 @@
+
+ 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
+
+ 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:
+
+ 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
+
+ smallest number of Ethernet multicast addresses that can be
+
+ simultaneously attended by any host in the VLN, or 64,511,
+
+ whichever is smaller. A network composed of hosts with the Intel
+
+
+
+
+ 31
+
+
+
+
+
+
+
+
+ DOS-26 Rev A Virtual Local Network
+ RFC 824
+
+
+
+ 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
+
+ attend. (11)
+
+
+ The local address field of a VLN multicast address can be
+
+ represented in two octets, in hexadecimal:
+
+
+ mm-mm
+
+
+ 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
+
+ 09-00-08-00-mm-mm
+
+ 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.
+
+
+
+
+ 32
+
+
+
+
+
+
+
+
+ DOS-26 Rev A Virtual Local Network
+ RFC 824
+
+
+
+ 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
+
+ particular assignment affects multicast performance.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 33
+
+
+
+
+
+
+
+
+ DOS-26 Rev A Virtual Local Network
+ RFC 824
+
+
+
+ 4.4 Reliability Guarantees
+
+
+ Delivered datagrams are accurate copies of transmitted
+
+ datagrams because VLN components do not deliver incoming
+
+ datagrams with invalid Frame Check Sequences. The 32 bit CRC
+
+ 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 introduced
+
+ before the checksum is computed or after it is checked is
+
+ comparable to the probability of an error in a disk subsystem
+
+ before a write operation or after a read; often, but not always,
+
+ it can be ignored.
+
+
+ Datagram duplication does not occur because the VLN layer
+
+ does not perform datagram retransmissions, the primary source of
+
+ duplicates in other networks. Ethernet controllers do perform
+
+ retransmission as a result of "collisions" on the channel, but
+
+ the "collision enforcement" or "jam" assures that no controller
+
+ receives a valid frame if a collision occurs.
+
+
+ The sequencing guarantees hold because mutually exclusive
+
+ access to the transmission medium defines a total ordering on
+
+
+
+
+ 34
+
+
+
+
+
+
+
+
+ DOS-26 Rev A Virtual Local Network
+ RFC 824
+
+
+
+ Ethernet transmissions, and because a VLN component buffers all
+
+ datagrams in FIFO order, if it buffers more than one datagram.
+
+
+
+
+
+
+ 4.5 Use of Assigned Numbers
+
+
+ On a philosophical note, protocols such as IP and TCP exist
+
+ to provide communication services to extensible sets of clients;
+
+ new clients and usages continue to emerge over the life of a
+
+ protocol. Because a protocol implementation must have some
+
+ unambiguous knowledge of the "names" of the clients, sockets,
+
+ hosts, networks, etc., with which it interacts, a need arises for
+
+ the continuing administration of the 'assigned numbers' related
+
+ to the protocol. Typically the organization which declares a
+
+ protocol to be a standard also becomes the administrator for its
+
+ assigned numbers. The organization will designate an office to
+
+ assign numbers to the clients, sockets, hosts, networks, etc.,
+
+ that emerge over time. The office will also prepare lists of
+
+ number assignments that are distributed to protocol users; the
+
+ reference [4] is a list of this kind.
+
+
+
+
+
+ 35
+
+
+
+
+
+
+
+
+ DOS-26 Rev A Virtual Local Network
+ RFC 824
+
+
+
+ There are three organizations responsible for number
+
+ assignment related to the Ethernet-based VLN implementation:
+
+ DARPA, Xerox, and the DOS Design/Implementation Project; their
+
+ respective roles are described below.
+
+
+
+
+
+ 4.5.1 DARPA
+
+
+ DARPA administers the internet network number and internet
+
+ protocol number assignments. The Ethernet-based VLN
+
+ implementation does not involve DARPA assigned numbers, but any
+
+ particular 'instance' of a Cronus VLN is expected to have a class
+
+ 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 B
+
+ network number 128.011.xxx.xxx.
+
+
+ Protocols built above the VLN will make use of other DARPA
+
+ assigned numbers, e.g., the Cronus object-operation protocol
+
+ requires an internet protocol number.
+
+
+
+
+
+
+
+ 36
+
+
+
+
+
+
+
+
+ DOS-26 Rev A Virtual Local Network
+ RFC 824
+
+
+
+ 4.5.2 The Xerox Ethernet Address Administration Office
+
+
+ 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 that
+
+ every Ethernet host have a distinct specific address, and that
+
+ the address space be large enough to accomodate a very large
+
+ population of inexpensive hosts (e.g., personal workstations).
+
+ They have therefore chosen to delegate the authority to assign
+
+ specific addresses to the manufacturers of Ethernet controllers,
+
+ by granting them large blocks of addresses on request.
+
+ Manufacturers are expected to assign specific addresses from
+
+ these blocks densely, e.g., sequentially, one per controller, and
+
+ to consume all of them before requesting another block.
+
+
+ The preceding paragraph explains the Xerox address
+
+ assignment policy not because the DOS Design/Implementation
+
+ Project intends to manufacture Ethernet controllers (!), but
+
+ because Xerox has chosen to couple the assignment of specific and
+
+ multicast Ethernet addresses. An assigned block is defined by a
+
+
+
+
+ 37
+
+
+
+
+
+
+
+
+ DOS-26 Rev A Virtual Local Network
+ RFC 824
+
+
+
+ 23-bit constant, which specifies the contents of the first three
+
+ octets of an Ethernet address, except for the broadcast/multicast
+
+ bit (the least significant bit of the first octet). The
+
+ possessor of an assigned block thus has in hand 2**24 specific
+
+ addresses and 2**24 multicast addresses, to parcel out as
+
+ necessary.
+
+
+ The block assigned for use in the Cronus system is defined
+
+ by the octets 08-00-08 (hex). The specific addresses in this
+
+ 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 addresses
+
+ are actually utilized, as explained in Sections 4.2 and 4.3.
+
+
+ The Ethernet Address Administration Office has designated a
+
+ public frame type, "DoD IP", 08-00 (hex), to be used for
+
+ encapsulated internet protocol datagrams. The Ethernet VLN
+
+ implementation uses this frame type exclusively for datagram
+
+ encapsulation. In addition, the Cronus system uses two private
+
+ Ethernet frame types, assigned by the Ethernet Address
+
+ Administration Office:
+
+
+
+
+
+ 38
+
+
+
+
+
+
+
+
+ DOS-26 Rev A Virtual Local Network
+ RFC 824
+
+
+
+
+
+ NAME TYPE
+
+ Cronus VLN 80-03
+ Cronus Direct 80-04
+
+ (The use of the "Cronus Direct" frame type is not described in
+
+ this note.)
+
+
+ The same Ethernet address and frame type assignments will be
+
+ used by every instance of a Cronus VLN; no further assignments
+
+ from the Ethernet Address Administration Office are anticipated.
+
+
+
+
+
+
+ 4.5.3 The DOS Design/Implementation Project
+
+
+ The DOS Design/Implementation Project assumes responsibility
+
+ for the assignment of subtypes of the Ethernet frame type "Cronus
+
+ VLN". No assignments of subtypes for purposes unrelated to the
+
+ Cronus system design are expected, nor are assignments to other
+
+ organizations. The subtypes currently assigned are:
+
+
+
+
+
+
+
+
+
+ 39
+
+
+
+
+
+
+
+
+ DOS-26 Rev A Virtual Local Network
+ RFC 824
+
+
+
+
+
+ NAME SUBTYPE
+
+ Mapping Update 00-01
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 40
+
+
+
+
+
+
+
+
+ DOS-26 Rev A Virtual Local Network
+ RFC 824
+
+
+
+ REFERENCES
+
+
+ [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," Yogen
+ K. Dalal and Robert S. Printis, Proc. of the 7th Data
+ Communications Symposium, October 1981.
+
+ [3]
+ "The Ethernet: a local area network, data link layer and
+ physical layer specifications," Digital Equipment Corp., Intel
+ Corp., and Xerox Corp., Version 1.0, September 1980.
+
+ [4]
+ "Assigned numbers," Jon Postel, RFC 790, USC/Information
+ Sciences Institute, September 1981.
+
+ [5]
+ "Internet Protocol - DARPA internet program protocol
+ specification," Jon Postel, ed., RFC 791, USC/Information
+ Sciences Institute, September 1981.
+
+ [6]
+ "Internet protocol transition workbook," Network Information
+ Center, SRI International, Menlo Park, California, March 1982.
+
+ [7]
+ "IP - Local Area Network Addressing Issues," Robert Gurwitz
+ and Robert Hinden, Bolt Beranek and Newman Inc., (draft)
+ August 1982.
+
+
+
+
+
+
+
+
+
+
+ 41
+
+
+
+