Digital PDFs

AA-Y298A-TK

December 1983

64 pages

Original

0.7MB

Document:	DECnet Digital Network Architecture Phase IV Ethernet Data Link Functional Specification
Order Number:	AA-Y298A-TK
Revision:	000
Pages:	64
Original Filename:	http://decnet.ipv7.net/docs/dundas/aa-y298a-tk.pdf

OCR Text

DECnet Digital Network Architecture
Phase IV
Ethernet Data Link Functional Specification
Order No. AA-Y298A-TK

December 1983
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.

SUPERSESSIONIUPDATE INFORMATION: This is a new manual.
VERSION:

1.O.O

To order additional copies of this document, contact your local
Digital Equipment Corporation Sales Office.

digital equipment corporation magnard, massachusetts

First Printing, December 1983

The information in this document is subject to change without notice and should not be construed as a
commitment by Digital Equipment Corporation. Digital Equipment Corporation assumes no responsibility
for any errors that may appear in this document.
The software described in this document is furnished under a license and may only be used or copied in
accordance with the terms of such license.
No responsibility is assumed for the use or reliability of software on equipment that is not supplied by
DIGITAL or its affiliated companies.

The postage-prepaid READER'S COMMENTS form on the last page of this document requests the user's
critical evaluation to assist us in preparing future documentation.

The following are trademarks of Digital Equipment Corporation:

DIGITAL
DEC
PDP
DECUS
UNIBUS
COMPUTER LABS
COMTEX
DDT
DECCOMM
ASSIST-11
VAX
DECnet
DATATRIEVE

DECsystem-10
DECtape
DIBOL
EDUSYSTEM
FLIP CHIP
FOCAL
INDAC
LAB-8
DECSYSTEM-20
RTS-8
VMS
IAS
TRAX

MASSBUS
OMNIBUS
OS/8
PHA
RSTS
RSX
TYPESET-8
TYPESET- 11
TMS-11
ms-10
SBI
PDT

Distributed Systems Publications typeset this manual using DIGITAL'S
TMS-11 Text Management System.
MGTPEALL

Page 3

Table of Contents
CONTENTS

....................
FUNCTIONAL DESCRIPTION . . . . . . . . . . . . . . . 6
Designscope . . . . . . . . . . . . . . . . . . . 6
Requirements . . . . . . . . . . . . . . . . . . 7
Goals . . . . . . . . . . . . . . . . . . . . . 7
Non-Goals . . . . . . . . . . . . . . . . . . . 7
MODELS . . . . . . . . . . . . . . . . . . . . . . . 8
Relationship to DIGITAL Network Architecture . . . 8
DNA Ethernet Data Link Model . . . . . . . . . . 10
Resource Naming . . . . . . . . . . . . . . . 11
DataLinkStates . . . . . . . . . . . . . . . 11
INTERFACES . . . . . . . . . . . . . . . . . . . . 13
User Interface . . . . . . . . . . . . . . . . . 13
Open . . . . . . . . . . . . . . . . . . . . . 15
~nable-promiscuous. . . . . . . . . . . . . . 16
Disable-promiscuous . . . . . . . . . . . . . 16
Enable-protocol . . . . . . . . . . . . . . . 17
Disable-protocol . . . . . . . . . . . . . . . 18
Enable-multicast . . . . . . . . . . . . . . . 18
isa able-multicast . . . . . . . . . . . . . . 19
Close . . . . . . . . . . . . . . . . . . . . 20
Transmit . . . . . . . . . . . . . . . . . . . 20
Transmit-poll . . . . . . . . . . . . . . . . 2 1
Receive . . . . . . . . . . . . . . . . . . . 22
Receive-poll . . . . . . . . . . . . . . . . . 23
Receive-abort . . . . . . . . . . . . . . . . 25
Network Management Interface . . . . . . . . . . 25
~ead-channel . . . . . . . . . . . . . . . . . 26
Read-portal-list . . . . . . . . . . . . . . . 27
Read-portal . . . . . . . . . . . . . . . . . 27
Reset . . . . . . . . . . . . . . . . . . . . 28
Set-address . . . . . . . . . . . . . . . . . 2 8
INTRODUCTION

. . . . . . . . . . . . . . . . 29
. . . . . . . . . . . . . . . 30
. . . . . . . . . . . . . . . . 30

Enable-channel
Disable-channel
Read-counters
Read.event
Ethernet Interfaces
Client to Data Link Interface
Network Management to Data Link Interface
Network Management to Physical Link Interface

. . . . . . . . . . . . . . . . . . 31
. . . . . . . . . . . . . . 32
. . . . . . . . 33
. . 34
34

.. .. .. .. .. .. .. .. .. .. 35
.
.
.
.
.
.
.
.
.
.
. . . . . . . . . . . . . . . . . . . . . 35
39
INTERFACE USAGE EXAMPLES . . . . . . . . . . . . . 43
Portal Filter Setup . . . . . . . . . . . . . . 43
Data Error Diagnostic . . . . . . . . . . . . . 4 3

NETWORK MANAGEMENT INFORMATION
Counters
Events

Table of Contents
7
7.1
7.1.1
7.1.2
7.1.3
7.1.4
7.1.5
7.1.6
7.1.7
7.1.8
7.1.9
7.1.10
7.1.11
7.1.12
7.1.13
7.2
7.2.1
7.2.2
7.2.3
7.2.4
APPENDIX A

Page 4

. . . .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 44
. . . . . . . . . . . . . . . . . . . . . 46
. . . . . . . . . . . . . . 46
47
. . . . . . . . . . . . . 47
. . . . . . . . . . . . . . . 48

OPERATION
Portal Handler
Open
Enable-promiscuous
Disable-promiscuous
Enable-protocol
Disable-protocol
Enable-multicast
Disable-multicast
Close
Transmit
Transmit-poll
Receive
Receive-abort
Receive-poll
Transmitter and Receiver
Transmitter
Receiver
Counters
Events

. . . . . . . . . . . . . . . 48
. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 48
. . . . . . . . . . . . . . . . . . . . 49
49
. . . .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 49
49
. . . .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 50
. . . . . . . . . . . . . . . . . 50
51
. . . . . . . . . . . . 51
.................
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 51
51

. . . . . . . . . . . . . . . . . . . . 52
55

PROTOCOL TYPES AND MULTICAST ADDRESSES

............
. . . . . . . . . . . . . . . A-1
A-1

CROSS-COMPANY ASSIGNMENTS
DIGITALASSIGNMENTS

Introduction
1

Page 5

INTRODUCTION

The Digital, Intel, Xerox intercompany Ethernet specification is the
basis for defining the DNA (DIGITAL Network ~rchitecture)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:
DNA Data Access Protocol (DAP) Functional
5.6.0, Order No. AA-K177A-TK
DNA

Specification, Version

a
Data
Communications
Message
Protocol
(DDCMP)
Functional Soecification, Version 4.1.0, Order No. AA-K175A-TK

DNA Ethernet Node Product Architecture
1.0.0, 0 r d a o . AA-X440A-TK

Specification, Version

DNA Maintenance Operations Functional
3.0.0, Order No. AA-X436A-TK

Specification,

DNA Network Management Functional
Order No. AA-X437A-TK

Specification, Version

DNA Network Services Protocol Functional
4.0.0, Order No. AA-X439A-TK

Version
4.0.0,

Specification, Version

DNA Routing Layer Functional Specification, Version
NO. AA-X435A-TK

2.0.0,

Order

DNA Session Control Functional Specification, Version 1.0.0, Order
NO. AA-K182A-TK

Introduction

Page 6

The Ethernet; a Local Area Network; Data Link Layer and Physical
Layer
~p~cifications,Version
Xerox), Order No. AA-K759B-TK

2 . 0 7 ~ 1 g i t a 1 , Intel,

and

The DECnet DIGITAL Network Architecture (Phase IV) General Description
(Order No.
AA-N149A-TC)
provides an overview of the network
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
- - the data communication services that DNA Ethernet Data
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 -- the control and observation services
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.

2.1

Design Scope

The DNA Ethernet Data Link requires certain characteristics to be
present, attempts to meet certain goals, and lacks some features that

Page 7

Functional Description
are not within the scope of the design.

2.1.1

Requirements

The DNA Ethernet
characteristics:

Data

Link

design

must

have

. All capabilities included in the Ethernet

the

following

Specification

are

available from the DNA Ethernet Data Link.

. The network manager can control and observe the data

link

it functions.

. It complies with the Ethernet Specification.
2.1.2

Goals

The DNA Ethernet Data Link
characteristics:

design

attempts

have

the

following

. 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.
2.1.3

Non-Goals

DNA Ethernet Data Link design does not attempt to have

the

following

in
the
want to

Ethernet
implement

characteristics:

. Addition of

functions
not
included
specification
that higher layers may
differently (such as reliable delivery).

. Self-diagnosis of all data link problems.

Diagnosis
problems requires information from higher layers.

some

Models
3

Page 8

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.

3.1

Relationship to DIGITAL Network Architecture

Figure 1 shows the relationship of the DNA Ethernet Data Link
DNA hierarchy.

the

Mode 1s

Page 9

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. The highest layer, the User layer supports user
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. The Network Management layer is the
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 parametersand counters. These
modules also perform up-line dumping, down-line loading, and
testing functions.
Network Application layer. Modules in the Network Application
layer support network functions, such as remote file access
and file transfer, used by the User and Network Management
layers.
Session Control layer.
The Session Control defines the
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

Page 10

End Communication layer. The End Communication layer defines
the system-independent aspects of logical link communication.

Routing layer. Modules in the Routing layer route messages,
called packets, between source and destination nodes.

Data Link layer. The Data Link layer defines the protocol
concerning data integrity and physical channel management.

Physical Link layer. The Physical Link layer encompasses a
part of the device driver for each communications device plus
the communications hardware itself.
The hardware includes
interface devices, modems, and the communication lines.

3.2

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.

Channel 1
/

I
Channel 2
I

E T H E R N E T

\
... Channel
m

D a t a

L i n k

DNA
Ethernet
Data
Link

Models
3.2.1

Page 11
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.

. A channel is a particular Ethernet hardware connection.

Each

channel has one name and each name identifies one channel.

. A portal represents a particular user's data base needed by

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
I t also
enabled protocol types and multicast addresses.
contains the lists of outstanding transmits and receives for
the user.

3.2.2

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 -- the channel is not available.
. Init -- the channel is being initialized and tested by
data
link.
self-test.

This

test

the
implementation dependent

. On -- the channel is available for use.
. Broken
-- an attempt was made to turn the channel on, but it
failed the initialization test, or the channel was on but the
data link determined that
initialization test.

the

channel

would

now

fail

the

Changes between these states do not affect counters or parameters such
as the node's physical address.

Mode 1 s

Page 12

The following diagram shows the data
channel :

.....................
I
++++
I
v
v +
I
------------.-- I
1 <--- I
I
I
1 +++

I o f f I
I init I * * * > on I +
->I
1 +++> 1
I
I
1 <++
- - _ _
1
- - - - I
---- I

*
*
I
*
I
+ v
-------*
I
------ I broken I < * * * * *

*
+ *

--------

link

state

transitions

for a

Key:

--- Management Disable
+++

Management Enable

*** Data Link Operation

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
I f this succeeds, the data link changes the state to
the channel.
'on". If initialization and test fail, the data link changes the
state to "broken".
From the "broken" state,
initialization again with
disable command.

network
management
can
either
try
an enable command or go to "off" with a

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
management disable command.

"off"

from

any

state

network

Interfaces
4

Page 13

INTERFACES

The following sections describe the interfaces provided
Ethernet Data Link. They are the following:

DNA

. User
Interface -- contains the functions to transmit and receive
data between data links.
. Network Management

Interface -- contains the
observation functions for the local data link.

control

and

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
functions from the intercompany Ethernet specification.

4.1

interface

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.

Page 14

Interfaces
The interface contains the following functions:
Open -- open a portal.
Enable-promiscuous -- enable all
addresses for a portal.

protocol

types

and

multicast

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
A frame that does not pass filtering is
by multicast address.
discarded. In actual practice, an implementation may first filter in
hardware the union of the multicast addresses for all portals and then

Page 15

Interfaces
do the filtering again on a reduced number of frames.

4.1.1

Open

The open function opens a portal so that the
receive frames.

user

can

transmit

and

Inputs:
Channel-id - the unique identification of the Ethernet hardware on
which the portal is to be opened.
Pad - a user flag that indicates whether the data link is to pad
frames that are under minimum length.
Padding is
accomplished via data link generated additions to user
It is the responsibility of the user's protocol
data.
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 - the status of the request.

One of:

Success - a portal was opened.
No resources - the DNA Ethernet Data Link does
have sufficient resources to open a portal.

not

Unrecognized channel - there is no channel with the
specified identification.
Channel not on - a portal cannot be opened
the channel state is not "on".

because

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 - a portal identification to be used in the
interface functions.

other

user

Interfaces

Page 16

The Enable-promiscuous function indicates that the portal is to
receive all frames regardless of protocol type or multicast address.
I f 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:
1.

Not implemented.

The function fails.

Exclusive use only. The function fails if any other portal is
open or if this portal has any protocol types or multicast
addresses enabled.

Non-exclusive use. The function always succeeds.
Any frames
that would have been delivered to another portal are duplicated
and delivered to this one also. This is in addition to all other
frames.

Inputs:
Portal-id - a portal identification assigned by the Open function.
outputs:
Return-code - the status of the request.

One of:

Success - promiscuous receive enabled.
Not implemented - the implementation
support the requested function.

does

not

Non-exclusive - the implementation allows only
exclusive promiscuous receipt and this portal or
some other portal has a.protoco1 type or multicast
address enabled.
Unrecognized portal - there is no open portal
the specified identification.

with

Channel not on - the function
channex state is not "on".

the

The Disable-promiscuous function
longer to receive frames for
addresses.

failed

indicates that the
all protocol types

because

portal is no
and multicast

Interfaces

Page 17

Inputs:
Portal-id - a portal identification assigned by the Open function.
Protocol-type - a protocol type that is to be recognized for
portal.

this

outputs:
Return-code - the status of the request.

One of:

Success - promiscuous receive is
the portal.

not

enabled

for

Unrecognized portal - there is no open portal
the specified identification.

with

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.

Inputs:
Portal-id - a portal identification assigned by the Open function.
Protocol-type - a protocol type that is to be recognized for
portal.

this

outputs:
Return-code - the status of the request.

One of:

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
the specified identification.

with

Interfaces

Page 18
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
channel state is not "on".

failed

because

The Disable-protocol function indicates that the portal is
to receive frames for a protocol type.

the

longer

Inputs:
Portal-id - a portal identification assigned by the Open function.
Protocol-type - a protocol type that is no longer to be recognized
for this portal.
outputs:
Return-code - the status of the request.

One of:

Success - the protocol type is not enabled for
portal.

the

Unrecognized portal - there is no open portal
the specified identification.

with

The Enable-multicast function adds a multicast address to the list
those that the portal wishes to receive.

Portal-id - a portal identification assigned by the Open function.
Multicast-address - a multicast address that is to
for this portal.

recognized

Page 19

Interfaces
outputs:
Return-code - the status of the request.

One of:

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
the specified identification.

with

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
channel state is not "on".

The Disable-multicast indicates that the
receive frames for a multicast address.

portal

failed

because

longer

the

Inputs:
Portal-id - a portal identification assigned by the Open function.
~ulticast-address- a multicast address that is no
recognized for this portal.

longer

Success - the multicast address is not enabled
the portal.

for

Unrecognized portal - there is no open portal
the specified identification.

with

outputs:
Return-code - the status of the request.

One of:

Interfaces
4.1.8

Page 20

The Close function closes an open portal and releases all its
A portal cannot be closed unless all outstanding transmit
resources.
or receive requests are completed.
CLOSE(PO~~~~-id,Return-code)

Inputs:
Portal-id - a portal identification assigned by the Open function.
Outputs:
Return-code - the status of the request.

One of:

Success - the portal is closed.
Unrecognized portal - there is no open portal
the specified identification.

with

Calls outstanding - there are uncompleted transmit
or receive requests outstanding on the portal.

4.1.9

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
allowed by the implementation.

Transmits,

the

limit

NOTE
Ethernet does not guarantee attempted delivery of
fewer than 46 mbytes or more than 1500 bytes of user
may
attempt
data.
The DNA Ethernet Data Link
transmission, but the result is unspecified.

Inputs:
Portal-id - a portal identification assigned by the Open function.
This
Destination-address - the address of the frame destination.
can be either a physical address or a multicast
address. As a matter of good citizenship, users should

Interfaces

Page 21
not transmit to the broadcast address unless the
message is intended for all systems, regardless of
their function or manufacturer.

Protocol-type - identifies the protocol at the receiving system.
Input-buffer - a buffer containing the data to be sent.
If the
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 ~ransmit-poll), the user must
not disturb the contents of the buffer.
CRC-32 -

caller- and implementation-optional 32-bit cyclic
redundancy code that is to be used for this frame.
This overrides the one normally supplied by the data
link.

Outputs:
Return-code - the status of the request.

One of:

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
the specified identification.

with

Channel not on - the function
channel state is not "on".

the

failed because

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

Page 22

Inputs:
Portal-id - a portal identification assigned by the Open function.
Outputs:
Return-code - the transmit request for this portal.
Not complete - no
portal is done.

outstanding

None outstanding - there
transmits for this portal.

One of:

transmit

are

for

this

outstanding

Transmit successful - a frame successfully left the
local transmitter.
Transmit failed - the local transmitter
transmit the frame.

could

not

Unrecognized portal - there is no open portal
the specified identification.

with

Channel left "on" state - the function failed
because the channel is no longer in the "on" state.
Input-buffer - the buffer
function.

that

was

supplied

the

Transmit

Error-detail - the caller-optional reason for a return-code of
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 - the caller-optional distance in bit times to a
short or open circuit. This is meaningful only when
error-detail is "short circuit" or "open circuitn.

4.1.11

Receive

The Receive function queues a buffer to receive a frame.

Page 23

Interfaces
Inputs:

Portal-id - a portal identification assigned by the Open function.
Receive-bad - a caller- and implementation-optional indication
that frames are to be returned even though they contain
invalid data, This includes frames with CRC or framing
errors.
Output-buffer - a descriptor of a buffer to contain
frame.

the

received

outputs:
Return-code - the status of the request.

One of:

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
the specified identification.

with

Channel not on - the function
channel state is not "on".

the

failed

because

Frames-lost - the caller-optional count of the number of frames
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.

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.

Interfaces

Page 24

Inputs:
Portal-id - a portal identification assigned by the Open function.
outputs:
Return-code - the status of the receive request.
Not complete - no
portal is done.

outstanding

None outstanding - there
receives for this portal.
Receive successful - a
received into the buffer.

One of:
receive

are

frame was

for

this

outstanding
successfu~~y

Receive with overrun - a frame was successfully
receivedI but had to be truncated to f i t into the
buffer.
Length error - the received frame length was
inconsistent
with the length recorded by the
padding conventions. The buffer contains the data
receivedI 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 o f
bad frames.
Receive aborted - the user cancelled the
request with the Receive-abort function.

receive

Unrecognized portal - there is no open portal
the specified identification.

with

Channel left .bb "on'' state - the function failed
because the channel is no longer in the "on" state.
Error-detail - the caller-optional reason for a return-code of
"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 - the address to which the received frame
addressed.

was

Source-address - the address of the system
received frame.

the

that

transmitted

Page 25

Interfaces
Protocol-type - the protocol type from the received frame.
Output-buffer - the received data.

Bytes-lost - the number of bytes lost when the return-code is
"receive with overrun". This argument is optional both
for user and implementor. I f it is applicable but not
implemented, it returns a value of "not implemented".
CRC-32 - the caller-optional 32-bit cyclic redundancy
came into the data link with the frame.

code

that

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.

Inputs:
Portal-id - a portal identification assigned by the Open function.
outputs:
Return-code - the status of the request.

One of:

Success - the request is now complete.
Unrecognized portal - there is no open portal
the specified identification.
None outstanding - there
receives for this portal.

4.2

are

with

outstanding

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

Page 26

. 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.
The Read-channel function
specified channel.

reads

status

information

relative

Inputs:
-Channel-id - the unique identification of
status is to be read.

channel

for

which

outputs:
Return-code - the status of the request.

One of:

Success - status successfully read.
Unrecognized channel - there is no channel with th.e
specified identification.

Physical-address - the physical address of
set".
This is the address
currently using.

the channel or "not
that the channel is

Hardware-address - the hardware address of the channel or "not
available1'. This is the address associated with the
channel hardware.
State - the channel state as described earlier, one of:
On
Off
Init
Broken
Broken-code -

implementation-specific value

indicating

the

Page 27

Interfaces
reason the state is "broken".

4.2.2

Read-portal-list

The Read-portal-list
ident if icai ions.

function

reads

the

list

open

portal

Inputs:
Channel-id - the unique identification of a channel for which
open portal list is to be read.

the

Buffer - a buffer to contain the list of portals.
outputs:
Return-code - the status of the request.

One of:

Success - list successfully read.
Buffer too small - the buffer could not hold the
entire list. Portal identifications that would not
f i t in the buffer are not returned.
Unrecognized channel - there is no channel with the
specified identification.
descriptor of buffer
identifications.

containing

list

The Read-portal function reads portal
portal.

d,ata base

information

Buffer

portal

for

READ-PORTAL(Porta1-idIBufferI~eturn-code)

Inputs:
Portal-id - the portal identification of the open portal for which
the data base is to be read.
Buffer - descriptor of a buffer to contain the
information.

portal

data

base

Interfaces

Page 28

Outputs:
Return-code - the status of the request.

One of:

Success - portal data base successfully read.
Buffer too small - the buffer could not hold all
the information. Information that would not f i t in
the buffer is not returned.
Unrecognized channel - there is no channel with the
specified identification.
Buffer - descriptor of a buffer containing the portal data base
informat ion.
Each
parameter
entry contains the
following information:
Parameter-type the
identification of
particular
portal
data
base parameter.
parameters are listed in the Portal Data
operation section.

the
The
Base

Value - the parameter value.

4.2.4

Reset

The Reset function returns the specified channel to initial state.
The physical address is unset. The counters are zeroed. ~ l portals
l
are closed. The channel state is "off".

Inputs:
Channel-id - the unique identification of the channel that
be reset.

Outputs:
Return-code - the status of the request.

One of:

Success - channel reset.
Unrecognized channel - there is no channel with the
specified identification.

The Set-address function sets the physical address of the specified
channel.
This is the address recognized as specific destination in

Page 29

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.

Inputs:
Channel-id - the unique identification of the channel for which
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 - the address to set.
Outputs:
Return-code - the status of the request.

One of:

Success - the address was successfully set.
Unrecognized channel - there is no channel with the
specified identification.
Channel not off - the function failed because
channel state is not "off".

the

The Enable-channel function attempts to put the channel into
where it can be used.

Enabling the
variables.

counter

channel

does

not

disturb

the

contents

state

Inputs:
Channel-id - the unique
enabled.

identification of

the

channel

Outputs:
Return-code - the status of the request.

One of:

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

Page 30
Read-channel function.
Address not set - the physical
channel has not been set.

address

for

the

Unrecognized channel - there is no channel with the
specified identification.

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.

Inputs:
Channel-id - the unique
disabled.

identification of

the

channel

Outputs:
Return-code - the status of the request.

One of:

Success - channel is disabled.
Unrecognized channel - there is no channel with the
specified identification.

The Read-counters function reads and optionally sets all
associated with the specified channel or portal to zero.

counters

Inputs:
Entity-id - the unique identification of the particular channel or
portal for which counters are to be read.
Operation

the

data

link

performs

one

the

following

Page 31

Interfaces
operations:
Read - only read the counters.
Read-and-zero - read the counters and set
zero.

them

Buffer - descriptor of a buffer to receive the counters.
Outputs:
Return-code - the status of the request.
Success - counters
requested).

read

One of:
(and set

zero

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.
I f read-and-zero was requested, all the counters
are set to zero even if their values were not
returned.
Each
Buffer - descriptor of buffer containing counters.
entry contains the following information:

counter

Counter-type - the identification of the particular
counter.
The counters are listed in the Network
Management Information section.
Value - the counter value.
reasons
the
counter
was
Causes - specific
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.

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.

Interfaces

Page 32

Inputs:
Channel-id - the unique identification of the channel for which an
event is to be read.
Buffer - descriptor of a buffer to receive the event.
Outputs:
Return-code - the status of the request.

One of:

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 - the number of events that were lost since
Read-event.
Buffer

descriptor of buffer containing event.
includes the following information:

the

last

The

event

The
Event-type - the identification of the event.
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
parameter.

the

identification of

the

Value - the value of the parameter.

4.3

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,
This section only contains those functions that relate
Version 2.0.
directly to the operation of the DpA 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

Page 33

Most of the Ethernet interface functions return a status as the
of the function.

4.3.1

value

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. I t contains the following
functions:

. TransmitFrame - send a frame.
. ReceiveFrame - receive a frame.
4.3.1.1

TransmitFrame

TransmitFrame sends a frame.
either succeeds or fails.

I t does not return

until

the

transmit

TransmitFrame (destinationParam,sourceParam,typeParam,dataParam)
Inputs:
destinationparam - address of the destination system.
sourceparam - physical address of the local system.
typeparam - protocol type for the frame.
dataparam - data to go in the frame.
Outputs:
TransmitFrame - the status of the operation.

One of:

transmitOK - frame successfully transmitted.
excessiveCollisionError - transmission failed.

4.3.1.2

ReceiveFrame

ReceiveFrame receives a frame.
received.

It does not return until

frame

ReceiveFrame (destination~aram,sourceParam,typeParam,data~aram)

Page 34

Interfaces
Inputs:

none.

Outputs:
ReceiveFrame - the status of the operation.

One of:

receiveOK - frame successfully received.
frameCheckError - frame block check failed.
alignmentError - frame did not contain an
number of bytes.

integral

destinationparam - address of the destination system.
sourceparam - physical address of the remote system.
typeparam - protocol type from the frame.
dataparam - data from the frame.

4.3.2

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.

. TransmitFrame.
ReadNumberCollisions - read the number of collisions for the last
. DataLinkOn - start data link operation.
,

DataLinkOff - stop data link operation.

. promiscuous.
SetAddressMode - changes addressing mode between normal and
. Multicaston - enable reception of multicast addresses.
. Multicastoff - disable reception of multicast addresses.
4.3.3

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
It contains the
control access to the Ethernet Physical Link.
following function:

Page 35

Interfaces
checks status of last TransmitFrame.

5
I

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.

5.1

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
counters:
Length

bit

lengths

Name
Seconds since last zeroed
Bytes received
Bytes sent
Frames received
Frames sent
Multicast bytes received
Multicast frames received
Frames sent, initially deferred
Frames sent, single collision
Frames sent, multiple c,ollisions
Send failure *
Collision detect check failure
Receive failure *
Unrecognized frame destination
Data overrun
System buffer unavailable
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

all

the

Page 36

Network Management Infromation
Frames sent
User buffer unavailable

. Seconds since last zeroed
The number of seconds since the counters were last
length is 16 bits.

zeroed.

The

Provides a frame of reference for the
indicating the amount of time they cover.

counters

other

. 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
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 sqccessfully transmitted.
This does
not include data link generated retransmissions. The length is
32 bits.

Network Management Infromation

Page 37

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.
length is 32 bits.

The

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,
contention with no collisions.

measures

Ethernet

. 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
the above three counters.

than

one

. 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
meanings and use can be found in the section on events.

their

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
sensed after a transmission. The length is 16 bits.

was

not

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
This
multicast address comparison.
The length is 16 bits.
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
meaning and use can be found in the section on events.
Block check error
Framing error
Frame too long

their

Network Management Infromation

Page 39

. 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
because it was unable to keep up with the data rate.

frame

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
incoming frame. The length is 16 bits.

for

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.

5.2

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

Page 40
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
collisions.

retransmissions due

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
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

Page 41

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
remote system began
window for collisions.

the

allowed

This indicates either a problem with some other
carrier sense or a weak transmitter locally.

system's

transmitting

after

. 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
cable collision circuitry.

transceiver

. 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

Page 42

Framing error
The frame did not contain an integral
bytes.

number

bit

I t can be
This indicates several possible failures.
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
buffers or CPU time.

example,

insufficient

hardware

System buffer unavailable
The frame was discarded because
buffer available to receive it.

there

was

system

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
available to receive it.

buffer

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
Ethernet maximum length and could not be received.

the

Network Management Infromation
This indicates that a remote system
length frames.

6
i

Page 43
is

sending

invalid

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.

6.1

Portal Filter Setup

This example opens a portal and sets up its receive filter criteria.
The portal wishes to receive frames of protocol types PI and P2 that
are addressed to the physical address and multicast address Ml.
Open(Channe1-id,Return-code,Portal-id)
IF Return-code = "success1'
~nable-protocol(Porta1-id,PI,Return-code)
IF Return-code = "suc~ess'~
Enable-protocol(Porta1-idfP2,Return-code)
IF Return-code = "suc~ess'~
~nable-multicast(Porta1-id,Ml,Return-code)
ENDIF
ENDIF
END I F
IF Return-code = "success11
{use the data link]
~lose(~orta1-id,Return-code)
ELSE
{Handle error]
ENDIF

6.2

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. I t 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.

Operat ion
7

Page 44

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
diagram:

the

following

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
shared data bases correct.

exclusion

The Portal Data Base contains an entry for each
entry contains:

necessary
open

keep

portal.

Each

Operat ion

Page 45

. 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. I f
not user-supplied, the DNA Ethernet Data Link will supply
it.

Error detail returned by the
and desired by the user.

Transmitter

applicable

Fault distance returned by the Transmitter if
and desired by the user.

applicable

. 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
desired by the user.

Destination address returned from the received
the Receiver.

applicable
frame

and
by

Page 46

Operat ion

7.1

Source address returned from the received
Receiver.

frame

the

Protocol type returned from the
Receiver.

frame

the

Bytes lost returned by the
desired by the user.

applicable

and

CRC-32 returned from the received frame by
if desired by the user.

received

Receiver

the

Receiver

Portal Handler

This section describes Portal Handler operation relative to the
Interface functions. The Portal Handler functions are:

User

Open
~nable-promiscuous
is able-promiscuous
Enable-protocol
Disable-protocol
Enable-multicast

isa able-multicast
Close
Transmit
Transmit-poll
Receive
Receive-abort
Receive-poll

7.1.1

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 llpromiscuousreceiver active"

If there is no promiscuous receiver problem, the Portal Handler
checks that it has the necessary resources to open a new portal. I f
not, it returns "no resources".

I f 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
If not, it returns "channel not onn.

on.

Operat ion

Page 47

I f 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.

When the user calls Enable-promiscuous, the Portal Handler checks to
see if the supplied portal identification identifies an open portal.
I f not, it returns "unrecognized portal".
I f 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. I f this
Otherwise it puts
fails, it returns "channel in wrong state".
'promiscuous" in the portal's list of enabled protocol types and
returns "success''.

When the user calls Disable-promiscuous, the Portal Handler checks to
see if the supplied portal identification identifies an open portal.
I f not, it returns "unrecognized portal".
I f the portal is open, the Portal Handler checks the portal's list of
I f not found, it returns
protocol
types
for "promiscuous".
success".
I f 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".

Page 48

Operat ion

When the user calls Enable-protocol, the Portal Handler checks to see
if the supplied portal identification identifies an open portal. I f
not, it returns "unrecognized portal".
I f 'the portal is open, the Portal Handler checks to see if
resources to record another protocol type for this portal.
it returns "no resources".

it has
I f not,

I f the Portal Handler has resources, it scans all portals to see i f
any of them have the protocol type enabled. I f so, it returns
"protocol type in use".

I f the protocol type is available, the Portal Handler checks to see
if the portal's channel is on. I f not, it returns "channel not on".

If the channel is on, the Portal Handler puts the
the portal's list and returns "success".

protocol

type

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".

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
portaln.
I
If the portal is open, tihe Portal Handler checks to see if it has
resources to record another multicast address for this portal. I f
not, it returns "no resources".
If the Portal Handler has resources, it checks to see if the portal's
channel is on. I f 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".

Operat ion

Page 49

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 portalw.
1

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".

7.1.8

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".
I f 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 "suc~ess'~.

7.1.9

Transmit

When the user calls Transmit, the Portal Handler checksto see i f 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. I f it does not, i,t
returns "no resources".
I f the Portal Handler has resources, it checks to see i f the portal's
channel is on. If it is not, it returns "channel not onw.

If the portal's channel is on, the Portal Handler transfers the
information from the call into the portal's transmit list, marked
"pendingw, for action by the Transmitter. The Portal Handler then
returns "request accepted".

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".

Operat ion

Page 50

If the portal is open, the Portal Handler checks the transmit list to
see if it is empty. If so, it returns "none outstanding".
I f 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.

7.1.11

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
If it is not, it returns "channel not on" and the
channel is on.
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.

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
see if it is empty. If so, it returns "none outstandingw.

If the receive list is not empty, for each entry, the Portal Handler
checks to see if the entry state is "completen. If not, it marks the
request "complete", and sets the return code to "receive aborted".
The Portal Handler then returns "successn.

Operat ion

Page 51

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".
I

If the portal is open, the Portal Handler checks the receive list
see if it is empty. If so, it returns "none outstanding".

I f the receive list is not empty, the Portal Handler checks to see i f
If not, it returns "not
the first request state is "complete".
complete".

I f 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.

7.2
7.2.1

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.
I f 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.
I f 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
The Transmitter then continues its scan
and marks it "complete".
with the next portal.

7.2.2

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.

Operat ion

Page 52

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

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.
I f the Receiver finds a match it checks the portal's receive list for
the first pending request. I f 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
portals.

7.2.3

has

checked

all

open

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.

Page 53

Operat ion
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)
I t allows the
This counter is incremented once every second.
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). I t is incremented by the number
of bytes in t h e 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 (frames~eceivedNoErrors)
This counter is incremented by one every time a frame is received
with no errors.

. Frames sent (framesSentNoErrors)
This counter is incremented
transmitted with no errors.

one

every

time

frame

. Multicast bytes received (not specified in Ethernet V2.0)
This counter is updated every time a frame is received for a
multicast address with no errors (framesReceivedNoError and
address[l] = 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 ~ 2 . 0 )
This counter is incremented by one every time a frame is received
for a multicast address with no errors (framesReceivedNoError and
addressCl1 = 1).

. Frames sent, initially deferred (not specified in Ethernet ~ 2 . 0 )

Operat ion

Page 54

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 ( t r a n s m i t ~ k ~ u l t i p l e ~ o l l i s i o n s )
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
A flag is set to indicate
Data Link TransmitFrame operation.
which type of fault(s) has occurred.
(Ethernet V2.0 specifies
two separate 16-bit counters for frames~bortedLateCollision 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 framesReceived~lignErrors)
Block check error (frameCheckError)
Framing error (alignmentError)
Frame too long

Operat ion

Page 55

. 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 ~ 2 . 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.

7.2.4

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
fails.
The operation of the
specific.

self
self

test
test

at
is

initialization
implementation

. 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 (excessive~ollision~rror)
Carrier check failed (carriersense~ailed)
Short circuit
Open circuit

Operat ion

Page 56

Frame too long
Remote failure to defer (latecollision)

. Collision detect check failed (collisionDetect~ailed)
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.

A.1

CROSS-COMPANY ASSIGNMENTS

The cross-company protocol type is:
Value
90-00

Meaning
Loopback

The cross-company multicast addresses are:
Value
FF-FF-FF-FF-FF-FF
CF-00-00-00-00-00

A.2

Meaning
Broadcast
Loopback Assistance

DIGITAL ASSIGNMENTS

The DIGITAL protocol types are:
Value
60-00
60-01
60-02
60-03
60-04
60-05
60-06
60-07

Meaning
DNA Dump/Load (MOP)
DNA Remote Console (MOP)
DNA Routing
Local Area Transport (LAT)
Diagnostics
Customer use
System Communication Architecture (SCA)

PROTOCOL TYPES AND MULTICAST ADDRESSES
DNA Phase IV nodes have addresses
through
AA-00-04-00-FF-FF
(see
Specification).

in the range
DNA
Routing

Page A-2
AA-00-04-00-00-00
Layer Functional

The DIGITAL multicast addresses are:
Meaning
Value
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 ( S C A )

DECnet Digital Network Architecture Phase IV
Ethernet Data Link Functional Specification
AA-Y298A-TK

READER'S COMMENTS
NOTE: This form is for document comments only. DIGITAL will use comments submitted on this form at the
company's discretion. If you require a written reply and are eligible t o receive one under Software
Performance Report (SPR) service, submit your comments on an SPR form.

Did you find this manual understandable, usable, and well-organized? Please make suggestions for improvement.

Did you find errors in this manual? If so, specify the error and the page number

Please indicate the type of userlreader that you most nearly represent,
D

0
Name

Assembly language programmer
Higher-level language programmer
Occasional programmer (experienced)
User with little programming experience
Student programmer
Other (please specify)

Date

Organization
Street
City

State

Zip Code
or
Country

- - -Do Not Tear - Fold Here and Tape - - - - - - - - - - - - - - - - - - - - - - I

Necessary

1 BUSINESS REPLY MAIL 1
I

FIRST CLASS PERMIT N O 3 3 MAYNARD MASS.
POSTAGE WILL BE PAID BY ADDRESSEE

-I

-1
SOFTWARE DOCUMENTATION
1925 ANDOVER STREET TW/E07
TEWKSBURY, MASSACHUSETTS 01876

-1

I
I

- - Do Not Tear - Fold Here and Tape - - - - - - - - - - - - - - - - - -7