Digital PDFs

AA-X440A-TK

December 1983

22 pages

Original

0.3MB

Document:	DECnet Digital Network Architecture Phase IV Ethernet Node Product Architecture Specification
Order Number:	AA-X440A-TK
Revision:	000
Pages:	22
Original Filename:	http://decnet.ipv7.net/docs/dundas/aa-x440a-tk.pdf

OCR Text

O m e t Digital Network Archftecture
Phaae IV
Ethfnet NodÃ
mduct m i f c t u r e Sp~iflcdmn
OrtttriNo. &A-X440Ai*TK

sott ware

DECnet Digital Network Architecture
Phase IV
Ethernet Node
Product Architecture Specification
Order No. AA-X440A-TK

December 1983
This document specifies the minimum required functions for a DEC node
connected to an Ethernet. A node meeting these requirements will be
maintainable and usable to build additional product specific functions.

SUPERSESSIONIUPDATE INFORMATION: This is a new manual.
VERSION:

1 .O.O

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

digital equipment corporation maynard, massachusetts

First Printing, December 1983

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

No responsibility is assumed for the use or reliability of software on equipment t h ~ + qr" supplied by
DIGITAL or its affiliated companies.

T h e 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
POP
DECUS
UNIBUS
COMPUTER LABS
COMTEX
DDT
DECCOMM
ASSIST- 11
VAX
DECnet
DATATRIEVE

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

MASSBCS
OMNIBUS
OS/8
PHA
RSTS
RS X
TYPESET4
TYPESET-1 1
TMS- 11
ITPS- 10
SBI
PDT

Distributed Systems Publications typeset this manual using DK'ilTAL's
TMS- 1 1 Text Management System.
MC.TI'KALl.

Page 3

Table of Contents
CONTENTS

Introduction . . . . . . . . . . . . . . . . . . . . 4
Functions
4
Requirements. Goals. And Non-goals
5
Requirements
5
Goals
5
Non-qoa 1s
5

. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . .. .. .. .. .. .. .. ..
.....................
...................
.
Models . . . . . . . . . . . . . . . . . . . . . . . -,
Relation
Digital Network Architecture . . . . .
Ethernet Node Type Model . . . . . . . . . . . . . 8
Required Functions . . . . . . . . . . . . . . . . . 9
All Nodes . . . . . . . . . . . . . . . . . . . . 9
Data Link Layer Requirements . . . . . . . . . . 9
Network Management Layer Requirements . . . . 10
User Layer Requirements . . . . . . . . . . . 11
. . . . . . . . . . 11
Remote Control Nodes . . .
Network Management Layer Requirements . . . . 11
Remote Dump/Load Nodes . . . . . . . . . . . . . 12
Network Management Layer Requirements . . . . 12
RemoteDiagnosisNodes . . . . . . . . . . . . . 12
Network Management Layer Requirements . . . . 12
User Layer Requirements . . . . . . . . . . . 12
Network Auto-configuration . . . . . . . . . . . . 13
Goals . . . . . . . . . . . . . . . . . . . . . 13
Algorithm . . . . . . . . . . . . . . . . . . . 13
1

;

Introduction

T h i s d o c u m e n t s p e c i f i e s t h e minimum r e q u i r e d f u n c t i o n s f o r a D L C n o a e
connected t o an E t h e r n e t .
A n o d e m e e t i n g t h i s s p e c i f i c a t i o n w i 11 be
m a i n t a i n a b l e and
usable t o build
additional
product
specitic
functions.
is d e f i n e d a s a
W i t h i n t h e c o n t e x t o f t h i s s p e c i f i c a t i o n , a node
t h a t appears t o o t h e r nodes a s a
c o l l e c t i o n of
h a r d w a r e and
single functional unit.
T h i s n e d e is a t t a c h e d t o a common c o a x i a l
c a b l e a n d u s e s t h i s c a b l e a s a n e t w o r k c o m m u n i c a t i o n medium a e c o r d i n q
t o t h e D i q i t a l , I n t e l , Xerox E t h e r n e t S p e c i f i c a t i o n .
(--f6'-1-

This specification
documents :

assumes

reader

The E t h e r n e t , A L o c a l A r e a N e t w o r k ,

familiarity

with

the

following

D a t a L i n k L a v e r and ~ h v s i c a lL a y e r

DNA E t h e r n e t D a t a L i n k F u n c t i o n a l S p e c i f i c a t i o n , V e r s i o n 1 . 0 . 0 ,
AA-YT^SA'^'~~

uraer

DNA M a i n t e n a n c e O p e r a t i o n s F u n c t i o n a l
O r d e r No.
AA-X436A-TK

3.0.0,

NO.

Specification,

DECnet D i i t a l Network A r c h i t e c t u r e ( P h a s e
Odre*r
AA-N 149A-TC

Version

IV)
General
-

Description,

DNA' Network Management F u n c t i o n a l S p e c i f i c a t i o n , V e r s i o n 4.k).B,
No.
AA-X437A-TK

DNA R n u t i n q L a y e r F u n c t i o n a l S p e c i f i c a t i o n , V e r s i o n 2 . D . & ,
AA-X435A-TK

Order

No.

DNA Network S e r v i c e s P r o t o c o l (NSP) F u n c t i o n a l S p e c i f i c a t i o n ,
4 . 0 . 0 , O r d e r No.
AA-X439-

Version

DNA D a t a
Access Protocol
(DAP)
-5 . 6 . 0 , O r d e r No.
AA-K177A-TK

Version

DNA D i

-h

Functional

Specification,

i t a l Data Communications Message
Protocol
(DDCMP)
i m o n , V e r s i o n 4 . 1 . 0 , O r d e r No.
AA-K175A-TK

DNA S e s s i o n C o n t r o l F u n c t i o n a l S p e c i f i c a t i o n , V e r s i o n

AA-K182A-TK

1.0.0,

functional
O r d e r No.

Introduction
1.1

Page 5

Functions

This specification addresses the following functional areas:

1.2

I n i t i a l i z a t i o n and s e l f - t e s t -- t h e p r o c e s s i n g
performs t o d e c l a r e i t s e l f o p e r a t i o n a l .

Communication
service.

Communication d i a g n o s i s
t e s t i n g the a b i l i t y of
n o d e s rc
communicate o v e r t h e E t h e r n e t and
i s o l a t i n g communication
problems t o s p e c i f i c nodes.

System d i a g n o s i s
testing
t h e node i t s e l f
and
isolatinq
f a u l t s t h a t p r e v e n t a node from f u n c t i o n i n g p r o p e r l y .

Down-line l o a d and u p - l i n e dump
using
t h e s e r v i c e s of
a
h o s t node
f o r s t o r a g e and r e t r i e v a l o f s y s t e m s o f t w a r e o v e r
the Ethernet.

service

-- t h e

basic

hithernet

that

node

communication

R e q u i r e m e n t s , G o a l s , and N o n - g o a l s

T h i s s e c t i o n d e s c r i b e s c h a r a c t e r i s t i c s t h a t t h e E t h e r n e t Node d e s i g n
i t w i l l a t t e m p t t o h a v e , and t h a t i t w i l l n o t h a v e .
must h a v e ,
that
T h e s e c o n s t r a i n t s v a r y somewhat a c c o r d i n g t o
the node's
individual
product requirements.
They must t h u s b e c o n s i d e r e d i n t h a t c o n t e x t .
The v a r i o u s c l a s s e s o f p r o d u c t s a r e d i s c u s s e d i n t h e Model s e c t i o n .

1.2.1

Requirements

T h i s E t h e r n e t Node d e s i q n m u s t h a v e t h e f o l l o w i n g c h a r a c t e r i s t i c s :
o

A l l E t h e r n e t c a p a b i l i t i e s needed

for

higher

level

functions

are available.
o

A n e t w o r k m a n a g e r c a n c o n t r o l and o b s e r v e

the

node

and

the

network a s they f u n c t i o n .
o

The d e s i q n c o m p l i e s w i t h o t h e r a p p l i c a b l e s p e c i f i c a t i o n s .

The d e s i q n c a n b e a d a p t e d
to
l e g i t i m a t e l y d i f f e r e n t products.

the

varied

requirements

Page 6

Introduction
1.2.2

Goals

T h i s E t h e r n e t Node
characteristics:

desiqn

attempts

have

the

tollowing

Be e f f i c i e n t i n u s a g e o f p r o c e s s o r , memory, and n e t w o r ~ .

Required f u n c t i o n s a r e simple t o irplement.

Usage is p r e d i c t a b l e , s i m p l e ,

Node and n e t w o r k o p e r a t i o n c o n t i n u e i n t h e f a c e
h a r d w a r e , o r management p r o b l e m s .

S e c u r i t y w i l l n o t b e d e c r e a s e d from t h e
a l r e a d y p r e s e n t i n a b r o a d c a s t network.

;:Â¥"Â

^*nC:istent.

low

of
level

software,
that

The f o l l o w i n g a r e n o t q o a l s o f t h e E t h e r n e t Node d e s i g n :
1.

High l e v e l f u n c t i o n s a d d r e s s e d beyond u h o s e r e q u i r e d
for
minimal maintenance.
G e n e r a l network f u n c t i o n s ana most
management f u n c t i o n s a r e l e f t f o r h i g h e r l e v e l d e f i n i t i o n .

I s o l a t i o n of f a i l i n g components w i t h i n a node.
T h i s is l e f t
This
to
the
specific
diaqnostics
f o r t h a t product.
a r c h i t e c t u r e d e f i n e s o n l y p r i m i t i v e a c c e s s t o t h e node, u s a b l e
by s p e c i f i c d i a g n o s t i c s .

Functional p a r t i t i o n s f o r implementations.
bor example,
tnis
document d o e s n o t a d d r e s s the d i v i s i o n o f l a b o r between a
s y s t e m p r o c e s s o r and a c o m m u n i c a t i o n p r o c e s s o r .

F u n c t i o n s w i t h i n a node t h a t do n o t a f f e c t t h e network o r need
n o t be a v a i l a b l e a c r o s s t h e n e t w o r k .

S e c u r i t y beyond t h e e a r l i e r s t a t e m e n t o t q o a l s .

Page 7

Models
2

Models

This section describes the relationship of the
Ethernet
Node
architecture to other network layers and modules. I t also defines the
model used to classify nodes so that their functional requirements can
be stated.
Although this specification only describes how the
Ethernet Data Link fits into the Digital Network Architecture (DNA),
the Ethernet Data Link col.ildbe integrated into any layered network
architecture
(for
example,
Digital's
System
Communication
Architecture).

2.1

Relation To Digital Network Architecture

The functions addressed in this specification are found in the User,
Network Management, and Data Link Layers.
Those that are in the
Network Management Layer are defined in the DNA Maintenance Operations
Functional Specification.
The Data Link functions are in the DNA
Ethernet Data Link Functional Specification. The User functions are
defined in this specification.
Note that although there are other DNA layers, and other high level
functions in the Network Management layer that use them, their
existence is not directly relevant to this specification.
The high
level functions they represent may be provided by DNA or any other
similar architecture.
The following diagram shows the relationship of
modules.

the

above

mentioned

........................

Ethernet Node User

User
Layer
. . . . l.....l...l..........
I
I
I
----I
I
I
V
I
Network
------------1
Management
I
1
1 Maintenance I<---1
Layer
I
I Operation I
I
I
' ------------I

........................

. . . . l.....l......l......
v

........................

Ethernet Data Link

........................

I<-'
I

Data
Link
Layer

Arrows indicate flow of control. Vertical arrowheads indicate User
Interfaces,
horizontal
arrowheads
indicate
Network Management
Interfaces.

Page 8

Models
2.2

Ethernet Node Type Model

This section defines a model for viewing Ethernet Node types.
The
model is in terms of how the node is maintained and controlled as
related to the scope of this specification. This model is used later
in this specification to define required functions for different node
types in different states.
There are three important characteristics that must be considered:
1.

Control -- causing a node to load or .iupii.-,
Causing a node to load is called "booting".

System image location -- where copies of the system image are
actually kept.
Transfer of the image is the process o f
up-line dump or down-line load.

Diagnosis -- detection and isolation of failures in the node.

system

image.

Each of these necessary functions may be performed locally or
remotely, that is, within the node itself, or on its behalf by some
other node.
Since these three functions may independently
be
performed locally or remotely, they can be combined into eight
different configurations.
Any of the node types may be in one of three states relative to
maintenance operations. Changes between these states are a matter of
system operation, sometimes in implementation-specific ways
and
sometimes due to outside control.
Primitive -- the node supports only the absolute minimum
maintenance functions for its type.
For example, these
functions may be implemented in read-only memory, while all
other functions are available only when explicitly loaded.
Maintenance -- the node supports all maintenance functions
appropriate to its type.
This state is appropriate to
smaller nodes that may not have room for all maintenance and
normal functions simultaneously.
Normal -- the node is in its normal operating mode.

'Required Functions
3

Page 9

Required Functions

This section specifies the required interface functions for the
various node types and states. Unless specified otherwise, functions
are required regardless of node states as described in the Models
sect ion.
Any functions not required are optional.
Inclusion of optional
functions must be based on specific product requirements.
For
example, a node that is to be able to do active communication testing
must implement the Loop Requester.

3.1

All Nodes

The functions in this section are required regardless of node type.
The following statements of principle must be met:

. All protocol type usage must

be
applicable protocol specification.

compliance

with

the

frame
function

is
or

. The broadcast address must not be used unless a
intended
for
manufacturer.

all

nodes,

regardless

. No two channels on the same cable may have the same physical
address.

. In any case of a node with multiple Ethernet

channels, the
User
Layer must resolve all potential conflicts.
For
example, a node with multiple channels may have to resolve
conflicts between multiple attempts to take control of its
remote console.

3.1.1

Data Link Layer Requirements

The following User Interface functions must be implemented:
Open
Enable-protocol
Disable-protocol
Enable-multicast
Disable-multicast
Close
Transmit
Transmit-poll
Rece ive
Receive-poll
Receive-abort

Required Functions

Page 10

The following Network Management functions must be implemented:

The Network Management Set-address function must be implemented o n
nodes that have more than one channel. I t must also be implemented on
all -'-^a< that do not automatically have the correct DECnet address as
descr i bed below.
All channel counters must be implemented. All portal counters must be
implemented
except for the maintenance protocols for loopback,
console, and dump/load. In the case of the maintenance protocols,
portal counters are optional.
All event information must be implemented. All event information must
be available through either the User transmit and receive functions or
the Network Management Read-event function.

3.1.2

Network Management Layer Requirements

The Loop Server must be implemented. Furthermore, it must be enabled
whenever the Data Link state is "on". The only optional Loop Server
functions are Enable-assistance and Disable-assistance. Note that all
required functions must operate regardless of such special states as
promiscuous rece ivefl.
The Console Server Identify-self function must be implemented.
The
Console Server must respond to a remote Read-identity function.
Furthermore, these functions must be enabled whenever the Data Link
state is o n " .
In

normal

state,

the

Console

Server

must

respond

remote

Read-counters function.

In normal state, a DECnet Phase IV node must set its physical address
t o a function of its DECnet address* Referring to transmission order,
the first three bytes of the address consist of one of the address
groups assigned to Digital by Xerox. The fourth byte is a zero. The
fifth byte is the low order byte of the 16 bit DECnet address, and the
sixth byte is the high order byte of the 16 bit DECnet address.
So, for example, DECnet node number 14 would have the Ethernet address
AA-OO-04-OO-OE-00
(this
format for address display is further
discussed in a later section).

Page 11

Required Functions
3.1.3

User Layer Requirements

When enabling the Data Link, the node must perform sufficient
initialization and self test, short of using the network, to believe
that it can communicate properly. I f it fails this self test, i t must
not come onto the network.
The node must report
necessarily as events.

all

event

information

some

way,

not

The node must implement some means of d i ~ p l - ~ ' , ithe
g hardware address.
The node must implement some means of displaying the physical address
if it can be different from the hardware address. These requirements
can be met, for example, with a printed label or a machine-accessible
output.
The format for display of an Ethernet address must be according to the
inter-company standard as found in the Ethernet Specification. That
standard is repeated here for reader convenience. Each byte o f the
address is displayed as a hexadecimal number. The bytes are displayed
from left to right, in the order that they are transmitted, separated
by hyphens.
The bits within the bytes are transmitted from right to
lei t.
As an example, consider the address AB-CD-EF-01-23-45. The first byte
transmitted is AB, the last is 45. The first bit transmitted is the
low order bit of AB, a one, therefore the example is a multicast
address.
The last bit transmitted is the high.order bit of 45, a
zero. The first three bytes ( A B , CD, and EF) are assigned by Xerox.
The
last
three bytes (01, 23, and 45) are assigned by the
manufacturer.
Whenever the Data Link state is "on", the node must periodically call
the Console Server Identify-self function. For the precise definition
of this period and an explanation of the use of this function, see the
section on Network Auto-configuration.

3.2

Remote Control Nodes

This section states additional requirements for a node that is
remotely controlled.
This is a node that can be forced by a remote
node to load or dump itself.

3.2.1

Network Management Layer Requirements

The node must implement response to the Console Server Boot function
in primitive and maintenance states. The node must implement this
response in normal state i f it does not reliably and automatically go
to primitive or maintenance state when it malfunctions.

Required Functions
3.3

Page 12

Remote Dump/Load Nodes

This section states additional requirements for a node that uses
remote storage of its system image. This is a node that is down-line
loaded or up-line dumped.

3.3.1

Network Management Layer Requirements

The node must inip~t~nenthe Dump/Load Requester Load-self function in
the primitive state. The Load-self function should start as far into
the multi-stage load process as possible. In other words it should
not go through the load of a secondary or tertiary loader program
unless required by implementation constraints.

3.4

Remote Diagnosis Nodes

This section states additional requirements for nodes that are
remotely diagnosed.

3.4.1

Network Management Layer Requirements

The node must implement Console Server response to the console carrier
functions.
The required Console Server functions need not be available in
primitive
state i f the node is remotely controlled, down-line
loadable, and the node's self test covers all resources neccessary to
support them.

3.4.2

User Layer Requirements

The node must either keep the Console Server available for remote
or implement some reliable way of making it available.

use

Network Auto-configuration
4

Page 13

Network Auto-configuration

The functions required above allow the automatic determination of the
configuration of an Ethernet network.
This section explains the
algorithm for using the required primitives and the goals used in
selecting the algorithm.
This procedure is specified as part of
general maintenance operations because it is Ethernet specific.

4.1

uuals

The
following
goals
were
auto-configuration algorithm:

used

the

selection

Configuration available within one hour.
With a 0.999 probability, configuration
whose Data Link state is "on".

includes

all

nodes

The configuration information includes physical addresses and
system identification information.
The process is of low overhead for the nodes being configured
and the overall network.
The process is simple
implement.

for

the

nodes

being

The process works correctly when multiple
determine configuration.
The process is simple and of
determining the configuration
conflict with the other goals.

4.2

configured

nodes

attempt

to
to

low overhead on the node
when this goal is not in

Algorithm

Simply stated, every node periodically sends a system identification
message to the remote console service multicast address. A node
wishing to determine network configuration listens to this multicast
address for a multiple of the transmission period and builds the
configuration list from the
received
messages.
The
minimum
requirement to implement this is that each system periodically call
the Console Server Identify-self function.
The periodic transmission algorithm is:
Compute wait time.
WHILE Data Link state = "on"
CALL Console Server Identify-self.
Wait.
ENDWH I LE

Network Auto-configuration

Page 14

The wait time base is ten minutes. On a thousand node network this
creates an average traffic of 100 frames/minute. Assuming a network
capacity of 60,000 frames/minute, this represents an overhead o f less
than 0.2% of network bandwidth.
In order to avoid overwhelming a listener with synchronized messages,
each node modifies its timer value so that nodes started at the same
time will not transmit at the same time. The timer modification is a
16 bit signed number.
The number must be random or pseudo-random
based on a seed that i Â ¥
liniaue across similar implementations (such as
the node address).
This
The resulting number is treated as milliseconds divided by 4.
number is added to the number of milliseconds divided by 4 in 10
minutes (150,000) resulting in a timer value of 10 minutes plus or
minus about 2 minutes 11 seconds, to a resolution of 4 milliseconds.
The node then truncates this to its nearest timer resolution, and uses
it as the time between sending identification messages.
Assuming a random distribution of modifications, a thousand node
network that all came up at the same time would transmit over four
minutes, a rate of about 4 frames/second.
A node collecting a list should listen for at least 40 minutes.
A n o d e that has a list and wishes to confirm it can use the
Requester Read-identity function to each node on its list.

Console

DECnet Digital Network Architecture Phase IV
Ethernet Node Product Architecture Specification
AA-X440A-T K

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

Did you find this manual understandable, usable, :.id -:;ell-organized? Please make suggestions for improvement.

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

Please indicate the type of userlreader that you most nearly represent.
0

0
0

0
0
0

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

Street
City

State

Zip Code
or
Country

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

Necessary

' BUSINESS REPLY MAIL

FIRST CLASS PERMIT N0.33 MAYNARD MASS.
POSTAGE WILL BE PAID BY ADDRESSEE

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

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

I
I