Digital PDFs

AA-X440A-TK

December 1983

22 pages

Original

4.0MB

view download

OCR Version

1.4MB

view download

Document:	DECnet Digital Network Architecture Phase IV Ethernet Node Product Architecture Specification
Order Number:	AA-X440A-TK
Revision:	0
Pages:	22
Original Filename:

OCR Text

DECnet Dlgltal Network Architecture
Phase |V
Ethernet Node

Product Architecture Speclflcatlon

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.

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 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 that is not supplied by
DIGITAL or its affiliated companies.

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

The following are trademarks of Digital Equipment Corporation:

DIGITAL
DEC
PDP
DECUS
UNIBUS
COMPUTER LABS
COMTEX
,
-DDT
DECCOMM
ASSIST-11

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

DECnet

IAS

VAX

DATATRIEVE

MASSBUS
OMNIBUS
0S/8
PHA
-

RSTS
RSX
TYPESET-8
TYPESET-11
TMS-11

ITPS-10

SBI

VMS

PDT

TRAX

Distributed Systems Publicatidns typeset this manual using DIGITAL’s
TMS-11 Text Management System.

MGTPEALL

Table of Contents

N
w
®

W N

[

All

Nodes

.
.
¢i
.
.

[]
®
[]

.
¢«
e
«

«
e
«

¢«
e
o«

«
e
«

.«
e
.

D1gltal

Node

Type

Network Archltecture
Model

Control

Nodes

10
11

Layer

Remote Dump/Load Nodes . .
Network Management Layer
Remote Diagnosis Nodes . .
Network Management Layer

User

And Non goals

. «
e
e
.«

Network Management

Data Link Layer Requlrements e e
Network Management Layer Requ1rements
User Layer Requirements
Remote

[]

«
.

Q1 O1 U1 O

®
[]

o
[]
®

Ethernet

(OO NN

Goals,

Requirements
Goals
.« & ¢
Non-goals
.

Relation To

®
[1]

®
[]
[}
®
[]

B WWNDND
-

[]
[]

W WWWwWwwww

.«
.

Required Functions

.«
.

Requirements,

Models

[]

TSR

Introduction
Functions

(WO

CONTENTS

Requ1rements'
.
. .
Requ1rements
.
.
Requ1rements

Layer Requirements

Network Auto- conflguratlon
Goals ¢ ¢ ¢ ¢ i
e e e 4
Algorithm
. . . . . . .

12
12
12

12
12
13

e
.

Introduction

This document
connected
to

maintalnable

specifies the minimum required functions for a DEC
node
an Ethernet.
A node meeting this specification will be

and

usable

build

functions.

additional

collection

‘single
cable
‘to the

product

specific

Within the context of this specification,

This

Page 4

hardware

and

software

that

node

1is

appears

defined

other

nodes

functional unit.
This node is attached
to
a common
<coaxial
and uses this cable as a network communication medium according
Digital, Intel, Xerox Ethernet Specification.

specification

assumes

reader

familiarity

with

the

following

documents:

The

Ethernet,

A Local

Specifications,
No.

Network,
2.0,

Data

and

Intel,

and

Physical

Layer

Xerox),

Order

Link Functional

Spe01f1cat10n,

Version

1.0.0,

Order

Version

3.0.0,

AA-Y298A-TK

DECnet Dlgltal Network Architecture
No.

- Order

DNA Network

DNA

Layer
|

DNA Maintenance.Operations Functional
- Order No.
AA—X436A~TK

No .

Link

(Digital,

AA-K759B-TK

DNA Ethernet Data
No.

Area

Version

AA-N149A-TC

Management

Functional

©Specification,

(Phase

IV)

General

Specification,

.DeSCription;

Version 4.0.0,

Order

AA-X437A-TK

Routing

Layer

Functional

Spec1f1cat10n,

Version

2. @ G,

Order

No.

AA-X435A-TK

DNA Network Sérvices Protocol
4.0.0,

DNA Data

Order

Access

DNA Digital

Data

No.

(NSP) Functional Spe01flcatlon,

AA-X439A TK

Protocol

(DAP)

Communications

Specification,

Version

Functional

Message

4.1.0,

Order

Specification,

Protocol

No.

(DDCMP)

AA-K175A-TK

Version
Version

Functional

DNA Session'Control Functional Specificatibn, Version 1l.0.0, Order No.

\\\

AA-K182A-TK

Introduction

l.1

Functions

This

specification addresses

the

following

functional

Initialization and self-test —— the
"performs

declare

Communication

itself

Page

areas:

processing

that

node

operational.

service -— the

basic

Ethernet

communication

service.

Communication diagnosis —- testing the
communicate
over
the
Ethernet
and
problems

specific

System

diagnosis

faults

that

Down-—-line

—-—

prevent

load

host

node

the

Ethernet.

and

for

nodes.

testing

the

node

1tself

node

from

functioning

up—line

dump

storage and

Goals,

ability
of
nodes
to
isolating communication

and

using

and

1isolating

properly.

the

services

retrieval of system software over

1.2

Requirements,

Non—-goals

This

section describes characteristics

that

the

Ethernet

Node

design

must
have,
that
it will attempt to have, and that it will not have.
These constraints vary somewhat according
to
the
node's
individual
product requirements.
They must thus be considered 1in that context.

The various classes
of products are discussed

Requirements

1.2.1
This

in the Model section.

Ethernet Node design must

the

following

All Ethernet capabilities needed for
are

have

characteristics:

higher

1level

functions

available.

A network manager can control and observe
network

they

the

node

and

the

function.

The design complies with other applicable specifications.

The design can

adapted

legitimately different

products.

the

wvaried requirements
:

Page 6

Introduction
102.2

Goals

This

Ethernet

Node

the

have

attempts

design

following

characteristics:
0

Be efficient

in usage of processor, memory,

functions

Usage

predictable,

implement.

simple

simple,

and

are

Required

and network.

consilstent.

of software,

Node and network operation continue in the face

hardware,

management

problems.

Security will not be decreased

"already present

1.2.3

in a broadcast

from

low

the

level

that

network.

Non—-goals

The following are not goals of the Ethernet Node design:
l.

High

level

functions

addressed

beyond

"minimal
maintenance.
General
network
management functions are left for higher

those

required

for

functions
and
most
level definition.

Isolation of failing components within a node.
This
1s
left
to
the
specific
diagnostics
for
that
product.
This
architecture defines only primitive access to the node, usable
by

specific

Functional

diagnostics.

partitions

document
does
not
system processor and

Functions
not

for

implementations.

For

example,

address
the
division of labor
a communication processor.

within

a node

that do

avallable

across

the

not

affect

the

network.

Security beyond the earlier statement of goals.

this

between

network or

need

Models

Page

Models

This
section
describes
the
architecture to other network

relationship
of
the
Ethernet
Node
layers and modules.
It also defines the

model used to classify nodes so that their functional requirements can
‘be
stated.
Although
this
specification
only
describes
how
the
Ethernet
Data Link fits into the Digital Network
Architecture
(DNA),
the
Ethernet
Data Link could be integrated into any layered network
Communication
architecture
(for
example,
Digital's
System
Architecture).

\
\

Note that although there are other DNA layers, and
other
high
level
functions
1in
the
Network
Management
layer
that
wuse
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 functions addressed in this specification are found in the
User,
Network
Management,
and
Data
Link
Layers.
Those that are 1in 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.

\\.,/

2.1 Relation To Digital Network Architecture

The

following diagram shows

modules.

relationship of

|
-

Interfaces.

DL e DL e D DLt !

above

mentioned

User

N
1
RS :

ymm—————m————-— .
|
Maintenance [<----|

Operation

Layer
e e o

Management
Layer

Data
Link

———————————————————————— '

Layer

horizontal

Vertical

arrowheads

indicate

Network

Y
v
|
———————————————————— -——|
|
Ethernet Data Link
| <-"

indicate flow of control.

Interfaces,

the

Ethernet Node User

R
O
|
|

Arrows

the

indicate

Network

User

Management

Models

2.2

Page 8

Ethernet Node Typé Model

This section defines a model for viewing
Ethernet
Node
types.
The
model
1s
1in
terms
of
how the node is maintained and controlled as
related to the scope of this specification.
This model is used
later
in
this specification to define required functions for different node

types

in different

states.

There are three important characteristics that must be considered:

Control -- causing a node to load or dump its 'system

System

Causing
a node
image

location

actually
kept.
up-line dump or

Diagnosis

load

called

where

copies

+the

1mage

Transfer
of
down-line load.

detection

and

"booting".

isolation of

the

system
1is

the

failures

image.

image

are

process

the

node.

Each

of
these necessary
functions
may
be
performed
1locally
or
remotely,
that
1s,
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
1into eight

different
Any

configurations.

the

node

types

may

1in

malntenance
operations.
Changes
system
operation,
sometimes
1in
sometimes due to outside control.

one

three

states

between these states are
implementation-specific

relative

a matter of
ways
and

Primitive -- the node
supports
only
the
absolute minimum
maintendnce
functions
for 1its
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
1is
appropriate to
smaller nodes that may not have room for all malntenance
and
normal functlons simultaneously.

Normal

the

node

its

normal

operating

mode.

‘Page 9

Required Functions
Required Functions

This section specifies

the

required

functions

interface

for

the

various node types and states. Unless specified otherwise, functions
are required regardless of node states as described 1in the Models
|

section.

Inclusion of optional
Any functions not required are optional.
requirements. For
product
specific
on
functions must be Dbased
on testing
communicati
active
do
to
able
be
example, a node that is to

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 in

applicable protocol specification.

The broadcast address must not be

intended

for

all

used

compliance

with

frame

unless

regardless

nodes,

function

the
1S

manufacturer.

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

‘

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

Data Link Layer Requirements

3.1.1

The following User Interface functions must be implemented:
.

Open

.
.

Enable-multicast
Disable-multicast

.
.

Enable-protocol
Disable-protocol

.
.
.

Transmit
Transmit-poll
Receilve
Receive-poll

Receive-abort

Required Functions

Page 10

~The following Network Management
.
.

Read-channel
Enable-channel

.
.

Disable-channel
Read-counters

functions must be

implemented:

The Network Management Set-address function
must
be
implemented
nodes that have more than one channel.
It must also be implemented
all nodes that do not automatically have the correct DECnet address
described below.
All channel
implemented

counters
except

must
for

be implemented.
All portal counters must Dbe
the
maintenance
protocols
for
loopback,

l\\-——///

console, and dump/load.
In the
portal counters are optional.

case

the

All event information must be implemented.

maintenance

protocols,

All event information must

be availlable through either the User transmit
the Network Management Read-event function.

3.1.2

on
on
as

and receive

functions

Network Management Layer Requirements

The Loop Server must be

implemented.

Furthermore,

it must be

enabled

whenever
the
Data Link state
is "on".
The only optional Loop Server
functions are Enable-assistance and Disable-assistance.
Note that all
required
functions
must operate regardless of such special states as
"promiscuous receive”.
The

Console

Server

Identify-self

function must

implemented.

The

Console
Server
must
respond
to
a
remote
Read-identity function.
Furthermore, these functions must be enabled whenever
the Data
Link

state
In

"on".

normal

state,

Read-counters
In

normal

the

Console

Server

function.

state,

DECnet

must

respond

|
Phase

remote

|
node

must

set

its

physical

address

to a function of its DECnet address. Referring to transmission order,
the first three bytes of the address consist of
one
of
the
address
groups assigned to Digital by Xerox.
The fourth byte is a zero.
The
fifth byte is the low order byte of the 16 bit DECnet address, and the
sixth byte is the high order byte of the 16 bit DECnet address.
|
So, for example, DECnet node number
AA-00-04-00-0E-00
(this
format
discussed in a later section).

14 would have the Ethernet
for
address display
1is

address
further

Page 11

Required Functions
User Layer Requirements

3.1.3

the node must perform sufficient
When enabling the Data Link,
of using the network, to believe
initialization and self test, short
If it fails this self test, it must
that it can communicate properly.
not

come onto the network.

report
node must
The
necessarily as events.

all

event

1n
1information
TR

some

way,

not

The node must implement some means of displaying the hardware address.
The node must implement some means of displaying the physical address
requirements
These
if it can be different from the hardware address.

can

be met, for example, with a printed label or a machine-accessible
o

output.

The format for display of an Ethernet address must be according to the
That
as found in the Ethernet Specification.
lnter-company standard
the
of
Each byte
standard is repeated here for reader convenience.
The bytes are displayed
address is displayed as a hexadecimal number.
separated
from left to right, in the order that they are transmitted,
The bits within the bytes are transmitted from right to
by hyphens.
left.

The first byte
As an example, consider the address AB—CD—EF—01—23—45.
The first bit transmitted 1s the
1is AB, the last is 45.
transmitted
example 1s a multicast
therefore the
low order bit of AB, a one,
1is the high. order bit of 45, a
transmitted
bit
last
The
address.
zero.
The first three bytes (AB, CD, and EF) are assigned
by Xerox.
the
assigned by
are
45)
and
23,
(01,
three bytes
last
The
manufacturer.

call
Whenever the Data Link state is "on", the node must periodically
definition
precise
the
For
the Console Server Identify-self function.
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

‘remotely
node to

3.2.1

states

controlled.

load or dump

additional
This

1itself.

requirements

for

node

that

1is a node that can be forced by a remote

Network Management Layer Requirements

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

Required Functions
3.3

Page 12

Remote Dump/Load Nodes

This section states additional
requirements
for
a
remote
storage of 1ts system 1mage.
This is a node
loaded or

3.3.1

up-line dumped.

Network Management

node
that
wuses
that 1is down-line

Layer Requirements

The node must implement the Dump/Load Requester Load-self function
1in
the
primitive state.
The Load-self function should start as far into
the multi-stage load process
as possible.
In other words
1t
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

requ1rements

for

nodes

that

are

remotely diagnosed.

3.4.1

Network Management Layer Requirements

The node must
functlons.

implement

The requlred
Console
primitive
state
1if
loadable,
support

3.4.2

Console

Server

response

Server
functions
need
the
node
1is
remotely

and the node's

self test

covers

them.

all

the

console

carrier

not
Dbe
available 1in
<controlled,
down-line
resources

neccessary

User Layer Requirements

The node must either keep the Console Server available for remote
or

implement some reliable way of making

1t available.

use

Network Auto-configuration

Page

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
1in
selecting
the
algorithm.
This
procedure
1s
specified as part of
general maintenance operations because
it is Ethernet specific.

4.1

Goals

The
following
goals
were
auto-configuration algorithm:

the

within

one

hour.

Configuration

With a 0.999 probability,
whose

available

used

Data Link

state

configuration

1includes

all

nodes

"on".

The configuration information includes phy51cal addresses
system identification information.
|
|

4.,

The process 1s of low overhead
and the overall network.

The process 1s simple

The process works correctly when multlple

implement.

determine

for

the

for the

simple

nodes

conflguratlon.

7. The process 1s

and

of' low

determining
the
configuration
conflict with the other goals.

4.2

selection
|

when

being

overhead on
this

goal

configured

nodes

and

attempt

to
:

the node

not

1in

Algorithm

Simply stated, every node periodically sends
a
system
1dentification
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
1list
from
the
received
messages.
The
minimum
requirement
to
implement
this 1s 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
Wait.

ENDWHILE

Identify-self.

Network Auto-configuration

Page

The wait time base is ten minutes.
On a thousand
node
network
this
creates
an
average traffic of 100 frames/minute.
Assuming a network
capacity of 60,000 frames/minute, this represents an overhead of
less
than 0.2% of network bandwidth.
In order to avoid overwhelming a listener with synchronized
messages,
each node
modifies its timer value so that nodes started at the same
time will not transmit at the same time.
The timer modification is
a
16
bit
signed
number.
The
number must be random or pseudo-random
based on a seed that 1s unique across similar implementations (such as
the node address).
-

The resulting number is treated as milliseconds divided
by
4.
This
number
1s
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,
1t

the

time between

Assuming

network

that

random

minutes,

rate

all

sending

identification messages.

distribution
came

about

of
the

modifications,
same

time

would

and uses

thousand

transmit

over

node
four

frames/second.

A node collecting a list should listen for at least 40 minutes.
A node that has a list and wishes to confirm it can

use

Requester

list.

Read-identity

function

to each

node

its

the

Console

N’

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

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

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

Dpid you find errors
in this manual?

If s0, specify the
error and the page
number.

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

Assembly language programmer

Higher-level language programmer

Occasional programmer (experienced)

User with little programming experlence

Student programmer

Other (please specify)

Name

. Date

Organization
Street

City

State

Zip Code
or

Country

|- == — —Do Not Tear - Fold Hereand Tape —

— — — — —- — — — — — — —

— — —

Jolialiltlall

No Postage

Necessary'
if Mailed in the

United States

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

POSTAGE WILL BE PAID BY ADDRESSEE

SOFTWARE DOCUMENTATION

1925 ANDOVER STREET TW/EQ7

TEWKSBURY, MASSACHUSETTS 01876

- = = = = — —

Cut Along Dotted Line

| —— - = Do Not Tear - Fold Here and Tape — — — —_—_—