Digital PDFs

AA-Y298A-TK

December 1983

64 pages

Original

14MB

view download

OCR Version

4.4MB

view download

Document:	DECnet Digital Network Architecture Phase IV Ethernet Data Link Functional Specification
Order Number:	AA-Y298A-TK
Revision:	0
Pages:	64
Original Filename:

OCR Text

440I(S;

i
b

]

DECnet Drgutal Network Architecture
Phase IV
Ethernet Data Link Functlonal Speclfication
Order No. AA-Y298A-TK
|

December 1983

This document describes the structure, functiohs, interfaces, and protocols of the DNA Ethernet Data Link not defined in the Ethernet Specification that make it compatible with DNA.

SUPERSESSION/UPDATE INFORMATION: This is a new manual.
VERSION:

1.0.0

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

digital equipment corpordtien . maynard, massachusetts

First Printing, December 1983

'The information in this documentis subject to change without notice and should not be construed as a
commitment by Digital Equlpment Corporation. D1g1tal Equipment Corporation assumes no responsibility
for any errors that may appear in this document.

The software descrlbedin this documentis furnished under a license and may only be used or copledin
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

UNIBUS

COMPUTER LABS
COMTEX

MASSBUS

OMNIBUS
0S/8

DIBOL

DECUS

DECsystem-10
DECtape

EDUSYSTEM

PHA

FLIP CHIP

RSTS

FOCAL

RSX

INDAC

TYPESET-8

DDT

LAB-8

TYPESET-11

DECCOMM

DECSYSTEM-20

TMS-11

ASSIST-11

RTS-8

ITPS-10

VAX

VMS

SBI

DECnet

IAS

PDT

DATATRIEVE

TRAX

Dlstrlbuted Systems Publications typeset thls manual usmg DIGITAL’
TMS-11 Text Management System.

MGTPEALL

Table of Contents

Page 3

CONTENTS

INTRODUCTION .

2
2.1
.
2.1.1
2.1.2
2.1.3

FUNCTIONAL DESCRIPTION
Design Scope . .
c
Requirements . . .«
GOoals
& ¢ ¢ 4 et
Non-Goals
. ¢ ¢ o

3
3.1
3,2
3.2.1
3.2.2

MODELS . .
|
|
Relatlonshlp to DIGITAL Network Archltecture
DNA Ethernet Data Link Model . . . . . . . .
Resource Naming
. .« « « ¢ o« « o« o o o o o«
Data Link States . . ¢ v ¢« « ¢« ¢ o o« o o o

.
.
.
«
«

.
.
.
«
o

INTERFACES

4.,1.1
4,.1.2
4.1.3
4,1.4
4.1.5
4.1.6
4.1.7
4.1.8
4.1.9
4,1.10
4.1.11
4,1.12
4,1.13
4.2
4.2.1
4.2.2
4.2.3
4.,2.4
4.2.5
4.2.6
4.2.7
4.2.8
4.2.9
4.3
4.3.1
4,.3.2
4.3.3

4.1

5.1
5.2

6.1
6.2

¢«

User Interface

& «

o o

.
e
«
e
o

« ¢«
e e
« «
e e
¢ o

¢ o
e e
o o
e e
o o

¢
«
e
e
o

o o
e«
e e
e e
o o

o
e
e
e
o

o
e

e
o

o« o« o

o«

e
o

o«

&5
.
.
.

6
6
7
7
7

.
.

8
8
10
11
11
13

Open . . .
e e+ s e e e e e e o e e &« « «
15
Enableprom1scucus e
Disable-promisSCuoOuUS
. « « « o« « o o o « « o« o«
16
Enable-protocol
. . . . + ¢ ¢« ¢ ¢ o oo o o o
17
Disable-protocol . . . «. « « « « « « « « « « o«
18
Enable-multicast. « « ¢« +« « « « o« « « « « « o
18
Disable-multicast
. « ¢« « « ¢ ¢«« « o« « « o« o 18
ClOSE
v v v v ¢ o o o o o &« o o« o o« o o o« o«
20
Transmit « « o« ¢ o « o o o o o o« o o« o o« « o« «
20
Transmit-poll
. . ¢ ¢« ¢« ¢ ¢ ¢ o o oo o« o« o o
21
ReCeIVEe
v v v v ¢ e v ¢ o o 4 o 4 e e 4 e e .
22
Receive-poll . . ¢« ¢« ¢« ¢« ¢ o o o o 6 o o o o o
23
Receive-abort . .
e « o o o o & « o« o
25
Network Management Interface G« e« o o e e o 4+ o .
25
Read-channel . . . ¢« ¢« ¢« ¢ & « o « o o o « o« +
26
Read-portal-list . . + v v ¢ ¢ ¢ o o « o o « o
27
Read-portal
. . & v ¢« ¢ ¢ o o o o o o o« o o o 27
Reset
& ¢ ¢ ¢« v v 6 0 e e e e e e e e e e e
28
Set—-addresSsS
.« . ¢ ¢ ¢ e e e 4 e e« 4o e o+ e« « .
28
Enable-channel . . . . . ¢« ¢ ¢« ¢« ¢ « o« o« « « «
29
Disable-channel
. . . .+« ¢ ¢« ¢« ¢« « ¢« ¢« « « « o«
30
Read-counters
. . « « « « o« « o o o« « o« « « «
30
Read-event .« « ¢ « « « o o« o« « o o« o o o « «
31
Ethernet Interfaces . .
&« e e+ e« o o o« o
32
Client to Data Link Interface
. .
e« « o«
33
Network Management to Data Link Interface
. .
34
‘Network Management to Physical Link Interface
34

NETWORK MANAGEMENT INFORMATION . . . « « « « « . .

INTERFACE USAGE EXAMPLES . . . &« . & o « « « o« . .

COUNLErS
EVENES v

&
v

«
o

o
v

&
¢

&
+

o
o

Portal Filter Setup
.
Data Error Diagnostic

o
o

.
.

o
o

.
«

o
o

+
«

o o
oo
«
¢

«
¢

o
s

«
o

o
o

¢
«

o
o

«
«

o
o

«
o

o
o

«
o

o
o

«
«

o« +
o«
o«
o«

o«
o«

35
39

43
43

Page 4

Contents

7.1

OPERATION

Portal

e
o
o
Handler

e
.

s
.

Open
.

Enablepromlscuous « e
Disable-promiscuous .
Enable-protocol
. . .
Disable-protocol
.

e
.
.
.

7.1.6
7.1.7

Enable-multicast .
Disable-multicast

7.1.8
7.1.9
7.1.10

Close
Transmit .
.
Transmitpoll»

.
.

. .
. .

48
49

49
49

.
e
e

Recelive
. .
« e e
Recelve- abort
« e e
Recelive-poll . . . .
Transmitter and Recelver

e
50

Transmitter

7.2.2

Receiver

7.2.3

Counters

7.2.4

Events

APPENDIX A

7.1.1

7.2.1

7.1.2
7.1.3
7.1.4
7.1.5

7.1.11
7.1.12
7.1.13
7.2

PROTOCOL

e
.

TYPES

A.l

CROSS-COMPANY

A.2

DIGITAL

¢«

AND MULTICAST
ASSIGNMENTS

ASSIGNMENTS

51
52
55

ADDRESSES

’r‘“’-

Table

Page 5

Introduction
INTRODUCTION

The Digital, Intel, Xerox intercompany Ethernet specification 1s the
basis for defining the DNA (DIGITAL Network Architecture) Ethernet
et Link incorporates the functions and
The DNA EthernData
Data Link.
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.

and
interfaces,
functions,
This document describes the structure,
Ethernet
the
in
defined
not
Link
Data
protocols of the DNA Ethernet
DNA is the model on
specification that make it compatible with DNA.
network is a family
DECnet
A
based.
are
which DECnet implementations
used to tie
components
hardware
and
of software modules, data bases,
computation
distributed
sharing,
resource
for
DIGITAL systems together
or remote system communication.

DNA is a layered structure. Modules in each layer perform distinct
Modules within a single DNA layer (but typically in
functions.
different computer systems) communicate using specific protocols.

Modules

layers

different

the same computer

1in

typically

(but

system) interface using subroutine calls or a system-dependent method.
interfaces are described 1in terms of calls to
In this document
-

- subroutines.

This document assumes that the reader is familiar with computer
DECnet. The primary audience consists of those who
and ions
communicat
implement DECnet systems. However, the document may be wuseful to
anyone interested 1in the details of DECnet structure. The other
current DNA functional specifications are:

DNA Data Access Protocol (DAP) Functional Specification,

Version

Protocol

(DDCMP)

Architecture 'Specification,

Version

5.6.0, Order No.

Digital

Data

Communications

DNA Ethernet

Node

Product

DNA

Message

Functional Specification, Version 4.1.0, Order No. AA-K175A-TK
1.0.0,

DNA

AA-K177A-TK

Order No.

Maintenance

3.0.0,

AA-X440A-TK

Operations

Order No.

Functional

AA-X436A-TK

Functional
DNA Network Manag-ement
Order No.

DNA Network Services Protocol
4.0.0,

AA-X437A-TK

Order No.

Specification,
|

Specification,

Version

;

Functional Specification,

4.0.0,

Version

AA-X439A-TK

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

Version

2.0.0,

Order

DNA Session Control Functional Specification, Version 1.0.0, Order
|

No.

AA-K182A-TK

Introduction

Page

The Ethernet; a Local Area Network; Data Link Layer
Layer

Specifications,

Xerox)
The

DECnet

(Order

Order No.

AA-N149A-TC)

FUNCTIONAL

2.0,

AA~-K759B-TK

DIGITAL Network Architecture

No.

architecture and
specifications.

Ver51on

introduction
|
-

each

Physical

(Digital, 1Intel,
|

(Phase

provides

and

IV)

General

overview
of

+the

DNA

and

Description

the

network

functional
-

DESCRIPTION

The Ethernet functions
Ethernet
Data
Link.
functions:
|

are a
The

subset
of
those
DNA Ethernet Data

included by
the
DNA
Link has two classes of
|

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
1in
the
network
architecture, rather than the end user at the top layer.

Network Management -- the
needed

to maintain

The DNA Ethernet

transmitting
‘The data link
type based on

Data Link

the

control

Data

gives

and

Link.

its

users

observation

communication

services

service

for

and
receiving
frames, but does not guarantee delivery.
filters incoming frames by system address and protocol
filter values established by the user.
|

A specific system (physical address),

function-oriented

grdup

systems (multicast address), or all systems (broadcast address) can be
addressed using the
data
1link.
Each
frame
has
a
protocol
type
assigned
to it that is used by the data link to identify the protocol
handling module that 1s to recelve 1t.

The use of protocol types

protocols

the

layer

allows

above

concurrent

the data

link.

operation of multiple
For

example,

in DNA the

Routing layer and the DNA Ethernet Data Link Loop Testlng Service
can
both
use
the DNA Ethernet Data Link at the same time.
Neither needs
to be aware of the other.
This 1s in contrast to the DDCMP Data
Link
where
maintenance traffic
and normal traffic use mutually exclusive

modes

protocol

operation.

The DNA Ethernet DatavLink‘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
The

DeSign Scope

DNA Ethernet Data Link
present,
attempts to meet

requires
certain
certain goals, and

characteristics
to
be
lacks some features that

- Page 7

Functional Description

are not within the scope of the design.

2.1.1

Requirements

DNA Ethernet

The

characteristics:

Data

Link design

All capabilities included in the

Ethernet

available from the DNA Ethernet Data Link.

are

link

The'network manager can control and observe the data

It complies W1th the Ethernet Spec1f1cat10n.

functlons.

Goals

The DNA Ethernet Data Link
characteristics:

.
..
|

2.1.3

Specification

2.1;2

the following

have

must

de51gn

attempts
|

have

following

the

Uses both processor and memory efficiently.
Common functions needed by higher layers are included

data link.

the

Inputs and outputs are simple, predictable, and consistent.

Non-Goals

the

following

included
not
functions
Addition of
layers may
that higher
specification
dlfferently (such as rellable delivery).

the
in
to
want

Ethernet
1mplement
o

Self-dlagn051s of all data llnk problems.

Diagnosis

DNA Ethernet Data Link design does not attempt to have
characteristics:

problems requires information from h1gher layers.

some

Models
3

Page 8

MODELS

- This section describes the relationship of the
to

other
primarily

network

layers

3.1

m————

|
|
I
l

| -———>

|
|
I

l
| ———=>

the

] —H ' T

I
*«

|
|
I

DIGITAL

Network

relatlonshlp of

T T TT

Network

other

o« - T T

network

the

DNA Ethernet Data

Management

T T
|
v

———

|
I
I

|
v
Rt et .
Routlng Modules

o
L T
—'
|
|

| - == >

gmmmm————— ————— e
Data Link Modules

|
l
I
ei>

|
|
I

—————— °

| —————="
|
|
\Y/
|

——— ..

I
|
|
i e e
i
et R "
|
l
|
|
\Y
|
) I
——————————————————————————— TM
I
| ———— > | End Communication Modules |
|

Modules

T T TT T T T T TT T T T T
Session Control Modules

| -=>

Link

———————————————————————————————————— [

| —————
I
|
'
Y
————————————————————————————————

|
|
|
I

archltectures.

Architecture

| Network Application Modules

B
|
v

|
|
|

|
N

|
|

]
|
|

. l
|
|
o
|
I
|

|
|
|
|

|
|

Y
.
|

___________________________________________ ]

s~
|

Link

modules.
Although this specification
Ethernet
Data
Link
to
DNA,
the
same

the
DNA
also be applied within

Figure 1 shows
DNA hierarchy.

DNA Ethernet Data

and

relates
relationships can

Relationship

)

|
\V/
T - - - """ -"""""—""="\¥"=—"=-"=—-"—/——=~ °
Physical Link Modules

the

Page 9

Models

The DNA Ethernet Data Link resides within the DNA Data Link layer.
can

X [] 2 5 ®

co-resident with other DNA Data Link modules such as DDCMP or
|

direct

In figure 1, horizontal arrows show

control

for

access

arrows
Vertical
counters, etc.
observation of parameters,
interfaces between layers for normal wuser operations such as
access, down-line load, and logical link usage.
Each layer in

DNA

functional

consists

modules

and

show
file

protocols.

In this
Generally, modules use the services of the next lower layer.
the way the
1in
1is demonstrated
document the service relationship

Note that the
subroutines.
to
<calls
as
interfaces are modeled,
lower
the
Network Management layer interfaces directly with each of
1layers above Session Control interface directly
the
Also,
layers.

For

with it.

this

referred to as the

reason

upper

the

"end user.”

three

layers

are

sometimes

Modules of the same type in the same layer communicate with each other
The rules governing this communication and
to provide their services.
for those modules.
the messages required constitute the protocol

1n
are typically exchanged Dbetween equivalent modules
Messages
can
node
However, equivalent modules within a single
different nodes.
|

also exchange messages.

A brief desCription of each layer follows in order from the highest to
the

lowest

layer:

user
supports
The highest layer, the User layer
User layer.
Control
Network
the
Programs such as
services and programs.
layer,
Program, which interfaces with the Network Management
Network
the
with
and file transfer programs, which interface
Application layer,

reside in the user layer.

functions.

Network Application layer. Modules in the Network Application
layer support network functions, such as remote file access
and file transfer, used by the
layers.

The Network Management layer 1s the
Network Management layer.
access to each lower layer for
has direct
only one that
Modules in this layer provide user control
control purposes.
These
s counters.
and
over and access to network parameter
and
loading,
down-line
modules also perform up-line dumping,
testing

User

and

Network

Management

The Session Control defines the
layer.
Session Control
system-dependent aspects of logical link communication, which
in a
allows messages to be sent from one node to another
address
to
name
include
functions
Session Control
network.
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.

6. "Routing layer.
called

packets,

Modules in the Routing layer
between

source

and

destination

route

Data Link layer. The Data Link.Alayer ‘defines
concerning data

integrity

Physical Link layer.
-

and physical

messages,

nodes.

the 'protocol

channel management.

The Physical Link

layer

encompasses

part
of the device driver for each communications device plus
the communications hardware
1itself.
The
hardware ‘includes
interface devices, modems, and the communication lines.

3.2

DNA Ethernet Data Link Model

The

DNA

Ethernet

multiple
channels.
Ethernet

Data

Link

provides

concurrent
users.
A channel 1s defined
cable.

standard.

Each

It
as

channel

communication

services

for

also
supports
multiple
Ethernet
a single hardware connection to
an

implements

the

cross—-company

Ethernet

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
1is
the.
lowest level module in the Client Layer.

User #1 |
S '
\
\

|
User #2
e
|
|
l
|
I

\
Ethernet

Channel

T ———— .

Data

Channel

|
B

User #n
T

Link

|
e

Interfaces

...

Channel

Users
|
e

Data

DNA

Ethernet
e ——— .

Link

Physical
S,

T ———— .

ETHERNET

DNA
|
Ethernet

ETHERNET

oSe

DNA

Lintk

Data

Link

Models

3.2.1

Resource Naming

- Page 11

The user of the DNA Ethernet Data Link 1s concerned with two different
levels

identification.

Users

1identify

either

portal.

channel

or a

A channel
is a particular Ethernet hardware connection.

A portal represents a particular user's data
base
needed
by
the
data
1link
to service that user's requests.
A portal
1is
assigned by the data link in
response
to
a wuser's
1nitial
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.

channel has one name and each name

identifies one channel.

Each

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

3.2.2

user.

‘

Data Link States

In observing the operation of the data link, the
wuser 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
data
link.
This
test
self-test.

initialized
and
tested
by
the
1s
an 1implementation
dependent

On --

the channel

Broken -- an attempt was made to turn the channel on,
failed

data

is availlable

the initialization

link determined that

initialization

for use.

test,

the

channel

channel was

would

now

but

on but

fail

the

test.

Changes between these states do not
as the node's physical address.

affect

counters or parameters
|

such

Models

Page 12

The following diagram shows the data

link

channel:

++++

off

init

| +++> |

e ———— '

Cemm

[***>]|
|

Key:

+++
|
+
| <++

|
Management Disable

+++

Management Enable

***

--|

for

fmm———= .

| <-—-]
|
|

transitions

-— |
|
|

state

Data Link Operation

*
yommm— .
|
S
broken
|<**%*x*

Network management can enable the channel.
states,
state,

this

enable

has

causes

effect.

From the "off" or "broken"

transition to "init".

From the "on"

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
1link changes
the

state to "broken".

From

the

"broken"

initialization

disable

again

state,

network

with

an enable

management

can

command or go to

command.

elther

try‘[

"off" with a

The data link can change the state from "on" to "broken" at

any

time

it determines 'that the channel would fail initialization and test.

The channel can be forced

management disable

command.

"off"

from

any

state

network

Interfaces
4

Page 13

INTERFACES

The

following

sections

Ethernet Data Link.

describe

They are

the

interfaces

provided

following:

User Interface -- contains the functions to transmit and

Network

data between data

receive

links.

Management

observation functions

Interface
for

the

contains the

local data

control

link.

DNA

and

The function descriptions are in terms of subroutines with
1input
and
output arquments.
These subroutines are to be understood as abstract,
functional descriptions.
Actual implementations may vary, for example
in
synchronization
techniques,
as
1long
as
they
provide the same
functions.
Furthermore, these are
models
for
privileged,
1internal
system
interfaces.
They are not necessarily to be used as high level
user

interfaces.

The interfaces use the two levels of

Model
section.
Callers
identify
either channel-id or portal-id.

1identification

the

object of
|

defined

a call

the

in terms of

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 1s restricted to one or the
other.
In
implementations that allow expression of one of the forms
of address in a case where it
1s
1invalid,
the
1implementation
must
reject

the

function request with an appropriate error

return code.

The interface descriptions assume that buffers are passed
in the
of
a
descriptor that contains buffer address, maximum buffer
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

User

1interface

Interface

This section describes the User Interface
to

- Link.

form

length,

The User

Interface

maintains

the

portals

DNA

Ethernet

Data

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

‘Page 14

The interface contains the following functions:
.

Open -- open a portal.

Enable-promiscuous -- enable all

addresses

for

Disable-promiscuous -- disable

multicast

protocOl

a portal.

address enable

for

the

types and

blanket

a portal.

multicast

protocol

type

and

Enable-protocol -- enable a protocol type for a portal.

Dlsable
-protocol -- disable a protocol type for a portal

Enable-multicast -- enable a multlcast address

Disable—multicast -- disable a multicast address for a portal.

Close --

close a portal.

Transmit

Transmit-poll -- checks for completion of a Transmit.

Recei&e -—- recelve a frame.

for a portal

send a frame.

. Receive-abort ——'Aborts a Receive.

Receive-poll -- checks for completion.of a Receive,

Some features 1n thé interface deScfiptions

are optional.

Features

can
be
optional
for caller or implementor or both. Caller-optional
features can be invoked at the wuser'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
1s
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

frames

addressed
to
the
channel's
physical
address.
A
portal receives
multicast frames only for those multicast
addresses
1t
specifically
enables.
In
this
context,
broadcast
1s treated the same as other
multicast addresses. Multicast addresses enabled or disabled
on
one
portal

have no effect

Conceptually,

on other portals.

receive filtering is done first by protocol

by
multicast
address.
A
frame
discarded.
1In actual practice, an
hardware

the union of

the multicast

type,

then

that
does
not
pass filtering
implementation may first filter
addresses

for all

portals

and

1s
1in

then

\fi-v'"/

Interfaces

Page 15

do the filtering again on a reduced number of frames.

4.1.1

Open

The open function opens a portal so that the
3

receive

user

can

transmit

and

frames.

OPEN(Channel—id,Pad,Return—cOde,Portal—id)
Inputs:

Channel-id - the unique
which

identification of the Ethernet hardware on

the portal

to be

opened.

Pad - a user flag that indicates whether the data link is to

pad

frames +that
are
under
minimum
length.
Paddlng 1S
accomplished via data link generated additions to
user

data.

It 1s the responsibility of the user's protocol
conventions to define
that its
protocol
modules
1in
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

Success

the

request.

a portal was

One of:

opened.

No resources - the DNA Ethernet Data Link does
have

\)
/

|
|

sufficient

resources

Unrecognized channel
specified

to open a portal.

there

identification.

is no

Channel not on - a portal cannot
the channel state 1s not "on"

not

channel with the

be opened

Dbecause

Promiscuous receiver active - a
portal
cannot
be
opened
because
some
other
portal
has
enabled
promiscuous receive.
This
error
return
applies
only
in
implementations
that
1limit
promilscuous

receive

Enable-promiscuous

single

function).

portal

Portal-id - a portal identification
to be used in the
interface

functions.

(see

the

other user

Interfaces
4.1.2

function

1indicates

Page 16

Enable-promiscuous

The Enable-promiscuous

that

the

portal

1is

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

Not

implemented.

Exclusive use
open
or
1if
addresses

The

only.
this

this

function

function are allowed:

fails.

The function fails 1f any
portal
has
any
protocol

.other
portal
1is
types or multicast

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.

ENABLE-PROMISCUOUS (Portal-id, Return-code)
Inputs:
Portal-id -

a portal

identification assigned by

the Open

function.

OQutputs:

Return-code -

the status of
Success

Not

the

promiscuous

implemented

support

request.

the

One of:

receive

the

requested

enabled.

1implementation

function.

does

not
|

Non-exclusive
the
implementation
allows
only
exclusive
promiscuous
recelipt
and this portal or
some other portal has a protocol type or
multicast
address enabled.
|

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

Channel not on - the function
channel

4.1.3

state

is not

"on".

failed

because

with

the.

Disable-promiscuous

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

1indicates
that
the
all
protocol
types
|

portal 1s
no
and
multicast

Page 17

Interfaces

DISABLE—PROMISCUOUS(Portal—id,Protocol—type,Return—code)
|

Inputs:

Portal-id- a portal identification assigned by the Open function.
this

Protocol-type - a protocol type that is to be recognized for
|

portal.

Outputs:

Return-code - the status of the request.

One of:

not

Success - promiscuous receive is

with

Unrecognized portal - there is no open portal

the specified identification.

4,1.4

for

enabled

the portal.

Enable—prdtocol

The Enable-protocol function adds a protocol type to the list of those
that the portal wishes to receive. The function fails 1f the protocol
'\\__//

type is enabled by some other portal.

ENABLE-PROTOCOL(Portal-id,Protocol-type,Return-code)
Inputs:

Portal-id - a portal identification assigned by the Open function.

this

Protocol-type - a protocol type that is to be recognized for
|

portal.

Outputs:

Return-code - the status of the request.

One of:

Success - the protocol type 1s enabled.

Protocol type 1n use - this

enable

portal cannot

the protocol type because some other portal already

has

it enabled.

No resources- the DNA Ethernet Data Link does
have

sufficient

protocol

resources

type.

enable

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

not

another

with

Interfaces

‘Promiscuous receive active because
this
portal
has

recelive.

This

implementations

single
portal
function).

error
that

(see
|

4.1;5

state

not

applies

promiscuous

the

Channel not on - the function
channel

Page

"on".

only
receive

1n
to

Enable-promiscuous

failed

because

the

Disable-protocol

The Disable-protocol funetion indicates that the portal
is no
to

the
function
failed
enabled
promiscuous

return

limit

receive

frames

for

a protocol

type.

longer

DiSABLE—PROTOCOL(Portal—id,Protocol—type,Return—code)

-~ Inputs:

Portal-id
- a portal
Protocol-type

for

identification assigned by the Open function.

a protocol type
this portal.

that

longer

recognlzed

Outputs:

Return-code - the status of the request.

One of:

Success - the protocol type is not enabled for the

portal.

Unrecognized portal - there 1s no
the specified identification.

4.1.6

open portal

with

Enable-multicast

The Enable-multicast function adds a multicast address to the list .of
those

that

the portal

wishes

receive.

ENABLE—MULTICAST(Portal—id,Multicast—address,Returnfcode)
Inputs:

Portal-id - a portal identifieation»assigned by the Open function.
Multlcast address - a multlcast
for this portal

address

that

to
|

recognized

‘Page 19

Interfaces
Outputs:

Return-code - the:status df the request.

One of:

- Success - the multicast addfess is enabled.
No resources - the DNA Ethernet Data Link does vnot

sufficient
have
multicast address

to
resources
for this portal.

another

enable

Unrecognizéd portal - there is no open portal ‘with
|

the specified identification.

failed
function
Promiscuous receive active - the
promiscuous
enabled
has
portal
this
because

in
only
return applies
error
This
receive.
implementations that limit promiscuous receive to a

single

portal

function).

(see

the

Channel'not on - the function
channel

4,1.7

state

1s not

"on".

Enable-promiscuous
\

failed
|

because

the

longer

Disable-multicast

4) The DiSablefmulticast indicates

that

receive frames for a multicast address.

the portal 1is

DISABLE—MULTICAST(Portal—id,Multicést-address,Return—code)
InputS:
Portal-id - a portal identification assigned by the Open function.
Multicast-address - a multicast address that

longer to

Success - the multiCast address 1s not enabled

for

Unrecognized portal - there is no open portal

with

recognized

for

this portal.

is no

Outputs:

Return-code - the status of the request.

One of:

the portal.

the specified

identification.

Interfaces
4.1.8

Page 20

The Close 'functioh
resources.

receive

A portal

requests

closes

cannot

are

an open portal

closed unless

and releases

all

outstandlng

all

its

transmit

completed.

CLOSE(Portal-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
the specified identification.
Calls outstanding or receilve requests

4,1,9
The

for

function

completion

queues

portal

uncompleted

outstanding

frame

user

allowed

can

have

the

by using Transmit-poll.

always succeeds or fails within such
abort function 1$ not necessary.
The

are

open

the

with

transmit

portal.

Transmit

tests

there

multiple

outstandlng

small

transmitted.

The

Transmission
amount

Transmlts,

time

user

frame

that

the

implementation.

limit

NOTE

Ethernet does
fewer

data.

than
The

transmission,

not

gquarantee

attempted

46 ibytes or more than 1500
DNA
Ethernet
Data
Link

but

the

result

delivery

bytes of user
may
attempt

unspecified.

TRANSMIT(Portal-id,Destination-address,Protocol-type,
Input-buffer,
CRC-32,Return-code)
Inputs:

Portal—id - a portal identification assigned by the Open function.

Destination—address - the address of the frame destination.
can
be
address.

either
a
physical
As a matter of good

address
or
citizenship,

This

a
multicast
users should

Interfaces

Page 21

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

Protocol-type - identifies the protocol at

the
of

the receiving system.

Input-buffer - a buffer containing the data to be
sent.
If
the
data
1s shorter than the minimum Ethernet message size
and padding is not enabled, or the data i1s longer
than
the
maximum
Ethernet message size, then the frame may

not arrive at the destination.
If padding
1s
enabled
there
1s
no minimum size, and the maximum size 1is the
Ethernet limit minus two bytes.
Until the
request
1s
completed
(as sensed via Transmit-poll), the user must
not

CRC-32 -

disturb

caller-

the

contents

and

the

buffer.

implementation—optidnal

32-bit

cyclic

redundancy
code that
1is
to
be used for this frame.
This overrides the one normally supplied
by
the
data
link.

Outputs:

Return-code - the status of

the request.

Request accepted -

DNA

One of:

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
supply

support

or allow the

function.

No resources - the DNA Ethernet
Data Link does
have sufficient
for

not

resources to queue another transmit

this portal.

Unrecognized portal - there
the specified

channel

is no open portal

identification.

Channel not on -

4,1.10

CRC and the implemention either does not

the

state
1s not

function
"on".

failed

because

with
the

Transmit-poll

The Transmit-poll function checks for the 'completion
request.

The

user submits

data

them.

link

believes

that

transmit

Successful completion of this function implies
transmitter

transmits frames in the order in which the

it sent the frame.

relative to reception by the destination.

only

that

the

1local

It has no implication

Interfaces

Page 22

TRANSMIT-POLL(Portal-id,Return- code Input
-buffer,Error-detail,
Fault- dlstance)
Inputs:

Portal-id - a portal 1identification assigned by the Open'function.

Outputs:

‘

Return-code
-

the

transmit

request

for

this portal.

Not complete - no
portal is done.

outstanding

None
outstanding
transmits for this

there
portal.

One

transmit

are

of:
for

this

outstanding

Transmit successful - a frame successfully
left the
local

transmitter.

Transmit failed - the
transmit
the frame.

local

transmitter

Unrecognized portal - there is
the speC1f1ed 1dent1f1cat10n,
Channel
because

left
"on"
the channel

Input-buffer - the
buffer
'function.

that

state
is no

was

could

no open portal

the
function
longer
in the "on"

supplied

1in

the

not

with

failed
state.

Transmit

Error
-detail - the caller-optional reason
for
a
return-code
of
"transmit
failed".
Detailed
explanation
of these
reasons 1s 1n the section on events.
One of:
Excessive collisions
Carrier check failed
Short circuit
Open circuilt
Frame

Remote

too

long

failure

defer

Fault-distance - the calleroptlonal distance in bit
times
to
a
short
or
open
circuit.
This is meaningful only when
error-detail
1s "short circuit" or "open circuit".

4.1.11

Receive

The Receive function queues a buffer to receive a frame.

RECEIVE(Portal-id,Receive-bad,Output-buffer,Return-code,Frames-1lost)

Interfaces
\>

- Page
23

Inputs:

Portal-id -

a portal

identification

assigned by

the Open function.

Receive-bad - a
callerand
implementation-optional
1indication
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 conta1n

frame.

the

received

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

Request

accepted -

specified portal,

put

into

via

the

One of:

a message

the buffer.

Receive-poll

receipt

~ not

support

Dbad
the

received

for

Notification of

completion

frames but

the

<call

requested

implementation
does

function.

,
\\

NO resources'— the DNA Ethernet Data Link does
have
for

sufficient

this

resources

specified

Channel
channel

~
)

)

Frames—-lost
~

for

not on - the
state 1s not

frames

4.1.12

1s no open portal

function
"on"..

were

Note that
lost

failed

the

this count

low enough

filtering could not be
done.
required iin
implementations
always

not

receive

‘with

because
|

number

‘the

frames

portal that were discarded because no buffer

was available.
if

another

identification.

the caller-optional count of

this

to queue

portal.

Unrecognized portal - there
~the

the

function.

Receive-bad not implemented -

1is

the DNA Ethernet Data Link will

This
where

can

level

1incorrect

that

portal

argument
1is
not
the
buffering 1is

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,
Sourceaddress Protocol type, Output
buffer
~
Bytes-lost,CRC-32)

Interfaces

Page 24

Inputs:

Portal-i1d - a portal

1dentification assigned by the Open

function.

Outputs:.
Return-code - the status of the receive request.
Not complete portal 1is done.

outstanding
|
|

None
outstanding
- there
receives for this portal.

Receive
successful
a
recelved into the buffer.'
Receive with overrun received,
but
had to
buffer.

a
be

One of:
receive

for

this

are

outstanding
|

frame

was

successfully

frame
was
truncated to

successfully
fit into the

Length
error
the
received
frame
1length
was
inconsistent
with
the
1length
recorded
by
the
padding conventions.
The buffer contains the data
received,
1including
the
padding
1information and
truncated if it was too long
to all
fit
1in
the
buffer.

Invalid data
- a frame was received with bad
data.
This
return-code
value
1is
only
seen
1if on the
Recelive function the caller requested dellvery
of
bad frames.

Receive aborted - the user
request

with

the

cancelled

Receive-abort

the

function.

receive

Unrecognized portal
- there is no open portal
the

specified

Channel
because

left .bb "on" state - the
function
the channel is no longer in the "on"

Error--detaill - the caller-optional reason
"invalid
data".
1s in the section

with

identification.

for

Detailed explanation
on events.
One of:

failed
state.

return—code_

these

reasons

Block check error
Framing error
Frame too long

" Destination-address - the address to which the received frame
addressed

Source-address
- the address
received frame.

the system

that

transmitted
,

was
the

Interfaces

- Page

Protocol-type

the protocol

Output-buffer

the received data.

Bytes-lost

type

from the

received

frame.

- the number of bytes
1lost
when
the
return-code
1is
"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 - the caller-optional 32-bit cyclic

code

that

The Receive-abort function aborts all incomplete receive requests

for

4.1.13
the

came

1nto

the data

redundancy

link with the

frame.

Receive-abort

portal.

They may be

The buffers are

returned

returned via the Receive-poll

aborted or

normally

function.

completed.

RECEIVE-ABORT (Portal-id,Return-code)

InputS:

Portal-1id —.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' with
the

specified

identification.

‘None
outstanding
there
receives for this portal.

4.2

are

outstanding

Network Management Interface

This section describes the

interface

used

control

and

observe

operation of
the
DNA FEthernet
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

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.

4,2.1

read

Page
26

. Read-event

information for a portal.

read channel

event.

Read-channel

The Read-channel function

reads

specified channel.

status

information

relative
|

READ-CHANNEL(Channel-id,Return-code,Physical-address,
Hardware-address,State,Broken-code)

InputS:
Channel-id
- the unique identification
status

to be

read.

channel for

which

Outputs:

Return-code - the status of the request.

One of:

Success - status successfully read.
Unrecognized channel - there
specified identification.

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

is no channel with the

the
channel
or
"not
that
the
channel
1is
|

Hardwarefaddress - the hardware'addtess'of‘,the
avalilable”.

This

channel hardware.

1is

channel or

"not

the address associated with the
|

State - the channel state as described earlier,

one of:

Off
Init
Broken

Broken-code -

implementation-specific

value

indicating

the

Interfaces

Page 27

reason the state is "broken".

4.2.2

The

Read-portal-list

identifications.

function
|

reads

the
|

1list

open

portal

READ-PORTAL-LIST(Channel-id,Buffer,Return-code)

Inputs:
Channel-1d

Buffer

- the unique identification of a
open portal list 1s to be read.

a buffer

contain

the

list

channel

portals.

Return-code - the status of the request.

Ohe»df:

for which

the

Outputs:

Success - list successfully read.

Buffer too small - the buffer could

not

entire
fit 1n

list,
Portal identifications
the buffer are not returned.

~Unrecognized

channel

there

specified identification.

Buffer

4.,2.3

descriptor

of
buffer
identifications.

containing

hold

that

channel

list

the

would not

with

the

portal

Read—portal-A

The Read-portal function reads portal

data

base

information

for

portal.

READ—PORTAL(Portal—id,Buffer,Return—codé)v
Inputs:

Portal-id - the portal identification of the open portal for which
the

data base

read.

| Buffer - descriptor of a buffer to contain the
information.

portal

data
|

base

Interfaces

Page 28

OutputS:
Return-code

the

status

the

request.

One

of:

Success - portal data base successfully read.
Buffer

the

too

small

information.

the buffer

the

buffer

not

the

all

fit

1in

is no channel with the

identification

particular
portal
data
‘parameters are
listed
1n
operation section.
Value

The
The
are

hold

- descriptor of a buffer containing the
portal
data
base
information.
Each
parameter
entry
contains
the
following information:

Parameter-type

4.2.4

not

returned.

Unrecognized channel - there
specified identification.
"Buffer

could

Information that would not

the

parameter

the

base
parameter.
the
Portal
Data
|

The
Base

value.

Reset

Reset function returns the specified
channel
physical address 1is unset.
The counters are
closed.
The channel state 1s "off".

to
1initial
state.
zeroed.
All portals
-

RESET(Channel-id,Return-code)

Inputs:
- Channel-1d - the uniquevidentificatiOH of the channel that
be

Outputs:

reset.

»to.

Return—éode - the status of the request.

Success - channel reset.

One of:

‘

Unrecognized channel - there
specified identification.

4.,2.5

1is

is no channel with the
|
-

Set—-address

- The Set-address
channel.
This

function sets the physical address
of
the
specified
is
the address recognized as specific destination
1in

Interfaces

received

frames

and sent

source

Page 29

address 1in 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 unique identification of the channel
for
which
the
address
1is
to
be
set.
This must be a physical
address.
Furthermore, it
must
be
unique among
all
channels
Address

the

attached

address

the

same

cable.

set.

Qutputs:

Return-code - the status of the request.
Success

the

address

was

One of:
successfully

Unrecognized channel - there
specified identification.
Channel
channel

4.2.6

is no channel with the

not off - the function
state 1s not "off",.

failed

because
-

the

Enable-channel

The Enable-channel
where

set.

Enabling

function attempts to put

the channel

can be used.

variables.

into

the channel

does

not

disturb

the

state
|

contents

counter

ENABLE-CHANNEL(Channel-id,Return-code)
Inputs:

Channel-id - the

wunique

identification

the

channel

enabled.
Outputs:

Return-code - the status of the request.

One of:

Success - Channel is enabled.

channel

that is

enabled
1s
not
necessarily usable. The user can
determine the actual state of the channel with
the

Interfaces

|
Read-channel

function.

Address not

set
-

channel

not

has

. Page 30

the

been

physical

address

for

the

set.

UnrecogniZed channel- there is no channel with the
specified

4.2.7

identification.

Disable-channel

The Disable-channel function puts the channel into the "off" state so

that 1t
cannot be
used.
The
purpose of this function is to halt
operation.
The channel can still be observed.
1In particular counters
and
other
data base information not directly related to state change
operatlon

1s not disturbed.

All outstanding transmit and receive operations for
completed
with
a
return
code
Receive-poll or Transmit-poll.

"*hanuel

left

the

channel

are

on state"
|
|

on the

channel

to be

DISABLE-CHANNEL (Channel-id,Return-code)
Inputs:

Channel-id
- the wunique
disabled.

1identification of

the

OQutputs:

Return-code - the status of the request.

One of:

Success - channel is disabled.

Unrecognized channel - there 1is no channel with the
specified

4.2.8

identification.

Read-counters

The Read-counters function reads and
associated with the

optionally

specified channel
or portal

sets

zero.

all

counters
|

READ-COUNTERS (Entity-id,Operation,Buffer,Return-code)
Inputs:

Entity-id - the unique 1dent1f1cat10n of the particular channel or
portal

Operation

the

for Wthh counters

data link

are to be

read.

performs vOne,=of.

the

following

Interfaces

Page 31

operations:
Read

- only

read

Read-and-zero

the

counters.

read

the

counters

and

set

them

=zero

Zero.

Buffer - descriptor of a buffer to receive the counters.

Outputs:

Return-code - the status of the request.

One of:

Success -

(and

requested).

counters

read

set

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
1information.
The information 1is
truncated.
Information that would not fit is lost.
If

read-and-zero

are set to zero
returned.
|

)

Buffer

descriptor of buffer
entry contains the

was

even

requested,

their

all

the

values

counters

were

not

|
containing counters.
following information:

Each

counter

Counter-type - the identification of the particular

counter.,

The

Management

Information

Value

- the

counters

counter

are

listed

in the Network

section.

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 1ncremented because of block
check errors or framing errors.

A4.2-9

Read-event

The Read-event
associated

function reads the next event

with

the

specified

channel

and

Only one event at a time need be buffered.
the

event

events.

buffer
|

often

enough

avoid

from

removes

the event
that

event

buffer
from the

The higher level must poll

excessive

READ—EVENT(Channel—id,Buffer,Return—code,Events—lost)v

number

lost

Interfaces

Page

Inputs:

Channelid - the unlque
event

identification of the channel
be

read.

for which an
~

Buffer - descriptor of a buffer to receive the event.
Outputs:
Return-code - the status
of the request.

One of:

Success - eveht read with no problems.
Buffer too small - the buffer was not big enough to
contain
the
entire
event.
The information
1is
truncated.
Information that would not fit 1s lost.
No

events

the queue

empty.

Unrecognized channel - there is no channel with Lhe
specified

Events lost

identification.

the number of

events

that were

lost

since

Read- event.

Buffer

descriptor
includes

the

last

The

event

buffer

following

contalning

information:

event.

Event-type - the identification of the event.
The
events and
their
parameters are
listed
1n the
Network Management Information section.

Event-parameters - the parameters
the event.
following

associated

Each event parameter entry

with

includes

the

information:

Parameter-type

the

parameter.

1identification

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,
Version
2.0.
This section only contains those functions that relate

directly
to the operation
of the DNA Ethernet Data Link.

The Ethernet spetification 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
1intended
to be a complete description
of the Ethernet

1interfaces.

Interfaces

Page

Most of the Ethernet
of the function.

4.3.1

interface

functions

return a status as

the

wvalue

Client to DatarLink‘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 -

4.3.1.1

receive a frame.

TransmitFrame

TransmitFrame sends a frameQ
either succeeds or

TransmitFrame

fails.

It does not return
-

until

the

transmit

(destinationParam,sourceParam,typeParam,dataParam)

/',

Inputs:

destinationParam —.addfess 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
|

Rec':eiveFrame»’(destinationParam,sourc:eParam,typeParam,dataParam)-j

Inputs:

Page 34

Interfaces
none,

Outputs:

ReceiyeFrame'—lthe status of the-operation.

dne of:

receiveOK - frame successfully received.

frameCheckError - frame block check failed.
alignmentError - frame did not contain an
number

1integral

bytes.

destinationParam - address of the destination system.

sourceParam - physical address of the remote system.
typeParam - protocol type from the frame.
- data from the
dataParam

frame.

to Data Link Interface
Network Management

4.3.2

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

Data

Link.

following

contains the

ReadEthernetAddress - read the physical address.

ReadNumberCollisions - read the number of collisions for the last

DataLinkOn - start data link operation.

DataLinkOff - stop data link operation.

SetAddressMode -

promiscuous.

TransmitFrame.

changes

addressing

mode

between
|

normal

MulticastOn - enable réception of multicast addresses.

MulticastOff - disable reception of multicast addresses.

4.3.3

and

Network Management to Physical Link Interface

to Physical Link Interface is the one
The Network Management
the DNA Ethernet
control access to
following

function:

used

Data Link for network management information and
It contains the
the Ethernet Physical Link.

Interfaces

Page 35

CheckTransmit - checks status of last TransmitFrame.

NETWORK MANAGEMENT

INFORMATION

This section describes the counters and events that the

DNA

Ethernet

Each description
Data Link provides for the Network Management layer.
a statement of
and
contains a conceptual definition of the information
the Operation
in
are
Precise operational definitions
its use.
section.

5.1

Counters

of
Some
channel.
The following counters are kept for each Ethernet
All
integers.
unsigned
are
Counters
them are also kept for portals.
counters remain at their maximum value to indicate overflow.

and
include both normal
counters
all
stated,
otherwise
Unless
all
for
1information
include
they
Furthermore,
traffic.
multicast
not
do
counters
Frames received and bytes received
protocol types.
include frames

received with errors.

The following table contains the names and bit
1lengths
counters:
|
R

Length
16
32

Name

;

"Seconds since last
Bytes receilved
Bytes

sent

zeroed

32
32
32
32
32
32
32

Frames received
Frames sent
Multicast bytes received
Multicast frames received
Frames sent, initially deferred
Frames sent, single collision
Frames sent, multiple collisions

16
16
16

Collision detect check failure
Receive failure *
Unrecognized frame destination

Send

failure

Data

overrun

16
16

System buffer unavailable
User buffer unavailable
* Counter has multiple causes

The following counters are kept
Seconds since last
Bytes received
Bytes

Frames

sent

received

for each portal:

zeroed

all

the

Network Management

Frames

User

Infromation

Page

sent

buffer

unavailable

Seconds since last zeroed
The number of seconds
~length 1s 16 bits.

since

the

counters

Provides
a
frame
of
reference
indicating the amount of time they

were

for
+the
cover.

last

zeroed.

The

other

counters

by
|

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
1includes
any
padding or length fields when they are enabled.
The length
is 32

bits.

These

are

filtering.

Dbytes

from

frames

that

passed

hardware
|

When the number of frames received is used to calculate
prototol
overhead, the overhead plus bytes received provides a measurement

of the
frames
'«

Bytes

amount of
addressed

Ethernet bandwidth
to the local system.

(over
|

time)

consumed
|

sent

The

total number of user
data
bytes
successfully
transmitted.
This does
not
1include
Ethernet data link headers or data link
generated retransmissions.
This number is the number of bytes in

the
Ethernet
data
fields when they are

field,
which
enabled.
The

includes any padding
length is 32 bits.

When the number of frames sent
1s
overhead,
the overhead plus bytes

the

amount

sent

Frames
The

Ethernet

local

total

bits.

(over
«

number

of iframes

successfully

These

are frames

a gross

system.

error

Frames

calculate
protocol
a measurement of

sent provides

system.

local
the

bandwidth

length

time)

consumed

frames

received

Provides

the

wused

that

measurement

Provides

counters

received.

passed hardware
incoming

The

Ethernet

usage

information used to determine
successful

length

1is

filtering.
by

the

ratio

transmits.

sent

The total number of frames sqccessfullytransmitted.
not
1nclude
32 bits.

data

link

generated

retransmissions.

The

This does
length

Network Management

Infromation

Page

Provides a gross measurement
of outgoing Ethernet

usage
Dby
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 deta bytes

successfully‘ recelved.

This does not include Ethernet data link headers.
This number 1is
the number of bytes in the Ethernet data field.
The length is 32
bits.

In conjunctlon with total bytes rece1ved provides a measurement
of
the percentage of this system's receive bandwidth (over time)
that was consumed by multlcast

frames

addressed

the

local

~sSystem.,

Multicast

frames

received

The total number of multicast frames successfully~receiVed.length

bits.

In conjunction with

percentage
to

this

Frames

system.

sent,

total

frames

received,

proVides

The
gross

the Ethernet usage for multicast frames addressed

1initially deferred

The total number of times that a frame transmission was

deferred

Ethernet

on its first transmission attempt.

conjunction

The length is 32 bits.

with total frames sent,

contention with no collisions.

Frames sent,

measures

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.

conjunction

The

length

with

32 bits,.

total frames

sent,

measures

Ethernet

contention
at a level where there are colllslons but the backoff
algorithm still operates eff1c1ently
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
con]unctlon
w1th
total
frames sent,
measures
Ethernet
at a level where there are COlllSlOHS and the backoff
contention
algorithm
no longer operates efficiently.

Network Management

Infromation

Page 38

NOTE

'No single frame is counted in more
the

above

three

than

one

counters.

Send failures
The

total

failure

Dbits.

counter,
set

number of

the

zero,

Each

times

recorded.

list of

the

list

time

transmit

the counter

When

failures

this

are

also

captured as

cleared.

sent,

failed.

function

length

a type of

reads

When the counter
|

provides

All of

The

incremented,

is also read.

In conjunction with total frames
transmit problems.

Read-counter

failures

significant

counter

attempt

the problems

the

1is

measure of

reflected

events.

FOllOWlng are the possible failures.
meanings and use can be found in the

More information
section on events.

their

Excessive collisions
Carrier check
Short circuit
Open circult

failed
|

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

frames sent,
correctly or

Receive

either the collision detect circuitry
the test signal is not implemented.

not working

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
1is
16
bits.
This
counter
includes
failure
reasons
1in
the same way
as the send
failure

counter,

In conjunction with total

frames

received,

provides a measure

data
related receive problems.
All of the problems
this counter are also captured as events.

reflected

Following are the possible reasons.
More
information
meaning and use can be found in the section on events.
Block

check

Framing
Frame

error

too

long

of
in

their

Network Management Infromation

Page 39

Unrecognized frame destination

s was discarded because there
a frame
The number of time

was

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

lost

The total number of times the hardware

incoming frame

because it was unable to keep up with the data rate.

In conjunction with total frames received, provides a measure of
The problem reflected 1in this
hardware resource failures.
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 an

In conjunction with total frames received, provides a measure of
system buffer related receive problems. The problem reflected 1in
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 1is implementation specific.
User buffer unavailable

The total number of times no user buffer

was

available

for

These are the buffers
incoming frame that passed all filtering.
length is 16 bits.
The
requests.
supplied by users on Receive

In conjunction with total frames received, provides a measure of
user buffer related receive problems. The problem reflected in
this counter

5.2

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 descriptidns include a conceptual definition
and an explanation of its use.

are

in the Operation section.

the

event

Precise operational event definitions
|

Events are recorded regardless of protocol type.

Network Management Infromation

~_ Page 40

NOTE

Since
some
events
can
occur
very
.
rapidly,
1mplementations = must
take
care
that
main
line
processing 1s not pre-empted
by event processing.

Initialization failed
This event is logged when the self test at initialization
fails.
The procedures 1n the self test are implementation dependent, but
include such things as
internal
hardware
1loop
testing.
This
event 1s optional on channels that cannot fail in initialization.
When this event is logged, it includes an implementation
value that i1ndicates the reason for the failure.

Provides

Send

notification

that

the

channel

specific

incapable
of operating.

failed

This event 1is logged for any error in transmitting a frame.
reason

for

data. The

the

error 1is included,

possible

Excessive

reasons

followed

any

other

The

pertinent

are:

collisions

Exceeded

the maximum number
collisions.

systems

Carrier 'check
The data
required

Indicates

are

trying

retransmissions

due

Indicates an overload condition
many

transmit

the Ethernet.
at

the

same

Too

time.

failed
link did not
to accompany

Short

failure

1is

either transmitting
or
receiving
either
transceiver
or transceiver
cable related.
Could
be caused by a babbling
controller
that has bean cut off.

hardware.

sense the receive
signal
that
the transmission of
a frame.

Could

circuit

There is a short somewhere
1in
the
coaxial
cable,
or
the
controller/transceiver cable failed.
logged,
an
estimated
distance
to
times, 1s included.
|
|

local area
network
transceiver
- or
When this reason 1is
the failure, in bit

This indicates a problem either
in the local hardware
or
a
4global
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

a break

coaxial
cable.
‘distance to the

somewhere

1in

the

1local

area

network

When this reason is logged, an estimated
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:
it
tried
to
send
a
frame
that
was too long,
hardware

cut

off

transmission

too

either
or the

soon.

fRemote failure to defer
A remote system
window

for

began

transmitting

collisions.

after

the

This indicates either_a problem with some other
carrier sense or

a weak

allowed

transmitter

system's

locally.

Collision'detect check failed
'This event is logged when the data link
collision

signal that

did not

sense

the

is supposed
to follow the transmission

of
a frame.

/,‘

Indicates a failure either

cable
Receive

collision circultry.

in the transceiver or

transceiver

failed

This event is logged for any error in
receiving
a
frame.
The
reason
for
the
error
1is 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
Block

reasons

check

The

are:

error

frame

failed

the CRC check.

This indicates several
caused

such

late collisions,

possible

failures.

can

things as electromagnetic interference,

improperly

(such as receiver squelch).

set

hardware

parameters

Network Management Infromation
Framing

The

Page 42

error

frame did not

contain an

integral

number

bit

can

bytes.

This

indicates

caused
late

several

such

collisions,

possible

improperly

(such as receiver squelch).

Data

failures.

things as electromagnetic
set

interference,

hardware

parameters

overrun

The

frame was

This

lost due

1indicates,

buffers
or CPU

for

time.

to a hardware

example,

resource

failure.

insufficient

hardware

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

there

was

system

This indicates a lack of buffers
1in
the local
system.
This
can
be
any
buffer between the cable and the user
buffers (those
supplied
by
the
wuser
1in
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

receive

This indicates a lack of buffers
These are
function.

Unrecognized

the buffers
|

buffer

1t.

supplied by
.

the

the user

user
1in

process.

the Receive
|

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
wuse
a
protocol that 1s locally unsupported.

Frame

too

long

The frame was

Ethernet maximum

discarded

because

length and could not

was

outside

received.

the

Network Management Infromation
-

\>
6

This

indicates that a remote system

length frames.

|
1is

Page 43

sending

invalid

INTERFACE USAGE EXAMPLES

This section contains examples of how the
user
interface
might
be
they
how
show
to
and
functions
the
motivate
to
1s
intent
The
used.
might interrelate.
This section does not specify how the
1interfaces

)

must

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 Pl and P2 that
are addressed to the physical address and multicast address Ml.

Open(Channel-id,Return-code,Portal-id)

IF Return-code

"success"”

Enable-protocol(Portal-id,Pl,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

6.2

Data Error Diagnostic

In this case, the data link is to be used by
a
diagnostic
program
that
has
a
direct
1interest
1in the characteristics of incorrectly
received messages.
It wishes
to supply
1its
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 handllng within both the local and the
remote sides of the data

link.

It accompllshes this by using the optlons on the
Transmit,
Recelve,
and Receive-poll
functions
that allow it to meet 1its task specific
needs.

Operation

Page 44

~ OPERATION

The bulk of the detailed
operation
of
Ethernet
1is
found
1n
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 1n any other.

The model implementation 1is modularized accordlng

diagram:

User #1

User #2

_________ J

—— e

User #n

———

following

———————— | ]

the

.——_——————-—'

Portal Handler

[

Transmitter

|----|

|-.

‘Portal

| Data Base

—

SIS

Management

Data Base

Receiver

.-|

WGNN

—

w——

——

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
Transmltter
and
Receiver
send
and
receilve frames through the DNA
thernet Data Link User Interface and
malntaln
counter
and
event
1nformat10n in the Management Data Base.
-

This specification assumes the muytual
shared data bases

The Portal Data Base

entry contalins:

exclusion necessary

‘keep

correct,

contains an entry

for

each

open

portal.

Each

Operation

Page

" Channel identification.
Count
Pad

lost

frames.

flag.

List of enabled protocol types.

List of enabled.multicast addresses.

List of outstanding Transmits, each list entry includes:
-

Request state, set to "pending"
"complete" by the Transmitter.

Destination

Protocol type supplied by the user for the frame.

Input buffer with the»user'sddata to send»in the frame.

Return code returned by the Transmitter.

address

by the Portal Handler

supplied by the user for

and

the frame.

- CRC-32 optionally supplied by the user.for the frame.

?gt user-supplied, the DNA Ethernet
Data Link will supply

Error detail returned by the
and desired by

Fault distance returned by the Transmitter
and desired by

applicable

the user.

List of outstanding Receives,

‘

each list entry includes:

Request state, set to "pend1ng"
"complete“ by the Recelver.

Output buffer supplled~by the user for a received frame.

Indicator whether user wants frames with invalid data.

Return code returned by the Receiver.

—

by the Portal Handler

Error detail returned by the Receiver
desired by the user.

Transmitter

the user.

applicable

and

Destination address returned from the received
the Receliver.

and',
-

frame

~by

Operation

Page

Source address returned from the received

frame

by the

Protocol

frame

the

applicable

and

Receiver,

type

returned from the

received

Receiver.

7.1

Bytes lost returned by the
desired by the user.

CRC-32 returned from the received frame by

Portal

desired by the

Receiver

user.

the

Receiver

Handler

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

to the

User
~

Open

Enableprom1scuous

Disable-promiscuous
Enable-protocol
Disable-protocol
Enable-multicast
Disable-multicast
Close

Transmit
Transmit-poll
Receilve
Receilve-abort
Receive-poll

7.1.1

Open

When the user calls Open,
promiscuous
active.
If

the

implementation

allows

receiver,
the
Portal
Handler
checks to see
so, it returns "promiscuous receiver active".

only
if

one

1is

If there 1s 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”.
v
.

If resources are available, the Portal Handler checks to see
1f
the
requested channel exists.
1If not, it returns "unrecognized channel”.

If the channel exists, the Portal Handler
If not, it returns "channel not on".

checks

to see
|

if it

on.

Operation

Page 47

data

If the channel is on, the Portal Handler initializes the portal

the pad flag, empty lists, and the channel identification

base

with

7.1.2

Enable—promiscuous

and returns "success" and the portal identification.

When the user calls Enable-promiscuous, the Portal Handler checks
see

if the supplied portal identification identifies an open portal.
it returns "unrecognized portal”.

If not,

If the pQrtal is open, the Portal Handler does one of the following:
.

Returns "not implemented".

has
Or checks to see if any other portal is open or this one
so
1f
and
enabled
any protocol types or multicast addresses
it returns

"non exclusive".

Or accepts the fact that for this

portal

duplicate messages that other portals recelve.

have

will

it
If the Portal Handler can allow promiscuous receive,
L1nk
Data
promiscuous addressing through the DNA Ethernet
fails, it returns
in
"promiscuous"

"success".

returns

1in wrong
"channel
list
the portal's

enables
If this

Otherwise 1t puts
state"
protocol types and
enabled
of

Disable-promiscuous

7.1.3
/,

When the user calls Disable-promiscuous, the Portal Handler checks to
see

1if the supplied portal identification 1dent1f1es an open portal.

If not,

returns "unrecognized portal".

If the portal is open, the Portal Handler checks the portal's list of

protocol

"success".

types

for

"promiscuous”.
|

If the portal is receiving promlscuously,

not

the

returns

Handler

scans

found,

Portal

to see if any others are receiving promiscuously

other portals
If
(if the implementation allows multiple promiscuous receivers).
addre551ng
promiscuous
disables
Handler
the Portal
none are found,

all

through the DNA Ethernet Data Link.
"success"

The Portal Handler then

returns

Opefation
7.1.4

Page 48

Enable
protocol

When the user calls Enable-protocol, the Portal Handler checks to
if
the supplied portal identification identifies an open portal.
not, it returns "unrecognized portal”.

If the portal
resources
to

1t
If

has
not,

see

If the protocol type is available, the Portal Handler checks

see

If the channel is on, the Portal Handler puts the

type

checks

returns

is open, the Portal Handler checks to
see
1f
record another protocol type for this portal.

see
If

"no resources".

If the Portal Handler has resources,
it scans all portals to

any

"protocol

them

have

type

the

1n use".

the portal's channel

the portal's

7.1.5

list

and

protocol

is on.

returns

type

not,

1if the supplied portal
it

returns

the Portal

identification

"unrecognized portal”.

If the portal is open, the
Portal Handler
protocol
type is in the portal's list.
If
removes

"channel not on".

protocol

it. The Portal Handler

then

Handler

returns

checks
to
see
1f
the
it is, the Portal Handler
"success”

Enable-multicast

checks

is open, the Portal Handler checks to
see
1f
1t
record another multicast address for this portal.

has
If

1if the supplied portal

If not,

returns

If the portal
resources
to
not,

1t returns

identifies an open portal.

When the user calls Enable-multicast, the Portal
see

1If so,

Disable-protocol

not,

7.1.6

returns

"success".

When the user calls Disable-protocol,
see

-enabled.

returns

"no

1dent1f1cat10n

"unrecognlzed portal”.

Handler

identifies an open portal
v

resources".

If the Portal Handler has resources, 1t checks to see if
channel is on.
If not, 1t returns "channel not on",

the portal S

" If the channel 1is on, the Portal Handler puts the
multicast
address
in
the
portal's
1list.
If
this
1is
the first multicast address

enabled,

the Portal Handler calls,

enable multicast.

the

DNA

Ethernet

The Portal Handler then returns

Data

"success".

Link

Operation
7.1.7

Page 49

Disable-multicast

When the user calls Disable-multicast, the Portal Handler
see

the supplied portal

If not,

returns

1dent1f1cat10n

checks

1dent1f1es an open portal

"unrecognized portal"

If the portal is open, the
Portal
Handler
checks
to
see
1f
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 dlsable
multicast.

7.1.8

The

Portal Handler

then

returns

"success”

When the user calls Close, the Portal Handler checks to
supplied portal
returns

identification

If the portal is open, the
transmit

Portal

and receive

Handler

7.1.9

see

if the

empty,

the

Portal

checks

lists are empty

"Calls outstanding”.

the
it

releases

all

resources

they are not,

If the portal's transmit and receive

Handler

If not,

"unrecognized portal”.

portal's
returns

see

identifies an open portal.

for

lists

the portal

are

and

returns

"success".

Transmit

When the user calls Transmit, the Portal Handler checks to see if the
supplied portal

1dent1f1cat10n

1dent1f1es an open portal.

If not,

returns "unrecognized portal".

If the portal
resources
to
~returns

"no

is open, the Portal Handler checks to
see
1f
it
has
queue a
transmit for the portal.
1If it does not, it

resources”.

If the Portal Handler has resources,

channel

is on.

1If

not,

it checks to see 1f the portal's

returns "channel

not

on".

If the portal's channel
information
from
the

"pending",

for

is
on,
the
Portal
Handler
transfers
the
<call
1into the portal's transmit list, marked
action by the Transmitter.
The
Portal Handler
then

returns

"request

accepted”.

7.1.10

Transmit-poll

When the user calls Transmit—poll, the Portal Handler checks
if
the supplied portal identification
not, it returns "unrecognized portal"”.

to see

identifies an open portal.

Operation
If

see

the portal is open,
if

it is empty.

Page 50

the Portal Handler checks the transmit list to

If so,

returns

"none outstanding"

If,the»transmit list is not empty, the Portal Handler checks
if

the

first

request

state

"complete".

If not,

see

returns

"not

the first

request

is complete, the Portal Handler gets the

parameters
from the
1list
deallocates
the transmit
parameters.

7.1.11

for
list

return.
The Portal
entry
and
returns

output

handler then
the
output

Receive

When the user calls Receive, the Portal Handler checks to see if
the
supplied
portal identification identifies an open portal.
1If not, 1t
returns

"unrecognized portal”.

If the portal is open, the Portal Handler gets
frames
lost and zeros
1its
own record
of
Handler then checks to see if it has resources

the portal.
lost count.,

If it does not,
-

the portal's count
of
the count.
The Portal
to queue a receive for

returns
"no resources"
S
-

and the

frames

If the Portal Handler has re50urces, it checks to see 1f the portal's

channel
frames

lost

on.

1s not,

returns

"channel

not on"

and the

count.

If the portal's channel is
on,
the
Portal
Handler
transfers
the
information from
the
<call
1into the portal's receive list, marked
"pending", for action by
the Receiver.
The
Portal
Handler
then
returns "request accepted" and the frames lost count.

7.1.12

Receive-abort

When. the user calls Receive-abort, the Portal Handler checks
if
the
not, it

supplied portal 1dent1f1cat10n
returns "unrecognized portal”.

identifies
|

to see

an open portal

If the portal 1S open,,the Portal Handler checks the receive list

see

if it

1s empty.

so,

returns

"none outstanding”.

If the receive list is not empty, for each entry, the Portal

checks to see if the entry state
request "complete", and sets the
The

Portal

Handler then

returns

is "complete®.
return code
to

"success".

Handler

If not, 1t marks the
"receive
aborted".

complete"”.

Operation
'7.1.13

Page 51

Receive-poll

When the user calls Receive—poll, the Portal Handler checks to see if
the
not,

supplied
portal
identification
it returns "unrecognized portal".

If the portal
is open,
see

empty.

If the receive list
the
first
request
complete".

7.2

the Portal Handler checks the receive list

not
state

returns

empty,

1is

"none

the Portal
"complete”.

outstanding".
Handler

not,

checks

to see if
returns "not

If the first request
parameters
deallocates

open portal.

so,

identifies

is‘complete,

from
the
1list
the receive list

the Portal Handler gets the

output

for
return.
The
Portal handler then
entry and returns the output parameters.

Transmitter and Receiver

7.2.1

Transmitter

The Transmitter constantly scans the the transmit lists for all open
portals
for
'"pending"'lt

the first pending request.
Whenever
uses the information from that entry

it
to

finds one marked
send the frame.

If the pad flag for the portal 1nd1cates that paddlng 1S enabled
Transmitter
prefixes
the wuser's data with two bytes containing

the
the

length of the data as indicated by the user, low
order
byte
first.
If
the
resulting
data
1s
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
1t "complete".
The Transmitter then continues 1its scan
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

buffer.

This description also assumes the most complex form of protocol
type
matching
This
1is
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

Page 52

The Receiver has at least one Ethernet maximum size receive buffer of
1ts own.
The
Receiver
always
tries
to keep an Ethernet receive
outstanding.

When a frame is received, the Receiver scans the open portals
for
matching
recelver.
It
checks the protocol type list first.
TIf
finds .@ match here it may then check the multicast address list.
no match in the protocol type list, it goes on to the next portal.
receiver matches if one of the following 1s true:

.
.
.

The protocol type

physical address or

matches

and the

frame

destination

the broadcast address.

1is

a
1t
If

the

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
wuser
buffer
wunavailable
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.qg.
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
1length
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.

.TheReCeiver then marks the receive "complete”.
The Receiver repeats this procedure until

it has

checked

all

open

portals.

7.2.3

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 1t 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
counters are cleared simultaneously.

incremented.

All

Operation

Page 53
NOTE

The
names
used
1n
the
Ethernet
Version
2.0
specification
are
1indicated in parentheses.
A more
formal description of their operation can be found 1in
the
Pascal
procedural
model
found
1n
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
It is incremented by the number
errors (framesReceivedNoErrors).
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

by the number of
It is incremented
(frameSentNoErrors).
errors
bytes in
the
Ethernet
data
field of
the
transmitted
frame
|
|
|
(dataSize).
Frames received

(framesReceivedNoErrors)

This counter is 1ncremented by one every time a frame is received
with no

errors.

Frames sent (framesSentNoErrors)
This counter

1is

incremented

one

transmitted with no errors.

time

every
~

frame

Multicast bytes received (not specified in Ethernet V2.0)

This counter is updated every time a

frame

received ifor ‘a

and
errors (framesReceivedNoError
no
with
address
multicast
It is incremented by the number of bytes in the
address[1l] = 1).
Ethernet data field of the received frame (dataSize).
|

Multicast frames received (not specified 1in Ethernet V2. 0)

This counter is incremented by one every time a frame is received
for a multicast address with no errors (framesReceivedNoError and
address[1l]

= 1).

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

Operation

Page 54

This counter
1is
1incremented
by
one
every
time
a
frame
1is
transmitted
with
no
errors after being initially deferred.
It
does
not
get 1incremented
1f a
deferral takes
place
on
a
subsequent
attempt
to transmit
after a collision
if the first
attempt was not deferred.

Frames sent,

single collision

This counter

incremented

(transmitOkOneCollision)

one

every time

transmitted
with
no errors after a single collision
sequence; 1.e., successful on the second attempt.

Frames sent,

multiple collisions

This counter
1s
transmitted
with

backoff sequence;
attempt.

incremented
no
errors

i.e.,

frame

and backoff

(transmitOkMultipleCollisions)

by
one
every
time
after
more than one

successful on

the

third

a
frame
collision

1is
and

subsequent

Send failures (not specified in Ethernet V2.0)
This counter 1s 1incremented 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 1s 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
Carrier check failed
Short circuit
Open circuilt
Frame too long
Remote failure

Collision detect

(excessiveCollisionError)
(carrierSenseFailed)

to defer

check

(lateCollision)

failures

(collisionDetectFailed)

This counter is incremented by one every time no
collisionDetect
signal
1s
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 1s 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.
for

(Ethernet V2.0

specifies

framesReceivedCRCErrors

and

two

Block check error (frameCheckError)
Framing error (alignmentError)
Frame

too

long

separate

16-bit

counters

framesReceivedAlignErrors)

Operation

Page

Unrecognized frame destinations (not specified in Ethernet V2.0)

This counter 1s 1incremented by one every time a frame is received
but
discarded because there was no portal with the protocol
or multicast address enabled.

Data overruns

(not specified
in Ethernet V2.0)

This counter is incremented
by one every time an
is

type

incoming

frame

lost because the hardware was unable to keep up with the data

rate.

System buffers unavailable

(not specified in Ethernet v2.0)

This counter 1is 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 Vv2.0)
This counter 1s 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
1n
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.

specific.

The

operation

of the

self
self

test

initialization

1implementation

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
Carrier check failed
Short circuit
Open circuit

(excessiveCollisionError)
(carrierSenseFailed)

Operation

Frame

too

Remote

Page 56

long

failure

Collision detect

to defer (lateCollision)

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 folIOW1ng the deassertlon of carrierSense after
the
end of transmission.

ReCeive failed
This event 1is logged every time an incoming frame is lost.
may
be
due
to
one
during or immediately

or
more of
after a Data

Block check error (frameCheckError)
Framing error (alignmentError)
Data

Overrun

System buffer unavailable
User buffer unavailable
Unrecognized frame destination

This

the following faults occurring
Link ReceiveFrame operation.

APPENDIX

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

1is:

Meaning
Loopback

Value
90-00

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

Value

60-00

60-01
60-02

DNA Dump/Load (MOP)
DNA Remote Console (MOP)
DNA Routing

60-03

60-04

Local Area Transport

Diagnostics

60-05
60-06

60-07

Customer use

(LAT)
|

System Communication Architecture (SCA)

PROTOCOL TYPES AND MULTICAST ADDRESSES

DNA Phase IV nodes
through

have

addresses

AA-00-04-00-FF- FF

Specification).

The DIGITAL multicast

(see

addresses

Value

Page A-2

DNA

the

range

Meaning

DNA Dump/Load Assistance
'DNA Remote Console (MOP)

AB-00-00-03-00-00
AB-00-00-04-00-00

DNA Routing
DNA Routing

AB-00-04-00-00-00 thru
AB-00-04-00-FF-FF
AB-00-04-01-00-00 thru

Customer

AB-00-04-01-FF-FF

Layer

Functional

are:

AB-00-00-01-00- 00
AB-00-00-02-00-00

AB-00-03-00-00-00

AA-00-04-00-00-00

Routing

Layer
Layer

(MOP)

routers
end nodes

Local Area Transport

(LAT)

use
~

System Communication Architecture

(SCA)

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

'READER’S COMMENTS

NOTE: This formis for document comments only. DIGITAL will use comments submltted onthJS form at thg
company’s discretion. If you require a written reply and are eligible to receive one under Software i

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 fifid errors in this manual? If so, specify the error and the page number.

Please indicate the type of user/reader that you most nearly represent.

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

{. g

Jo - — —

--Do Not Tear - Fold Here and Tape

diloli 12l

—

— —

—

No Postage
Necessary
if Mailed in the |

Un-ited States

BUSINESS REPLY MAIL
FIRST CLASS PERMIT NO.33 MAYNARD MASS.

POSTAGE WILL BE PAID BY ADDRESSEE

SOFTWARE DOCUMENTATION

1925 ANDOVER STREET TW/EQ7

—

Cut Along Dotted Line

— — — — Do Not Tear - Fbld Here and Tape — — —« — — — — — — —

TEWKSBURY, MASSACHUSETTS 01876

i
R