DECnet DIGITAL Network Architecture Ethernet Data Link Architectural Specification Version 1.0.0 September 1983 .-------. `=======' .------. .---. .-------. | | .-------. `======' `===' `=======' | | `=======' \\ ..| |\ \\ \ | | / / \...| .-----. .-------------. ......| | \ \ \ .-------. .-------. o\.--------------. o `--/ /--' `---|\--' o `-----\\ \-----' o / / | \ o \\ \ o / / | \ O \\ \ O ------------. .----------------. .-----------------. /| | \ \ \ / | \ \ \ \ /.-----| \------.\ \ / `-----| \-----' \ \ --------. / .---------------------. \ .----------------------. / | | | \| \ \ | / /----' `---------------------' `--------\ \ \-------' / / \ \ \ / / \ \ \ / .------------------------ / |\ \ \ \ \ \ \ \ \ \ \ \ \ .---------------- \ | \ \| \ \ `---------\ \ Page 2 ________ This document describes the structure, functions, interfaces, and protocols of the DNA Ethernet Data Link not defined in the Ethernet Specification that make it compatible with DNA. _______ _________ ___________ MAYNARD, MASSACHUSETTS 01754 Copyright (c) 1983 by Hewlett-Packard Company 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 CONTENTS 1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . 5 2 FUNCTIONAL DESCRIPTION . . . . . . . . . . . . . . . 6 2.1 Design Scope . . . . . . . . . . . . . . . . . . . 6 2.1.1 Requirements . . . . . . . . . . . . . . . . . . 7 2.1.2 Goals . . . . . . . . . . . . . . . . . . . . . 7 2.1.3 Non-Goals . . . . . . . . . . . . . . . . . . . 7 3 MODELS . . . . . . . . . . . . . . . . . . . . . . . 8 3.1 Relationship to DIGITAL Network Architecture . . . 8 3.2 DNA Ethernet Data Link Model . . . . . . . . . . 10 3.2.1 Resource Naming . . . . . . . . . . . . . . . 11 3.2.2 Data Link States . . . . . . . . . . . . . . . 11 4 INTERFACES . . . . . . . . . . . . . . . . . . . . 13 4.1 User Interface . . . . . . . . . . . . . . . . . 13 4.1.1 Open . . . . . . . . . . . . . . . . . . . . . 15 4.1.2 Enable-promiscuous . . . . . . . . . . . . . . 16 4.1.3 Disable-promiscuous . . . . . . . . . . . . . 16 4.1.4 Enable-protocol . . . . . . . . . . . . . . . 17 4.1.5 Disable-protocol . . . . . . . . . . . . . . . 18 4.1.6 Enable-multicast . . . . . . . . . . . . . . . 18 4.1.7 Disable-multicast . . . . . . . . . . . . . . 19 4.1.8 Close . . . . . . . . . . . . . . . . . . . . 20 4.1.9 Transmit . . . . . . . . . . . . . . . . . . . 20 4.1.10 Transmit-poll . . . . . . . . . . . . . . . . 21 4.1.11 Receive . . . . . . . . . . . . . . . . . . . 22 4.1.12 Receive-poll . . . . . . . . . . . . . . . . . 23 4.1.13 Receive-abort . . . . . . . . . . . . . . . . 25 4.2 Network Management Interface . . . . . . . . . . 25 4.2.1 Read-channel . . . . . . . . . . . . . . . . . 26 4.2.2 Read-portal-list . . . . . . . . . . . . . . . 27 4.2.3 Read-portal . . . . . . . . . . . . . . . . . 27 4.2.4 Reset . . . . . . . . . . . . . . . . . . . . 28 4.2.5 Set-address . . . . . . . . . . . . . . . . . 28 4.2.6 Enable-channel . . . . . . . . . . . . . . . . 29 4.2.7 Disable-channel . . . . . . . . . . . . . . . 30 4.2.8 Read-counters . . . . . . . . . . . . . . . . 30 4.2.9 Read-event . . . . . . . . . . . . . . . . . . 31 4.3 Ethernet Interfaces . . . . . . . . . . . . . . 32 4.3.1 Client to Data Link Interface . . . . . . . . 33 4.3.2 Network Management to Data Link Interface . . 34 4.3.3 Network Management to Physical Link Interface 34 5 NETWORK MANAGEMENT INFORMATION . . . . . . . . . . 35 5.1 Counters . . . . . . . . . . . . . . . . . . . . 35 5.2 Events . . . . . . . . . . . . . . . . . . . . . 39 6 INTERFACE USAGE EXAMPLES . . . . . . . . . . . . . 43 6.1 Portal Filter Setup . . . . . . . . . . . . . . 43 6.2 Data Error Diagnostic . . . . . . . . . . . . . 43 Table of Contents 7 OPERATION . . . . . . . . . . . . . . . . . . . . 44 7.1 Portal Handler . . . . . . . . . . . . . . . . . 46 7.1.1 Open . . . . . . . . . . . . . . . . . . . . . 46 7.1.2 Enable-promiscuous . . . . . . . . . . . . . . 47 7.1.3 Disable-promiscuous . . . . . . . . . . . . . 47 7.1.4 Enable-protocol . . . . . . . . . . . . . . . 48 7.1.5 Disable-protocol . . . . . . . . . . . . . . . 48 7.1.6 Enable-multicast . . . . . . . . . . . . . . . 48 7.1.7 Disable-multicast . . . . . . . . . . . . . . 49 7.1.8 Close . . . . . . . . . . . . . . . . . . . . 49 7.1.9 Transmit . . . . . . . . . . . . . . . . . . . 49 7.1.10 Transmit-poll . . . . . . . . . . . . . . . . 49 7.1.11 Receive . . . . . . . . . . . . . . . . . . . 50 7.1.12 Receive-abort . . . . . . . . . . . . . . . . 50 7.1.13 Receive-poll . . . . . . . . . . . . . . . . . 51 7.2 Transmitter and Receiver . . . . . . . . . . . . 51 7.2.1 Transmitter . . . . . . . . . . . . . . . . . 51 7.2.2 Receiver . . . . . . . . . . . . . . . . . . . 51 7.2.3 Counters . . . . . . . . . . . . . . . . . . . 52 7.2.4 Events . . . . . . . . . . . . . . . . . . . . 55 APPENDIX A PROTOCOL TYPES AND MULTICAST ADDRESSES A.1 CROSS-COMPANY ASSIGNMENTS . . . . . . . . . . . . A-1 A.2 DIGITAL ASSIGNMENTS . . . . . . . . . . . . . . . A-1 Introduction INTRODUCTION The Digital, Intel, Xerox intercompany Ethernet specification is the basis for defining the DNA (DIGITAL Network Architecture) Ethernet Data Link. The DNA Ethernet Data Link incorporates the functions and operations defined in the Ethernet Specification Version 2.0. To these, the DNA Ethernet Data Link adds further features needed by the upper layers of DNA. This specification assumes understanding of the Ethernet specification. This document describes the structure, functions, interfaces, and protocols of the DNA Ethernet Data Link not defined in the Ethernet specification that make it compatible with DNA. DNA is the model on which DECnet implementations are based. A DECnet network is a family of software modules, data bases, and hardware components used to tie DIGITAL systems together for resource sharing, distributed computation or remote system communication. DNA is a layered structure. Modules in each layer perform distinct functions. Modules within a single DNA layer (but typically in different computer systems) communicate using specific protocols. Modules in different layers (but typically in the same computer system) interface using subroutine calls or a system-dependent method. In this document interfaces are described in terms of calls to subroutines. This document assumes that the reader is familiar with computer communications and DECnet. The primary audience consists of those who implement DECnet systems. However, the document may be useful to anyone interested in the details of DECnet structure. The other current DNA functional specifications are: ___ ____ ______ ________ _____ __________ _____________ 5.6.0, Order No. AA-K177A-TK ___ _______ ____ ______________ _______ ________ _______ __________ _____________ ___ ________ ____ _______ ____________ _____________ 1.0.0, Order No. AA-X440A-TK ___ ___________ __________ __________ _____________ 3.0.0, Order No. AA-X436A-TK ___ _______ __________ __________ _____________ Order No. AA-X437A-TK ___ _______ ________ ________ __________ _____________ 4.0.0, Order No. AA-X439A-TK ___ _______ _____ __________ _____________ No. AA-X435A-TK ___ _______ _______ __________ _____________ No. AA-K182A-TK Introduction ___ _________ _ _____ ____ ________ ____ ____ _____ ___ ________ _____ ______________ Xerox), Order No. AA-K759B-TK ______ _______ _______ ____________ ______ ___ _______ ___________ (Order No. AA-N149A-TC) provides an overview of the network architecture and an introduction to each of the DNA functional specifications. FUNCTIONAL DESCRIPTION The Ethernet functions are a subset of those included by the DNA Ethernet Data Link. The DNA Ethernet Data Link has two classes of functions: User Link provides for higher layers. In the context of this specification, the user is the next layer up in the network architecture, rather than the end user at the top layer. Network Management needed to maintain the Data Link. The DNA Ethernet Data Link gives its users a communication service for transmitting and receiving frames, but does not guarantee delivery. The data link filters incoming frames by system address and protocol type based on filter values established by the user. A specific system (physical address), a function-oriented group of systems (multicast address), or all systems (broadcast address) can be addressed using the data link. Each frame has a protocol type assigned to it that is used by the data link to identify the protocol handling module that is to receive it. The use of protocol types allows concurrent operation of multiple protocols in the layer above the data link. For example, in DNA the Routing layer and the DNA Ethernet Data Link Loop Testing Service can both use the DNA Ethernet Data Link at the same time. Neither needs to be aware of the other. This is in contrast to the DDCMP Data Link where maintenance traffic and normal traffic use mutually exclusive modes of protocol operation. The DNA Ethernet Data Link provides control and observation services needed to maintain the data link. These are functions that enable and disable physical channels and monitor the status of specific channels. Design Scope The DNA Ethernet Data Link requires certain characteristics to be present, attempts to meet certain goals, and lacks some features that Functional Description are not within the scope of the design. Requirements The DNA Ethernet Data Link design must have the following characteristics: . All capabilities included in the Ethernet Specification are available from the DNA Ethernet Data Link. . The network manager can control and observe the data link as it functions. . It complies with the Ethernet Specification. Goals The DNA Ethernet Data Link design attempts to have the following characteristics: . Uses both processor and memory efficiently. . Common functions needed by higher layers are included in the data link. . Inputs and outputs are simple, predictable, and consistent. Non-Goals DNA Ethernet Data Link design does not attempt to have the following characteristics: . Addition of functions not included in the Ethernet specification that higher layers may want to implement differently (such as reliable delivery). . Self-diagnosis of all data link problems. Diagnosis of some problems requires information from higher layers. Models MODELS This section describes the relationship of the DNA Ethernet Data Link to other network layers and modules. Although this specification primarily relates the DNA Ethernet Data Link to DNA, the same relationships can also be applied within other network architectures. Relationship to DIGITAL Network Architecture Figure 1 shows the relationship of the DNA Ethernet Data Link to the DNA hierarchy. .----------------------------. | User Modules | `----------------------------' | | | | | V .- | ------- | ------------------------------------. .------| | Network | Management Modules | | `- | ------- | ------------------------------------' | | | | | | | | V V | | | .- | -------------------------------- | ------. | |----> | | Network Application Modules | | | | `- | -------------------------------- | ------' | | | | | | | | V V V | | | .---------------------------------------. | | |----> | Session Control Modules | | | | `---------------------------------------' | | | | | | | V | | | .---------------------------. | | |------------> | End Communication Modules | | | | `---------------------------' | | | | | | | V | | | .---------------------------. | | |------------> | Routing Modules | | | | `---------------------------' | | | | | | | V V V | .-------------------------------------------. |------------> | Data Link Modules | | `-------------------------------------------' | | | V | .--------------------------. `------------> | Physical Link Modules | `--------------------------' | `-------------------------------- Models The DNA Ethernet Data Link resides within the DNA Data Link layer. It can be co-resident with other DNA Data Link modules such as DDCMP or X.25. In figure 1, horizontal arrows show direct access for control and observation of parameters, counters, etc. Vertical arrows show interfaces between layers for normal user operations such as file access, down-line load, and logical link usage. Each layer in DNA consists of functional modules and protocols. Generally, modules use the services of the next lower layer. In this document the service relationship is demonstrated in the way the interfaces are modeled, as calls to subroutines. Note that the Network Management layer interfaces directly with each of the lower layers. Also, the layers above Session Control interface directly with it. For this reason the upper three layers are sometimes referred to as the "end user." Modules of the same type in the same layer communicate with each other to provide their services. The rules governing this communication and the messages required constitute the protocol for those modules. Messages are typically exchanged between equivalent modules in different nodes. However, equivalent modules within a single node can also exchange messages. A brief description of each layer follows in order from the highest to the lowest layer: User layer. services and programs. Programs such as the Network Control Program, which interfaces with the Network Management layer, and file transfer programs, which interface with the Network Application layer, reside in the user layer. Network Management layer. only one that has direct access to each lower layer for control purposes. Modules in this layer provide user control over and access to network parameters and counters. These modules also perform up-line dumping, down-line loading, and testing functions. Network Application layer. layer support network functions, such as remote file access and file transfer, used by the User and Network Management layers. Session Control layer. system-dependent aspects of logical link communication, which allows messages to be sent from one node to another in a network. Session Control functions include name to address translation, process addressing, and, in some systems, process activation and access control. Models End Communication layer. the system-independent aspects of logical link communication. Routing layer. called packets, between source and destination nodes. Data Link layer. concerning data integrity and physical channel management. Physical Link layer. part of the device driver for each communications device plus the communications hardware itself. The hardware includes interface devices, modems, and the communication lines. DNA Ethernet Data Link Model The DNA Ethernet Data Link provides communication services for multiple concurrent users. It also supports multiple Ethernet channels. A channel is defined as a single hardware connection to an Ethernet cable. Each channel implements the cross-company Ethernet standard. The following diagram shows the relationship of these users to the DNA Ethernet Data Link and its relationship to the standard Ethernet Data Link. In Ethernet terminology, the DNA Ethernet Data Link is the lowest level module in the Client Layer. .---------. .---------. .---------. | User #1 | | User #2 | . . . | User #n | DNA `---------' `---------' `---------' Ethernet \ | / Users \ | / . . . . . . .\. . . . . . .|. . . . . . . ./. . . . . . . . . . . . . \ | / .----------------------------------------. | DNA Ethernet Data Link Interfaces | `----------------------------------------' / | \ Channel 1 Channel 2 ... Channel m DNA / | \ Ethernet .---------. .---------. .---------. Data | E T H E R N E T D a t a L i n k | Link `---------' `---------' `---------' | | | .----------. .---------. .-----------. | E T H E R N E T P h y s i c a l L i n k | `----------' `---------' `-----------' Models Resource Naming The user of the DNA Ethernet Data Link is concerned with two different levels of identification. Users identify either a channel or a portal. channel channel has one name and each name identifies one channel. portal the data link to service that user's requests. A portal is assigned by the data link in response to a user's initial call. The user then uses that portal in subsequent related calls. Many users can simultaneously have their own portal associated by the data link with the same channel. A portal data base contains the lists of protocol types and multicast addresses that the user has enabled for receipt of incoming frames. The user will receive frames only for enabled protocol types and multicast addresses. It also contains the lists of outstanding transmits and receives for the user. Data Link States In observing the operation of the data link, the user can see four channel states. Some of these states are reached due to network management commands, others due to data link operation. The states are: Off Init data link. This test is an implementation dependent self-test. On Broken failed the initialization test, or the channel was on but the data link determined that the channel would now fail the initialization test. Changes between these states do not affect counters or parameters such as the node's physical address. Models The following diagram shows the data link state transitions for a channel: .---------------------. | ++++ | V V + | .-----. .------. .----. Key: .--| |<---| | | |+++ | | off | | init |***>| on | + --- Management Disable `->| |+++>| | | |<++ `-----' `------' `----' +++ Management Enable A A * * | + * * *** Data Link Operation | + V * | .--------. * `------| broken |<***** `--------' Network management can enable the channel. From the "off" or "broken" states, this enable causes a transition to "init". From the "on" state, enable has no effect. In the "init" state, the data link performs initialization and test of the channel. If this succeeds, the data link changes the state to "on". If initialization and test fail, the data link changes the state to "broken". From the "broken" state, network management can either try initialization again with an enable command or go to "off" with a disable command. The data link can change the state from "on" to "broken" at any time if it determines that the channel would fail initialization and test. The channel can be forced to "off" from any state by a network management disable command. Interfaces INTERFACES The following sections describe the interfaces provided by DNA Ethernet Data Link. They are the following: User Interface data between data links. Network Management Interface observation functions for the local data link. The function descriptions are in terms of subroutines with input and output arguments. These subroutines are to be understood as abstract, functional descriptions. Actual implementations may vary, for example in synchronization techniques, as long as they provide the same functions. Furthermore, these are models for privileged, internal system interfaces. They are not necessarily to be used as high level user interfaces. The interfaces use the two levels of identification defined in the Model section. Callers identify the object of a call in terms of either channel-id or portal-id. In many of the interface functions, the caller can specify an Ethernet address. In some cases this address can be either a physical address or a multicast address. In other cases it is restricted to one or the other. In implementations that allow expression of one of the forms of address in a case where it is invalid, the implementation must reject the function request with an appropriate error return code. The interface descriptions assume that buffers are passed in the form of a descriptor that contains buffer address, maximum buffer length, and, if applicable, length of information in buffer. This section also contains an overview of the required interface functions from the intercompany Ethernet specification. User Interface This section describes the User Interface to the DNA Ethernet Data Link. The User Interface maintains portals for transmission and reception of frames through the data link on behalf of the user. The user can enable or disable broadcast and multicast addresses and appropriate protocol types on specific portals for flexible filtering of incoming frames. The User Interface provides functions for queuing frames and monitoring the status of those queued requests. Interfaces The interface contains the following functions: . Open -- open a portal. . Enable-promiscuous -- enable all protocol types and multicast addresses for a portal. . Disable-promiscuous -- disable the blanket protocol type and multicast address enable for a portal. . Enable-protocol -- enable a protocol type for a portal. . Disable-protocol -- disable a protocol type for a portal. . Enable-multicast -- enable a multicast address for a portal. . Disable-multicast -- disable a multicast address for a portal. . Close -- close a portal. . Transmit -- send a frame. . Transmit-poll -- checks for completion of a Transmit. . Receive -- receive a frame. . Receive-abort -- Aborts a Receive. . Receive-poll -- checks for completion of a Receive. Some features in the interface descriptions are optional. Features can be optional for caller or implementor or both. Caller-optional features can be invoked at the user's option. Implementor-optional features may or may not be included in particular implementations based on product requirements. A portal will receive only those frames that match the filtering criteria set up with the enable and disable functions. These functions can be invoked multiple times for the same portal, allowing a single portal to receive many protocol types and multicast addresses. Alternatively, a portal can enable promiscuous receipt. This is exclusive of individual enables or disables, and allows the portal to receive all protocol types and multicast addresses. Enabling of a protocol type automatically implies receipt of frames addressed to the channel's physical address. A portal receives multicast frames only for those multicast addresses it specifically enables. In this context, broadcast is treated the same as other multicast addresses. Multicast addresses enabled or disabled on one portal have no effect on other portals. Conceptually, receive filtering is done first by protocol type, then by multicast address. A frame that does not pass filtering is discarded. In actual practice, an implementation may first filter in hardware the union of the multicast addresses for all portals and then Interfaces do the filtering again on a reduced number of frames. Open The open function opens a portal so that the user can transmit and receive frames. OPEN(Channel-id,Pad,Return-code,Portal-id) Inputs: Channel-id which the portal is to be opened. Pad frames that are under minimum length. Padding is accomplished via data link generated additions to user data. It is the responsibility of the user's protocol conventions to define that its protocol modules in other systems will either request the same option or will understand the padding conventions. The data link will apply padding conventions to both transmitted and received messages for the portal. Outputs: Return-code Success - a portal was opened. No resources - the DNA Ethernet Data Link does not have sufficient resources to open a portal. Unrecognized channel - there is no channel with the specified identification. Channel not on - a portal cannot be opened because the channel state is not "on". Promiscuous receiver active - a portal cannot be opened because some other portal has enabled promiscuous receive. This error return applies only in implementations that limit promiscuous receive to a single portal (see the Enable-promiscuous function). Portal-id interface functions. Interfaces Enable-promiscuous The Enable-promiscuous function indicates that the portal is to receive all frames regardless of protocol type or multicast address. If a portal has this enable function in effect, it cannot explicitly enable individual protocol types or multicast addresses. Three possible implementations of this function are allowed: Not implemented. Exclusive use only. open or if this portal has any protocol types or multicast addresses enabled. Non-exclusive use. that would have been delivered to another portal are duplicated and delivered to this one also. This is in addition to all other frames. ENABLE-PROMISCUOUS(Portal-id,Return-code) Inputs: Portal-id Outputs: Return-code Success - promiscuous receive enabled. Not implemented - the implementation does not support the requested function. Non-exclusive - the implementation allows only exclusive promiscuous receipt and this portal or some other portal has a protocol type or multicast address enabled. Unrecognized portal - there is no open portal with the specified identification. Channel not on - the function failed because the channel state is not "on". Disable-promiscuous The Disable-promiscuous function indicates that the portal is no longer to receive frames for all protocol types and multicast addresses. Interfaces DISABLE-PROMISCUOUS(Portal-id,Protocol-type,Return-code) Inputs: Portal-id Protocol-type portal. Outputs: Return-code Success - promiscuous receive is not enabled for the portal. Unrecognized portal - there is no open portal with the specified identification. Enable-protocol The Enable-protocol function adds a protocol type to the list of those that the portal wishes to receive. The function fails if the protocol type is enabled by some other portal. ENABLE-PROTOCOL(Portal-id,Protocol-type,Return-code) Inputs: Portal-id Protocol-type portal. Outputs: Return-code Success - the protocol type is enabled. Protocol type in use - this portal cannot enable the protocol type because some other portal already has it enabled. No resources - the DNA Ethernet Data Link does not have sufficient resources to enable another protocol type. Unrecognized portal - there is no open portal with the specified identification. Interfaces Promiscuous receive active - the function failed because this portal has enabled promiscuous receive. This error return applies only in implementations that limit promiscuous receive to a single portal (see the Enable-promiscuous function). Channel not on - the function failed because the channel state is not "on". Disable-protocol The Disable-protocol function indicates that the portal is no longer to receive frames for a protocol type. DISABLE-PROTOCOL(Portal-id,Protocol-type,Return-code) Inputs: Portal-id Protocol-type for this portal. Outputs: Return-code Success - the protocol type is not enabled for the portal. Unrecognized portal - there is no open portal with the specified identification. Enable-multicast The Enable-multicast function adds a multicast address to the list of those that the portal wishes to receive. ENABLE-MULTICAST(Portal-id,Multicast-address,Return-code) Inputs: Portal-id Multicast-address for this portal. Interfaces Outputs: Return-code Success - the multicast address is enabled. No resources - the DNA Ethernet Data Link does not have sufficient resources to enable another multicast address for this portal. Unrecognized portal - there is no open portal with the specified identification. Promiscuous receive active - the function failed because this portal has enabled promiscuous receive. This error return applies only in implementations that limit promiscuous receive to a single portal (see the Enable-promiscuous function). Channel not on - the function failed because the channel state is not "on". Disable-multicast The Disable-multicast indicates that the portal is no longer to receive frames for a multicast address. DISABLE-MULTICAST(Portal-id,Multicast-address,Return-code) Inputs: Portal-id Multicast-address recognized for this portal. Outputs: Return-code Success - the multicast address is not enabled for the portal. Unrecognized portal - there is no open portal with the specified identification. Interfaces Close The Close function closes an open portal and releases all its resources. A portal cannot be closed unless all outstanding transmit or receive requests are completed. CLOSE(Portal-id,Return-code) Inputs: Portal-id Outputs: Return-code Success - the portal is closed. Unrecognized portal - there is no open portal with the specified identification. Calls outstanding - there are uncompleted transmit or receive requests outstanding on the portal. Transmit The Transmit function queues a frame to be transmitted. The user tests for completion by using Transmit-poll. Transmission of a frame always succeeds or fails within such a small amount of time that an abort function is not necessary. The user can have multiple outstanding Transmits, up to the limit allowed by the implementation. NOTE Ethernet does not guarantee attempted delivery of fewer than 46 bytes or more than 1500 bytes of user data. The DNA Ethernet Data Link may attempt transmission, but the result is unspecified. TRANSMIT(Portal-id,Destination-address,Protocol-type,Input-buffer, CRC-32,Return-code) Inputs: Portal-id Destination-address can be either a physical address or a multicast address. As a matter of good citizenship, users should Interfaces not transmit to the broadcast address unless the message is intended for all systems, regardless of their function or manufacturer. Protocol-type Input-buffer data is shorter than the minimum Ethernet message size and padding is not enabled, or the data is longer than the maximum Ethernet message size, then the frame may not arrive at the destination. If padding is enabled there is no minimum size, and the maximum size is the Ethernet limit minus two bytes. Until the request is completed (as sensed via Transmit-poll), the user must not disturb the contents of the buffer. CRC-32 redundancy code that is to be used for this frame. This overrides the one normally supplied by the data link. Outputs: Return-code Request accepted - DNA Ethernet Data Link will attempt to transmit the frame. Notification of completion is via the Transmit-poll function. CRC control not available - the user attempted to supply a CRC and the implemention either does not support or allow the function. No resources - the DNA Ethernet Data Link does not have sufficient resources to queue another transmit for this portal. Unrecognized portal - there is no open portal with the specified identification. Channel not on - the function failed because the channel state is not "on". Transmit-poll The Transmit-poll function checks for the completion of a transmit request. The data link transmits frames in the order in which the user submits them. Successful completion of this function implies only that the local transmitter believes that it sent the frame. It has no implication relative to reception by the destination. Interfaces TRANSMIT-POLL(Portal-id,Return-code,Input-buffer,Error-detail, Fault-distance) Inputs: Portal-id Outputs: Return-code Not complete - no outstanding transmit for this portal is done. None outstanding - there are no outstanding transmits for this portal. Transmit successful - a frame successfully left the local transmitter. Transmit failed - the local transmitter could not transmit the frame. Unrecognized portal - there is no open portal with the specified identification. Channel left "on" state - the function failed because the channel is no longer in the "on" state. Input-buffer function. Error-detail "transmit failed". Detailed explanation of these reasons is in the section on events. One of: Excessive collisions Carrier check failed Short circuit Open circuit Frame too long Remote failure to defer Fault-distance short or open circuit. This is meaningful only when error-detail is "short circuit" or "open circuit". Receive The Receive function queues a buffer to receive a frame. RECEIVE(Portal-id,Receive-bad,Output-buffer,Return-code,Frames-lost) Interfaces Inputs: Portal-id Receive-bad that frames are to be returned even though they contain invalid data. This includes frames with CRC or framing errors. Output-buffer frame. Outputs: Return-code Request accepted - If a message is received for the specified portal, the DNA Ethernet Data Link will put it into the buffer. Notification of completion is via the Receive-poll function. Receive-bad not implemented - the call requested receipt of bad frames but the implementation does not support the function. No resources - the DNA Ethernet Data Link does not have sufficient resources to queue another receive for this portal. Unrecognized portal - there is no open portal with the specified identification. Channel not on - the function failed because the channel state is not "on". Frames-lost for this portal that were discarded because no buffer was available. Note that this count can be incorrect if frames were lost at a low enough level that portal filtering could not be done. This argument is not required in implementations where the buffering is always available. Receive-poll The Receive-poll function checks for the completion of a receive request. The data link gives received frames to the user in the order in which they arrived. RECEIVE-POLL(Portal-id,Return-code,Error-detail,Destination-address, Source-address,Protocol-type,Output-buffer, Bytes-lost,CRC-32) Interfaces Inputs: Portal-id Outputs: Return-code Not complete - no outstanding receive for this portal is done. None outstanding - there are no outstanding receives for this portal. Receive successful - a frame was successfully received into the buffer. Receive with overrun - a frame was successfully received, but had to be truncated to fit into the buffer. Length error - the received frame length was inconsistent with the length recorded by the padding conventions. The buffer contains the data received, including the padding information and truncated if it was too long to all fit in the buffer. Invalid data - a frame was received with bad data. This return-code value is only seen if on the Receive function the caller requested delivery of bad frames. Receive aborted - the user cancelled the receive request with the Receive-abort function. Unrecognized portal - there is no open portal with the specified identification. Channel left .bb "on" state - the function failed because the channel is no longer in the "on" state. Error-detail "invalid data". Detailed explanation of these reasons is in the section on events. One of: Block check error Framing error Frame too long Destination-address addressed. Source-address received frame. Interfaces Protocol-type Output-buffer Bytes-lost "receive with overrun". This argument is optional both for user and implementor. If it is applicable but not implemented, it returns a value of "not implemented". CRC-32 came into the data link with the frame. Receive-abort The Receive-abort function aborts all incomplete receive requests for the portal. The buffers are returned via the Receive-poll function. They may be returned as aborted or as normally completed. RECEIVE-ABORT(Portal-id,Return-code) Inputs: Portal-id Outputs: Return-code Success - the request is now complete. Unrecognized portal - there is no open portal with the specified identification. None outstanding - there are no outstanding receives for this portal. Network Management Interface This section describes the interface used to control and observe operation of the DNA Ethernet Data Link. The Network Management Interface enables and disables channels and monitors the events and counters that provide information on network operation. The Network Management Interface contains the following functions: . Read-channel -- read channel status. . Read-portal-list -- read list of open portals. Interfaces . Read-portal -- read information for a portal. . Reset -- reset the channel to initial state. . Set-address -- set channel physical address. . Enable-channel -- enable channel operation. . Disable-channel -- disable channel operation. . Read-counters -- read channel or portal counters. . Read-event -- read channel event. Read-channel The Read-channel function reads status information relative to a specified channel. READ-CHANNEL(Channel-id,Return-code,Physical-address, Hardware-address,State,Broken-code) Inputs: Channel-id status is to be read. Outputs: Return-code Success - status successfully read. Unrecognized channel - there is no channel with the specified identification. Physical-address set". This is the address that the channel is currently using. Hardware-address available". This is the address associated with the channel hardware. State On Off Init Broken Broken-code Interfaces reason the state is "broken". Read-portal-list The Read-portal-list function reads the list of open portal identifications. READ-PORTAL-LIST(Channel-id,Buffer,Return-code) Inputs: Channel-id open portal list is to be read. Buffer Outputs: Return-code Success - list successfully read. Buffer too small - the buffer could not hold the entire list. Portal identifications that would not fit in the buffer are not returned. Unrecognized channel - there is no channel with the specified identification. Buffer identifications. Read-portal The Read-portal function reads portal data base information for a portal. READ-PORTAL(Portal-id,Buffer,Return-code) Inputs: Portal-id the data base is to be read. Buffer information. Interfaces Outputs: Return-code Success - portal data base successfully read. Buffer too small - the buffer could not hold all the information. Information that would not fit in the buffer is not returned. Unrecognized channel - there is no channel with the specified identification. Buffer information. Each parameter entry contains the following information: Parameter-type - the identification of the particular portal data base parameter. The parameters are listed in the Portal Data Base operation section. Value - the parameter value. Reset The Reset function returns the specified channel to initial state. The physical address is unset. The counters are zeroed. All portals are closed. The channel state is "off". RESET(Channel-id,Return-code) Inputs: Channel-id be reset. Outputs: Return-code Success - channel reset. Unrecognized channel - there is no channel with the specified identification. Set-address The Set-address function sets the physical address of the specified channel. This is the address recognized as specific destination in Interfaces received frames and sent as source address in transmitted frames. This function is necessary for a system that wants to use the same physical address on multiple different cables or has a physical address that is obtained completely independently of the data link. SET-ADDRESS(Channel-id,Address,Return-code) Inputs: Channel-id the address is to be set. This must be a physical address. Furthermore, it must be unique among all channels attached to the same cable. Address Outputs: Return-code Success - the address was successfully set. Unrecognized channel - there is no channel with the specified identification. Channel not off - the function failed because the channel state is not "off". Enable-channel The Enable-channel function attempts to put the channel into a state where it can be used. Enabling the channel does not disturb the contents of counter variables. ENABLE-CHANNEL(Channel-id,Return-code) Inputs: Channel-id enabled. Outputs: Return-code Success - Channel is enabled. A channel that is enabled is not necessarily usable. The user can determine the actual state of the channel with the Interfaces Read-channel function. Address not set - the physical address for the channel has not been set. Unrecognized channel - there is no channel with the specified identification. Disable-channel The Disable-channel function puts the channel into the "off" state so that it cannot be used. The purpose of this function is to halt operation. The channel can still be observed. In particular counters and other data base information not directly related to state change operation is not disturbed. All outstanding transmit and receive operations for the channel are completed with a return code of "channel left on state" on the Receive-poll or Transmit-poll. DISABLE-CHANNEL(Channel-id,Return-code) Inputs: Channel-id disabled. Outputs: Return-code Success - channel is disabled. Unrecognized channel - there is no channel with the specified identification. Read-counters The Read-counters function reads and optionally sets all counters associated with the specified channel or portal to zero. READ-COUNTERS(Entity-id,Operation,Buffer,Return-code) Inputs: Entity-id portal for which counters are to be read. Operation Interfaces operations: Read - only read the counters. Read-and-zero - read the counters and set them to zero. Buffer Outputs: Return-code Success - counters read (and set to zero if requested). Unrecognized entity - there is no channel or portal with the specified identification. Buffer too small - the buffer was too small to hold all the counter information. The information is truncated. Information that would not fit is lost. If read-and-zero was requested, all the counters are set to zero even if their values were not returned. Buffer entry contains the following information: Counter-type - the identification of the particular counter. The counters are listed in the Network Management Information section. Value - the counter value. Causes - specific reasons the counter was incremented. Some counters may be incremented for one or more reasons. For example, the data errors inbound counter can be incremented because of block check errors or framing errors. Read-event The Read-event function reads the next event from the event buffer associated with the specified channel and removes that event from the queue. Only one event at a time need be buffered. The higher level must poll the event buffer often enough to avoid an excessive number of lost events. READ-EVENT(Channel-id,Buffer,Return-code,Events-lost) Interfaces Inputs: Channel-id event is to be read. Buffer Outputs: Return-code Success - event read with no problems. Buffer too small - the buffer was not big enough to contain the entire event. The information is truncated. Information that would not fit is lost. No events - the queue is empty. Unrecognized channel - there is no channel with the specified identification. Events-lost Read-event. Buffer includes the following information: Event-type - the identification of the event. The events and their parameters are listed in the Network Management Information section. Event-parameters - the parameters associated with the event. Each event parameter entry includes the following information: Parameter-type - the identification of the parameter. Value - the value of the parameter. Ethernet Interfaces This section summarizes the Ethernet interfaces on which DNA Ethernet Data Link depends. For a complete description of the Ethernet interfaces, refer to the Digital, Intel, Xerox Ethernet Specification, Version 2.0. This section only contains those functions that relate directly to the operation of the DNA Ethernet Data Link. The Ethernet specification uses Pascal as its representation language. That notation is reproduced here to the minimum extent necessary to recognize functions between the specifications. This is not intended to be a complete description of the Ethernet interfaces. Interfaces Most of the Ethernet interface functions return a status as the value of the function. Client to Data Link Interface The Client to Data Link Interface is the one used by the DNA Ethernet Data Link to transmit and receive frames. It contains the following functions: . TransmitFrame - send a frame. . ReceiveFrame - receive a frame. TransmitFrame TransmitFrame sends a frame. It does not return until the transmit either succeeds or fails. TransmitFrame (destinationParam,sourceParam,typeParam,dataParam) Inputs: destinationParam sourceParam typeParam dataParam Outputs: TransmitFrame transmitOK - frame successfully transmitted. excessiveCollisionError - transmission failed. ReceiveFrame ReceiveFrame receives a frame. It does not return until a frame is received. ReceiveFrame (destinationParam,sourceParam,typeParam,dataParam) Interfaces Inputs: none. Outputs: ReceiveFrame receiveOK - frame successfully received. frameCheckError - frame block check failed. alignmentError - frame did not contain an integral number of bytes. destinationParam sourceParam typeParam dataParam Network Management to Data Link Interface The Network Management to Data Link Interface is the one used by DNA Ethernet Data Link for network management information and control access to the DNA Ethernet Data Link. It contains the following functions: . ReadEthernetAddress - read the physical address. . ReadNumberCollisions - read the number of collisions for the last TransmitFrame. . DataLinkOn - start data link operation. . DataLinkOff - stop data link operation. . SetAddressMode - changes addressing mode between normal and promiscuous. . MulticastOn - enable reception of multicast addresses. . MulticastOff - disable reception of multicast addresses. Network Management to Physical Link Interface The Network Management to Physical Link Interface is the one used by the DNA Ethernet Data Link for network management information and control access to the Ethernet Physical Link. It contains the following function: Interfaces . CheckTransmit - checks status of last TransmitFrame. NETWORK MANAGEMENT INFORMATION This section describes the counters and events that the DNA Ethernet Data Link provides for the Network Management layer. Each description contains a conceptual definition of the information and a statement of its use. Precise operational definitions are in the Operation section. Counters The following counters are kept for each Ethernet channel. Some of them are also kept for portals. Counters are unsigned integers. All counters remain at their maximum value to indicate overflow. Unless otherwise stated, all counters include both normal and multicast traffic. Furthermore, they include information for all protocol types. Frames received and bytes received counters do not include frames received with errors. The following table contains the names and bit lengths of all the counters: Length Name 16 Seconds since last zeroed 32 Bytes received 32 Bytes sent 32 Frames received 32 Frames sent 32 Multicast bytes received 32 Multicast frames received 32 Frames sent, initially deferred 32 Frames sent, single collision 32 Frames sent, multiple collisions 16 Send failure * 16 Collision detect check failure 16 Receive failure * 16 Unrecognized frame destination 16 Data overrun 16 System buffer unavailable 16 User buffer unavailable * Counter has multiple causes The following counters are kept for each portal: Seconds since last zeroed Bytes received Bytes sent Frames received Network Management Infromation Frames sent User buffer unavailable Seconds since last zeroed The number of seconds since the counters were last zeroed. The length is 16 bits. Provides a frame of reference for the other counters by indicating the amount of time they cover. Bytes received The total number of user data bytes successfully received. This does not include Ethernet data link headers. This number is the number of bytes in the Ethernet data field, which includes any padding or length fields when they are enabled. The length is 32 bits. These are bytes from frames that passed hardware filtering. When the number of frames received is used to calculate protocol overhead, the overhead plus bytes received provides a measurement of the amount of Ethernet bandwidth (over time) consumed by frames addressed to the local system. Bytes sent The total number of user data bytes successfully transmitted. This does not include Ethernet data link headers or data link generated retransmissions. This number is the number of bytes in the Ethernet data field, which includes any padding or length fields when they are enabled. The length is 32 bits. When the number of frames sent is used to calculate protocol overhead, the overhead plus bytes sent provides a measurement of the amount of Ethernet bandwidth (over time) consumed by frames sent by the local system. Frames received The total number of frames successfully received. The length is 32 bits. These are frames that passed hardware filtering. Provides a gross measurement of incoming Ethernet usage by the local system. Provides information used to determine the ratio of the error counters to successful transmits. Frames sent The total number of frames successfully transmitted. This does not include data link generated retransmissions. The length is 32 bits. Network Management Infromation Provides a gross measurement of outgoing Ethernet usage by the local system. Provides information used to determine the ratio of the error counters to successful transmits. Multicast bytes received The total number of multicast data bytes successfully received. This does not include Ethernet data link headers. This number is the number of bytes in the Ethernet data field. The length is 32 bits. In conjunction with total bytes received, provides a measurement of the percentage of this system's receive bandwidth (over time) that was consumed by multicast frames addressed to the local system. Multicast frames received The total number of multicast frames successfully received. The length is 32 bits. In conjunction with total frames received, provides a gross percentage of the Ethernet usage for multicast frames addressed to this system. Frames sent, initially deferred The total number of times that a frame transmission was deferred on its first transmission attempt. The length is 32 bits. In conjunction with total frames sent, measures Ethernet contention with no collisions. Frames sent, single collision The total number of times that a frame was successfully transmitted on the second attempt after a normal collision on the first attempt. The length is 32 bits. In conjunction with total frames sent, measures Ethernet contention at a level where there are collisions but the backoff algorithm still operates efficiently. Frames sent, multiple collisions The total number of times that a frame was successfully transmitted on the third or later attempt after normal collisions on previous attempts. The length is 32 bits. In conjunction with total frames sent, measures Ethernet contention at a level where there are collisions and the backoff algorithm no longer operates efficiently. Network Management Infromation NOTE No single frame is counted in more than one of the above three counters. Send failures The total number of times a transmit attempt failed. The length is 16 bits. Each time the counter is incremented, a type of failure is recorded. When Read-counter function reads the counter, the list of failures is also read. When the counter is set to zero, the list of failures is cleared. In conjunction with total frames sent, provides a measure of significant transmit problems. All of the problems reflected in this counter are also captured as events. Following are the possible failures. More information on their meanings and use can be found in the section on events. Excessive collisions Carrier check failed Short circuit Open circuit Frame too long Remote failure to defer Collision detect check failure The approximate number of times that collision detect was not sensed after a transmission. The length is 16 bits. If this counter contains a number roughly equal to the number of frames sent, either the collision detect circuitry is not working correctly or the test signal is not implemented. Receive failures The total number of frames received with some data error. Includes only data frames that passed either physical or multicast address comparison. The length is 16 bits. This counter includes failure reasons in the same way as the send failure counter. In conjunction with total frames received, provides a measure of data related receive problems. All of the problems reflected in this counter are also captured as events. Following are the possible reasons. More information on their meaning and use can be found in the section on events. Block check error Framing error Frame too long Network Management Infromation Unrecognized frame destination The number of times a frame was discarded because there was no portal with the protocol type or multicast address enabled. This includes frames received for the physical address, the broadcast address, or a multicast address. The length is 16 bits. Data overrun The total number of times the hardware lost an incoming frame because it was unable to keep up with the data rate. In conjunction with total frames received, provides a measure of hardware resource failures. The problem reflected in this counter is also captured as an event. System buffer unavailable The total number of times no system buffer was available for an incoming frame. The length is 16 bits. In conjunction with total frames received, provides a measure of system buffer related receive problems. The problem reflected in this counter is also captured as an event. This can be any buffer between the hardware and the user buffers (those supplied on Receive requests). Further information as to potential different buffer pools is implementation specific. User buffer unavailable The total number of times no user buffer was available for an incoming frame that passed all filtering. These are the buffers supplied by users on Receive requests. The length is 16 bits. In conjunction with total frames received, provides a measure of user buffer related receive problems. The problem reflected in this counter is also captured as an event. Events The following events are recorded for each channel. Such information as channel identification, date, and time are assumed to be added as needed by higher layers. The event descriptions include a conceptual definition of the event and an explanation of its use. Precise operational event definitions are in the Operation section. Events are recorded regardless of protocol type. Network Management Infromation NOTE Since some events can occur very rapidly, implementations must take care that main line processing is not pre-empted by event processing. Initialization failed This event is logged when the self test at initialization fails. The procedures in the self test are implementation dependent, but include such things as internal hardware loop testing. This event is optional on channels that cannot fail in initialization. When this event is logged, it includes an implementation specific value that indicates the reason for the failure. Provides notification that the channel is incapable of operating. Send failed This event is logged for any error in transmitting a frame. The reason for the error is included, followed by any other pertinent data. The possible reasons are: Excessive collisions Exceeded the maximum number of retransmissions due to collisions. Indicates an overload condition on the Ethernet. Too many systems are trying to transmit at the same time. Carrier check failed The data link did not sense the receive signal that is required to accompany the transmission of a frame. Indicates a failure in either transmitting or receiving hardware. Could be either transceiver or transceiver cable related. Could be caused by a babbling controller that has been cut off. Short circuit There is a short somewhere in the local area network coaxial cable, or the transceiver or controller/transceiver cable failed. When this reason is logged, an estimated distance to the failure, in bit times, is included. This indicates a problem either in the local hardware or a global network problem. The two can be distinguished by checking to see if other systems are reporting the same problem. Network Management Infromation Open circuit There is a break somewhere in the local area network coaxial cable. When this reason is logged, an estimated distance to the failure, in bit times, is included. This indicates a problem either in the local hardware or a global network problem. The two can be distinguished by checking to see if other systems are reporting the same problem. Frame too long The controller or transceiver cut off transmission at the maximum size. This indicates a problem with the local system: either it tried to send a frame that was too long, or the hardware cut off transmission too soon. Remote failure to defer A remote system began transmitting after the allowed window for collisions. This indicates either a problem with some other system's carrier sense or a weak transmitter locally. Collision detect check failed This event is logged when the data link did not sense the collision signal that is supposed to follow the transmission of a frame. Indicates a failure either in the transceiver or transceiver cable collision circuitry. Receive failed This event is logged for any error in receiving a frame. The reason for the error is included, followed by the source and destination physical addresses, the protocol type, and any other pertinent data as defined for the specific event, if available. The possible reasons are: Block check error The frame failed the CRC check. This indicates several possible failures. It can be caused by such things as electromagnetic interference, late collisions, or improperly set hardware parameters (such as receiver squelch). Network Management Infromation Framing error The frame did not contain an integral number of 8 bit bytes. This indicates several possible failures. It can be caused by such things as electromagnetic interference, late collisions, or improperly set hardware parameters (such as receiver squelch). Data overrun The frame was lost due to a hardware resource failure. This indicates, for example, insufficient hardware buffers or CPU time. System buffer unavailable The frame was discarded because there was no system buffer available to receive it. This indicates a lack of buffers in the local system. This can be any buffer between the cable and the user buffers (those supplied by the user in the Receive function). Further information as to potential different buffer pools is implementation specific. User buffer unavailable The frame was discarded because there was no user buffer available to receive it. This indicates a lack of buffers in the user process. These are the buffers supplied by the user in the Receive function. Unrecognized frame destination The frame was discarded because there was no portal with either the protocol type or the multicast address enabled. This includes frames received for the physical address, the broadcast address, or a multicast address. This indicates either that the local system has not enabled a protocol type or multicast address that it should or that a remote system is attempting to use a protocol that is locally unsupported. Frame too long The frame was discarded because it was outside the Ethernet maximum length and could not be received. Network Management Infromation This indicates that a remote system is sending invalid length frames. INTERFACE USAGE EXAMPLES This section contains examples of how the user interface might be used. The intent is to motivate the functions and to show how they might interrelate. This section does not specify how the interfaces must be used. Portal Filter Setup This example opens a portal and sets up its receive filter criteria. The portal wishes to receive frames of protocol types P1 and P2 that are addressed to the physical address and multicast address M1. Open(Channel-id,Return-code,Portal-id) IF Return-code = "success" Enable-protocol(Portal-id,P1,Return-code) IF Return-code = "success" Enable-protocol(Portal-id,P2,Return-code) IF Return-code = "success" Enable-multicast(Portal-id,M1,Return-code) ENDIF ENDIF ENDIF IF Return-code = "success" {Use the data link} Close(Portal-id,Return-code) ELSE {Handle error} ENDIF Data Error Diagnostic In this case, the data link is to be used by a diagnostic program that has a direct interest in the characteristics of incorrectly received messages. It wishes to supply its own cyclic redundancy code, find what code was received from the other end, and be able to analyze the bit patterns in damaged frames. Using these features it can test some of the data handling within both the local and the remote sides of the data link. It accomplishes this by using the options on the Transmit, Receive, and Receive-poll functions that allow it to meet its task specific needs. Operation OPERATION The bulk of the detailed operation of Ethernet is found in the Ethernet Specification, Version 2.0, and is not repeated here. This section specifies the operation of those functions that are additions to the Ethernet base. The operations specified here are portal handling and transmit/receive handling, which includes recording of counters and events. This section uses a model implementation to describe DNA Ethernet Data Link operation. Implementations are not required to implement this model, but must be functionally equivalent. For example, a counter kept by one implementation must be incremented according to exactly the same criteria as the same counter in any other. The model implementation is modularized according to the following diagram: .---------. .---------. .---------. | User #1 | | User #2 | . . . | User #n | `---------' `---------' `---------' | | | `--------. | .----------' | | | .--------------------. | Portal Handler | `--------------------' | .-------------. .------------. .------------. | Transmitter |----| Portal |----| Receiver | | |-. | Data Base | .-| | `-------------' | `------------' | `------------' | | | | | | .------------. | | | `--| Management |--' | | | Data Base | | | `------------' | | | .---------------------------------------. | Ethernet Data Link and Physical Link | `---------------------------------------' The Portal Handler maintains the Portal Data Base according to user requests through the User Interface. The Portal Handler communicates with the Transmitter and Receiver through the Portal Data Base. The Transmitter and Receiver send and receive frames through the DNA Ethernet Data Link User Interface and maintain counter and event information in the Management Data Base. This specification assumes the mutual exclusion necessary to keep shared data bases correct. The Portal Data Base contains an entry for each open portal. Each entry contains: Operation . Channel identification. . Count of lost frames. . Pad flag. . List of enabled protocol types. . List of enabled multicast addresses. . List of outstanding Transmits, each list entry includes: - Request state, set to "pending" by the Portal Handler and "complete" by the Transmitter. - Destination address supplied by the user for the frame. - Protocol type supplied by the user for the frame. - Input buffer with the user's data to send in the frame. - Return code returned by the Transmitter. - CRC-32 optionally supplied by the user for the frame. If not user-supplied, the DNA Ethernet Data Link will supply it. - Error detail returned by the Transmitter if applicable and desired by the user. - Fault distance returned by the Transmitter if applicable and desired by the user. . List of outstanding Receives, each list entry includes: - Request state, set to "pending" by the Portal Handler and "complete" by the Receiver. - Output buffer supplied by the user for a received frame. - Indicator whether user wants frames with invalid data. - Return code returned by the Receiver. - Error detail returned by the Receiver if applicable and desired by the user. - Destination address returned from the received frame by the Receiver. Operation - Source address returned from the received frame by the Receiver. - Protocol type returned from the received frame by the Receiver. - Bytes lost returned by the Receiver if applicable and desired by the user. - CRC-32 returned from the received frame by the Receiver if desired by the user. Portal Handler This section describes Portal Handler operation relative to the User Interface functions. The Portal Handler functions are: Open Enable-promiscuous Disable-promiscuous Enable-protocol Disable-protocol Enable-multicast Disable-multicast Close Transmit Transmit-poll Receive Receive-abort Receive-poll Open When the user calls Open, if the implementation allows only one promiscuous receiver, the Portal Handler checks to see if one is active. If so, it returns "promiscuous receiver active". If there is no promiscuous receiver problem, the Portal Handler checks that it has the necessary resources to open a new portal. If not, it returns "no resources". If resources are available, the Portal Handler checks to see if the requested channel exists. If not, it returns "unrecognized channel". If the channel exists, the Portal Handler checks to see if it is on. If not, it returns "channel not on". Operation If the channel is on, the Portal Handler initializes the portal data base with the pad flag, empty lists, and the channel identification and returns "success" and the portal identification. Enable-promiscuous When the user calls Enable-promiscuous, the Portal Handler checks to see if the supplied portal identification identifies an open portal. If not, it returns "unrecognized portal". If the portal is open, the Portal Handler does one of the following: . Returns "not implemented". . Or checks to see if any other portal is open or this one has any protocol types or multicast addresses enabled and if so it returns "non-exclusive". . Or accepts the fact that for this portal it will have to duplicate messages that other portals receive. If the Portal Handler can allow promiscuous receive, it enables promiscuous addressing through the DNA Ethernet Data Link. If this fails, it returns "channel in wrong state". Otherwise it puts "promiscuous" in the portal's list of enabled protocol types and returns "success". Disable-promiscuous When the user calls Disable-promiscuous, the Portal Handler checks to see if the supplied portal identification identifies an open portal. If not, it returns "unrecognized portal". If the portal is open, the Portal Handler checks the portal's list of protocol types for "promiscuous". If not found, it returns "success". If the portal is receiving promiscuously, the Portal Handler scans all other portals to see if any others are receiving promiscuously (if the implementation allows multiple promiscuous receivers). If none are found, the Portal Handler disables promiscuous addressing through the DNA Ethernet Data Link. The Portal Handler then returns "success". Operation Enable-protocol When the user calls Enable-protocol, the Portal Handler checks to see if the supplied portal identification identifies an open portal. If not, it returns "unrecognized portal". If the portal is open, the Portal Handler checks to see if it has resources to record another protocol type for this portal. If not, it returns "no resources". If the Portal Handler has resources, it scans all portals to see if any of them have the protocol type enabled. If so, it returns "protocol type in use". If the protocol type is available, the Portal Handler checks to see if the portal's channel is on. If not, it returns "channel not on". If the channel is on, the Portal Handler puts the protocol type in the portal's list and returns "success". Disable-protocol When the user calls Disable-protocol, the Portal Handler checks to see if the supplied portal identification identifies an open portal. If not, it returns "unrecognized portal". If the portal is open, the Portal Handler checks to see if the protocol type is in the portal's list. If it is, the Portal Handler removes it. The Portal Handler then returns "success". Enable-multicast When the user calls Enable-multicast, the Portal Handler checks to see if the supplied portal identification identifies an open portal. If not, it returns "unrecognized portal". If the portal is open, the Portal Handler checks to see if it has resources to record another multicast address for this portal. If not, it returns "no resources". If the Portal Handler has resources, it checks to see if the portal's channel is on. If not, it returns "channel not on". If the channel is on, the Portal Handler puts the multicast address in the portal's list. If this is the first multicast address enabled, the Portal Handler calls the DNA Ethernet Data Link to enable multicast. The Portal Handler then returns "success". Operation Disable-multicast When the user calls Disable-multicast, the Portal Handler checks to see if the supplied portal identification identifies an open portal. If not, it returns "unrecognized portal". If the portal is open, the Portal Handler checks to see if the multicast address is in the portal's list. If it is, the Portal Handler removes it. If this was the only multicast address enabled, the Portal Handler calls the DNA Ethernet Data Link to disable multicast. The Portal Handler then returns "success". Close When the user calls Close, the Portal Handler checks to see if the supplied portal identification identifies an open portal. If not, it returns "unrecognized portal". If the portal is open, the Portal Handler checks to see if the portal's transmit and receive lists are empty. If they are not, it returns "Calls outstanding". If the portal's transmit and receive lists are empty, the Portal Handler releases all resources for the portal and returns "success". Transmit When the user calls Transmit, the Portal Handler checks to see if the supplied portal identification identifies an open portal. If not, it returns "unrecognized portal". If the portal is open, the Portal Handler checks to see if it has resources to queue a transmit for the portal. If it does not, it returns "no resources". If the Portal Handler has resources, it checks to see if the portal's channel is on. If it is not, it returns "channel not on". If the portal's channel is on, the Portal Handler transfers the information from the call into the portal's transmit list, marked "pending", for action by the Transmitter. The Portal Handler then returns "request accepted". Transmit-poll When the user calls Transmit-poll, the Portal Handler checks to see if the supplied portal identification identifies an open portal. If not, it returns "unrecognized portal". Operation If the portal is open, the Portal Handler checks the transmit list to see if it is empty. If so, it returns "none outstanding". If the transmit list is not empty, the Portal Handler checks to see if the first request state is "complete". If not, it returns "not complete". If the first request is complete, the Portal Handler gets the output parameters from the list for return. The Portal handler then deallocates the transmit list entry and returns the output parameters. Receive When the user calls Receive, the Portal Handler checks to see if the supplied portal identification identifies an open portal. If not, it returns "unrecognized portal". If the portal is open, the Portal Handler gets the portal's count of frames lost and zeros its own record of the count. The Portal Handler then checks to see if it has resources to queue a receive for the portal. If it does not, it returns "no resources" and the frames lost count. If the Portal Handler has resources, it checks to see if the portal's channel is on. If it is not, it returns "channel not on" and the frames lost count. If the portal's channel is on, the Portal Handler transfers the information from the call into the portal's receive list, marked "pending", for action by the Receiver. The Portal Handler then returns "request accepted" and the frames lost count. Receive-abort When the user calls Receive-abort, the Portal Handler checks to see if the supplied portal identification identifies an open portal. If not, it returns "unrecognized portal". If the portal is open, the Portal Handler checks the receive list to see if it is empty. If so, it returns "none outstanding". If the receive list is not empty, for each entry, the Portal Handler checks to see if the entry state is "complete". If not, it marks the request "complete", and sets the return code to "receive aborted". The Portal Handler then returns "success". Operation Receive-poll When the user calls Receive-poll, the Portal Handler checks to see if the supplied portal identification identifies an open portal. If not, it returns "unrecognized portal". If the portal is open, the Portal Handler checks the receive list to see if it is empty. If so, it returns "none outstanding". If the receive list is not empty, the Portal Handler checks to see if the first request state is "complete". If not, it returns "not complete". If the first request is complete, the Portal Handler gets the output parameters from the list for return. The Portal handler then deallocates the receive list entry and returns the output parameters. Transmitter and Receiver Transmitter The Transmitter constantly scans the the transmit lists for all open portals for the first pending request. Whenever it finds one marked "pending" it uses the information from that entry to send the frame. If the pad flag for the portal indicates that padding is enabled, the Transmitter prefixes the user's data with two bytes containing the length of the data as indicated by the user, low order byte first. If the resulting data is less than the Ethernet minimum, the Transmitter adds bytes of zeroes at the end of the user data to pad out to minimum length. The Transmitter then uses the DNA Ethernet Data Link to send the frame. When this request completes, the transmitter records the necessary completion information in the portal's transmit list entry and marks it "complete". The Transmitter then continues its scan with the next portal. Receiver This operational description assumes that Receiver operation is fast enough to receive all frames received by the DNA Ethernet Data Link. Implementations that are not fast enough will have to be able to record frames lost due to no buffer. This description also assumes the most complex form of protocol type matching. This is the form in which multiple users are allowed to receive promiscuously regardless of protocol types enabled by other users. The simpler cases are direct subsets of this case. Operation The Receiver has at least one Ethernet maximum size receive buffer of its own. The Receiver always tries to keep an Ethernet receive outstanding. When a frame is received, the Receiver scans the open portals for a matching receiver. It checks the protocol type list first. If it finds a match here it may then check the multicast address list. If no match in the protocol type list, it goes on to the next portal. A receiver matches if one of the following is true: . The protocol type matches and the frame destination is the physical address or the broadcast address. . The protocol type matches and the multicast destination is in the portal's multicast address list. . The portal protocol type list indicates promiscuous. If the Receiver finds a match it checks the portal's receive list for the first pending request. If it does not find one it increments the portal's frames lost count and the total user buffer unavailable count, then proceeds as if it had completed giving the frame to the portal. If the Receiver finds a pending receive, it copies the pertinent information into the portal's receive list according to the user's desires. For example it copies in a frame with invalid data (e.g. bad CRC) if the user requested this type of receive. If the pad flag is set, the Receiver uses the first two bytes of the data as the received length and copies that amount into the user's buffer, not including the first two bytes. If the actual length of the data in the frame is less than the amount indicated by the first two bytes, the Receiver gives the user all of the data, including the first two bytes, and sets a "length error" return code. The Receiver then marks the receive "complete". The Receiver repeats this procedure until it has checked all open portals. Counters This section defines exactly when the data link increments counters. All counters operate the same with respect to overflow. Whenever a counter reaches maximum value for its length it remains at that value until the counters are set to zero. This operation is assumed in all of the following descriptions of when counters are incremented. All counters are cleared simultaneously. Operation NOTE The names used in the Ethernet Version 2.0 specification are indicated in parentheses. A more formal description of their operation can be found in the Pascal procedural model found in that specification. . Seconds since last zeroed (not specified in Ethernet V2.0) This counter is incremented once every second. It allows the counters to be maintained for about 18 hours without being read. . Bytes received (not specified in Ethernet V2.0) This counter is updated every time a frame is received with no errors (framesReceivedNoErrors). It is incremented by the number of bytes in the Ethernet data field of the received frame (dataSize). . Bytes sent (not specified in Ethernet V2.0) This counter is updated every time a frame is transmitted with no errors (frameSentNoErrors). It is incremented by the number of bytes in the Ethernet data field of the transmitted frame (dataSize). . Frames received (framesReceivedNoErrors) This counter is incremented by one every time a frame is received with no errors. . Frames sent (framesSentNoErrors) This counter is incremented by one every time a frame is transmitted with no errors. . Multicast bytes received (not specified in Ethernet V2.0) This counter is updated every time a frame is received for a and address[1] = 1). It is incremented by the number of bytes in the Ethernet data field of the received frame (dataSize). . Multicast frames received (not specified in Ethernet V2.0) This counter is incremented by one every time a frame is received and address[1] = 1). . Frames sent, initially deferred (not specified in Ethernet V2.0) Operation This counter is incremented by one every time a frame is transmitted with no errors after being initially deferred. It does not get incremented if a deferral takes place on a subsequent attempt to transmit after a collision if the first attempt was not deferred. . Frames sent, single collision (transmitOkOneCollision) This counter is incremented by one every time a frame is transmitted with no errors after a single collision and backoff sequence; i.e., successful on the second attempt. . Frames sent, multiple collisions (transmitOkMultipleCollisions) This counter is incremented by one every time a frame is transmitted with no errors after more than one collision and backoff sequence; i.e., successful on the third or subsequent attempt. . Send failures (not specified in Ethernet V2.0) This counter is incremented by one every time an error causes the termination of the transmission of a frame. This may be due to one or more of the following faults occurring during a single Data Link TransmitFrame operation. A flag is set to indicate which type of fault(s) has occurred. (Ethernet V2.0 specifies two separate 16-bit counters for framesAbortedLateCollision and framesAbortedExcessCollisions.) Excessive collisions (excessiveCollisionError) Carrier check failed (carrierSenseFailed) Short circuit Open circuit Frame too long Remote failure to defer (lateCollision) . Collision detect check failures (collisionDetectFailed) This counter is incremented by one every time no collisionDetect signal is seen from the Physical Layer during a transmission or within 2 microseconds following the deassertion of carrierSense after the end of transmission. . Receive failures (not specified in Ethernet V2.0) This counter is incremented by one every time an error causes an incoming frame to be lost. This may be due to one or more of the following faults occurring during a single Data Link ReceiveFrame operation. A flag is set to indicate which type of fault(s) has occurred. (Ethernet V2.0 specifies two separate 16-bit counters for framesReceivedCRCErrors and framesReceivedAlignErrors) Block check error (frameCheckError) Framing error (alignmentError) Frame too long Operation . Unrecognized frame destinations (not specified in Ethernet V2.0) This counter is incremented by one every time a frame is received but discarded because there was no portal with the protocol type or multicast address enabled. . Data overruns (not specified in Ethernet V2.0) This counter is incremented by one every time an incoming frame is lost because the hardware was unable to keep up with the data rate. . System buffers unavailable (not specified in Ethernet V2.0) This counter is incremented by one every time a frame is received but discarded because there is no system buffer available. . User buffers unavailable (not specified in Ethernet V2.0) This counter is incremented by one every time a frame is received but discarded because there is no user buffer available. Events This section defines exactly when the data link records events. NOTE The names used in the Ethernet Version 2.0 specification are indicated in parentheses. A more formal description of their operation can be found in the Pascal procedural model found in that specification. . Initialization failed (not specified in Ethernet V2.0) This event is logged whenever the self test at initialization fails. The operation of the self test is implementation specific. . Send failed (not specified in Ethernet V2.0) This event is logged every time an error causes the termination of the transmission of a frame. This may be due to one or more of the following faults occurring during a single Data Link TransmitFrame operation. Excessive collisions (excessiveCollisionError) Carrier check failed (carrierSenseFailed) Short circuit Open circuit Operation Frame too long Remote failure to defer (lateCollision) . Collision detect check failed (collisionDetectFailed) This event is logged every time no collisionDetect signal is seen from the Physical Layer during a transmission or within 2 microseconds following the deassertion of carrierSense after the end of transmission. . Receive failed This event is logged every time an incoming frame is lost. This may be due to one or more of the following faults occurring during or immediately after a Data Link ReceiveFrame operation. Block check error (frameCheckError) Framing error (alignmentError) Data Overrun System buffer unavailable User buffer unavailable Unrecognized frame destination APPENDIX A PROTOCOL TYPES AND MULTICAST ADDRESSES This appendix lists all the protocol types and multicast addresses defined for Digital Equipment Corporation or across companies. DIGITAL protocol types are in the range 60-00 through 60-09. DIGITAL physical and multicast addresses are in the range AA-00-00-00-00-00 through AA-00-04-FF-FF-FF and AB-00-00-00-00-00 through AB-00-04-FF-FF-FF, respectively. CROSS-COMPANY ASSIGNMENTS The cross-company protocol type is: Value Meaning 90-00 Loopback The cross-company multicast addresses are: Value Meaning FF-FF-FF-FF-FF-FF Broadcast CF-00-00-00-00-00 Loopback Assistance DIGITAL ASSIGNMENTS The DIGITAL protocol types are: Value Meaning 60-00 60-01 DNA Dump/Load (MOP) 60-02 DNA Remote Console (MOP) 60-03 DNA Routing 60-04 Local Area Transport (LAT) 60-05 Diagnostics 60-06 Customer use 60-07 System Communication Architecture (SCA) PROTOCOL TYPES AND MULTICAST ADDRESSES DNA Phase IV nodes have addresses in the range AA-00-04-00-00-00 through AA-00-04-00-FF-FF (see DNA Routing Layer Functional Specification). The DIGITAL multicast addresses are: Value Meaning AB-00-00-01-00-00 DNA Dump/Load Assistance (MOP) AB-00-00-02-00-00 DNA Remote Console (MOP) AB-00-00-03-00-00 DNA Routing Layer routers AB-00-00-04-00-00 DNA Routing Layer end nodes AB-00-03-00-00-00 Local Area Transport (LAT) AB-00-04-00-00-00 thru AB-00-04-00-FF-FF Customer use AB-00-04-01-00-00 thru AB-00-04-01-FF-FF System Communication Architecture (SCA)