From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc824.txt | 2379 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2379 insertions(+) create mode 100644 doc/rfc/rfc824.txt (limited to 'doc/rfc/rfc824.txt') 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 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 + + + + -- cgit v1.2.3