DECnet DIGITAL Network Architecture Ethernet Node Product Architecture Specification Version 1.0.0 September 1983 .-------. `=======' .------. .---. .-------. | | .-------. `======' `===' `=======' | | `=======' \\ ..| |\ \\ \ | | / / \...| .-----. .-------------. ......| | \ \ \ .-------. .-------. o\.--------------. o `--/ /--' `---|\--' o `-----\\ \-----' o / / | \ o \\ \ o / / | \ O \\ \ O ------------. .----------------. .-----------------. /| | \ \ \ / | \ \ \ \ /.-----| \------.\ \ / `-----| \-----' \ \ --------. / .---------------------. \ .----------------------. / | | | \| \ \ | / /----' `---------------------' `--------\ \ \-------' / / \ \ \ / / \ \ \ / .------------------------ / |\ \ \ \ \ \ \ \ \ \ \ \ \ .---------------- \ | \ \| \ \ `---------\ \ Ethernet Node Product Architecture Page 2 ________ This document specifies the minimum required functions for a DEC node connected to an Ethernet. A node meeting these requirements will be maintainable and usable to build additional product specific functions. _______ _________ ___________ MAYNARD, MASSACHUSETTS 01754 Copyright (c) 1983 by Digital Equipment Corporation This material may be copied, in whole or in part, provided that the above copyright notice is included in each copy along with an acknowledgment that the copy describes protocols, algorithms, and structures developed by Digital Equipment Corporation. This material may be changed without notice by Digital Equipment Corporation, and Digital Equipment Corporation is not responsible for any errors which may appear herein. Table of Contents Page 3 CONTENTS 1 Introduction . . . . . . . . . . . . . . . . . . . . 4 1.1 Functions . . . . . . . . . . . . . . . . . . . . 4 1.2 Requirements, Goals, And Non-goals . . . . . . . . 5 1.2.1 Requirements . . . . . . . . . . . . . . . . . . 5 1.2.2 Goals . . . . . . . . . . . . . . . . . . . . . 5 1.2.3 Non-goals . . . . . . . . . . . . . . . . . . . 5 2 Models . . . . . . . . . . . . . . . . . . . . . . . 7 2.1 Relation To Digital Network Architecture . . . . . 7 2.2 Ethernet Node Type Model . . . . . . . . . . . . . 8 3 Required Functions . . . . . . . . . . . . . . . . . 9 3.1 All Nodes . . . . . . . . . . . . . . . . . . . . 9 3.1.1 Data Link Layer Requirements . . . . . . . . . . 9 3.1.2 Network Management Layer Requirements . . . . 10 3.1.3 User Layer Requirements . . . . . . . . . . . 11 3.2 Remote Control Nodes . . . . . . . . . . . . . . 11 3.2.1 Network Management Layer Requirements . . . . 11 3.3 Remote Dump/Load Nodes . . . . . . . . . . . . . 12 3.3.1 Network Management Layer Requirements . . . . 12 3.4 Remote Diagnosis Nodes . . . . . . . . . . . . . 12 3.4.1 Network Management Layer Requirements . . . . 12 3.4.2 User Layer Requirements . . . . . . . . . . . 12 4 Network Auto-configuration . . . . . . . . . . . . 13 4.1 Goals . . . . . . . . . . . . . . . . . . . . . 13 4.2 Algorithm . . . . . . . . . . . . . . . . . . . 13 Introduction Page 4 Introduction This document specifies the minimum required functions for a DEC node connected to an Ethernet. A node meeting this specification will be maintainable and usable to build additional product specific functions. Within the context of this specification, a node is defined as a collection of hardware and software that appears to other nodes as a single functional unit. This node is attached to a common coaxial cable and uses this cable as a network communication medium according to the Digital, Intel, Xerox Ethernet Specification. This specification assumes reader familiarity with the following documents: ___ _________ _ _____ ____ ________ ____ ____ _____ ___ ________ _____ ______________ Xerox), Order No. AA-K759B-TK ___ ________ ____ ____ __________ _____________ Order No. AA-Y298A-TK ___ ___________ __________ __________ _____________ 3.0.0, Order No. AA-X436A-TK ______ _______ _______ ____________ ______ ___ _______ ___________ Functions This specification addresses the following functional areas: Initialization and self-test performs to declare itself operational. Communication service service. Communication diagnosis communicate over the Ethernet and isolating communication problems to specific nodes. System diagnosis faults that prevent a node from functioning properly. Down-line load and up-line dump host node for storage and retrieval of system software over the Ethernet. Introduction Page 5 Requirements, Goals, And Non-goals This section describes characteristics that the Ethernet Node design must have, that it will attempt to have, and that it will not have. These constraints vary somewhat according to the node's individual product requirements. They must thus be considered in that context. The various classes of products are discussed in the Model section. Requirements This Ethernet Node design must have the following characteristics: . All Ethernet capabilities needed for higher level functions are available. . A network manager can control and observe the node and the network as they function. . The design complies with other applicable specifications. . The design can be adapted to the varied requirements of legitimately different products. Goals This Ethernet Node design attempts to have the following characteristics: . Be efficient in usage of processor, memory, and network. . Required functions are simple to implement. . Usage is predictable, simple, and consistent. . Node and network operation continue in the face of software, hardware, or management problems. . Security will not be decreased from the low level that is already present in a broadcast network. Non-goals The following are not goals of the Ethernet Node design: 1. High level functions addressed beyond those required for minimal maintenance. General network functions and most management functions are left for higher level definition. Introduction Page 6 2. Isolation of failing components within a node. This is left to the specific diagnostics for that product. This architecture defines only primitive access to the node, usable by specific diagnostics. 3. Functional partitions for implementations. For example, this document does not address the division of labor between a system processor and a communication processor. 4. Functions within a node that do not affect the network or need not be available across the network. 5. Security beyond the earlier statement of goals. Models Page 7 Models This section describes the relationship of the Ethernet Node architecture to other network layers and modules. It also defines the model used to classify nodes so that their functional requirements can be stated. Although this specification only describes how the Ethernet Data Link fits into the Digital Network Architecture (DNA), the Ethernet Data Link could be integrated into any layered network architecture (for example, Digital's System Communication Architecture). Relation To Digital Network Architecture The functions addressed in this specification are found in the User, Network Management, and Data Link Layers. Those that are in the Network Management Layer are defined in the DNA Maintenance Operations Functional Specification. The Data Link functions are in the DNA Ethernet Data Link Functional Specification. The User functions are defined in this specification. Note that although there are other DNA layers, and other high level functions in the Network Management layer that use them, their existence is not directly relevant to this specification. The high level functions they represent may be provided by DNA or any other similar architecture. The following diagram shows the relationship of the above mentioned modules. .------------------------. | Ethernet Node User | User `------------------------' Layer . . . . | . . . . .|. . . |. . . . . . . . . . | | | | | `-----. | V | Network | .-------------. | Management | | Maintenance |<----| Layer | | Operation | | | `-------------' | . . . . | . . . . .|. . . . . . | . . . . . . V V | .------------------------. | Data | Ethernet Data Link |<-' Link `------------------------' Layer Arrows indicate flow of control. Vertical arrowheads indicate User Interfaces, horizontal arrowheads indicate Network Management Interfaces. Models Page 8 Ethernet Node Type Model This section defines a model for viewing Ethernet Node types. The model is in terms of how the node is maintained and controlled as related to the scope of this specification. This model is used later in this specification to define required functions for different node types in different states. There are three important characteristics that must be considered: Control Causing a node to load is called "booting". System image location actually kept. Transfer of the image is the process of up-line dump or down-line load. Diagnosis Each of these necessary functions may be performed locally or remotely, that is, within the node itself, or on its behalf by some other node. Since these three functions may independently be performed locally or remotely, they can be combined into eight different configurations. Any of the node types may be in one of three states relative to maintenance operations. Changes between these states are a matter of system operation, sometimes in implementation-specific ways and sometimes due to outside control. Primitive maintenance functions for its type. For example, these functions may be implemented in read-only memory, while all other functions are available only when explicitly loaded. Maintenance appropriate to its type. This state is appropriate to smaller nodes that may not have room for all maintenance and normal functions simultaneously. Normal Required Functions Page 9 Required Functions This section specifies the required interface functions for the various node types and states. Unless specified otherwise, functions are required regardless of node states as described in the Models section. Any functions not required are optional. Inclusion of optional functions must be based on specific product requirements. For example, a node that is to be able to do active communication testing must implement the Loop Requester. All Nodes The functions in this section are required regardless of node type. The following statements of principle must be met: . All protocol type usage must be in compliance with the applicable protocol specification. . The broadcast address must not be used unless a frame is intended for all nodes, regardless of function or manufacturer. . No two channels on the same cable may have the same physical address. . In any case of a node with multiple Ethernet channels, the User Layer must resolve all potential conflicts. For example, a node with multiple channels may have to resolve conflicts between multiple attempts to take control of its remote console. Data Link Layer Requirements The following User Interface functions must be implemented: . Open . Enable-protocol . Disable-protocol . Enable-multicast . Disable-multicast . Close . Transmit . Transmit-poll . Receive . Receive-poll . Receive-abort Required Functions Page 10 The following Network Management functions must be implemented: . Read-channel . Enable-channel . Disable-channel . Read-counters The Network Management Set-address function must be implemented on nodes that have more than one channel. It must also be implemented on all nodes that do not automatically have the correct DECnet address as described below. All channel counters must be implemented. All portal counters must be implemented except for the maintenance protocols for loopback, console, and dump/load. In the case of the maintenance protocols, portal counters are optional. All event information must be implemented. All event information must be available through either the User transmit and receive functions or the Network Management Read-event function. Network Management Layer Requirements The Loop Server must be implemented. Furthermore, it must be enabled whenever the Data Link state is "on". The only optional Loop Server functions are Enable-assistance and Disable-assistance. Note that all required functions must operate regardless of such special states as "promiscuous receive". The Console Server Identify-self function must be implemented. The Console Server must respond to a remote Read-identity function. Furthermore, these functions must be enabled whenever the Data Link state is "on". In normal state, the Console Server must respond to a remote Read-counters function. In normal state, a DECnet Phase IV node must set its physical address to a function of its DECnet address. Referring to transmission order, the first three bytes of the address consist of one of the address groups assigned to Digital by Xerox. The fourth byte is a zero. The fifth byte is the low order byte of the 16 bit DECnet address, and the sixth byte is the high order byte of the 16 bit DECnet address. So, for example, DECnet node number 14 would have the Ethernet address AA-00-04-00-0E-00 (this format for address display is further discussed in a later section). Required Functions Page 11 User Layer Requirements When enabling the Data Link, the node must perform sufficient initialization and self test, short of using the network, to believe that it can communicate properly. If it fails this self test, it must not come onto the network. The node must report all event information in some way, not necessarily as events. The node must implement some means of displaying the hardware address. The node must implement some means of displaying the physical address if it can be different from the hardware address. These requirements can be met, for example, with a printed label or a machine-accessible output. The format for display of an Ethernet address must be according to the inter-company standard as found in the Ethernet Specification. That standard is repeated here for reader convenience. Each byte of the address is displayed as a hexadecimal number. The bytes are displayed from left to right, in the order that they are transmitted, separated by hyphens. The bits within the bytes are transmitted from right to left. As an example, consider the address AB-CD-EF-01-23-45. The first byte transmitted is AB, the last is 45. The first bit transmitted is the low order bit of AB, a one, therefore the example is a multicast address. The last bit transmitted is the high order bit of 45, a zero. The first three bytes (AB, CD, and EF) are assigned by Xerox. The last three bytes (01, 23, and 45) are assigned by the manufacturer. Whenever the Data Link state is "on", the node must periodically call the Console Server Identify-self function. For the precise definition of this period and an explanation of the use of this function, see the section on Network Auto-configuration. Remote Control Nodes This section states additional requirements for a node that is remotely controlled. This is a node that can be forced by a remote node to load or dump itself. Network Management Layer Requirements The node must implement response to the Console Server Boot function in primitive and maintenance states. The node must implement this response in normal state if it does not reliably and automatically go to primitive or maintenance state when it malfunctions. Required Functions Page 12 Remote Dump/Load Nodes This section states additional requirements for a node that uses remote storage of its system image. This is a node that is down-line loaded or up-line dumped. Network Management Layer Requirements The node must implement the Dump/Load Requester Load-self function in the primitive state. The Load-self function should start as far into the multi-stage load process as possible. In other words it should not go through the load of a secondary or tertiary loader program unless required by implementation constraints. Remote Diagnosis Nodes This section states additional requirements for nodes that are to be remotely diagnosed. Network Management Layer Requirements The node must implement Console Server response to the console carrier functions. The required Console Server functions need not be available in primitive state if the node is remotely controlled, down-line loadable, and the node's self test covers all resources neccessary to support them. User Layer Requirements The node must either keep the Console Server available for remote use or implement some reliable way of making it available. Network Auto-configuration Page 13 Network Auto-configuration The functions required above allow the automatic determination of the configuration of an Ethernet network. This section explains the algorithm for using the required primitives and the goals used in selecting the algorithm. This procedure is specified as part of general maintenance operations because it is Ethernet specific. Goals The following goals were used in the selection of an auto-configuration algorithm: 1. Configuration available within one hour. 2. With a 0.999 probability, configuration includes all nodes whose Data Link state is "on". 3. The configuration information includes physical addresses and system identification information. 4. The process is of low overhead for the nodes being configured and the overall network. 5. The process is simple for the nodes being configured to implement. 6. The process works correctly when multiple nodes attempt to determine configuration. 7. The process is simple and of low overhead on the node determining the configuration when this goal is not in conflict with the other goals. Algorithm Simply stated, every node periodically sends a system identification message to the remote console service multicast address. A node wishing to determine network configuration listens to this multicast address for a multiple of the transmission period and builds the configuration list from the received messages. The minimum requirement to implement this is that each system periodically call the Console Server Identify-self function. The periodic transmission algorithm is: Compute wait time. WHILE Data Link state = "on" CALL Console Server Identify-self. Wait. ENDWHILE Network Auto-configuration Page 14 The wait time base is ten minutes. On a thousand node network this creates an average traffic of 100 frames/minute. Assuming a network capacity of 60,000 frames/minute, this represents an overhead of less than 0.2% of network bandwidth. In order to avoid overwhelming a listener with synchronized messages, each node modifies its timer value so that nodes started at the same time will not transmit at the same time. The timer modification is a 16 bit signed number. The number must be random or pseudo-random based on a seed that is unique across similar implementations (such as the node address). The resulting number is treated as milliseconds divided by 4. This number is added to the number of milliseconds divided by 4 in 10 minutes (150,000) resulting in a timer value of 10 minutes plus or minus about 2 minutes 11 seconds, to a resolution of 4 milliseconds. The node then truncates this to its nearest timer resolution, and uses it as the time between sending identification messages. Assuming a random distribution of modifications, a thousand node network that all came up at the same time would transmit over four minutes, a rate of about 4 frames/second. A node collecting a list should listen for at least 40 minutes. A node that has a list and wishes to confirm it can use the Console Requester Read-identity function to each node on its list.