Digital PDFs

AA-K181A-TK

October 1980

149 pages

Original

5.3MB

Document:	Network Management Functional Specification
Order Number:	AA-K181A-TK
Revision:	0
Pages:	149
Original Filename:

OCR Text

Order No. AA-K181A-TK

DECnet
DIGITAL Network Architecture
Network Management
Functional Specification
Version 2.0.0

DEenet
DIGITAL Network Architecture
(Phase III)
Network Management
Functional Specification
Order No. AA-K181 A-TK
Version 2.0.0

October 1980

This document describes the functions, structures, protocols,
algorithms, and operation of the DIGITAL Network Architecture Network Management modules. It is a model for DECnet
implementations of Network Management software. Network
Management provides control and observation of DECnet network functions to users and programs.

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

digital equipment corporation · maynard, massachusetts

First Printing, October 1980

This material may be copied, in whole or in part, provided that the
copyright notice below in included in each copy along with an
acknowledgment that the copy describes protocols, algorithms, and
structures developed by Digital Equipment Corporation.
This material may be changed without notice by Digital Equipment
Corporation, and Digital Equipment Corporation is not responsible for
any errors which may appear herein.

~ 1980 by Digital Equipment Corporation

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-II
VAX
DECnet
DATATRIEVE

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

MASSBUS
OMNIBUS
OS/8
PHA
RSTS
RSX
TYPESET-8
TYPESET-ll
TMS-ll
ITPS-IO
.SBI
PDT

CONTENTS
Page
1.0
2.0
2.1
2.2
2.3
3.0
3.1
3.1.1
3.1.2
3.1.3
3.1.4
3.1.5
3.1.6
3.2
3.2.1
3.2.2
3.2.3
3.2.4
3.2.5
3.2.6
3.3
3.3.1
3.3.1.1
3.3.1.2
3.3.1.3
3.3.1.4
3.3.1.5
3.3.2
3.3.2.1
3.3.2.2
3.3.2.3
3.3.2.4
3.3.2.5
3.3.3
3.3.4
3.3.4.1
3.3.4.2
3.3.5
3.3.6
3.3.6.1
3.3.6.2
3.3.7
3.3.8
3.3.8.1
3.3.8.2
3.3.8.3
3.3.8.4
3.3.9
3.3.10
4.0

INTRODUCTION
FUNCTIONAL DESCRIPTION
Design Scope
Relationship to DIGITAL Network Architecture
Functional Organization within DIGITAL Network
Architecture
NETWORK CONTROL PROGRAM (NCP)
Network Control Program Functions
Changing Parameters
Gathering Information
Down-line Loading
Up-line Dumping
Testing Line and Network
Zeroing Counters
Network Control Program Operation
Specifying the Executor
Program Invocation, Termination, and Prompting
Privileged Commands
Input Formats
Output Characteristics
Status and Error Messages
Network Control Program Commands
SET and DEFINE Commands
SET and DEFINE EXECUTOR NODE destination-node
SET and DEFINE KNOWN Entity Commands
SET and DEFINE LINE Commands
SET and DEFINE LOGGING Commands
SET and DEFINE NODE Commands
CLEAR and PURGE Commands
CLEAR and PURGE EXECUTOR NODE Commands
CLEAR and PURGE KNOWN Entity Commands
CLEAR and PURGE LINE Commands
CLEAR and PURGE LOGGING Commands
CLEAR and PURGE NODE Commands
TRIGGER Command
LOAD Command
LOAD NODE Command
LOAD VIA Command
DUMP Command
LOOP Command
LOOP LINE Command
LOOP NODE Command
SHOW QUEUE Command
SHOW and LIST Commands
Information Type Display Format
Counter Display Format
Tabular and Sentence Formats
Restrictions and Rules on Returns
ZERO Command
EXIT Command
NETWORK MANAGEMENT LAYER

iii

1
3
3
5
6

9
9
9

10
10
10
11
11
11
11
12
12
12
14
14
15
18
19
19
19
22
24
29
29
29
29
30
30
32
32
32
33
33
34
34
34
35
35
36
36
37
39
39
40
44

CONTENTS (Con t. )

Page
4.1
4.1.1
4.1.2
4.1.3
4.1.4
4.1.4.1
4.1.4.2
4.1.4.3
4.1.4.4
4.1.5
4.1.5.1
4.1.5.2
4.2
4.2.1
4.2.2
4.2.3
4.2.4
4.2.4.1
4.2.4.2
4.2.5
4.2.6
4.2.7
4.2.8
4.2.9
4.2.10
4.3
4.3.1
4.3.2
4.3.3
4.3.4
4.3.5
4.3.6
4.3.7
4.3.8
4.3.9
4.3.10
4.3.11
4.3.12
4.3.13
5.0
5.1
5.2
5.3
5.3.1
5.3.2
5.3.3

Network Management Layer Modules
Network Management Access Routines and Listener
Local Network Management Functions
Line Watcher
Line Service Functions
States and Substates
Priority Control
Line State Algorithms
Line Handling Functions
Event Logger
Event Logger Components
Suggested Formats for Logging Data
Network Management Layer Operation
Down-line Load Operation
Up-line Dump Operation
Trigger Bootstrap Operation
Loop Test Operation
Node Level Testing
Data Link Testing
Change Parameter Operation
Read Information Operation
Zero Counters Operation
NICE Logical Link Handling
Algorithm for Accepting Version Numbers
Return Code Handling
Network Management Layer Messages
NICE Function Codes
Message and Data Type Format Notation
Request Down-line Load Message Format
Request Up-line Dump Message Format
Trigger Bootstrap Message Format
Test Message Format
Change Parameter Message Format
Read Information Message Format
Zero Counters Message Format
NICE System Specific Message Format
NICE Response Message Format
NICE Connect and Accept Data Formats
Event Message Binary Data Format
APPLICATION LAYER NETWORK MANAGEMENT FUNCTIONS
Loopback Mirror Modules
Loopback Mirror Operation
Logical Loopback Message
Connect Accept Data Format
Command Message Format
Response Message

APPENDIX A NETWORK MANAGEMENT ENTITIES, PARAMETERS AND
COUNTERS: FORMATS AND DATA BLOCKS
A.1
LINE Entity
A.1.1
Line Parameters
A.1.2
Line Counters
A.2
LOGGING Entity
A.3
NODE Entity
A.3.1
Node Parameters
A.3.2
Node Counters
APPENDIX B MEMORY IMAGE FORMATS

44
44
44
45
45
46
48
48
49
50
52
55
55
56
60

61
62
62
66
67
69
69
69
70
70

71
71
71
73
74
75
75
77
77
78
78
79
79
80

82
82
82
82
82
82
83
84
87
89
91
94
96
98
103
104

CONTENTS (Cont.)

Page
APPENDIX C MEMORY IMAGE FILE CONTENTS
APPENDIX D NICE RETURN CODES WITH EXPLANATIONS
APPENDIX E NCP COMMAND STATUS AND ERROR MESSAGES
APPENDIX F EVENTS
F.l
Event Class Definitions
F.2
Event Definitions
F.3
Event Parameter Definitions
APPENDIX G JULIAN HALF-DAY ALGORITHMS
APPENDIX H DMC DEVICE COUNTERS
APPENDIX I NCP COMMANDS SUPPORTING EACH NETWORK MANAGEMENT
INTERFACE
GLOSSARY

105
106
III

113
113
113
115
123
125
126
135

FIGURES
FIGURE

1
2
3
4
5
6
7
8

Network Management Relation to DNA
Network Management Layer Modules and Interfaces in a
Single Node
Event Logging Architectural Model
Down-line Load File Access Operation
Down-line Load Request Operation
Examples of Node Level Testing Using a Loopback Node
Name with and without the Loopback Mirror
Examples of Node Level Logical Link Loopback Test
with and without the Loopback Mirror
Physical Link Loopback Tests and Command Sequences
Effecting Them

6
8
51
57
59
64
65
67

TABLES
TABLE

1
2
3
4
5
6
7
8

9
10
11
12

NCP Commands
Network Management Line States
Line State Transitions
Line Service States, Substates and Functions and
Their Relationship to Line States
DECnet Line Devices
Line Parameters
Line Counters
Logging Parameters
Node Parameters
Node Counters
Event Classes
Events

16
40
41
46
89

91
92
96
101
103
113
114

1.0

INTRODUCTION

This document describes the structure, functions, operation, and
protocols of Network Management. Network Management 1S that part of
the DIGITAL Network Architecture that models the software that enables
operators and programs to plan, control, and maintain the operation of
centralized or distributed
DECnet
networks.
DIGITAL
Network
Architecture (DNA)
is the model on which DECnet network software
implementations are based. Network software is the family of software
modules, data bases, hardware components, and facilities used to tie
DIGITAL systems together in a network
for
resource
sharing,
distributed computation, or remote system communication.
DNA is a layered structure. Modules in each layer perform distinct
functions.
Modules within the same layer
(either in the same or
different nodes) communicate using specific protocols. The protocols
specified in this document are the Network Information and Control
Exchange (NICE) protocol, the Loopback Mirror protocol, and the Event
Receiver protocol.
Modules in different layers interface using subroutine calls or a
similar
system-dependent
method.
In this document, interface
communications between layers are referred to as calls or requests
because
this
is
the most convenient way of describing them
functionally. An implementation need not be written as calls to
subroutines.
Interfaces to other DNA layers are not specified in
detail, however, Appendix I describes which Network Management user
commands (Network Control Program) support each DNA interface.
In this document network nodes are described by function as executor,
command, host, and target.
The executor is an active network node
connected to one end of a line being used for a load, dump, or line
loop test and is the node that executes requests. The command node is
the node in which the Network Management request originates. The host
is a node that provides a higher level service such as a file system.
The target is a node that is to receive a load, loop back a test
message, or generate a dump. Executor, command, and host nodes may be
three different nodes, all the same node, or any combination of two
nodes.
A glossary at the end of this document defines many Network
Management terms.
This document describes commands that can be standardized across
different DECnet implementations.
An implementation may use only a
subset of the commands described herein.
Moreover, commands and
functions
specific to one particular operating system are not
described.
This document specifies the functional requirements of
Network
Management. Both algorithms and operational descriptions support this
specification. However, an implementation is not required to use the
same algorithms.
It is only required to have the functions (or a
subset of them) specified.

This is one of a series of functional specifications for the DIGITAL
Network Architecture, Phase III.
This document assumes that the
reader is familiar with computer communications and DECnet.
The
primary audience for this specification consists of implementers of
DECnet systems, but it may be of interest to anyone wishing to know
details of DECnet structure.
The other DNA Phase III functional
specifications are:
DNA Data Access Protocol (DAP) Functional Specification,
5.6.0, Order No. AA-K177A-TK

Version

D
=-::..;.N..:...:A_-::D::-=i~gL..:l=-·t~a:;:.=.l_..;;:.D~a:.....:t:....::a-=--.:::-_C=-o=-m:.;.:.::.;:;m~u..::..:n:....::i~c:....::a;:-t.=-l=-·o=-n=s~~M.:..:e::....:s;....:s=-a:.::...g,L..:;:....e--.~p.rot 0 col
( DDC MP)
Functional
Specification,
version
4.l~0,
Order
No.
AA-K175A-TK
DNA

Maintenance
Operations
Protocol
Specification, version 2.1.0, Order No.

DNA Network Services
3.2.0, Order No.

(NSP) Functional
AA-K176A-TK

(MOP)
Functional
AA-K178A-TK

Specification,

version

DNA Transport Functional Specification, version 1.3.0, Order
AA-K180A-TK
DNA Session Control Functional
Order No. AA-K182A-TK

Specification,

version

No.

1.0.0,

AA-K179A-TK) provides an
The DNA General Description (Order No.
overview of the network architecture and an introduction to each of
the functional specifications.

2.0

FUNCTIONAL DESCRIPTION

Network Management enables operators and programs to control and
monitor network operation. Network Management helps the manager of a
network to plan its evolution. Network Management also facilitates
detection,
isolation, and resolution of conditions that impede
effective network use.
Network Management provides user commands and capability
programs for performing the following control functions:

user

Loading remote systems. A system in one node can
load a system in another node in the same network.

down-line

Configuring resources.
A system manager can change the
network configuration and modify message traffic patterns.

Setting parameters. Line, node, and logging parameters
example, node names) can be set and changed.

Initiating and terminating network functions.
A system
manager or operator can turn the network on or off and
perform loopback tests and other functions.

(for

Network Management also enables the user to monitor network functions,
configurations, and states, as follows:
1.

Dumping remote systems. A system in one node can
dump a system to another node in the same network.

up-line

Examining configuration status. Information about lines and
nodes can be obtained. For example, an operator can display
the states of lines and nodes or the names of adjacent nodes.

Examining parameters. Line and node parameters (for example,
timer settings, line type, or node names) can be read.

Examining the status of network operations. An operator can
monitor network operations.
For example, the operator can
find out what operations are in progress and whether any have
failed.

Examining performance variables.
A system manager
can
examine the contents of counters in lower DNA layers to
measure
network
performance.
In
addition,
Network
Management's Event Logger provides automatic logging of
significant network events.

Besides controlling and monitoring the day-to-day operation of the
network, the functions listed above work to collect information for
future
planning.
These
functions
furnish
basic
operations
(primitives) for detecting failures, isolating problems, and repairing
and restoring a network.

2.1

Design Scope

Network
Management
requirements:
1.

functions

satisfy

the

following

design

Common interfaces.
Common interfaces are
provided
to
operators and programs, regardless of network topology or
configuration, as much as possible without impacting the

quality of existing products. There is a compromise between
the compatibility of network commands across heterogeneous
systems and the compatibility within a system between network
and other local system commands.
2.

Subsetability. Nodes are able to support a subset of Network
Management components or functions.

Ease of use. Invoking and understanding Network Management
functions are easy for the operator or user programmer.

Network efficiency. Network Management is both processing
and memory efficient. It is line efficient where this does
not conflict with other goals.

Extensibility. There is accommodation for future, additional
management
functions,
leaving
earlier functions as a
compatible subset. This specification serves as a basis for
building more sophisticated network management programs.

Heterogeneity. Network Management operates across a mixture
of network node types, communication lines, topologies, and
among different versions of Network Management software.

Robustness. The effects of errors such as operator input
errors, protocol errors, and hardware errors are minimized.

Security. Network Management supports the existing security
mechanisms in the DIGITAL Network Architecture (for example,
the access control mechanism of the Session Control layer).

Simplicity. Complex algorithms and data bases are avoided.
Functions provided elsewhere in the architecture are not
duplicated.

10.

Support of diverse management policies.
Network Management
covers a range between completely centralized and fully
distributed management.

The following are not within the scope of
Management:

Version

2.0.0

Network

Accounting. This specification does not provide for the
recording of usage data that would be used to keep track of
individual accounts for purposes of reporting on or charging
users.

Automation.
This specification does
not
provide
for
automatic execution of complex algorithms that handle network
repair or reconfiguration. More automation can be expected
in future revisions of this specification.

Protection against malicious use.
There is no foolproof
protection against malicious use or gross errors by operators
or programs.

Upward compatibility of user interfaces. The interfaces to
the user layer are not necessarily frozen with this version.
Observable data may change with the next version. Because of
this, a function such as node-up keyed to a spooler in an
implementation would not be wise.

2.2

Relationship to DIGITAL Network Architecture

DIGITAL Network Architecture
(DNA),
the model upon which DECnet
implementations are based, outlines several functional layers, each
with its own specific modules, protocols, and interfaces to adjacent
layers.
Network Management modules reside in the three highest
layers.
The general design of DNA is as follows in order from the
the lowest layer:

highest

The User layer.
The User layer is the highest layer.
It
supports user services and programs. The Network Control
Program (NCP) resides in this layer.

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

The Network Application layer.
Modules in the Network
Application
layer
support I/O device and file access
functions.
The Network Management module within this layer
is the Loopback Mirror,
providing logical link loopback
testing.

The Session Control layer.
The Session Control layer manages
the system-dependent aspects of logical link communication.

The Network Services layer.
The Network Services layer
controls
the creation, maintenance, and destruction of
logical links,
using the Network Services Protocol and
modules.

The Transport layer.
Modules in the Transport
messages between source and destination nodes.

The Data Link layer.
The Data Link layer manages the
communications over a physical link,
uSlng a data link
protocol,
for
example,
the Digital Data
Communications
Message Protocol (DDCMP).

The Physical Link layer.
The Physical Link layer provides
the hardware interfaces (such as EIA RS-232-C or CCITT V.24)
to specific system devices.

layer

route

Figure 1 shows the relationship of the Network Management layer to the
other DNA layers.

User Modules

Network
Management Laver

Network
Application Laver

Session Control Laver

Network Services Laver

Transport Laver

Data Link Laver

Physical Link Modules

Phvsical Link Laver

Horizontal arrows show direct access for control and examination of parameters, counters, etc. Vertical and curved arrows show interfaces
between layers for normal user operations such as fde acces~, down·llne load, up·line dump, end·lo·end looping, and logical link usage.

Figure 1

2.3

Network Management Relation to DNA

Functional Organization within DIGITAL Network Architecture

The functional components of Network Management are as follows:
User layer components
Network Control Program (NCP).
The Network Control Program
enables the operator to control and observe the network from a
terminal. Section 3 specifies NCP.
Network Management layer components
Section 4 specifies the Network Management layer components and
their operation.
Figure 2 shows the relationship of Network
Management layer modules in a single node.
Network Management Access Routines. These routines provide user
programs and NCP with generic Network Management functions, and
either convert them to Network Information and Control Exchange
(NICE)
protocol messages or pass them on to the Local Network
Management Function.
6

Network Management Listener.
The Network Management Listener
receives Network Management commands from the Network Management
level of remote nodes, via the NICE protocol.
In
some
implementations it also receives commands from the local Network
Management Access Routines via the NICE protocol.
It passes
these requests to the Local Network Management Function.
Local Network Management Functions. These take function requests
from the Network Management Listener and the Network Management
Access Routines and convert them to system dependent calls. They
also provide interfaces to lower level modules directly for
control purposes.
Line Watcher. The Line Watcher is a module in a node that can
sense service requests on a line from a physically adjacent node.
It controls automatically-sensed down-line load or up-line dump
requests.
Line Service Functions. These provide the Line Watcher and the
Local Network Management Functions with line services needed for
service functions that require a direct interface to the data
link layer
(line level testing, down-line loading, up-line
dumping, triggering a remote system's bootstrap loader and
setting the fine state).
The Line Service module maintains
internal states as well as line substates.
Event Logger.
The Event Logger provides the capability of
logging significant events for operator intervention or future
reference. The process concerned with the event
(for example,
the Transport module)
provides the data to the Event Logger,
which can then record it.
Network Application Layer Components
Loopback Mirror. Access and service routines communicate using
the Logical Loopback Protocol to provide node level loopback on
logical links. Section 5 describes this Network Application
layer component.
Object Types
The Network Management architecture requires three
object types. Each has a unique object type number.
The object types and numbers are:
Type

Object Type Number

Network Management
Listener

Loopback Mirror

Event Receiver

separate

User
Program

NCP

~------------

Line
Watcher

Network
NICE
Management
Protocol
commands .... - - - - - - to other
nodes

- - -User Layer

----

System- ~
Independent
Function
Requests

NICE

Network
Management
Access Routines

Network
Management
... - - - - commands
from other
nodes

Network
Management
Listener

i-P..!:o..!.o.£~

Local Network Management Functions

Events to

~~r_n~~:~_ _----"""f4- __ Events from
other nodes

Line Service
Functions

Event Logger
Network
Management
Layer

-----~------Service interface to Data
Link Layer (down-line
load, up-line dump, line
tests, line state change)

.1-

LatNer Layers

System-dependent calls to
application layer and local
operating system functions
(file access, logical link
loopback, timer setting, etc.)

Control over lower level ...
functions (examine line
state, turn on NSP, etc.)

Control interface to read
event queues

~------------------------------------------------------------------------------------------------------------

LEGEND:
NCP - Network Control Program
NICE - Network Information and
Control Exchange

+- Vertical arrowheads indicate interfaces for function requests
~

- Horizontal arrowheads indicate control interfaces

Figure 2 Network Management Layer Modules
and Interfaces in a Single Node

3.0

NETWORK CONTROL PROGRAM (NCP)

This section is divided into three parts.
Section 3.1 describes the
NCP functions.
Section 3.2 provides rules for the operation of NCP,
including such topics as input and output formatting, access control,
and status and error messages.
Section 3.3 presents a detailed
description of all the NCP commands.

3.1

Network Control Program Functions

There are two types of NCP commands:
1.

Internal commands. These are directed to NCP itself and
cannot be sent to remote nodes. Theie are the SET and DEFINE
EXECUTOR NODE node-id, CLEAR and PURGE EXECUTOR NODE,
and
SHOW QUEUE commands;
the TELL prefix; and the EXIT command
(Section 3.2).

Commands that use the Network Management interface.
These
use
the
Network Management Listener, via the Network
Information and Control Exchange (NICE) protocol, when sent
across logical links to remote nodes.
NCP commands directed
to the local node have the option of either using the Network
Management
Listener, via the Network Management Access
Routines and the NICE protocol, or of passing requests
directly to the Local Network Management Function from the
Network Management Access Routines.
The method chosen is
implementation-specific.

The NCP command language enables an operator to perform the
network functions:
•

Changing parameters (Section 3.1.1)

•

Gathering information (Section 3.1.2)

•

Down-line loading (Section 3.1.3)

•

Up-line dumping

•

Testing line and network (Section 3.1.5)

•

Zeroing counters (Section 3.1.6)

following

(Section 3.1.4)

3.1.1 Changing Parameters - The parameters are line, node, or logging
options specifically described in Appendix A.
Some examples of changing parameters are:
•

Setting a line state to ON

•

Changing a node name associated with a node address

•

Setting the routing cost for a line

•

Setting a node to be notified of certain logged events

Parameters may be set either as dynamic values in volatile memory
using the SET command or as permanent values in a mass-storage default
data base using the DEFINE command. The volatile data base is lost
when the node shuts down; the permanent data base remains from one
system initialization to the next. Parameters can be either status,
such as line state, or characteristics that are determined by SET,
DEFINE, CLEAR, and PURGE commands. Characteristics are static in the
sense that once set, either at system generation time or by an
operator, they remain constant until cleared or reset.
Status
consists of dynamic information (such as line state) that changes
automatically when functions are performed.
Permanent values take effect whenever the permanent data base is
re-read.
The
timing
of
the
values'
taking
effect
is
implementation-dependent. Volatile values take effect immediately.
Setting line states does not change line ownership, which is Transport
or its equivalent.
Line states can be set, however, to control the
use of the line by its owner. To Transport, the line is either OFF or
ON.
To Network Management, a line can also be in a SERVICE state, a
state which precludes normal traffic, and which temporarily prevents
Transport from using the line. The SERVICE state is used for loading,
dumping, and line testing. The ON and SERVICE states have various
substates
that inform the operator what function the line is
performing. When states are displayed, the substates are indicated as
a tag on the end of the operator-requested state.

3.1.2 Gathering Information - The information
gathered
includes
characteristics, status, and counters associated with the line,
logging, and node entities (detailed in Appendix A).
Examples of
gathering information are:
•

Displaying the state of a line

•

Reading and then zeroing line counters

•

Displaying characteristics of all reachable nodes

•

Showing the status of all commands in progress at a node

Characteristics and status are described in Section 3.1.1.
Counters are error and performance statistics such as messages sent
and received, time last zeroed, and maximum number of logical links in
use.

3.1.3 Down-line Loading - Down-line loading is the
process
of
transferring a memory image from a file to a target system's memory.
This requires that the executor, the node executing the command, have
direct access to the line to the target. The file may be located at
another remote node, in which
case
the
executor
uses
its
system-specific remote file access procedures. The executor supports
or has access to a data base of defaults for a load request.
Section
4.2.1 describes the down-line load operation in the Network Management
layer.

3.1.4 Up-line
Dumping - Up-line
dumping
is
the
process
of
transferring the dump of a memory image from a target system to a
destination file. Section 4.2.2 describes the up-line dump operation.
10

3.1.5 Testing Line and Network - Testing line and network can be
accomplished by message looping at both the line and node levels.
Testing requires receiving a transmitted message over a particular
path that is looped back to the local node by either hardware or
software.
Node level testing uses logical links and normal line usage.
The
lines involved are in the ON state, and the Session Control, Network
Services, and Transport layers are used.
During line level testing, the line being tested
is in the SERVICE
state;
normal usage is precluded.
Network Management accesses the
Data Link layer directly,
bypassing intermediate layers.
Section
4.2.4 describes line and network testing.

3.1.6 Zeroing Counters - Using NCP, an operator can set line and node
counters to zero.

3.2

Network Control Program Operation

This section describes general rules concerning the operation of NCP.
The SET, DEFINE, CLEAR, and PURGE commands must successfully act on
either all parameters entered or on none of them.
One parameter per
command is all that can be expected to take effect on any system,
although a system may allow some parameters to be grouped on the same
command.

3.2.1 Specifying the Executor - Since a command does not have to be
executed at the node where it is typed, the operator must be able to
designate on what node the command is to be processed.
The operator
has two options for controlling this:
1.

Specifying a default executor for a set of commands

Naming the executor with the commad

At NCP start-up time, the default executor is the node on which NCP is
running or the node that was previously defined with the DEFINE
EXECUTOR NODE command. The default executor is changed using the SET,
DEFINE,
CLEAR, or PURGE EXECUTOR NODE commands (see Sections 3.3.1.2
and 3.3.2.1).
with any command, the operator can override the default executor by
specifying which node is to execute the command. This is accomplished
by entering "TELL node-identification" as a prefix to the command.
The specified node identification applies only to the one command and
does not affect the default executor or any subsequent commands.

3.2.2 Program Invocation, Termination, and Prompting - The way NCP is
invoked or terminated is system-dependent. If a name is used for the
program, it must be "NCP.II The EXIT command terminates NCP.
The following rules apply to the initial NCP prompt:
For an NCP that accepts only a single outstanding command, the
is always the same:

p~ompt

NCP>
For an NCP that accepts several outstanding
obvious that NCP is prompting, the prompt is:

commands

where

tn>
For the multiple-outstanding-command case where it is not obvious that
NCP is prompting, the prompt is:
NCf'tn>
In any case, n is the command's request number,
the output for the command.

which

will

identify

An implementation that cannot integrate the request number with the
prompt, can display the request number when the command is accepted.

3.2.3 Privileged Commands - Network
and
system
planners
must
determine which commands should be limited to privileged users. The
exact determination of privilege is an
implementation-dependent
function.
Privilege is generally determined in a system-specific way
according to the privileges of the local user or the access control
provided at logical link connection time.

3.2.4 Input Formats - Command input is in the form of arguments
delimited by tabs or blanks. Either a single or multiple tab or blank
may be used to delimit arguments.
Null command lines. Null command
prompt being re-issued.

lines

will

result

command

Node identification and access control.
Nodes are identified by
address or name. The primary identification is the address (a Session
Control requirement). The keyword EXECUTOR can be substituted for
NODE
executor~node-identification.
If
a
node
identification
represents a node to be connected to, access control information may
be necessary or desired. If so, the access control follows the node
identification, the maximum length of each field being 39 bytes.
Specific systems may limit the amount of access control information
they will accept. The format is:
LOOP NODE
}
SET EXECUTOR NODE node-id [USER user-id] [PASSWORD password] [ACCOUNT account]
{
TELL
where:
LOOP NODE node-id

Is an NCP command used to initiate a node
loopback
test
(Section 3.3.6.2).
The
access control applies only to the command.

SET EXECUTOR NODE node-id

Is an NCP command used to set the node
identification and access control for the
default executor node
(Section 3.3.1.1).
The access control prevails until changed
by another SET EXECUTOR command or a TELL
or LOOP NODE command.

TELL node-id

Is an NCP command prefix used to pass one
command and access control information to a
specific node.
The access control applies
only to that one command.

[USER user-id]

Is access control information that provides
the identification of the user.

[PASSWORD password]

Is access control. information furnishing
password.

[ACCOUNT account]

Is access control information supplying
account identification.

For example:
TELL BOSS USER (211,1] PASSWORD secret ACCOUNT
SET EXECUTOR NODE 97 ACCOUNT

x~z

CLEAR KNOWN LINES

x~z

String input.
String input (every argument that is not a node name,
keyword or
number)
is defined by the executor node and the length
limitations of the NICE protocol.
For
consistency
from
one
implementation to another, the following rules apply to NCP's parsing
algorithm for these types of arguments:
•

Implementations will provide both a
transparent
and
non-transparent technique for specifying these arguments.

•

The transparent technique will act on any string of characters
enclosed in quotation marks
("XXXXX"). A quote within the
string will be indicated by a
double
quotation
mark
( II XXX II II XX ") .

•

The non-transparent technique will act on any string of
characters that does not contain blanks or tabs.
An exception
to this occurs where it is possible to recognize syntactically
that blanks or tabs are not intended as delimiters.

Keywords.
Implementations must accept keywords in their entirety.
However,
the user may abbreviate keywords when typing them in.
The
minimum abbreviation is system-specific.
The command formats specified in this document are to be the
formats
used
for
NCP input.
They may be modified only in the sense that
unsupported commands or options may be left out.
It is permissible to
prefix a command with an identifier such as OPR NCP.
However, this
prefix should not affect the remainder of the command syntax or
semantics.
Optional system-specific guide words such as TO or FOR can
be added to NCP commands if they do not
interfere with defined
key
words.
The NCP command language does not use a question mark as a syntactic
or semantic element.
The question mark is left available for use
according to operating system conventions.
An implementation may recognize locally defined names for
lines
accept other non-standard line identifications as string inputs.
13

3.2.5 Output Characteristcs - The output format specified in this
document is to be considered the basic pattern for all NCP output.
Implementations may differ as long as common information is readily
identifiable.
The following example shows three commands and their
resultant output.
User-furnished information is
underlined
to
distinguish it from the program output.

t23)LOAD NODE MANILA
t24)LOAD NODE TOKYO
t25)
REQUEST t24; LOAD FAILED, LINE COMMUNICATION ERROR
SHOW QUEUE
REQUEST t25; SHOW QUEUE
REQUEST
NUMBER EXECUTOR

COMMAND

21
6 (HNGKNG) SHOW
22
6 (HNGKNG)
SET
23
6 (HNGKNG)
LOAD
6 (HNGKNG)
LOAD
24
N/A
25
SHOW
t26)
REQUEST t23, LOAD COMPLETE

STATUS
COMPLETE
COMPLETE
IN PROGRESS
FAILED
IN PROGRESS

Passwords are not displayed. Instead, an ellipsis ( ... ) indicates
that a password is set. Section 3.3.8 provides details concerning
output for requested information (SHOW and LIST commands) .

3.2.6 Status and Error Messages - Status and error messages inform
the NCP user of the consequence of a command entry. NCP gives each
command a request number, which it displays with status and error
messages.
NCP displays status or error messages when the status of
the command changes as long as the user does not begin to type a new
command. The general form of status and error messages is:
REQUEST #n;

[entity,] command status [,error-message]

where:
n

Is the command's request number.

entity

Is a specific entity described in Appendix A.

command

Is a command indicator.

status

Is the status of the operation, one of COMPLETE,
FAILED, or NOT ACCEPTED.
If it is COMPLETE, there
is no error-message.
If it is FAILED or NOT
ACCEPTED, there is an error-message.

error-message

Is the reason for a failure.

Commands that act on plural entities (for example, SET KNOWN LINES)
have a separate status message for each individual entity and one for
the entire operation. In this case, each entity is identified with
its own status message.

In an NCP that allows only one command at a time, COMPLETE messages
are not displayed, and the request number is not included.
An example
of output for a command that has failed follows:

LOAD FAILED, LINE COMMUNICATION ERROR
NCP prints unrecognized return
numbers.
For example:

codes

error

details

decimal

Remuest t5~
SHOW failed, Management return t-34
SET FAILED, parameter not applicable, detail t2300
Error messages are either those from the set of NCP error messages in
Appendix E,
the NICE error returns in Appendix D or implementation
specific.

3.3

Network Control Program Commands

This section describes NCP commands.
The following symbols are used in NCP command syntax descriptions:
[

Brackets indicate optional input.
In most cases
these are the entity parameters and entity
parameter options for a command.

]

UPPER CASE

Upper case letters signify actual input, that is
keywords that are part of NCP commands.

lower case

Lower case letters in a command string
indicate
a description of an input variable, not the
actual input.

spaces

Spaces between variables
(not keywords)
command string delimit parameters.

hyphens

Multi-word variables are hyphenated.

{ }

Braces indicate that any
parameters is applicable.

the

enclosed

This designates keywords or messages that may be
returned on a SHOW command.
This is used in
Appendix I.

All NCP commands have the following common syntax:
command

entity

parameter-option(s)

where:
command

Specifies the operation to be performed, such
as SHOW or LOAD.

entity

Specifies the entity (component) to which the
operation applies,
such as LINE or KNOWN
NODES.

parameteroption(s)

Qualifies the command
specific information.

by providing further

Table I lists the complete set of NCP commands specified in this
document. Details concerning options and explanations of each command
follow in the text. Appendix I lists the NCP commands supporting each
Network Management interface.
Table I
NCP Commands
Command

Parameter

Entity

SET
}EXECUTOR
{DEFINE
LINE
line-id}
{KNOWN LINES

NODE

destination-node

ALL
CONTROLLER
COST
COUNTER TIMER
DUPLEX
NORMAL TIMER
SERVICE
SERVICE TIMER
STATE
TRIBUTARY
TYPE

controller-mode
cost
seconds
duplex-mode
milliseconds
service-control
milliseconds
line-state
tributary-address
line-type

LOGGING sink-type} EVENT event-list
{ KNOWN LOGGING
KNOWN EVENTS
NAME
STATE

* {NODE

nOde-id}
KNOWN NODES

ADDRESS
ALL
.BUFFER SI ZE
COUNTER TIMER
CPU
DELAY FACTOR
DELAY WEIGHT
DUMP ADDRESS
DUMP COUNT
DUMP FILE
HOST
IDENTIFICATION
INACTIVITY TIMER
INCOMING TIMER
LINE
LOAD FILE
MAXIMUM ADDRESS
MAXIMUM BUFFERS
MAXIMUM COST
MAXIMUM HOPS
MAXIMUM LINES
MAXIMUM LINKS
MAXIMUM VISITS

[source-qual] [sink-node]
sink-name
sink-state
node-address
memory-units
seconds
cpu-type
number
number
number
number
file-id
node-id
id-string
seconds
seconds
line-id
file-id
number
number
number
number
number
number
number

Legend:

EXECUTOR may be substituted for NODE node-ide

** The node-id with the LINE parameter is a name.
parameters, it can be either a name or address.
!

With all other

Used only with NODE node-ide
(continued on next page)
16

Table I (Cont.)
NCP Commands
Command

Entity

Parameter

* {NODE

node- id}
KNOWN NODES

NAME
OUTGOING TIMER
(CONT. )
ROUTING TIMER
SECONDARY DUMPER
SECONDARY LOADER
SERVICE DEVICE
SERVICE LINE
SERVICE PASSWORD
SOFTWARE
IDENTIFICATION
SOFTWARE TYPE
STATE
TERTIARY LOADER
TYPE

node-name
seconds
RETRANSMIT FACTOR number
number
file-id
file-id
device-type
line-id
password
file-id
program-type
node-state
file-id
node-type

NODE

{CLEAR} EXECUTOR
LPURGE
I ine- id}
LINE
{KNOWN LINES

ALL
COUNTER TIMER

LOGGING sink-type} EVENT event-list
{KNOWN LOGGING
KNOWN EVENTS
NAME

[source-qual] [sink-node]

{CLEAR}
LPURGE

* {NODE

node- id}
LKNOWN NODES

ALL
COUNTER TIMER
CPU
DUMP ADDRESS
DUMP COUNT
DUMP FILE
HOST
IDENTIFICATION
INCOMING TIMER
LINE
LOAD FILE
NAME
OUTGOING TIMER
SECONDARY DUMPER
SECONDARY LOADER
SERVICE DEVICE
SERVICE LINE
SERVICE PASSWORD
SOFTWARE IDENTIFICATION
SOFTWARE TYPE
TERTIARY LOADER

TRIGGER

NODE
{VIA

[[SERVICE]
! [VIA

nOde-id}
line-id

PASSWORD

password]
line-id]

(continued on next page)

Table 1 (Cont.)
NCP Commands

Command
LOAD

Entity
{NODE
VIA

Parameter
[A'oDRESS

nOde-id}
line-id

[FROM
[HOST
[NAME
[SECONDARY [LOADER]
[SERVICE DEVICE
[ [SERVICE] PASSWORD
[SOFTWARE
IDENTIFICATION
[SOFTWARE TYPE
[TERTIARY [LOADER]
! [VIA
DUMP

LOOP

node-address]
[CPU cpu-type]
load-file]
node-id]
node-name]
file-id]
device-type]
password]
software-id]
program-type]
file-id]
line-id]

~ODE
VIA

nOde-id}
line-id

[DUMP ADDRESS
[DUMP COUNT
[SECONDARY [DUMPER]
[SERVICE DEVICE
[ [SERVICE] PASSWORD
[TO
[VIA

number]
number]
file-id]
device-type]
password]
dump-file]
line-id]

{LINE

line-id}
node-id

[COUNT
[WITH
! [VIA

count]
block-type]
length]

* NODE

SHOW

QUEUE

{LIST}
SHOW

rCTIVE LOGGING }
KNOWN
LOGGING
LOGGING sink-type

{jVENTS
}
STATUS
CHARACTERISTICS
UMMARY

{SINK NODE nOde-id}
KNOWN SINKS

"'ACTIVE LINES
{CHARACTERI STICS}
ACTIVE NODES
COUNTERS
EXECUTOR
STATUS
SUMMARY
~ KNOWN LINES
~
KNOWN NODES
LINE line-id
LOOP NODES
NODE
node-name
~

ZERO

*{]INE
NODE

line-id}
node-id
KNOWN LINES
NOWN NODES

COUNTERS

EXIT

3.3.1 SET and DEFINE Commands - These commands modify volatile and
permanent parameters.
The SET command modifies the volatile data
base1 the DEFINE command changes the permanent data base.
Section
4.2.5 describes ~he change parameter operation.

The general form of the commands is:
SET
{

}

entity parameter

DEFINE
Entity is one of the following:
EXECUTOR
LINE line-identification
LOGGING sink-type
NODE node-identification
KNOWN LINES
KNOWN LOGGING
KNOWN NODES
Parameter is one (or more, if allowed by the
implementation)
parameter options defined for the specified entity.

the

3.3.1.1 SET and DEFINE EXECUTOR NODE destination-node - The SET and
DEFINE EXECUTOR NODE commands, processed by NCP, change the executor
node for subsequent commands.
Access control
information may be
supplied as described in Section 3.2.4.

3.3.1.2 SET and DEFINE KNOWN Entity Commands - These commands set
volatile and permanent parameters for
each one of the specified
entities known to the system.
The format is:
} KNOWN plural-entity parameter
{ SET
DEFINE
Plural entity is one of LINES, LOGGING or NODES.
The parameters are the same as for the SET and DEFINE entity commands
(Sections 3.3.1.3,
3.3.1.4,
and
3.3.1.5).
However,
DEFINE KNOWN
plural-entity ALL has no meaning.
SET KNOWN plural-entity ALL loads
all permanent entity parameters into the volatile data base.

3.3.1.3 SET and DEFINE LINE Commands - These commands set volatile
and permanent line parameters for the line identified.
The format is:
SET
{

}

DEFINE

LINE line-id

,ALL
CONTROLLER
COST
COUNTER TIMER
DUPLEX
NORMAL TIMER
SERVICE
SERVICE TIMER
STATE
TRIBUTARY
TYPE

controller-mode
cost
seconds
duplex-mode
milliseconds
service-control
milliseconds
line-state
tributary-address
line-type

where:
line-id

Is as specified in Section A.l.

ALL

with SET, puts permanent line parameters
associated with the line in the volatile
data base.
With
DEFINE,
creates
a
permanent data base entry for one line.

CONTROLLER controller-mode

Sets the controller mode for the line.
The values for controller mode are as
follows:
LOOPBACK

This
is
for
software
controlled loopback of the
controller.

NORMAL

This is for normal controller
operating mode.

The command automatically turns the line
OFF before setting the mode and back to
the original state after.
COST cost

Sets the routing line cost. The cost is a
decimal number in the range 1 to 25. The
cost parameter is a positive integer value
associated with using a line and is used
in
the
Transport
routing
algorithm
(Transport Functional Specification).

COUNTER TIMER seconds

Sets a timer whose expiration causes a
line counter logging event. Table 7 lists
the
line
counters.
These
counters
constitute the data for certain logged
events (Table 12). The line counters are
recorded as data in the event and then
zeroed. Seconds is specified as a decimal
number in the range 1-65535.

DUPLEX duplex-mode

Sets the hardware duplex mode of the line.
The possible modes are:

NORMAL TIMER milliseconds

FULL

Full-duplex

HALF

Half-duplex

Specifies the maximum amount of
time
allowed to elapse before a retransmission
is necessary. This is used for normal
operation
of
the
line.
Timing is
implementation-dependent.
This
timer
applies to the use of the data link
protocol (for example, DDCMP).

SERVICE service-control

Specifies whether or not the
service
operations
(loading,
dumping,
line
loopback testing)
are allowed for
the
line.
The service-control values are as
follows:
ENABLED

The line may be put
into
SERVICE
state and service
functions performed.

DISABLED

The line may not be put into
SERVICE
state and service
functions
may
not
be
performed.

SERVICE TIMER milliseconds

Specifies the maximum amount of
time
allowed to elapse before a receive request
completes while doing service operations
on
the line.
Service operations are
down-line load, up-line dump, or line loop
testing.
The timer value is an integer
number in the range 1-65535.
This timer
applies to the use of the service protocol
(for example, MOP).

STATE line-state

Sets the line's operational state at the
executor node.
The possible states are as
follows:
ON

The line is available to
its
owner
for
normal
use, with the
exception of temporary overrides
for service functions.

OFF

The line is not used by any
network
or
network-related
software.
The
line
is
functionally non-existent.

SERVICE

This state applies only to the
volatile data base (SET command) .
The line is available for
active
service functions:
load, dump,
and line loop.
The line can
provide passive loopback - direct
line
software-looped
testing
(Figure 8) - if no active service
function is in progress.

CLEARED

This state applies only to the
permanent
data
base
(DEFINE
command).
A line in this state
has
space reserved in system
tables but has no other databases
or parameters in volatile memory.
This state is only applicable
in
systems that can implement it.

If the line is set to its existing state a
null operation (NaP) results.

NOTE
An implementation may choose to effect
service functions in the ON state, as
temporary overrides to normal traffic.
In
this
case, error messages must
clearly indicate when a line is in a
temporary service condition.
TRIBUTARY tributary-address Sets the physical tributary address of the
line.
The tributary address is a decimal
number in the range 0-255.
It reflects
the
bit
setting
of
the
hardware
switch-pack for the tributary.
TYPE line-type

link
Sets up the line for the data
protocol
operation
together with the
DUPLEX option. Line type is one of the
following:
POINT
CONTROL

For a point to point line
For a multipoint
control
station
TRIBUTARY For a multipoint tributary

3.3.1.4 SET and DEFINE LOGGING Commands - This set of commands is
used to control event sinks (where events are logged) and event lists
(that control which events get logged). Appendix F specifies events.
The command format is:
SET
{

}

LOGGING sink-type

DEFINE

EVENT event-list [source-qual] [sink-node]
KNOWN EVENTS
[source-qual] [sink-node]
NAME sink-name
STATE sink-state

where:
sink-type

Is one of CONSOLE, FILE, or
MONITOR.
Determines the ultimate sink for events.
Section A.2 specifies the sink-type format.

[sink-node]

Specifies a node that receives events.
is of the form:

SINK NODE node-id
or
SINK EXECUTOR
This option can either precede or follow
KNOWN EVENTS or EVENT event-list. The node
identification is specified in Section A.2.
If a sink node is not supplied, the default
is executor.

[source-qualifier]

Selects a specific entity for certain event
classes.
It has the form:
LINE line-id
or
NODE node-id
This option can either precede or
KNOWN EVENTS or EVENT event-list.

EVENT event-list

Enables the
recording
of
the
events
specified by the event list.
The event
list consists of event class.event type(s).
The types
(Table 12)
are specified
in
ranges using hyphens and
in lists using
commas.
For example:
3.0-2
4.1-4,8,10
5.3-4,9
6.1,3,5
wild card notation indicates all
types of
events
for
a
particular class.
For
example:

3.*
NAME sink-name

Establishes device or file names for
sink
types CONSOLE and FILE, respectively.
It
specifies a process identification for
a
MONITOR.

KNOWN EVENTS

Enables the recording of all events known
to the executor node for the specified sink
node.

STATE sink-state

Controls the
operation
of
the
sink
specified
by sink type.
The possible
values of sink state are:
ON

The sink is available for
events.

receiving

OFF

The sink is not available and any
events destined for
it should be
discarded.

HOLD

The sink is temporarily unavailable
and events should be queued.

The following is an example of the SET LOGGING command:

SET LOGGING CONSOLE SINK ~ODE MANILA EVENT 6.2 LINE KDZ-O-l.4

3.3.1.5 SET and DEFINE NODE Commands - These commands set volatile or
permanent parameters for a node.
Certain parameters can be set only
for the executor node or for adjacent nodes.
See Table 9.
The format
for the command is:
SET
{

}

NODE

node-id

DEFINE

ADDRESS
ALL
BUFFER SIZE
COUNTER TIMER
CPU
DELAY FACTOR
DELAY WEIGHT
DUMP ADDRESS
DUMP COUNT
DUMP FILE
HOST
IDENTIFICATION
INACTIVITY TIMER
INCOMING TIMER
LINE
LOAD FILE
MAXIMUM ADDRESS
MAXIMUM BUFFERS
MAXIMUM COST
MAXIMUM HOPS
MAXIMUM LINES
MAXIMUM LINKS
MAXIMUM VISITS
NAME
OUTGOING TIMER
RETRANSMIT FACTOR
ROUTING TIMER
SECONDARY DUMPER
SECONDARY LOADER
SERVICE DEVICE
SERVICE LINE
SERVICE PASSWORD
SOFTWARE
IDENTIFICATION
SOFTWARE TYPE
STATE
TERTIARY LOADER
TYPE

node-address
memory-units
seconds
cpu-type
number
number
number
number
file-id
node-id
id-string
seconds
seconds
line-id
file-id
number
number
number
number
number
number
number
node-name
seconds
number
seconds
file-id
file-id
device-type
line-id
password
software-id
program-type
node-state
file-id
node-type

where:
node-id

Specifies node name or
node
address
(Section
A.3).
In some cases,
noted
below, the node identification must be a
node name.
EXECUTOR can be substituted
for NODE executor-node-identification.

ADDRESS node-address

Sets the address of the executor node.
This cannot be used to set the address of
any other node.

ALL

With SET this
moves
all
parameters
associated with the node identified from
the permanent data base into the volatile
data base.
With DEFINE it creates a
permanent data base entry for
the node
identified.

BUFFER SIZE memory-units

Sets the size of the line buffers.
The
size
is a decimal
integer in the range
1-65535.
This size
is in memory units
(Appendix C).
It is the actual buffer
size and therefore must take into account
such things as protocol overhead.
There
is one buffer size for all lines.

COUNTER TIMER seconds

Sets a timer whose expiration causes a
node counter logging event.
Node counters
are listed in Table 10.
They constitute
data for certain logged events (Table 12).
The node counters will be recorded as data
in the event and then zeroed.
Seconds is
specified as a decimal number in the range
1-65535.

CPU cpu-type

Sets the default target node CPU type
down-line loading the adjacent node.
possible values are:

for
The

PDP 8
PDP 11
DECSYSTEM 10
DECSYSTEM 20

VAX
DELAY FACTOR number

Sets the number by which to multiply one
sixteenth of the estimated round
trip
delay to a node to set the retransmission
timer
to that node.
The round trip delay
is used
in
an
NSP
algorithm
that
determines when to
retransmit a message
(NSP
functional
specification) .
The
number is decimal in the range 1-255.

DELAY WEIGHT number

Sets the weight to apply to a current
round trip delay estimate to a remote node
when updating
the estimated
round
trip
delay to a node.
The number is decimal in
the range 1-255.
On some systems the
number must be 1 less than a power of 2
for
computational
efficiency
(NSP
functional specification).

DUMP ADDRESS number

Sets the address in memory to begin
up-line dump of the adjacent node.

DUMP COUNT number

Determines the default number of memory
units to
up-line dump from the adjacent
node.

DUMP FILE file-id

Sets the identification of the file
to
write to when the adjacent node is up-line
dumped.
The file
identification is a
string that is interpreted depending on
the system where the file is.

HOST node-id

Sets the identification of the host node.
For the executor, this is the node from
which it requests services.
For
an
adjacent node, it is a parameter that the
adjacent node
receives
when
it
is
down-line
loaded.
If
no
host
is
specified, the default is executor node .

. IDENTIFICATION id-string

Sets the text identification string for
the executor node (for example, Research
Lab"). The identification string is an
arbitrary string of 1-32 characters. If
the string contains blanks or tabs it must
be enclosed in quotation marks ("). A
quotation mark within a quoted string is
indicated by two adjacent quotation marks
II

(

.... ) .

INACTIVITY TIMER seconds

Sets the maximum duration of inactivity
(no data in either direction) on a logical
link before the node checks to see if the
logical link still works. If no activity
occurs within the maximum
number
of
seconds, NSP generates artificial traffic
to
test
the
link
(NSP
functional
specification). The range is 1-65535.

INCOMING TIMER seconds

Sets the maximum duration between the time
a connect is received for a process and
the time that process accepts or rejects
it.
If the connect is not accepted or
rejected by the user within the number of
seconds specified, Session Control rejects
it for the user. The range is 1-65535.

LINE line-id

Defines a loop
node
and
sets
the
identification of the line to be used for
all traffic from the node.
Loop node
identification must be a node name. No
line can be associated with more than one
node name.

LOAD FILE file-id

Sets the identification of the file to
read from when the node is down-line
loaded.
The file identification is a
string that is interpreted depending on
the file system of the executor.

MAXIMUM ADDRESS number

Sets the largest
node
address
and,
therefore, number of nodes that can be
known about. The number is an integer in
the range 1-65535.

MAXIMUM BUFFERS number

Sets the total number of buffers allocated
to all lines.
In other words, it tells
Transport how big its own buffer pool is.
The count number is a decimal integer in
the range 0-65535.

MAXIMUM COST number

Sets the maximum total path cost allowed
from the executor to any node.
The path
cost is the sum of the line costs along a
path
between
two
nodes
(Transport
functional specification).
The maximum is
a decimal number in the range 1-1023.

MAXIMUM HOPS number

Sets the maximum routing hops from the
node to any other reachable node. A hop
is the logical distance over a
line
between
two adjacent nodes
(Transport
functional specification). The maximum is
a decimal number in the range 1-31.

MAXIMUM LINES number

Sets the maximum number of lines that this
node can know about.
The number is a
decimal in the range 1-65535.

MAXIMUM LINKS number

Sets the maximum active logical link count
for
the node.
The count is a decimal
number in the range 1-65535.

MAXIMUM VISITS number

Sets the maximum number of nodes a message
coming into this node can have visited.
If the message is not for
this node and
the MAXIMUM VISITS number is exceeded, the
message is discarded.
The number
is a
decimal in the range MAXIMUM HOPS to 255.

NAME node-name

Sets the node name to be associated with
the node
identification.
Only one name
can be assigned to a node address or a
line identification.
No name can be used
more than once in the node.

OUTGOING TIMER seconds

Sets a time-out value for
the duration
between the time a connect is requested
and the time that connect is acknowledged
by the destination node.
If the connect
is not acknowledged within the number of
seconds specified, Session Control returns
an error. The range is 1-65535.

RETRANSMIT FACTOR number

Sets the maximum number of times the
source NSP will restart the retransmission
timer when it expires.
If the number
is
exceeded, Session Control disconnects the
logical link for the user (NSP functional
specification) .
The number is decimal in
the range 1-65535.

ROUTING TIMER seconds

Sets the maximum duration before a routing
update is forced.
The routing
update
produces a routing message for an adjacent
node (Transport functional specification).
Seconds is a decimal integer in the range
1-65535.

SECONDARY DUMPER file-id

Sets the identification of the secondary
dumper
file
for
up-line dumping the
adjacent node.

SECONDARY LOADER file-id

Sets the identification of the secondary
loader file,
for down-line loading the
adjacent node.

SERVICE DEVICE device-type

Sets the service device type that the
adjacent node uses for service functions
when in service slave mode
(see Section
4.1.4.2).
The device type is one of the
standard line device mnemonics.

SERVICE LINE line-id

Establishes the line to the adjacent node
for down-line loading and up-line dumping.
Sets the default if the VIA parameter of
either
the LOAD or DUMP commands is
omitted. When down line loading a node
(Section 3.3.4), the node identification
must be that of the target node.

SERVICE PASSWORD password

Sets the password required to trigger the
bootstrap mechanism on the adjacent node.
The password is a hexadecimal number in
the range 0-FFFFFFFFFFFFFFFF (64 bits).

SOFTWARE IDENTIFICATION
software-id

Sets the identification of the software
that is to be loaded when the adjacent
node is down-line loaded.
Software-id
contains up to 16 alphanumeric characters.

SOFTWARE TYPE program-type

Sets the initial target node software
program type for down-line loading the
adjacent node. Program type is one of:
SECONDARY [LOADER]
TERTIARY [LOADER]
SYSTEM

STATE node-state

TERTIARY LOADER file-id

Sets the operational state of the executor
node. The possible states are:
ON

Allows logical links.

OFF

Allows
no
new
links,
existing links,
terminates
and stops routing
traffic
through.

SHUT

Allows no new logical links,
does
not destroy existing
logical links, and goes to
the
OFF
state
when all
logical links are gone.

RESTRICTED

Allows
logical
nodes.

no
new
incoming
links
from other

Sets the identification of the tertiary
loader file,
for down-line loading the
adjacent node.

TYPE nOde-type

Sets the type of the node as
following:

one

ROUTING

Full routing node.

NONROUTING

Node
with
capability.

PHASE II

Phase II node.

the

routing

3.3.2 CLEAR and PURGE Commands - These commands clear parameters from
the volatile and permanent data bases. The CLEAR command affects the
volatile data base;
the PURGE command affects the permanent data
base.
Not all parameters can be cleared individually.
A cleared or
purged parameter or entity identification is the same as one that has
not been set or defined.
The general form of the command is:
CLEAR}
{ PURGE

entity parameter

The entities are the same as for the SET and DEFINE commands
3.3.1) .

(Section

3.3.2.1 CLEAR and PURGE EXECUTOR NODE Commands - The CLEAR EXECUTOR
NODE command resets the executor to the node on which NCP is running.
Note that CLEAR EXECUTOR does not return the executor to that defined
in the permanent data base. The PURGE EXECUTOR NODE command redefines
the executor in the permanent data base as the local node.
Access
control is reset as well.

3.3.2.2 CLEAR and PURGE KNOWN Entity Commands - These commands clear
and purge parameters for
all of the specified entity known to the
system.
The format of the command is:

{

CLEAR}
PURGE

KNOWN plural-entity parameter

Plural entity is one of LINES, LOGGING or NODES.
Parameter is one or possibly more of the parameters associated with
the CLEAR and PURGE entity commands (Sections 3.3.2.3, 3.3.2.4, and
3.3.2.5) .

3.3.2.3 CLEAR and PURGE LINE Commands - These commands
parameters from the volatile and permanent data bases.
format is:

{

CLEAR}
PURGE

LINE 1 ine-id

ALL
COUNTER TIMER

clear line
The command

where:
ALL

Clears all parameters associated with the
line
identified
and
the
line
identification itself from the volatile or
permanent data base.

COUNTER TIMER

Clears the timer
that
controls
the
periodic logging of the line's counters.
This implies that they are no longer to be
logged.

3.3.2.4 CLEAR and PURGE LOGGING Commands - These
commands,
in
conjunction with the SET and DEFINE LOGGING commands, control event
sinks and event lists.
The same general definitions (sink-node,
sink-type, and source-qualifier) that apply to the SET LOGGING command
(Section 3.3.1.4) apply here.
{

CLEAR} LOGGING sink-type
PURGE

EVENT event-list [source-qual] [sink-node]
KNOWN EVENTS
[source-qual] [sink-node]
NAME

where:
EVENT event-list

Disables the recording of the
events
specified
by
the
event
list
(event-class.event-type) .
Appendix
F
specifies events. Section 3.3.1.4 details
the format of the event list.
The sink
node option turns off events for the
specified sink node. If no sink node is
specified, the EXECUTOR is assumed.

NAME

Clears the sink name assigned to the sink
type.
The sink then becomes the default
for the specific system, either no sink or
some system-specific standard.

KNOWN EVENTS

Disables the recording of all events known
to the executor node for the sink node.

3.3.2.5 CLEAR and PURGE NODE Commands - These commands clear volatile
(using CLEAR) or permanent (using PURGE) parameters for the node.
Node identification can be either a node name or a node address,
except for the LINE option where it must be a name. EXECUTOR may
substitute for NODE executor-node-identification.
CLEAR}
NODE node-id
{ PURGE

ALL
COUNTER TIMER
CPU
DUMP ADDRESS
DUMP COUNT
DUMP FILE
HOST
IDENTIFICATION
INCOMING TIMER
LINE
LOAD FILE

NAME
OUTGOING TIMER
SECONDARY DUMPER
SECONDARY LOADER
SERVICE DEVICE
SERVICE LINE
SERVICE PASSWORD
SOFTWARE IDENTIFICATION
SOFTWARE TYPE
TERTIARY LOADER

where:
ALL

Clears all parameters associated with
node identified.

DUMP FILE

Clears the identification of the file to
write to when the node is up-line dumped.

HOST

Clears
node.

INCOMING TIMER

Clears the node's incoming timer.

LINE

Clears the loop node entry associated with
the line.

IDENTIFICA'rION

Clears the node's identification string.

LOAD FILE

Clears the identification of the file to
read from when the node is down-line
loaded.

NAME

Clears the node name for the node.

OUTGOING TIMER

Clears the node s outgoing timer.

SECONDARY DUMPER

Clears the identification of the secondary
dumper file.

SECONDARY LOADER

Clears the identification of the secondary
loader file.

SERVICE DEVICE

Clears the service device type.

SERVICE LINE

Clears the identification of the line
associated with the node-id specified for
the purposes of down-line load, up-line
dump, and line loop test.

SERVICE PASSWORD

Clears the password required to trigger
the bootstrap mechanism on the node.

SOFTWARE IDENTIFICATION

Clears the identification of the
initial load software.

SOFTWARE TYPE

Clears the identification of the target
node software program type for down-line
loading.

TERTIARY LOADER

Clears the identification of the
loader file.

the

identification

the

host

target's

tertiary

3.3.3 TRIGGER Command - This command triggers the bootstrap of the
target node so that the node will load itself.
It initiates the load
of an unattended system.
This command will work only if the target
node either recognizes the trigger operation with software or has the
necessary hardware in the correct state.
Section 3.3.4 describes the
parameter options.
Parameters specified with a command override the
default parameters of the same type.
Section 4.2.3 describes the
trigger operation.
The format of the command is:
TRIGGER
{

NODE

nOde-id}

VIA

line-id

[[SERVICE]
[VIA
[[SERVICE]

PASSWORD
PASSWORD

password]
line-id]
password]

3.3.4 LOAD Command - This command initiates a down-line load.
There
are two variations.
Section 3.3.4.1 describes the parameters used
with this command.
Node identification is either the node name or the
node address of the target node.
This command works only if the
conditions for trigger are met,
or
if the target node has been
triggered locally.
Section 4.2.1 describes the operation of down-line
loading.

3.3.4.1 LOAD NODE Command - This loads the node
identified on the
line identified or on the line obtained from the permanent data base.
Any parameter not specified in the command line defaults to whatever
is specified in the permanent data base at the executor node.
LOAD NODE node-id

[ADDRESS
[CPU
[FROM
[HOST
[NAME
[SECONDARY [LOADER]
[SERVICE DEVICE
[[SERVICE] PASSWORD
[SOFTWARE
IDENTIFICATION
[SOFTWARE TYPE
[TERTIARY [LOADER]
[VIA

node-address]
cpu-type]
load-file]
node-id]
node-name]
file-id]
device-type]
password]
software-id]
program-type]
file-id]
line-id]

where:
[ADDRESS node-address]

Indicates the address the target
to use.

[CPU cpu-type]

Indicates the target
possible values are:

CPU

node

type.

is
The

PDP 8
PDP 11
DECSYSTEM 10
DECSYSTEM 20
VAX
[FROM load-file]

Indicates the file from which to load.

[HOST node-id]

Indicates the identification of the host
to be sent to the target node.

[NAME node-name]

Specifies the name the target node
use.

[SECONDARY [LOADER]
file-id

Provides
the
identification
secondary loader file.

[SERVICE DEVICE
device-type]

Indicates the device type that the target
node will use for service functions when
it is in service slave mode (see Section
4.1.4.2) .

[[SERVICE]
password]

Supplies the boot password for the
target
node.
A hexadecimal number in the
range
0-FFFFFFFFFFFFFFFF.

PASSWORD

is
of

to
the

[SOFTWARE IDENTIFICATION
software-id]

Provides the load software identification.
Software
identification is up
to
16
alphanumeric characters.

[SOFTWARE TYPE
program-type]

Indicates the target node software program
type.
Program-type is one of:
SECONDARY [LOADER]
TERTIARY [LOADER]
SYSTEM

[TERTIARY [LOADER]
file-id]

Provides
the
identification
tertiary loader file.

[VIA line-id]

Indicates the line to load over.

the

3.3.4.2 LOAD VIA Command - With this command
format,
the executor
loads
the target over
the
specified line,
obtaining
the node
identification from the permanent data base if necessary.
The command
format is:
LOAD VIA line-id

[ADDRESS
[CPU
[FROM
[HOST
[NAME
[SECONDARY [LOADER]
[SERVICE DEVICE
[[SERVICE] PASSWORD
[SOFTWARE IDENTIFICATION
[SOFTWARE TYPE
[TERTIARY [LOADER]

node-address]
cpu-type]
load-file]
node-id]
node-name]
file-id]
device-type]
password]
file-id]
program-type]
file-id]

3.3.5 DUMP Command - This command
performs
an
up-line
dump.
Parameters not supplied default to those in the permanent data base at
the executor node (see Section 3.3.1.5).
There are two variations, as
follows:
DUMP NODE node-id

[[DUMP] ADDRESS
[[DUMP] COUNT
[TO
[SECONDARY [DUMPER]
[SERVICE DEVICE
[[SERVICE] PASSWORD
[VIA

number]
number]
dump-file]
file-id]
device-type]
password]
line-identification]

DUMP VIA line-id

[[DUMP] ADDRESS
number]
[[DUMP] COUNT
number]
[TO
dump-file]
[SECONDARY [DUMPER] file-id]
device-type]
[SERVICE DEVICE
[[SERVICE] PASSWORD password]

3.3.6 LOOP Command - This command causes test blocks to loop back
from the specified line or node. It is limited by what the Loopback
Mirror and the passive looper can handle. There are two variations,
as described in the next two sections. Section 4.2.4 describes the
loop test operation.
When a loop test fails, the error message contains
information, in the form either
or

added

explanatory

UNLOOPED COUNT = n
MAXIMUM LOOP DATA = n

Where the unlooped count is the number of messages not yet looped when
the test failed and maximum loop data is the maximum length that can
be requested for the loop test data.

3.3.6.1 LOOP LINE Command - The line loop performs loopback testing
on a specific line, which is unavailable for normal traffic during the
test.
The optional parameters can be entered in
any
order.
Parameters not specified default to their values in the permanent data
base at the executor node. The command format is as follows:
LOOP LINE line-id

[COUNT
[WITH
[LENGTH

count]
block-type]
length]

where:
LOOP COUNT count

Sets the block count for loop tests.
integer in the range 0 to 65535.

LOOP LENGTH length

Sets the length of a block for loop tests.
Length is an integer in the range 0 to 65535.

Count is an

LOOP WITH block-type Sets the block-type for loop tests. The possible
values for block-type are ONES, ZEROES or MIXED.

3.3.6.2 LOOP NODE Command - A node loop will not interfere with
normal traffic, but will add to the network load. The parameter
options available are the same as for the line loop (Section 3.3.6.1).
The node loop can take place within one node or between two nodes. In
the latter case, the remote node is the one specified (Figures 6 and
7,
Section
4.2.4).
EXECUTOR
may
be
substituted for NODE
executor-node-identification.

3.3.7 SHOW QUEUE Command - This command displays the status of the
last few commands entered at the default executor.
The number of
commands displayed varies with each implementation. The executor
for
commands not sent across the network is shown as N/A (not applicable) .
Completed commands need not be displayed.
Every command in progress
must be shown in request number order.
Implementations that do not
allow multiple outstanding commands do not need this command.
An example of output follows:

REQUEST 113;
REQUEST
NUMBER
9

10
11
12
1 ~5

SHOW QUEUE

'EXECUTOR

COMMAND

STATUS

6 (HNGKNG)
(HNGKNG)
10 (MANILA)
6 (HNGKNG)
N/A

LOAD
SHOW
LOAD
SET
SHOW

FAILED
COMPLETE
IN PROGRESS
COMPLETE
IN PROGRESS

I.>

3.3.8 SHOW and LIST Commands - These commands are used to display
information.
The SHOW command displays information from the volatile
data base.
The LIST command displays information from the permanent
data base. The general command format is either:

{

SHOW}
LIST

entity [information-type]

[qualifiers]

or:
SHOW}
{

[information-type] entity [qualifiers]

LIST
The entities are:
ACTIVE LINES
ACTIVE LOGGING
ACTIVE NODES
EXECUTOR
KNOWN LINES
KNOWN LOGGING
KNOWN NODES
LINE
line-id
LOGGING
sink-type
LOOP NODES
NODE
node-name
KNOWN plural entities are all those known to the system, regardless of
state. ACTIVE plural entities are a subset of KNOWN as defined in the
glossary. When displaying plural nodes,
the executor display is
returned first, if it is included. Any loop nodes are returned last.
The information types are:
CHARACTERISTICS
COUNTERS
EVENTS
STATUS
SUMMARY

Appendix A contains definitions of the information types. The tables
in Appendix A specify the information returned for each information
type on the SHOW command.
The qualifiers vary according to the
specific entity, except one that is common to all entities that have
qualifiers:
TO alternate-output
This qualifier directs the output to an alternate output file or
device (for example, a disk file or a line printer) rather than the
default terminal display. The output is text in the same format it
would have on the terminal.
The format of the alternate output
specification is system-dependent.
When there is no information to display in response to a SHOW
display the phrase " no information" in place of the data.

command

3.3.8.1 Information Type Display Format - All of the SHOW and LIST
command information-type options have the same general output format.
The header of that format is:
REQUEST #ni

entity information-type AS OF dd-mon-yy hh-mm

For example:
REQUEST 121;

KNOWN LINES STATUS AS OF 8-JUL-79 10:55

REQUEST 143;

EXECUTOR NODE CHARACTERISTICS AS OF 10-SEP-79 10:56

REQUEST 145;

KNOWN NODES SUMMARY AS OF 10-SEP-79 10:57

The requested information follows the header.
the information is:

The general

format

entity-type = entity-id
data
If the entity type is NODE, then one of EXECUTOR, REMOTE, or LOOP must
precede it.
This information format repeats for each individual entity. A SHOW or
LIST command with no information type should default to SUMMARY.

3.3.8.2 Counter Display Format - Counters are identified by standard
type numbers as defined in Tables 7 and 10, Appendix A. Counters are
displayed in ascending order by type. The display format for counters
is:
value description[, INCLUDING:]
qualifier-l

qualifier-n
The value is the value of the counter, up to 10 digits for a 32-bit
counter.
It is a decimal number with no leading zeros. Zero values
distinguish the case of no-counts from the case where a counter is not

kept.
If the counter has overflowed, it is displayed as the overflow
value minus one, preceded by a greater-than sign.
For example, an
overflowed 8-bit counter would be displayed as ">254."
The description is the standard text that goes with the counter type
as defined in Tables 7 and 10. If the counter type is not recognized,
the description "COUNTER #n" is used, where n is the counter type
number.
If the counter has an associated bit map, the word "including" is
appended to the description, with a list of qualifiers. A qualifier
is the standard text for the bit position in the bit map. A qualifier
is displayed only if the corresponding bit is set. If the standard
text for the bit is not known, the qualifier "QUALIFIER #n" is used,
where n is the bit number.
For example:
REQUEST i21;

LINE COUNTERS AS OF 20-FEB-79 15:29

LINE :::: DUP-6
~.)32

416
()

400
3~j:~
4~:j

52379
4164()

963
423
5
()

ARRIVING PACKETS RECEIVED
DEPARTING PACKETS SENT
ARRIVING CONGESTION LOSS
TRANSIT PACKETS RECEIVED
TRANSIT PACKETS SENT
TRANSIT CONGESTION LOSS
BYTES RECEIVED
BYTES SENT
DATA BLOCKS RECEIVED
DATA BLOCKS SENT
DATA ERRORS INBOUND, INCLUDING:
NAK'S SENT REP RESPONSE
DATA ERRORS OUTBOUND

3.3.8.3 Tabular and
Sentence
Formats - Non-counter
information
permits two general formats. The first is easier to scan, the second
is more extensible. The first is a tabular form, with each individual
entity fitting on one line under a global header. Using this form,
unrecognized parameter types are more clumsily handled and the amount
of information per individual entity is limited to what will fit on
one output line~ The second is a sentence form.
It adapts easily to
a large number of parameters per individual entity and readily handles
unrecognized parameter types.
In either form, the order of parameter output is the same in all
implementations, even though in a particular implementation, some
parameters may be unrecognized. The output format for unrecognized
parameters is:
PARAMETER #n = value
where n is the decimal parameter number and value
value, formatted according to its data type.

the

parameter

Appendix A describes parameter types and their output order.
In the
sentence form of output, parameters that are logically grouped
together should appear on the same line.
Appendix A details these
logical groupings.

The general output format of the data for tabular form is:
entity-type

parameter-type

parameter-type ...

entity-id

parameter-value

parameter-value .••

An example of output of the data in tabular form follows:
KNOWN LINES STATUS AS OF 18-SEF'-78 15:20

439;

F~Et~UEST

LINE

STATE

ADJACENT NODE

DMC~M 1
DMe-·3
DL-O

ON
OFT
ON-LOADING

4 (BOSTON)

If NCP did not recognize an adjacent node parameter, the output would
specify the type number of the parameter and the value according to
the parameter data type.
(See Tables 6 to 10, Appendix A, for type
number s. )
The general output format of the data for sentence form is:
entity-type
par-type
par-type

entity-id
par-value, par-type
par-val ue,

par-value, ...

An example of output of the data for sentence form follows.
REQUEST +39;

KNOWN LINES STATUS AS OF 18-SEP-78 15:20

l.INE ::: DMC-1
STATE::: ON, ADJACENT NODE - 4 (BOSTON)
LINE

::.~

DMC-3

STATE :::; OFF
LINE :::; DL'-O
STATE

= ON, ADJACENT NODE = 12

The output format for the logging entity differs in the event display.
For example, for the following command:
SHOW LOGGING CONSOLE SUMMARY KNOWN SINKS

A correct output would be
LoSSins Summary as of 7-MAR-79 10:55
LoSSinS CONSOLE
State

= ON, NAME = COO:

Sink node

= 15 (HALDIR), EVENTS -

0.0,6
Line KDZ-0-1.3, 3.6-7
3.6--13
Sink node = 16 (EOWYN), Events 0.0
Line KDZ-0-l.3, 6.0-1

on
Returns - The
following
returns on SHOW and LIST entity

3.3.8.4 Restrictions
and
Rules
restrictions and rules apply to
information type commands.
1.

Node parameters. The parameters displayed for the SHOW and
LIST NODE commands depend on which node is specified. Table
8, Appendix A, indicates these restrictions.
The keywords
EXECUTOR, REMOTE or LOOP must precede NODE in a display of a
node to clarify what is displayed.

Line states. The returns
commands must show the
Table 2, following, lists
3, following,
lists all
and their causes.

Loop nodes.
Information for a single loop node is returned
when requested by the loop node name.
Information for
multiple loop nodes is returned at the end of the display for
KNOWN or ACTIVE NODES.
It is the exclusive display for LOOP
NODES.

Counters. COUNTERS can only be displayed
commands, and with line or node entities.

Events.
EVENTS applies only to the logging entity.
Sink
node identification must be address and name (if a name
exists) , even for the executor.

on the SHOW and LIST LINE STATUS
line substate as well as the state.
line states and substates.
Table
the possible line state transitions

with

the

SHOW

3.3.9 ZERO Command - This command causes a specified set of counters
to be set to zero. The command generates a counters zeroed event that
causes counters to be logged before they are zeroed.
The counters
zeroed are those the executor node supports for the specified entity.
The command format is:
ZERO

NODE
LINE
{ KNOWN
KNOWN

nOde-id}
line-id
LINES
NODES

[COUNTERS]

3.3.10

EXIT Command - This command terminates an NCP session.
Table 2
Network Management Line States

State

Meaning

Substate

--~---

..".

OFF

none

Line not usable by anything

running

Line in normal use by owner

"';'STARTING

Line
in
owner
initialization cycle

-REFLECTING

Line in use for passive (direct
line-software looped) loopback

-AUTOSERVICE

Line reserved
use

-AUTOLOADING

Line in use by Line
load

Watcher

for

-AUTODUMPING

Line in use by Line
dump

Watcher

for

-AUTOTRIGGERING

Line in use by Line
trigger

Watcher

for

-LOADING

for

(Transport)

Line

Watcher

Line in use by operator for load
-

SERVICE

---

-DUMPING

Line in use by operator for dump

-LOOPING

Line in use by operator
active line loopback

-TRIGGERING

Line in
trigger

operator

for

idle

Line reserved by operator
active service function

for

-REFLECTING

Line in use for passive (direct
line-software looped) loopback

-LOADING

Line in use by operator for load

-DUMPING

Line in use by operator for dump

-LOOPING

Line in use by operator
active line loopback

-TRIGGERING

Line in
trigger

use

operator

for

for
for

Table 3
Line State Transitions
Old State

New State

Cause of Change

Any

OFF

Operator command, SET
STATE OFF

LINE

OFF

ON-STARTING

Operator command, SET
STATE ON

LINE

SERVICE

Operator command, SET
STATE SERVICE

LINE

ON-STARTING

by
restarted
Data Link
Transport (from either end)

ON-REFLECTING

Line
message
loopback
received from remote system

ON-AUTOSERVICE

Service request received by
Line Watcher

ON-LOADING

Operator command, LOAD

ON-DUMPING

Operator command, DUMP

ON-LOOPING

Operator command, LOOP LINE

ON-TRIGGERING

Operator command, TRIGGER

SERVICE

Operator command, SET
STATE SERVICE

Transport
complete

ON-REFLECTING

message
Line
loopback
received from remote system

ON-AUTOSERVICE

Service request received by
Line Watcher

ON-LOADING

Operator command, LOAD

ON-DUMPING

Operator command, DUMP

ON-LOOPING

Operator command, LOOP LINE

ON-TRIGGERING

Operator command, TRIGGER

SERVICE

Operator command, SET
STATE SERVICE

ON-STARTING

line
Passive
terminated

ON-AUTOSERVICE

Service request received by
Line Watcher

ON-STARTING

ON-REFLECTING

LINE

initialization

LINE

loopback

(continued on next page)

Table 3 (Cont.)
Line State Transitions
Old State
ON-REFLECTING
(CaNT. )

New State

Cause of Change

ON-LOADING

Operator command, LOAD

ON-DUMPING

Operator command, DUMP

ON-LOOPING

Operator command, LOOP LINE

ON-TRIGGERING

Operator command, TRIGGER

SERVICE

Operator command, SET
STATE SERVICE

LINE

f-----

ON-STARTING

Line
released
watcher

Line

ON-AUTOLOADING

Load initiated
Watcher

Line

ON-AUTODUMPING

Dump initiated
Watcher

Line

ON-AUTOTRIGGERING

Trigger initiated
Watcher

Line

ON-AUTOLOADING

ON-AUTOSERVICE

Load complete

ON-AUTODUMPING

ON-AUTOSERVICE

Dump complete

ON-AUTOTRIGGERING

ON-AUTOSERVICE

Trigger complete

ON-LOADING

ON-STARTING

Load complete

ON-DUMPING

ON-STARTING

Dump complete

ON-LOOPING

ON-STARTING

Active line loop complete

ON-TRIGGERING

ON-STARTING

Trigger complete

SERVICE

message
SERVICE-REFLECTING Line
loopback
received from remote system

ON-AUTOSERVICE

SERVICE-LOADING

Operator command, LOAD

SERVICE-DUMPING

Operator command, DUMP

SERVICE-LOOPING

Operator command, LOOP LINE

SERVICE-TRIGGERING Operator command, TRIGGER
SERVICE

Operator command, SET
STATE ON

ON-STARTING

LINE

(continued on next page)

Table 3 (Cont.)
Line State Transitions
Old State
SERVICE-REFLECTING

Cause of Change

New State

line

loopback

SERVICE

Passive
complete

SERVICE-LOADING

Operator command, LOAD

SERVICE-DUMPING

Operator command, DUMP

SERVICE-LOOPING

Operator command, LOOP LINE

SERVICE-TRIGGERING Operator command, TRIGGER
SERVICE-LOADING

SERVICE

Load complete

SERVICE-DUMPING

SERVICE

Dump complete

SERVICE-LOOPING

SERVICE

Active line loop complete

SERVICE-TRIGGERING

SERVICE

Trigger complete

4.0

NETWORK MANAGEMENT LAYER

This layer, the heart of Network Management, contains the modules and
data bases providing most of the functions requested by Network
Control Program (NCP) commands. The Network Management layer also
provid€s automatic event-logging and an interface to user programs for
network control and information exchange. Section 4.1 describes the
Network Management modules. Section 4.2 outlines the operation of the
functions associated with each Network Information and
Control
Exchange (NICE) message, including algorithms for implementation.
Section 4.3 details the Network Management layer message formats as
well as NICE connect and accept data formats and the Event message
binary data format.

4.1

Network Management Layer Modules

This section describes the Network Management layer modules (Figure 2)
and some of the algorithms for implementing them.

4.1.1 Network Management Access Routines and Listener - The Network
Management Access Routines receive NICE commands from the Network
Control Program (NCP) and user programs.
Network Management Access
Routines pass NICE messages to the remote or local Network Management
Listener via logical links. They also pass local function requests to
the Local Network Management Functions.
The Network Management
Listener receives NICE command messages via logical links from the
Network Management Access Routines in the local node or in other
nodes.
The method used for processing Network Management functions within a
single node is implementation-dependent.
The Network Management
Access Routines can pass all local function requests to the Local
Network Management Functions. Alternatively, the access routines can
pass NICE messages to the Network Management Listener via a logical
link. The latter method cannot be used for functions, such as turning
the network on, that occur before a logical link is possible.

4.1.2 Local Network
Management Functions
other modules:
•

Management
receive the

Functions - The
Local
Network
following types of requests from

System-independent function requests from the
the Network Management Access Routines.

NICE function requests
• Management
Listener.

local

NCP

via

other

nodes

via

the

Network

function requests from the local
• NICE
Management Listener.

node

via

the

Network

from

• Automatically-sensed service requests from the Line Watcher.
The Local Network Management Functions have the
to other modules or layers:
•

following

interfaces

Line Service Functions.
The
Local
Network
Management
Functions have a control interface to the Line Service
Functions for setting and changing line states.
The Local

Network Management Functions have a "user" interface to the
Line Service Functions for handling functions that
are
necessary for service functions
(such as up-line dumping,
down-line loading, and line level testing) to be performed.
•

Control interfaces to lower layers.
The Local
Network
Management Functions interface with lower layers directly for
control and observation of
lower
level
counters
and
parameters.
An example of such an interface is examining a
node counter.

requests to lower layers and to local operating
• Function
system.
The Local Network Management Functions pass such
function requests as file access, node level loopback, and
timer setting to the application layer or to 'the local
operating system in the form of system-dependent calls.
•

Event logging.
The Local Network
Management
Functions
interface with the Event Logging module in order to set event
logging parameters that control such things as which events
are logged and at what sink node they are logged.

Section 4.2 supplies
function requests.

algorithms

for

handling

Network

Management

4.1.3 Line Watcher - The Line Watcher module senses data link level
service requests to up-line dump or load coming on a line from an
adjacent node.
The Line Watcher senses a request by calling the Line Service
Functions.
using parameters from that message, the Line Watcher then
determines the request type and calls the Local Network Management
Functions to accomplish the request.
The algorithm for implementing the Line Watcher is as follows:
Call Line Service Functions to set I_ine Service re~uest for line
IF Line Service reGuested
Set line state to ON-AUTOSERVICE (Local Network Management
Functions>
Determine function needed
Call Network Manasement Functions to perform needed function(s)
Reset line state to ON (Local Network ManaSement Functions)
ENDIF

Section 4.2.5 describes the algorithms for setting and resetting
states for the Line Watcher.

line

4.1.4 Line Service Functions - The Line Service Functions provide
Local Network Management Functions with line state changing and line
handling services. They are used for functions requiring a direct
interface to the' Data Link layer. The functions that use the Line
Service Functions are:
•

Down-line load (Section 4.2.1)

•

Up-line dump (Section 4.2.2)

•

Trigger bootstrap (Section 4.2.3)

•

Line test (Section 4.2.4.2)
1.

Active at the executor node

Passive at the target node (for unattended system)

Set line state (Section 4.2.5)

The Line Service Functions provide the following services:
•

Condition a node to be dumped, loaded or have a loopback test
performed.
This state of the target node is called service
slave mode, a mode in which the entire processor is taken
over. Control rests with the executor.

•

Notify a higher level that active line services
are needed.

(load,

dump)

•

Provide transmit/receive interface to higher level for
line services.

active

4.1.4.1 States and Substates - To arbitrate the use of the line, Line
Service Functions maintain states and substates. Table 4, following,
shows these as well as corresponding line states and substates
displayed with the NCP SHOW LINE STATUS command. Table 4 also shows
related Line Service functions.
The line can go from any substate to service slave mode.
Table 4
Line Service States, Substates and Functions and
Their Relationship to Line States

Line
State

Line
Subs tate

Line
Service
State

Line
Service
Subs tate

Line Service
Function in
Progress or Allowed

passive

idle

Pass message to
higher level

-STARTING

passive

idle

Pass message to
higher level

-REFLECTING

passive

reflecting

Passive loopback

-LOADING

open

Receive and
transmit loading
messages

-DUMPING

open

dumping

Receive and
transmit dumping
messages

-TRIGGERING

open

triggering

Receive and
transmit triggering
messages

(Continued On Next Page)

Table 4 (Cont.)
Line Service States, Substates and Functions and
Their Relationship to Line States

Line
State

Line
Subs tate

Line
Service
State

Line
Service
Subs tate

Line Service
Function in
Progress or Allowed

-LOOPING

open

looping

Receive and
transmit looping
messages

-AUTOSERVICE

closed

idle

Pass message to
higher level

-REFLECTING

closed

reflecting

Passive loopback

-AUTOLOADING

open

Receive and
transmit loading
messages

-AUTODUMPING

open

dumping

Receive and
transmit dumping
messages

-AUTOTRIGGERING

open

triggering

Receive and
transmit triggering
messages

closed

idle

Pass message to
higher level

..-

SERVICE
SERVICE

-REFLECTING

closed

reflecting

Passive loopback

SERVICE

-LOADING

open

Receive and
transmit loading
messages

SERVICE

-DUMPING

open

dumping

Receive and
transmit dumping
messages

SERVICE

-TRIGGERING

open

triggering. Receive and
transmit triggering
messages

SERVICE

-LOOPING

open

looping

off

idle

OFF

Receive and
transmit looping
messages

4.1.4.2 Priority Control - The Line Service Functions must make sure
that higher priority functions take over, and that lower priority
functions are resumed when higher priority functions are complete.
The priorities are as follows from highest (1) to lowest (5):
1.

Enter service slave mode (MOP primary mode) for passive line
loopback, receiving down-line load, sending up-line dump, and
transferring control. Control rests with the executor node.
Some implementations may require hardware support.

No line operation (off state).
is the first priority.

Active service functions (send down-line load,
trigger
bootstrap,
receive
up-line
dump, perform active line
loopback) .

Passive line loopback.

Normal operation (line available for use by owner) .

In some implementations, this

4.1.4.3 Line State Algorithms - The algorithms that follow are a
model for implementation of the Line Service states.
If these
algorithms are followed, the proper state transitions will take place.
The algorithms refer to Data Link maintenance mode. This is a Data
Link layer mode (DDCMP functional specification).
Set line state to off:
Call Data Link to halt line
Set subs tate to idle

Set line state to passive:
IF line state is off or closed
IF substate is not reflecting
Set subs tate to idle
ENDIF
ELSE
Fail
ENDIF

Set line state to closed:
IF line state is off, passive, or open
IF line state is off or passive and substate is not reflecting
Call Data Link to set line mode to maintenance
Set subs tate to idle
ENDIF
ELSE
Fail
ENDIF

Set line state to oPen:
IF line state is passive or closed
Call Data Link to set line mode to maintenance
IF subs tate is reflectins
Terminate passive loopback
ENDIF
Record sUbstate accordin~ to open parameter
ELSE
Fail
ENDIF

NOTE
The Data Link call to set the line mode
to maintenance is a single operation
that will succeed regardless of the
state in which Data Link has the line
when the call is issued.
4.1.4.4 Line Handling Functions - The line handling services of the
Line Service Functions and the algorithms for implementing them
follow.
1.

Handling line in passive state (for entering service slave
mode, passive loopback and passing messaqe to a higher
level) :
WHILE line state is passive
Call Data Link to see if line mode has Sone to maintenance
IF line mode has ~one to maintenance
Call Data Link to receive the service messa~e
IF enter service slave mode messaSe
Enter service slave mode
ELSE IF loop data messaSe
Perform passive loopback al~orithm
ELSE IF looped data messa~e
I~nore

ELSE
On re~uest, pass messaSe to hiSher level
ENDIF
IF line state is still passive
Call Data Link to halt line
ENDIF
ENDIF
ENDWHILE

Handling line in closed state (for entering
mode and performing passive loopback):
WHILE line state is closed
Call Data Link to receive message
IF enter service slave mode message
Enter service slave mode
ELSE IF loop data messaSe
Perform passive loopback alSorithm

ENDIF
ENDWHILE

service

slave

Handling line in open state (for entering service slave mode,
receiving a message, and transmitting a message):
WHILE line state is open
IF transmit reouested
Call Data Link to transmit messa~e
ELSE IF 'receive reouested
IF data overrun recorded
Return data overrun error
ELSE
Post receive reouested
ENDIF
ENDIF
Call Data Link to receive message
IF enter service slave mode message
Enter service slave mode
ELSE
IF receive posted
Return messa~e
ELSE
Record data overrun
ENDIF
ENDIF
ENDWHILE

Handling passive line loopback
target node):

(passive

the

remote

(Initial messa~e alread~ received)
Set subs tate to reflecting
WHILE substate is reflecting
IF loop data messaSe
Call Data Link to transmit looped data messa~e with received data
Call Data Link to receive a messaSe
IF timeout or start received or error or loopback terminated
Set substate to idle
ENDIF
ELSE
Set substate to idle
ENDIF
ENDWHILE

4.1.5 Event Logger - This module, diagrammed in Figure 3, following,
records events that may help maintain the system, recover from
failures, and plan for the future. Events originate in each of the
DNA
layers.
Appendix
F
describes the specified events and
corresponding event parameters.
A system manager controls event
recording with the SET LOGGING EVENT event-list command (Section
3.3.1.4). The event list entered may require the Event Logger to
filter out the recording of certain events.

Event
Monitor

- - - - - - _.- - - - - - - - - - - - - - - - - - -Network Management Layer

from Event
Transmitters

---\-

Event
Receiver

Event
Recorder

t--

...

pmo.".d .,.nts~

Event
Monitor
Interface

Event
Queue

......

....

Event
Queue

Event
File

........

-----

Event
Processor

)

Event Filters

Event
Queue

--.

Event
Queue

--.

Console

Event
Transmitter

Event
Queue

to Event
Receivers

(
Event
Queue

raw events

Event
Transmitter

Applications Layer

Event
Queue

raw events

---------~---------

Session Control Layer

Event
Queue

raw events

-------------------

Network Services Layer

Event
Queue

raw events

EVent
Queue

raw events

Event
Queue

t41---raw events

Event
Queue

raw events

Transport Layer

Data Link Layer

Physical Link Layer

Figure 3

Event Logging Architectural Model

DECnet Event Logging is specified to meet the following goals:
•

Allow events to be logged to multiple sink nodes including the
source node.

•

Allow an event to be logged to multiple logging sinks
sink node.

•

Allow the definition of subsets of events for a sink on a node
by event type and source node.

•

Include the following
monitor program.

•

Allow sharing of sinks between network event logging and local
system event logging.

•

Minimize processing, memory,
and
required to provide event logging.

•

Never block progress of network functions due to event logging
performance limitations.

•

Minimize loss of event logging
limitations.

information

due

resource

•

Record loss of
limitations.

information

due

resource

•

When required due to resource limitations, discard newer
information (which can often be regained by checking current
status) in favor of older.

•

Minimize impact of an overloaded sink on other sinks.

•

Standardize content and format of event logging information to
the extent practical, providing a means of handling system
specific information.

•

Allow independent control of sinks at sink node, including
sink identification and sink state. Sink states include use
of sink, non-use of sink, and temporary unavailability of
sink.

event

logging

sinks:

console,

network

file,

any

and

communication

4.1.5.1 Event Logger Components - As shown in Figure 3, the Event
Logger consists of the following components, described in this
section:

• Event queue

• Event processor

• Event transmitter
• Event receiver
•
•

Event recorder
Event console

• Event file
• Event monitor interface
• Event monitor
52

Event queue -- There are several event queues (Figure 3).
Each one
buffers events to be recorded or transmitted, and controls the filling
and emptying of the queue.
An event queue component has the following characteristics:
•

It buffers events on a first-in-first-out basis.

•

It fills a queue with one module;

•

It ensures that the filling 'module does not see an error
attempting to put an event on the queue.

empties it with another.
when

Since event queues are not of infinite length, events must be lost.
The filling module must record the loss of an event as an event, not
as an error because of the third characteristic above. This event is
called
an "events-lost" event.
An implementation requires the
following algorithm at each event queue:
IF WJeue i~:; full
Discard the event
ELSE IF this event would fill the Gueue
Discard the event
IF last event on Queue is not -events-lostQueue an -events-lost- event <which fills the Queue)
END IF

ELSE
(hH:~ue

the

E~vent

ENDIF
The event queue component handles "events-lost"
the following rules.

events

according

event

queues

and

Consider such events "raw" for raw
"processed" for processed event queues.

Flag such events for the sink types of the lost events.

Time stamp such events with the time of first loss.

Filter such events only if all events for the queue are
filtered.

also

Event Processor -- This component performs the following functions:
1.

Scans the lower level
records.

Modifies raw events into processed
contain the following fields:
EVENT CODE

event

queues,

collecting

raw

event

events.

Raw

events

ENTITY IDENTIFICATION

Processed events contain the following fields:
EVENT
CODE

SOURCE
NODE
ID

SINK
FLAGS

ENTITY
NAME

DATE AND
TIME STAMP

DATA

Compares the processed events with the event filters for each
defined sink node, including the executor. Following are the
characteristics of the filters used to control event logging:
•

The event source node maintains all filters.

•

Each event sink node has a separate set of filters at
source node.

•

Each sink node set of filters contains a set
for each sink (monitor, file, or console).

the

filters

sink node set of filters contains a set of global
• Each
filters, one global filter for each event class. It also
contains one or more specific filters,
particular entity within an event class.

each

for

•

Each filter contains one bit for each event type within
the class. The bit reflects the event state. SET if the
event is to be recorded, CLEAR if it is not.

•

The filtering algorithm sees first if there is a specific
filter that applies to the event. If so, the algorithm
uses the specific filter. If not, the algorithm uses the
global filter for the class.

•

Commands from higher levels create and change filters
using the EVENTS event-list option. When the specific
filters match the global filter, the event processor
deletes specific filters.

•

Although the filters are modeled in the event processor,
in some implementations, to reduce information loss or for
efficiency reasons, it may be necessary to filter raw
events before they are put into the first event queue. A
reasonable, low-overhead way to implement this is by
providing an event on/off switch at the low level. The
high level can turn this switch off if the event is
filtered out by all possible filters.
This avoids a
complex filter data base or search at the low level, but
prevents flooding the low level event queue with unwanted
events.

Passes events not filtered out to the event recorder for the
executor or to the appropriate event queue for other sink
nodes.

Event Transmitter. using a logical link, this component transmits
event records from its queue to the event receiver on its associated
sink node.
Event Receiver. This component receives event records over
links from event transmitters in remote event source nodes.
passes them to the event recorder.

logical
It then

Event Recorder. This module distributes events to the queues for the
various event sinks according to the sink flags in the event records.
Event Console. This is the event logging sink at which human-readable
copies of events are recorded.
Event File. This is the event logging sink at which machine-readable
copies of events are recorded.
To Network Management, it is an
append-only file.

Event Monitor Interface. This interface makes events available to the
Network Management Functions for reading by higher levels.
Event Monitor. This user layer module is an "operator's helper." It
monitors incoming events by using the Network Management Access
Routines and may take action based on what it has seen. Its specific
responsibilities and algorithms are undefined for the near term.

4.1.5.2 Suggested Formats for Logging Data - Following are suggested
text formats for logging data. System specific variations that do not
obscure the necessary data or change standard terminology are allowed.
The date field in the output is optional if it
context of the logging output.

obvious

from

the

Milliseconds can be used in the event time data if it is possible to
do so.
If not supported, this field will not be printed. It is
possible for two times given the same second to be logged and printed
out of order.
General format:
EVENT TYPE class.type[, event-text]
FROM NODE address[(node-name)]OCCURRED [dd-mon-yy]hh:mm:ss: [.uuu]
[entity-type[entity-name]]
[data]
For example:
Event t~pe 4.7, Packet aSeinS discard
From node 27 (DOODAH), occurred 9-FEB-79 13:55:38
Packet header = 2 23 91 20
Event t~pe 0.3, Automatic line service
From node 19 (ELROND), occurred 9-FEB-79 16:09:10.009
Line KDZ-0-l.3, Service = Load, Status = ReQuested

Or, on a node that does not recognize the events:
Event t~pe 4.7
From node 27~ occurred 9-FEB-79 13:55:38
Parameter 12 = 2 23 91 20
Event b~pe 0.3
From node 19, occurred 9-FEB-79 16:09:10.009
Line KDZ-0-l.3, Parameter 10 = 0, Parameter 11

4.2

Network Management Layer Operation

This section describes how Network Management operates with regard to
each general function.
Each function relates to a particular NICE
message. Algorithms are given for most functions. There is also some
user information in several of the descriptions, especially that
concerning testing. Finally, there is a section explaining how NICE
handles logical links. Appendix D lists status and error messages for
NICE commands, and Section 4.3.12 explains the response message
formats.

4.2.1 Down-line Load Operation - The down-line capability allows the
loading of a memory image from a file to a target node. The file may
reside at the executor node or at another node. Any node can initiate
the load.
The requirements for a down-line load are as follows:
•

The target node must be directly connected to the executor
node via a physical line. The executor node provides the line
level access.

•

The target node must be running a minimal cooperating program
(refer to the MOP functional specification). This program may
be a primary loader from a bootstrap ROM. The down-line loaq
procedure may actually involve loading a series of programs,
each of which calls the next program until the operating
system
itself
is loaded.
The initial program request
information determines the load file contents.

•

The direct access line involved must be in the ON
state.

•

The executor must have access to the file.
The location 'of
the file can be either specified in the load request or looked
up by the Local Network Management Function.

SERVICE

Local Network Management modules are used to obtain local
files.
Remote files are obtained via remote file access
techniques.
(Refer to the DAP functional specification.)
Figure 4, following, shows local and remote file access for
down-line load.
•

The executor must have access to a node data base,
be either local or remote.

which

a
can

The target node must be able to recognize the trigger
• operation
with software or hardware or must be triggered
locally.

1. LOCAL FILE ACCESS

2. REMOTE FI LE ACCESS

LEGEND:
MOP - Maintenance Operation Protocol
FAL - File Access Listener

Figure 4

Down-line Load File Access Operation

Either the target or executor node (or a remote command node) can
initiate a down-line load.
The target node initiates the load by
triggering its boot ROM. The executor node initiates the load with
either a trigger command or a load request. If the executor does not
have the initial program request or the target does not respond to the
attempt to load it, the executor should trigger the target.
Once the target is triggered, it requests the down-line load.
The
target node may be programmed to request the load over the line that
the trigger message came. Or, the target node could request the load
from another exe~utor.
The Line Watcher at the executor senses the
first program request from the target node (usually a request for the
secondary
loader, described below).
Or, if the operation was
initiated by a Network Management load request, the program request is
received as a response to that request. Figure 5, following, shows
the down-line load request operation.

1. TARGET·INITIATED REOUEST
"Target NOde

2. OPERATOR·INITIATED REOUEST FROM A REMOTE COMMAND NODE

LEGEND:
MOP - Maintenance Operation Protocol
NICE - Network Information and Control Exchange
NCP - Network Control Program

Figure 5

Down-line Load Request Operation

The executor proceeds with the load according to the
initial request.

options

the

Several fields in the NICE request down-line load message may be
either furnished as overrides or defaulted to the values in the node
data base. Any information left to default is first obtained from the
data base.
The executor identifies the target node by address, name, or line.
The name and address parameters may be supplied as overrides to those
in the data bases. The address or line identification key into the
node data base.
If line is used, then address is obtained from the
data base entry. If a target is identified by name, then address is
determined by normal name to address mapping and used to key into the
data base.
The address the target is to have is always sent to the target during
the down line load request operation. This target address is either
obtained from the node data base or supplied as an override.
The name the target is to have, if any, is either supplied with the
request as an override or obtained by normal address-to-name mapping.
Host identification follows similar rules to target identification.
The host node address must be sent to the target. If both name and
address are not supplied, address is obtained from the node data base.
Name, if any, is obtained by normal address-to-name mapping, if not
supplied.
The executor controls the process of loading the requested programs
until the operating system is loaded. The executor is responsible for
understanding the service protocol (for example, MOP) from and to the
target.
The first program to run in the target node, called the primary
loader, is typically loaded directly from its own bootstrap ROM. It
then requests, over the communications line, the next program in the
sequence.
This program, the secondary loader, may have certain
restrictions on the way it is loaded, depending on the capabilities of
the primary loader.
This process may extend through a tertiary
loader. The final program' to be loaded is defined as the operating
system, although it does not necessarily have to be capable of being a
network node.
Within a single down-line load process (possibly
including "loader loads") each program loaded is expected to request
another, except for the operating system, which does not.
When the down-line load has been completed (in other words, the
operating system successfully loaded) or aborted due to an error, the
executor sends the proper response back to the command node to finish
up the process.
The content of the load image file is specified in Appendix C.
The algorithm for handling the down-line load is as follows:
Call Line Service Function to open line for load
Perform load callin~ Line Service Function to transmit and receive
Call Line Service Function to close line

4.2.2 Up-line Dump Operation - The up-line dump capability of the
Network Management layer allows a system to dump its memory to a file
on a network node.
60

The requirements for such a dump correspond with those for a down-line
load:
•

The system being dumped must be connected to
(executor) by a specific physical line.

network

node

•

The system being dumped must run a minimal cooperative program
that can communicate over
the line with the executor. The
protocol used is implementation-dependent (refer
to the MOP
specification) .
If the executor determines that the program is not there, then
executor must supply the program.
This is the secondary
dumper.

•

The line used must be in the ON or SERVICE state and
afterwards to its original state.

returned

•

The executor must have access to the file receiving the dump.
If the file is remote,' the executor transfers the data using
remote file access routines.
(Refer
to the DAP Functional
Specification.)

The system to be dumped can indicate that
it is capable of being
dumped.
In this case, the Line Watcher at the executor node senses
the possibility of a dump and can pass a dump request to the Local
Network Management Functions at the executor node.
Alternatively, the
executor or a remote command node can initiate the dump with an NCP
DUMP command.
In this case,
the executor node's Local Network
Management Functions receive the request from the Network Management
Access Routines or the Network Management Listener.
The Local Network Management Functions proceed according to the
options in the request.
Any required information that has been left
to default is first obtained from the node data base.
The Local
Network Management Functions then accomplish the dump using the
system-dependent service protocol (for example, MOP),
and the local
operating system's file system or network remote file
transfer
facilities.
If the remote system does not respond, the executor can
trigger the remote system and load a secondary dumping program.
In cases where the dump was not initiated by the target node, when the
requested memory has been dumped to a
file or the dump has been
aborted, the executor sends an appropriate response back to the node
requesting the operation.
The content of the dump file is specified in Appendix C.
The algorithm for performing the up-line dump is as follows:
Call Line Service Function to open line for dump
Perform dump callin~ Line Service Function to transmit and receive
Call Line Service Function to close line

4.2.3 Trigger Bootstrap Operation - The trigger bootstrap capability
of the Network Management layer allows remote control of an operating
system's restart capability.
Since a system being booted
is not
necessarily a
fully functional
network node, the operation must be
performed over
a
specific
physical
line
(specified
by
a
line-identification) .
The node on the network side of the line is
called the executor node.

The NCP TRIGGER command can initiate the trigger bootstrap function
via the Network Management Listener and/or the Network Management
Access Routines.
The Local Network Management Functions at the
executor node receive the request.
the Local Network Management Functions receive a NICE trigger
bootstrap request, they proceed according to the options in the
request. Any required information which has been left to default is
obtained from the node data base.

Wh~n

The physical line being used must be in the ON or SERVICE state at the
executor node's end. The executor uses the system-dependent service
protocol (for example, MOP) to perform the operation.
When the operation is complete, the executor sends its response to the
command node.
Once the target node is triggered, it will then load itself in
whatever manner its bootstrap ROM is programmed to operate. This
could include requesting a down-line load either from the executor
that just triggered it or some other. The target node could load
itself from its own mass storage.
The algorithm for implementing the trigger bootstrap is as follows:
Call Line Service function to open line for tri~~er
Perform trig~er, callin~ line service to transmit
Call Line Service function to close line

4.2.4 Loop Test Operation - There are two types of loop tests, node
level and line level.
Both types are loopback tests that loop a
standard test block a specified number of times.
If either test fails, the response explains the failure.
If the test
fails because the test message was too long, the error return is
"invalid parameter value, length" (Appendix D) and the test data field
of the error message contains the maximum length of the loop test
data, exclusive of test data overhead. If the test fails for any
other reason, the test data field contains the number of messages that
had not been looped when the test was declared a failure.
The unlooped count need not be returned for success or for errors that
occur before looping can begin (for example, connect errors, command
message format, or content errors). The only exception to this is the
case that the value of the length parameter is too large, since this
requires a return of the maximum length.

4.2.4.1 Node Level Testing - There are two general categories of node
level tests (shown in Figures 6 and 7, following). Both use normal
traffic that requires logical links. Both have variations that use
the Loopback Mirror and NCP LOOP NODE commands. The difference is
that the first type uses what might be called "normal" communication,
while the second type sets up a loop node name established with the
NCP SET NODE LINE command.

The four ways in which node level messages travel are:
1.

Local to local

Local to remote

Local to local loopback
(using
an
operator-controlled
loopback device with a loop node defined with the line to be
used)

Local to remote loopback (using two connected
loop node defined with the line to be used)

nodes

with

The first two ways are used for the "normal" communication tests.
last two ways are used for the loop node name tests.

a
The

Test data can be a Loopback Mirror test message that is repeated a
defined number of times, a file that is transferred in any of the ways
listed above, or a message generated by a user task.
The set up commands for various
described in Figures 6 and 7.

types

node

level

tests

are

The operation of node level testing that uses Network Management
modules is as follows.
The Local Network Management Functions receive
the NCP LOOP NODE command from the Network Management Listener and/or
Network Management Access Routines.
If a line is involved in the
test, it must be in the ON state.
if the Loopback Mirror is involved,
the message is passed to the Loopback Mirror Access Routines (see
Section 5). One logical link loop test uses a loop node with a
routing node on the remote end of the line (Figure 6). This test
returns the test data on the line chosen by the Transport algorithm at
the routing node.

A. Local-to-Loopback Node Test, Single Node, uSing files as test data, with a software
controlled loopback capability
SEcT LINE Ilneld CONTROLLER LOOPBACK
SET NODE FISHY LINE l,ne 1<1
(Transfer fIle to/fro In FISHYI

B. Node Test, Single Node, uSing loopbaci' !lllrror and test messages, and a manually set
loaphack device
SET NODE FISHY LINE line Id
LOOP NODE FISHY

NODE BOB

NODE BOB
User
Modules

User
Modules

Network
Management

Network
ApplIcatIon

Network

Session Control

SessIOn Control

Network
Services

Applu:atlon

Transport

Loopback
Hardware
DeVice

Data LInk
PhYSIcal LInk

Data Link
PhYSIcal LInk

C. Local-to-Loopback Node Test, Two Nodes, using user task
SET NODE FISHY LINE line-id
(Invoke user task using BOB and FISHYI
NODE BOB
User
Modules

Use'Task

Network
Management

NODE TONY

Network
ApplicatIon

Network
Services

Network
Management
Network
ApplicatIon

Session Control

User Task

User
Modules

Session Control

Network
Services

Transport

Data Link

Data LInk

Physical Link

PhYSIcal LInk

Transport

I' "'.

I
T

i
i

1 I I

, ,-----------------------_/II
'"

Communications Hardware

)

~---------------------

D. Local-to-Loopback Node Test, Two Nodes, using loopback mirror and test messages
SET NODE FISHY LINE line-id
LOOP NODE FISHY
NODE TONY

NODE BOB
User
Modules

User
Modules

Network Management]
Access Routines

Network
Management

Network
ApplicatIon
Session Control

Network
Management

I Local Network Management FunctlonJ

•

Loopback
Access Routines

I
I

Loopback
Mirror

Network
ApplIcatIon

"J';~""

Network
Services

Transport

",';'

$""''''

~Se-ss-'o-n-C_o_-nt-ro-I----------------___l

~D-at-a-L-In-k-------'"ILI--'+:·-,r----Physical Link

'\ \'~
1

Network
ServIces

... ,

Transport
Data Link

PhYSIcal link

!i II

CommunIcatIons Hardware

',-, \

,I
1,1

, ~-----------------------------., )1
'.-::~;_;;;=_;;:;;;;;;;=-=-;;;;:~~;.~:;:.:;:.~.;;.;;.:'..l

Loopback node name = FISH Y

Figure 6 Examples of Node Level Testing Using a Loopback
Node Name with and without the Loopback Mirror

A. Normal Local-to-Local, using loop back mirror

B. Normal Local-to-Local, using user tasks

iLOOP NODE BOBI or iLOOP EXECUTORI

(Invoke user task uSing BOB)

NODE BOB
User
Modules

NODE BOB

~
I Network
Management I
Access Routines

Network
Management

User
Modules

Local Network Management Function

Session Control

Network
Services

Mirror

Network
Application

SeSSion Control

Network
Services

"' .... :::,--:,:....... "

Transport

User ,Task

user;ask

I Access
LooPback, I
Routines

Network
ApplicatIOn

Transport

I
I

+
:

' ....

,.I

Data Link

PhYSical Link

CommunicatIOns Hardware

Communications Hardware

C. Normal Local-to-Remote, using loopback mirror
LOOP NODE TONY

NODE BOB

NODE TONY

User

User
Modules

Modules

Network
Management

Network
Application
Session Control

Network Management I

Access Routines

Network
Management

I Local Network Management Function I

Loopback

Application

Network

Access Routllles I

SesSion Control

Network
Services

~:r~~c~sk

,. /

Transport

1/ / '

Data Link

Physical Link

Data Link
\

\
,

PhYSical LlI1k

CommUnications Hardware

/ /

/ / ,./

..... _---------------_ ....... / /
' , - - - - - ----- ----- - ----""

D. Normal Local-to-Remote, using files as test data
(Transfer files from BOB to TONY)

NODE TONY

NODE BOB
User
Modules

User
Modules

Network
Application

File Access
Routines

Network
Application

Session Control

SessIOn Control

Network

Network
Services

Services

Transport

File_ Access

r LIStener

Transport

Data Link

PhYSical Link

',I~
"

________________________~J
Communications Hardware

..........
""''-..

-----...--- ."...""

-- ...... --

I
//

Legend:
normal traffic flow
test data, using normal traffic paths

Figure 7

Examples of Node Level Logical Link Loopback Test
with and without the Loopback Mirror

4.2.4.2 Data Link Testing - Line level testing requires a direct
interface between the Line Service Function and the Data Link layer.
Figure 8 at the end of this section shows two types of line level
tests:
1.

Direct line loopback, hardware looped

Direct line loopback, software looped

Line loopback requires the use of line service software (for
MOP), with the line to be tested in the ON or SERVICE state.

example,

The hardware-looped option requires an operator-controlled loopback
controller, a modem set to loopback mode, a ROM with loopback
capabilities at the remote end, or some other equivalent operation.
It is recommended that the operator turn off the line, reconfigure the
hardware, and then turn the line back on. Alternatively, the operator
may leave the line in the ON state, and any resulting synchronization
problem will be logged as an error.
The algorithm for the active loop test is as ,follows:
Set not done
Call Line Service Functions to open line for active loop
WHILE not done
Call Line Service Function to transmit loopback data message
Call Line Service Function to receive message
IF error OR count exhausted OR message is not loop data or looped data
OR rf.~cei ved data does not match sent data
Set dcme
ENDIF
ENDWHIl.E
Call Line Service Function to close line

A. Direct Line Loopback. hardware looped
(SET LINE line-id STATE OFF]
)
(
(
(manually set loopback device)
) SET LINE line-idSTATE ON/SERVICE'"
( LOOP LINE lone-,d
,

I(line in ON or SERVICE state)
I
SET LINE line-id CONTROLLER LooPBACK I
ILOOP LINE line-id

Executor Node
User
Layer

I
Network
Management
Layer

N. M.

IAccess Routin
t ,

, ----fN.M.l
-~

---

Local N. M. Functions

Line Service Functions

I
I

Data
Link

: T

Physical
Link

l :

! I: I

Hardware Loopback
Device

Com"'m-u-n-:-ic-at~io-ns":"H:-ar"":'dw-a-re+--------1

:,------------"'----------1--.
.
~-,,)
B. Direct Line Loopback, software looped. line in ON or SERVICE stata"
Executor Nod.

Target Node
(in SERVICE or ON state)

LOOP LINE line-id
User
Layer

User
Layer

N. M.
LAcC8SS Routine
Network
Management
Layer

--'

Local N. M. Functions

Line Service Functions

Network
Management
Layer

~----------------~-~._----------------_1
, ,
Data
Link

! I

Physical
Link

Line Service Functions

~-~
I I

Link

l
II

~::ical:

Communications Hardware

I\ _______
,-----------------------------,
... ___________ .. __________ .J
I

Legend:
'optional alternative
* * implementation-dependent

Figure 8

control flow
- - - - .. data flow

N. M. = Network M8Ilapment

Physical Link Loopback Tests and Command
Sequences Effecting Them

4.2.5 Change Parameter Operation - When a NICE change parameter
request is received, the specified parameters are changed, usually by
interfacing with the local operating system. An appropriate resporise
is then returned to the requestor.
The options of the change
parameter request indicate the desired operation (either specifying a
different value or removing the value) and the entity it relates to.
The operation can be done either for volatile or permanent parameters.
The request may contain zero or more parameters. If there are none,
the operation applies to the entire entity entry (in other words, the
NCP ALL parameter). All parameters in the message should be checked
before any are changed in the data base. If one parameter fails the
check, then the operation should fail. A single response indicates
success or failure for single-entity operations.

A change parameter request may apply to a group of entities. In this
case, success or failure is individual. The entire request does not
fail if a single entity request fails. An initial fail return implies
no further responses are coming. A special success return indicates
more responses will follow, one for each entity in the group.
Changing the line state requires the following capabilities:
For operator:
•

set line state to OFF

•

Set line state to ON

•

Set line state to SERVICE

For the Line Watcher:
•

Set line state to ON-AUTOSERVICE

•

Reset line state from ON-AUTOSERVICE

All of the algorithms imply recording the line state if they
The line state algorithms follow.

succeed.

Set line state to OFF:
Call Transport to set line state to off
Call Line Service Function to set line state to off

Set line state to ON:
Call Line Service Function to set line state to passive
IF success
Call Transport to set line state to on
ELSE
Fail
ENDIF

Set line state to SERVICE:
Call Line Service Function to set line state to closed
IF success
Call Transport to set line state to off
ELSE
Fail
ENDIF

Set line state to ON-AUTOSERVICE:
IF line state is ON
Perform alSorithm to set line state to service
ELSE
Fail
ENDIF

Reset line state from ON-AUTOSERVICE:
If line state is ON-AUTOSERVICE:
Perform alSorithm to set line state to on
ENDIF

4.2.6 Read Information Operation - When a read information request is
received,
a response is returned, followed by the requested data in
the form of standard Network Management data blocks (Appendix A).
The
data may be obtained either from within the Local Network Management
Function itself or by interfacing with the system as appropriate.
The many restrictions and special situations relating to reading
specific
parameters
or counters are described in Appendix A.
Additional information is in Section 3.3.8 (SHOW command).
A fail return in the first response implies no further
responses are
coming.
A special success return indicates the command message was
accepted and more will follow.

4.2.7 Zero Counters Operation - When a
zero counters request is
received, the appropriate counters are cleared by interfacing with the
local operating system. An appropriate response is then returned to
the requestor.
If a read and zero was requested, the counters are returned
read information had been requested.

A fail return on the first response implies no further
responses are
coming.
Success is a single return for single-entity operations.
For
multiple-entity operations,
success is a special success return
implying further responses.

4.2.8 NICE Logical Link Handling - This section describes the logical
link algorithms that Network Management uses when sending NICE
messages.
The version data formats are in Section 4.3.12.
The
determination that a received version number is acceptable is always
the responsibility of the higher version software, whether it is the
command source or the listener.
The recommended buffer size for NICE messages is 300 bytes.
The Network Management Listener algorithm follows:

Receive connect reGuest
(Optionall~) Determine privile~e level based on access control
IF resources available and received version number OK
Send connect accept with version number in accept data
WHILE connected (see Note, below)
Receive command messa~e
IF messa~e received
Process command messa~e accordin~ to command and privile~e
Send response messa~e(s)
ENDIF
ENDWHILE
ELSE
IF received version number not OK
Send connect reject with version skew reason in reJect data
ELSE
Send connect reJect
ENDIF
ENDIF

NOTE
The algorithms used for connections is
implementation dependent. For example,
connections
can
be
maintained
permanently, only while the executor is
set, timed-out, or one per command.
The Network Management command source algorithm follows:
Send connect reauest with version number in connect data
IF connect accepted
IF received version number OK
WHILE desired
Send command messaSe
Receive response messaSe(s)
ENDWHILE
ENDIF
Disconnect link
ELSE
IF connect reJected b~ listener
IF reJect data indicates version skew
Failure due to version skew
ELSE
Failure due to listener resources
ENDIF
ELSE
Failure due to network connect problem
ENDIF
ENDIF

4.2.9 Algorithm for Accepting Version Numbers - A version number
consists of three parts -- version, ECO (Engineering Change Order) ,
and user ECO (Section 4.3.12).
In general, another version is
acceptable if it is greater than or equal to this version. If less
than this version, it is optionally acceptable as determined by
product requirements.
When comparing two version numbers, compare the second parts
the first parts are equal, and so on.

only

4.2.10 Return Code Handling - Use the following return code
algorithm to call the Network Management access routines:

handling

Initiate function
IF return code = more
WHILE return code < > done
Perform next operation
Process success/failure
ENDWHILE
ELSE
Process success/failure
ENDIF

Note that an initiate call starts the function, and an operate call
performs the function (one entity at a time in the case of plural
enti ties) .

4.3

Network'Management Layer Messages

This section describes the NICE and Event Logging Messages, NICE
response message format, and NICE connect and accept data format.
NICE is a command-response protocol.
Because the Network Management
layer
is built on top of the Network Services and Data Link layers,
which provide logical links that guarantee sequential and error-free
data delivery, NICE does not have to handle error recovery.
In the message descriptions that follow, any unused bits or bytes are
to be" reserved and set to zero to allow compatibility with future
implementations.
Conditions such as non-zero reserved areas and
unrecognized codes or unused bytes at the end of a field or message
should be treated as errors, and no operation should be performed
other than an appropriate error response.
The entire message should be parsed and checked
any operation is performed.

for

validity

before

4.3.1 NICE Function Codes - The Phase III NICE protocol performs the
following message functions.
The last one is for system specific
commands, not specified in this document.
Function
CODE

NICE
Function

15
16
17
18
19
20
21
22

Request down-line load
Request up-line dump
Trigger bootstrap
Test
Change parameter
Read information
Zero counters
System-specific function

4.3.2 Message and Data Type Format Notation - The Network Management
message format and data type descriptions use the following notation.
FIELD (LENGTH)

CODING

= Description of field

where:
FIELD

Is the name of the field being described

LENGTH

Is the length of the field as:
1.

A number meaning number of 8-bit bytes.

A number followed by a "B" meaning number of bits.

The letters "EX-n" meaning extensible field with n
being a number meaning the maximum length in 8-bit
bytes.
If no number is specified the length is
limited
only
by
the
maximum NICE message.
Extensible fields are variable in length consisting
of 8-bit bytes, where the high-order bit of each
byte denotes whether the next byte is part of the
same field.
The -1 means the next byte is part of
this field while a
0 denotes the last byte.

Extensible fields can be binary or bit map; if
binary, then 7 bits from each byte are concatenated
into a single binary field; if bit map, then 7
bits from each byte are used independently as
information bits.
The bit definitions define the
information bits after removing extension bits and
compressing the bytes.

CODING

The letters III_n" meaning image field with n being
a number which is the maximum length in 8-bit bytes
of the image. The image is preceded by a I-byte
count of the length of the remainder of the field.
Image fields are variable length and may be null
(count-0) .
All 8 bits of each byte are used as
information bits. The meaning and interpretation
of each image field is defined with that specific
field.

The character "*" meaning remainder of message.
A
number following the asterisk indicates the minimum
field length in bytes.

Is the representation type used.

where:
A

7-bit ASCII

Binary

Bit Map (where each
independent meaning)

Constant

bit

group

bits

has

NOTES
1.

If length and coding are omitted, FIELD represents
a
generic
field with a number of subfields
specified in the descriptions.

Any bit or field which is stated to be "reserved"
shall be zero unless otherwise specified. Any bit
or field not described is reserved.

All numeric values in this document are shown
decimal representation unless otherwise noted.

All fields are presented to the physical link
protocol least significant byte first. In an ASCII
field, the leftmost character is in the low-order
byte.

Bytes in this document are numbered with bit 0 the
rightmost (low-order, least-significant) bit, and
bit 7 the leftmost (high-order, most-significant)
bit.
Fields and bytes of other lengths are
numbered similarly.

Corresponding data type format notation used in
Tables 6, 8, and Appendix F is described at the
beginning of Appendix A.

4.3.3

Request Down-line Load Message Format

FUNCTION
CODE

OPTION

NODE

PARAMETER
ENTRIES

LINE

where:
FUNCTION CODE (1)

B = 15

OPTION (1)

Is one of the following options:

Option bits

Value/Meaning

0 = Identify target by node-ide
1 = Identify target by line-ide

NODE

Is the target node
identification in node-id
format
(see Appendix A) as key into defaults data
base (present only if option bit 0
0) .
Plural
nodes options are not allowed.

LINE

Is the line identification in line id format
(see
Appendix A).
Plural lines options not allowed.
Present only if option bit 0 = 1.

PARAMETER ENTRIES

are zero or more of PARAMETER ENTRY consisting of:
DATA
ID

DATA

where:
DATA ID (2)

Is the parameter type number
(see note below and Appendix
A) •

DATA

Is
the
parameter
(Appendix A).
NOTE

The parameters allowed are the following
node parameters:
ADDRESS
CPU
HOST
LOAD FILE
NAME
SECONDARY LOADER
SERVICE DEVICE
SERVICE LINE (allowed only
if bit 0 = 0)
SERVICE PASSWORD
SOFTWARE IDENTIFICATION
SOFTWARE TYPE
TERTIARY LOADER

data

4.3.4

Request Up-line Dump Message Format

FUNCTION
CODE

OPTION

NODE

PARAMETER
ENTRIES

LINE

where:
FUNCTION CODE (1):

B = 16

OPTION (1)

Is one of the following options:

: BM

Option bits

Value/Meaning

0 == Identify target by node-ide
1 = Identify target by line-ide

NODE

Identifies the node to be dumped (present only if
option bit 0 = 0). Format is defined in Section
A. 3.

LINE

Specifies the line over which to dump (present
only if option bit 0 = 1). Format is defined in
Section A.l.

PARAMETER ENTRIES

are zero or more of PARAMETER ENTRY consisting of:
DATA
where:
DATA ID (2)

Is the parameter type number
(see note below and Appendix
A) •

DATA

Is
the
parameter
(Appendix A) .
NOTE

The parameters are selected from the
node
parameters.
Only
certain
parameters are allowed in the
dump
message. They are:
DUMP ADDRESS
DUMP COUNT
DUMP FILE
SECONDARY DUMPER
SERVICE LINE (allowed only
if option bit 0 = 0)
SERVICE PASSWORD

data

4.3.5

Trigger Bootstrap Message Format

FUNCTION
CODE

OPTION

NODE

LINE

PARAMETER
ENTRIES

where:

= 17

FUNCTION CODE (1):

OPTION (1)

Is one of the following options:

: BM

Option bits

Value/Meaning
0 = Identify target by node-ide
1 = Identify target by line-ide

NODE

Identifies the node to trigger boot on
(present
only if option bit 0 = 0).
The format is defined
in Section A.3.

LINE

Identifies the line over which to trigger the boot
(present only if option bit 0 = 1). The format is
defined in Section A.l.

PARAMETER ENTRIES

are zero or more of PARAMETER ENTRY consisting of:
DATA
where:
DATA ID (2)

Is the parameter type number
(see note below and Appendix
A) •

DATA

Is
the
parameter
(Appendix A).
NOTE

The parameters are selected from the
node
parameters.
Only
certain
parameters are allowed
in the trigger
message.
They are:
SERVICE LINE (allowed only
if option bit 0 = 0)
SERVICE PASSWORD

4.3.6

Test Message Format

FUNCTION
CODE

OPTION

NODE USER PASSWORD ACCOUNTING LINE PARAMETER
ENTRIES

data

where:

= 18

FUNCTION CODE (1):

OPTION (1)

Is one of the following options:

: BM

Option bits

Value/Meaning

0
1

= Node type loop test
= Line type loop test

If node type loop test:

For node type loop tests only
follows:

(option

Default access control
Access control included
0),

four

parameters

are

NODE

Identifies the node to loopback the test block in
node-id format (Section A.3). Plural node options
are not allowed.

USER (1-39): A

Is the user-id to use when connecting
Present only if option bit 7 = 1.

node.

PASSWORD (1-39): A

Is the password to use when connecting
Present only if option bit 7 = 1.

node.

ACCOUNTING (I-39):A

Is the accounting
connecting to node.

= 1.

information to
use
when
Present only if option bit 7

For line tests only (option 1), one parameter is as follows:
LINE

Identifies the line to send the test on in line-id
format (Section A.l).
Plural lines options not
allowed.

PARAMETER ENTRIES

Are zero or more of
of:
IDATA ID I

PARAMETER

ENTRY,

consisting

DATA

where:
DATA ID (2)

DATA

Is the parameter type
(Appendix A).

number

Is
the
parameter
(Appendix A).

data

NOTE
The parameters are selected from the
node
parameters.
Only
certain
parameters are allowed in the
test
message. They are:

LOOP COUNT
LOOP LENGTH
LOOP WITH
76

4.3.7

Change Parameter Message Format

FUNCTION
CODE

OPTION

ENTITY
ID

FUNCTION CODE (1):

B = 19

OPT ION (1):

Is one of the following options:

PARAMETER
ENTRIES

where:

Bits
7

0-1

Meaning
0

= Change volatile parameters.

= Change permanent parameters.

= Set/define parameters.

= Clear/purge parameters.

Entity type

(Appendix A) .

ENTITY ID

Identifies the particular entity (Appendix A).

PARAMETER ENTRIES

Are zero or more of PARAMETER ENTRY consisting of:
IDATA IDI

DATA

where:
DATA ID (2)

Parameter
type
(Appendix A).

DATA

4.3.8

New value according
to DATA
ID
(Appendix A).
Present
only if option bit 6 = 0.

Read Information Message Format

FUNCTION
CODE

OPTION

where:
FUNCTION CODE (1):

number

OPTION (1):

Is one of the following options:
Bits

Meaning

0 = Read volatile parameter
1 = Read permanent parameter

4-6

Information type as follows:

0 = Summary
1 = Status
2 = Characteristics
3 = Counters
4 = Events
0-1
ENTITY ID
4.3.9

Entity type (Appendix A) .

Identifies the particular entity (Appendix A) .

Zero Counters Message Format

FUNCTION
CODE

OPTION

ENTITY
ID

FUNCTION CODE (1):

B = 21

OPTION (1):

Is one of the following options:

where:

Bits

Meaning

1 = Read and zero
0 = Zero only

0-1
ENTITY ID

4.3.10
FUNCTION
CODE

Entity type (Appendix A) .
(line or node only)

Identifies the
(Appendix A).

particular

entity,

required

NICE System Specific Message Format
SYSTEM
TYPE

REMAINDER

where:
B = 22

FUNCTION CODE (1)
SYSTEM TYPE (1)

REMAINDER (*)

: B Represents the type of operating system command to
which command is specific.

·Value

System

1
2
3
4

RSTS
RSX family
TOPS-20
VMS

Consists of data,
requirements.
78

depending

system

specific

4.3.11
RETURN
CODE

NICE Response Message Format
ERROR
DETAIL

ERROR
MESSAGE

ENTITY
ID

TEST
DATA

DATA
BLOCK

where:
RE'rURN CODE (1)

B Is one of the standard NICE return codes (Appendix
D) •

ERROR DETAIL (2)

:B Is more detailed error
information according
to
the error code (e.g., a parameter type).
Zero if
not applicable.
If applicable but not available,
its value is 65,535 (all bits set).
In this case
it is not printed.

ERROR MESSAGE
(1-72) : A

Is a
system dependent error message that may be
output in addition to the standard error message.

[ENTITY ID]

Identifies a particular entity
(Appendix A)
if
operation is on plural entities, or operation is
read information or read and
zero counters.
If
the entity is the executor node, bit 7 of the name
length is set.

[TEST DATA]

(2)

B Is the information resulting from a test operation
(Test message only).
This is only required if a
test failed and
if data
is relevant.
Section
4.2.4 explains contents.

[DATA BLOCK]

Is one of the data blocks described in Appendix A
(for
read
information message or read and zero
message) .

If a response message
is short terminated after any field,
the
existing fields may still be interpreted according to standard format.
This means,
for
example,
that a
single byte return is to be
interpreted as a return code.
Responses to messages not noted as exceptions above are single
responses indicating return code, error detail, and error message.
A success response to a request for plural entities is indicated by a
return code of 2,
followed by a separate response message for each
entity.
Each of these messages contains the basic response data
(return code,
error detail, and error message) and the entity ide
A
return code of -128 indicates the end of multiple responses.

4.3.12 NICE Connect and Accept Data Formats - The first
of the connect accept data are:
VERSION

DEC
ECO

USER
ECO

where:
VERSION (1)

Is the version number

DEC ECO (1)

Is the DIGITAL ECO number

Is the user ECO number

USER ECO (1)

three

bytes

4.3.13 Event Message Binary Data Format - This section describes the
generalized binary format of event data.
It applies to messages on
logical links and, as much as possible, to files.
The buffer size for event messages is 200 bytes.
The format of an event logging message is:
FUNCTION
CODE

SINK
FLAGS

EVENT
TIME

EVENT
CODE

SOURCE
NODE

EVENT
ENTITY

EVENT
DATA

where:
FUNCTION CODE (1)
SINK FLAGS (1)

B = 1, meaning event log

: BM Are flags indicating which sinks are to receive a
copy of this event, one bit per sink.
The bit
assignments are:
Bit

Sink

---.-

0
1
2

EVENT CODE (2)

EVENT TIME

Console
File
Monitor

BM Identifies the specific event as follows:
Bits

Meaning

0-4
6-14

Event type
Event class

Is the source node date
processing.
Consists of:

and

time

event

SECOND MILLISECOND
JULIAN
HALF DAY
where:
JULIAN HALF DAY (2)

SECOND (2)

: B

Number of
half
days
since 1 Jan 1977 and
before
9
Nov
2021
(0-32767).
For example,
the morning of Jan 1,
1977 is 0.
Second within
current
half day (0-43199) ~

MILLISECOND (2)

Millisecond
within
current second (0-999).
If not supported, high
order
bit
is
set,
remainder are clear, and
field
is not printed
when
formatted
for
outp.ut.

Identifies the source node.

SOURCE NODE

It consists of:

NODE
NODE
ADDRESS NAME
where:

EVENT ENTITY

NODE ADDRESS (2)

Node
address
Section A. 3) .

NODE NAME (1-6)

Node name, 0 length,
none.

Identifies the entity involved in
applicable.
Consists of:

the

(see
if

event,

Represents the type
entity, as follows:

where:
ENTITY TYPE (1)

Value

Entity Type

-1

none
Line
Node

ENTITY ID Field
none
LINE ID
NODE ID
Identifies the entity.
Depends on type, defined
below.

ENTITY ID

where:
LINE ID (1-16)

NODE ID

EVENT DATA (*)

Identifies
entity.

line

Identifies
a
node
entity, same form as for
SOURCE NODE.

Is event specific data, zero or more data entries
as defined
for NICE data blocks, parameter types
according to event class.

5.0

APPLICATION LAYER NETWORK MANAGEMENT FUNCTIONS

The only Network Management function
layer is the loopback mirror.

5.1

specified

for

the

application

Loopback Mirror Modules

The Loopback Mirror service tests logical links either between nodes
or within a single node. It consists of an access interface -- the
Loopback Access Routine;
service routines -- the Loopback Mirror;
and a simple protocol -- th~ Logical Loopback Protocol.

5.2

Loopback Mirror Operation

When the Loopback Mirror accepts a connect, it returns its maximum
data size in the accept data.
This is the amount of data it can
handle, not counting the function code.
When a Logical Loopback message is received, it is changed into the
appropriate response message and returned to the user (Figure 7,
Section 4). The Loopback Mirror continues to repeat all traffic
offered. The initiator of the link disconnects it.

5.3

Logical Loopback Message

Section 4.3.2 describes message format notation.
If the function code is not valid, or the message
failure code is returned.

5.3.1

too

long,

the

bytes,

that

the

Connect Accept Data Format

I MAXIMUM DATA I
where:
MAXIMUM DATA (2)

5.3.2

Is the maximum length,
Loopback Mirror can loop.

Command Message Format

FUNCTION
CODE

DATA

where:

FUNCTION CODE (I)

DATA (*)

Is the data to loop.

5.3.3

Response Message

IRETURN CODE I

DATA

where:
RETURN CODE (1)

B Indicates Success (1) or Failure (-1).

DATA (*)

Is the data as received, if success.

APPENDIX A
NETWORK MANAGEMENT ENTITIES, PARAMETERS, AND COUNTERS: FORMATS AND DATA BLOCKS

This appendix describes the formats of all entities, entity parameters
and entity counters, as well as the returns used in the NICE protocol
and Event Logging messages in response to a request for information.
There are three entities: LINE, LOGGING and NODE. The entities also
have plural forms:
KNOWN and ACTIVE LINES, LOGGING and NODES, and
LOOP NODES. The glossary defines the entities.
Type Number. Each entity, parameter and counter is
number. The entity type numbers are as follows:
Type Number

Keyword

NODE
LINE
LOGGING

The parameter and counter type numbers appear in the
appendix.

assigned

type

tables

this

Entity Identification Formats.
Each
entity
is
assigned
an
identification format at both NCP and Network Management layer level.
Thes~ formats also appear below in appropriate sections.
Entity Parameter and Counter Formats. Each parameter and counter is
assigned a format at both NCP and Network Management layer level,
described below in appropriate sections. The notation used for the
parameter formats is described in Section 4.3.2.
Parameter ~isplay Format and Automatic Parsing Notation.
Each
parameter IS assigned a data type at Network Management layer level
that corresponds with the format of the parameter.
This information
allows NCP to format and output most parameter values in a simple way,
even if NCP does not recognize the parameter type.
The notation used in the parameter tables in this appendix to describe
these data types is as follows:
Notation

Data Type

C-n
CM-n
AI-n
DU-n
DS-n
H-n
HI-n

Coded, single field, maximum n bytes
Coded, multiple field, maximum n fields
ASCII image field, maximum n bytes
Decimal number, unsigned, maximum n bytes
Decimal number, signed, maximum n bytes
Hexadecimal number, maximum n bytes
Hexadecimal image, maxlmum n bytes

NICE Returns.
A response to a SHOW command consists of
the
identification of the particular entity to which it applies and zero
or more data entries.
The data entries are either parameter or
84

counter entries, depending on the information requested. Entries are
in ascending order, by type, so that they can be easily grouped for
output.
When an implementation recognizes the parameter type of a coded field,
the output should be the keyword(s)
or other interpretation that
corresponds to the code for that parameter type.
If the parameter
type is not recognized, the field should be formatted as hexadecimal.
The format of a data entry is as follows:
DATA ID (2): BM

Identifies:
Bit

Meaning

0 = Parameter data
1 = Counter data

If bit 15 is clear, the rest of the
follows:

bits

are

Bits

Meaning

0-11

Parameter type, interpreted according
to entity type.
Reserved

12-14

If bit 15 is set, the rest
follows:

Bits

Meaning

0-11

Counter type

0 = not bit mapped
1 = bit mapped

13-14

Counter width

the

bits

are

0 = reserved
1 = 8 bits
2 = 16 bits
3 = 32 bits
DATA TYPE (1): BM

Identifies data type, present only
data
Bit
7

for

parameter

Meaning
1 = Coded, interpreted

according

PARAMETER TYPE.
0 = Not coded.
If bit 7 is set, the
follows:

rest

the

bits

are

Bit

Meaning

0 = Single field. Bits 0-5 are the
number of bytes in the field.
1 = Multiple field. Bits 0-5 are the
number of fields, maximum 15;
each field is preceded by a DATA
TYPE.

If bit 7 is not set, the rest of the bits
follows:
Bit
6

are

Meaning
1 = ASCII image field. Bits 0-5 zero.
o = Binary number. Bits 0-3 are data
length.
0 implies data is image
field.
Bits 4 and 5, used to
indicate how to format the binary
number for output, are:
Value

Meaning
Unsigned Decimal Number
Signed Decimal Number
Hexadec imal .Numbe r
Octal Number

1
2
3

BIT MAP (2): BM

Is the counter qualifier bit map, included only if
data id is counter and counter is bit mapped.

DATA: B

Is the data, according to data id and type.

The data required for setting a parameter or counter is the entity
identification, the DATA ID, and the DATA. The information required
for clearing a parameter or counter is the entity identification and
the DATA ID. When a parameter is displayed, the information is entity
id, DATA ID, DATA TYPE, BITMAP (if applicable) and DATA. The purpose
of the data type field is to provide information for an output
formatter. Thus the formatter can know how to format a parameter
value even if its parameter type is unrecognized.
A coded multiple (CM) field cannot appear as a data type for
within a coded multiple type parameter value.

field

All numbers are low byte first in binary form whether image or not.
The image option for numbers can only be used for parameters where it
is explicitly required. All number bases except hexadecimal have a
maximum Length of four bytes.
Indicate counter overflow by setting all bits in the DATA field.
The following ranges are reserved
parameters:

for

Range

Reserved for

2100-2299

RSTS specific

2300-2499

RSX specific

2500-2699

TOPS-20 specific

2700-2899

VMS specific

2900-3899

Future use

3900-4095

Customer specific

system

specific

counters

Information Types.
Each parameter is associated with one or more
information types.
The parameter tables
in this appendix use the
following symbols to indicate information types for each parameter.
Symbol
C
S

*EV

Keyword

Associated Entity

CHARACTERISTICS
STATUS
SUMMARY
EVENTS

All entities
All entities
All entities
LOGGING

Applicability Restrictions.
All node parameters and counters cannot
be displayed at every node;
nor can all line counters be displayed
for every line-id.
In the following tables, which describe the entity
parameters
and
counters,
the
following
symbols
note these
restrictions:
Symbol
A

DN
E
N
L
R

Applicability
Adjacent node only
Destination node only
(includes executor)
Executor node only
Node by name only
Loop nodes
Remote nodes
(all nodes except
executor and loop nodes)
Sink node only
Multipoint station
(when no tributary
number was specified
in the request line-id)
Multipoint tributary
(when a tributary
number was specified
in the request line-id)

Setability Restrictions.
Some parameters have
user
setability
restrictions, indicated in this appendix by the following notation:
Symbol
RO
WO

A.I

Meaning
Read only
Write only, in the sense that it appears in a
different form in a read function.
(For example,
a node name can be set, but it is read as part of
a node id . )

LINE Entity

Lines may be referred to individually or as a group.
The formats
specifying line entities symbolically are as follows:

for

LINE line-id
KNOWN LINES
- ACTIVE LINES
A line identification consists of a device identification
(dev), a
controller number
(c), a unit number
(u),
if a mulitple line
controller, and a tributary number (t), if multipoint.
These fields
represent the actual local hardware for the line.
If the device is

not a multiplexer, the unit number is not allowed.
The tributary
number is a logical tributary number and is not to be confused with
the tributary address used to poll the tributary.
The tributary
number is used by Network Management to identify the tributary. The
tributary address is used by the multipoint algorithm at the Data Link
level to identify a tributary (DDCMP functional specification). If
the device is not multipoint, the tributary number is not allowed. An
omitted unit and/or tributary number in a line-identification implies
the entire controller and/or station.
A line identification consists of one to sixteen upper or lower case
alphanumeric
characters.
The line-identification format is as
follows:
dev-c-u.t
Some examples:
DMC-0
DMC-l
DZ-0-1
DZ-.1-0
DV-0-0.8
DV-3-0.0
DL-l.3

(DMC, controller 0)
(DMCll, controller 1)
(DZll, controller 0, unit 1)
(DZll, controller 1, unit 0)
(DVll, controller 0, unit 0, tributary 8)
(DVll, controller 3, unit 0, tributary 0)
(DLll, controller 1, tributary 3)

"Wild cards~ are permitted in line identifications. A wild card is an
asterisk (*) that replaces a controller, unit, or tributary number in
a line identification. Wild cards specify known lines in the range
indicated by their position in the line identification.
The following represent legal uses of wild cards:
Line
Identification

Meaning

DMC-*

Known DMC lines.

DZ-3-*

Known units on DZ controller 3.

DZ-3-4. *

Known tributaries on DZ controller 3, unit 4.

DZ-3-*.*

Known units and tributaries on DZ controller 3.

The following represent illegal uses of wild cards:

*
DZ-*-3
When represented in binary, line identification is one of three
choices, depending on the function it will be applied to. The format
is as follows:
LINE FORMAT (1)

Line format type, with the following values:
Number

Active lines
Known lines
Length of line-id

-2
-1
>0

LINE ID

Type

The ASCII line identification if LINE
> 0.

FORMAT

The complete parsing of a line identification can take place only at
the executor node.
This is because the executor is the only node that
can know what device mnemonics and other line characteristics are
applicable to itself.
The following table contains
devices:

all

currently

recognized

DECnet

line

Table 5
DECnet Line Devices
Mne

Multiplexer

Description

**DP
DU

N
N

**DQ
DA
DUP
DMC

N
N
N
N

DLV
DMP
DTE
DV
DZ

N
N
N

KDP
KDZ
**KL
PCL

Y
y

DPII-DA synchronous line interface
DUII-DA
synchronous
line
interface
(includes DUVII)
DLII-C,
-E
asynchronous
serial
line
interface
DQII-DA synchronous serial line interface
DAII-B, -AL unibus link
DUPII-DA synchronous line interface
DMCII-DA/AR, -MA/AL, -FA/AR interprocessor
link
DLVII-E asynchronous line interface
DMPII multipoint interprocessor link
DTE20 interprocessor link
DVII-AA/BA synchronous link multiplexer
DZII-A,
-B
asynchronous
serial
line
multiplexer
KMCII/DUPII-DA synchronous line multiplexer
KMCII/DZ-II-A asynchronous line multiplexer
KL8-J serial line interface
PCLII-B multiple CPU link

A.I.I

Y
Y

N
y

Line Parameters - The line entity has the following parameters:

LINE STATE (I)

: B

Represents the line state, as follows:
Value

Keyword

0
I
2
3

ON
OFF
SERVICE
CLEARED

** not supported by Phase III DECnet

LINE SUBSTATE (1)

Represents the line
following values:

Value
0

1
2
3
4
5
6

7
8
9

LINE SERVICE (2)

substate,

the

with

the

Keyword
STARTING
REFLECTING
LOOPING
LOADING
DUMPING
TRIGGERING
AUTOSERVICE
AUTOLOADING
AUTODUMPING
AUTOTRIGGERING

Represents line service
following values:

with

Value

Keyword

0
1

ENABLED
DISABLED

control

LINE COUNTER TIMER (2)

B
Is the number of seconds between line counter
log events.

LINE LOOPBACK NAME (1-6)

: A
Is the name to be associated with a line as a
result of a "SET NODE node-id LINE line-id"
command.

LINE ADJACENT NODE

Identifies the node on the other end of
line.
Consists of:

this

NODE
NODE
ADDRESS NAME
where:

LINE BLOCK SIZE (2)
LINE COST (1)

: B

NORMAL TIMER (2): B

NODE ADDRESS (2)

: B

Adjacent node address.

NODE NAME (1-6)

: A

Name, zero length
none.

for

B Is Transport's block size for this line.
Represents the line cost.
Is the number of milliseconds before a
reply
should be received from the remote station.

LINE CONTROLLER (1): B

LINE DUPLEX (1)

Represents the line controller mode, with the
following values:
Value

Keyword

0
1

NORMAL
LOOPBACK

Represents the
line
following values:

Represents the line type, with the
values:
Value

following

Keyword
POINT
CONTROLLER
TRIBUTARY

0
1
2
LINE SERVICE TIMER (2)

B
Is the line service timer value.

LINE TRIBUTARY (1)

Is the line multipoint tributary address.

: B

the

FULL
HALF

0
1
B

with

Keyword

Value

LINE TYPE (1)

duplex,

Table 6 summarizes the line parameter data blocks.
Table 6
Line Parameters
Paramo
Type
Number

NICE
Data
Type

0
1
100
110
400
800

C-l
C-l
C-l
DU-2
AI-6
CM-l/2
DU-2
AI-6
DU-2
DU-l
C-l
C-l
C-l
DU-2
DU-2
DU-l

810
900
1110
1111
1112
1120
1121
1140

Inf.
Type
S*
S*
C
C
S*
S*
S
C
C
C
C
C
C
C

Set.
Rest.

NCP
Keywords
STATE
substate (not a keyword)
SERVICE
COUNTER TIMER
LOOPBACK NAME
ADJACENT NODE
node address
node name (optional if none)
BLOCK SIZE
COST
CONTROLLER
DUPLEX
TYPE
SERVICE TIMER
NORMAL TIMER
TRIBUTARY

RO
RO
RO
RO

A.l.2 Line Counters - The line entity counters are listed in Table 7,
following.
The definition of each counter and the way that it is
incremented can be found
in the functional specification for
the

appropriate
layer
(NSP
functional specification, version 3.2;
Transport functional specification, version 1.3; and DDCMP functional
specification, Version 4.1).
Due to hardware characteristics, some
devices cannot support all counters. In general, those counters that
make sense are supported for all devices. Specific exceptions related
to the DMC are noted in Appendix H.
Line counters are specified for the following layers only:
Layer

Type Number
Range

Network Management

Transport

800's

Data Link

1000's
Table 7
Line Counters
NOTE

When a line is point-to-point, both groups (ST and T) of the
counters are returned.

Appl.

Type
Number

Bit
width

Standard Text

line

Bit Number
Standard Text

Seconds Since Last Zeroed

T
T
T
T
T
T
T
T

800
801
802
810
811
812
820
821

32
32
16
32
32
16
8
8

Arriving Packets Received
Departing Packets Sent
Arriving Congestion Loss
Transit Packets Received
Transit Packets Sent
Transit Congestion Loss
Line Down
Initialization Failure

T
T
T
T
T

1000
1001
1010
1011
1020

32
32
32
32
8

Bytes Received
Bytes Sent
Data Blocks Received
Data Blocks Sent
Data Errors Inbound

1021

Data Errors Outbound

0 NAKs Sent
Header Block
Check error
1 NAKs Sent Data
Field Block
Check error
2 NAKs Sent REP
Response
0 NAKs Received
Header Block
Check error
1 NAKs Received
Data Field
Block Check
error
2 NAKs Received
REP Response
(continued on next page)

Table 7 (Cont.)
Line Counters

Appl.

Type
Number

Bit
Width

T
T
T

1030
1031
1040

8
8
8

Standard Text
Remote Reply Timeouts
Local Reply Timeouts
Remote Buffer Errors

1041

Local Buffer Errors

1050

1051

Selection Intervals
Elapsed
Selection Timeouts

Bit Number
Standard Text

0 NAKs Received

Buffer
Unavailable
1 NAKs Received
Buffer Too
Small
0 NAKs Sent
Buffer
Unavailable
1 NAKs Sent
Buffer Too
Small
0 No Reply to

Select
1 Incomplete

1100

Remote Process Errors

1101

Local Process Errors

Reply to
Select
0 NAKs Received
Receive
Overrun
1 NAKs Sent
Header Format
Error
2 Selection
Address Errors
3 Streaming
Tributaries
0 NAKs Sent
Receive
Overrun
1 Receive
Overruns, NAK
not Sent
2 Transmit
Underruns
3 NAKs Received
Header Format
Error

A.2

LOGGING Entity

The logging entity identification is the sink type.
Logging may be
referred to by individual sink types or by the sink types as a group.
The formats for specifying logging entities symbolically are as
follows:
Format

Meaning

LOGGING sink-type

A particular logging sink type

KNOWN LOGGING

All logging sink types known to the
node

executor

ACTIVE LOGGING

All known sink types that are in ON
state

HOLD

A sink type is one of the following:
CONSOLE
FILE
MONITOR
When represented in binary, sink type is:
SINK TYPE (1)

: B

Represents the logging sink type as follows:
Value

Meaning

-2
-1
1
2

Active sink types
Known sink types
CONSOLE
FILE
MONITOR

Appendix F defines all the event classes and their associated events
and parameters (not to be confused with the logging parameters).
Line and node counters provide information for event logging.
There
are
no
logging
entity
counters
specified,
just
status,
characteristics, and events.
The logging sink types have the following parameters:
STATE (1)

: B

Represents the
values:
Value
0

2
NAME (1-255)

sink

type

state

wi th

the

following

Keyword
ON
OFF
HOLD

A
Is the name of the logging sink.
If not set, the
logging sink name defaults to a system-specific value.

SINK NODE

Is the sink node identification that applies to all
following event parameters until another sink node id
is encountered.
If not present,
it defaults
to
executor node.
The format for setting this parameter
is described in Section A.3.
Plural options are not
allowed.
When reading parameter, sink node consists
of:
NODE
ADDRESS

NODE
NAME

where:
NODE ADDRESS (2)
NODE NAME (1-6)
EVENTS

: B

Node address

Node name, 0 length for none

Are the sink type events, consisting of:
ENTITY
TYPE

ENTITY
ID

EVENT
CLASS

EVENT
MASK

where:
ENTITY TYPE (1)

Represents
follows:

the

Value

Meaning

-1
0
1

ENTITY ID

entity

type

No entity
NODE
LINE

Is the entity id according to
ENTITY TYPE, present only for
NODE or LINE.
If ENTITY TYPE is NODE, format is
as described for sink node.
If entity type
is:
LINE ID (1-16)

EVENT CLASS (2)

is
:

LINE,

format

A = Line ide

Entity class specification:
Bits

Meaning

14-15

0 = Single class
2

= All events for

= KNOWN EVENTS

class

0-8

Event class if bits
14-15 equal 0 or 2.

EVENT MASK (1-8)

Event
mask,
bits
set
to
correspond to event types (Table
12, Section F.2).
Low
order
bytes first.
High order bytes
not present
imply
0
value.
Format for NCP input or output is
a list of numbers corresponding
to
the
bi ts
set
(Section
3.3.1.4). Only present if EVENT
CLASS is for a single class (bits
14-15 = 0).

NOTE
The
wild
card
and
KNOWN
EVENTS
specifications are for changing events
only. Return read events as a class and
mask.
Table 8 summarizes the logging parameters.
Table 8
Logging Parameters
NOTE
Symbols are explained at the beginning of this appendix.
NICE
Data Type

Info
Type

C-l

ESTATE

100

AI-255

NAME

200

CM-l/2
DU-2
AI-6

EV*

SINK NODE
Node address
Node name (optional if none)

201

CM-2/3/4/5
C-l
DU-2

EV*

EVENTS
Entity type
Node address (if entity type
is node)
Node name (if entity type is
node)
Line id (if entity type is
line)
Event class
Event mask (if single event
class indicated)

Param.

Appl.
Restr.

AI-6
AI-16

C-2
HI-8

A.3

NCP
Keywords

NODE Entity

The node entity is referred to by its keyword, NODE, followed by the
node identification.
The node identification is either the node
address or node name except where limited in the command descriptions

(Section 3.3).
Nodes,
as a group, can be referred to as KNOWN or
ACTIVE (see the glossary for definitions).
The possible node entities
are as follows:
NODE
node-id
EXECUTOR
ACTIVE NODES
KNOWN NODES
LOOP NODES
When the executor or loop nodes are mixed in a multiple return with
remote nodes, return the executor first, and the loop nodes last.
A node address is a unique decimal in the range 1 to MAXIMUM ADDRESS.
Node address is the primary identification of a node, due to its use
in the DIGITAL Network Architecture.
Transport routes messages to
node addresses only.
Node names are optionally added in the Session
Control layer as a convenience for users. A node address can have
only one node name associated with it.
However, implementations can
use system-specific methods to provide users with "alias" node names
(Transport Functional Specification).
A node name consists of one to six upper case alphanumeric characters
with at least one alpha character. A node name must be unique within
a node and should be unique within the network.
The format for displaying node identification is:
NODE

= node-address [(node-name)]

For example:
NODE

= 19 (ELROND)

The parentheses are only used if the node has a name.
When
represented in binary, node identification is one of four choices
(limited by applicability to a particular function).
All choices
begin with a format type. The input format is as follows:
NODE FORMAT (1)

: B

Represents the node format type, as follows:
Number
-3
-2
-1
0
>0

Type
Loop nodes, no further data
Active nodes, no further data
Known nodes, no further data
Node address
Length of node name, followed by the
of
ASCII
number
indicated
characters.

In the ENTITY ID field of a response message bit
7 set indicates the node identification is the
executor node.
NODE ADDRESS (2)

NODE NAME

B Is the node address if NODE FORMAT
0.
When
used as input, a node address of zero impiies the
executor node.
Is the node name if NODE FORMAT >0.

The usual binary output format is as follows:
NODE
ADDRESS

NODE
NAME

where:
NODE ADDRESS (2)

B Is the node address.
When supplied as output
node address of 0 indicates a loop node.

NODE NAME ( I-6}

A.3.l

Is the node name, 0 length implies none.

Node Parameters - The node entity has the following parameters:

NODE STATE (l)

Represents the executor or destination
node state with the following values:

: B

Value
0
1
2
3
4
5

Keyword

Node

ON
OFF
SHUT
RESTRICTED
REACHABLE
UNREACHABLE

Executor
Executor
Executor
Executor
Destination
Destination

Except for the executor
node
this is a read only parameter.
NODE IDENTIFICATION (I-32)

NODE MANAGEMENT VERSION

Is the node identification string (for
example, operating system and version
number) .
Is
the
node
Network
Management
version, consisting of the following:
VERSION (l)
ECO (1)

NODE SERVICE LINE (1-16)

NODE SERVICE PASSWORD (1-8)

: B

Version number
Engineering Change
Order (ECO) number

: B

USER ECO (1)

NODE SERVICE DEVICE (1)

state,

: B

User ECO number

Is the line used to perform down-line
load and up-line dump functions.
B Is the node service password
for
down-line loading and up-line dumping
the node.
The length in binary form
corresponds to the length of the text
form.
Is the device type over which the node
handles
service functions when in
service slave mode.
Code as defined
in the MOP Functional Specification
and correspond to the standard Network
Management device mnemonics.

NODE CPU (1)

Is the CPU type
down-line loading
values:

Value
0
1
2
3
NODE LOAD FILE (1-255)

: A

of the node for
with the following

Type
PDP 8
PDP 11
DEC SYSTEM 10 20
VAX

Is the node load file.

NODE SECONDA'RY LOADER (1-255)

A
Is the node secondary loader file.

NODE TERTIARY LOADER (1-255)

A
Is the node tertiary loader file.

NODE SOFTWARE TYPE (1)

Is the target node software program
type for down-line loads with the
following values:

Value
0
1

Program Type
SECONDARY LOADER
TERTIARY LOADER
SYSTEM

NODE SOFTWARE IDENTIFICATION (1-16) : A
Is the load software identification.
NODE DUMP FILE (1-255)

: A

Is the node dump file.

NODE SECONDARY DUMPER (1-255)

A
Is the node secondary dumper file.

NODE DUMP ADDRESS (4)

Is the actdress to begin
of the node.

NODE DUMP COUNT (4)

B
B

NODE HOST

up-line

Is the number of memory
up-line dump from the node.

dump

units

Is the host identification for reading
(SHOW or LIST) only. Consists of:

NODE HOST

NODE ADDRESS (2)

: B

Host node
address.

NODE NAME (1-6)

: A

Host node
name, zero
length if
none.

Is the identification of the node that
node being down-line loaded may use
for
suppor t
functions.
(Used
for
changing the parameter.) Format is as
described for the node entity.
Plural
options not allowed.

NODE LOOP COUNT (2)

: B

Is the default count for loop test.

NODE LOOP LENGTH (2)

: B

Is the default length for loop test.

NODE LOOP WITH {l}

Is the default block type for
test with the following values:

Type
0

1
2

NODE COUNTER TIMER (2)

Contents
ZEROES
ONES
MIXED

Is the number of seconds between
counter log events.

NODE NAME (I-6)

: A

Is the node name.

NODE LINE (I-16)

: A

Is the line used
executor node and
loopback node-name.

NODE ADDRESS {2}

: B

Is the executor node address.
B

Is the node incoming timer.

NODE OUTGOING TIMER (2)

Is the node outgoing timer.

NODE DELAY {2}

Is the number of logical links from
the executor to the destination node.
Is the average round trip delay in
seconds to the destination node~
Kept
on a remote node basis.

NODE NSP VERSION

Format same
Is the node NSP version.
as for Network Management version.

NODE MAXIMUM LINKS { 2}

: B

Is the node maximum links.

NODE DELAY FACTOR (l)

Is the node delay factor.

NODE DELAY WEIGHT (l)

Is the node delay weight.

NODE INACTIVITY TIMER ( 2)

: B

Is the node inactivity timer.

NODE RETRANSMIT FACTOR ( 2)

: B

Is the node retransmit factor.

NODE TYPE ( 1)

node

to get to
the
associated with a

NODE INCOMING TIMER {2}

NODE ACTIVE LINKS {2}

loop

Represents the executor node type with
the following values:

Value
0

1
2

Keyword
ROUTING
NONROUTING
PHASE II

NODE COST (2)

Is the total cost over the
path to the destination node.
a remote node basis.

NODE HOPS (l)

Is the total number of hops over the
current path to a destination node.
Kept on a remote node basis.

NODE LINE (I-16)

Is the line used to get
other than the executor.

100

current
Kept on

node

NODE ROUTING VERSION

Is the node routing version.
Format
same
as
for
Network
Management
version.

NODE TYPE (1)

Represents the adjacent node
with the following values:

Value

NODE MAXIMUM ADDRESS ( 2)

Keyword
ROUTING
NONROUTING
PHASE II

0
1
2
NODE ROUTING TIMER ( 2) : B

Is the node routing timer value.
Is the node maximum address.

NODE MAXIMUM LINES ( 2) : B

Is the node maximum lines value.

NODE MAXIMUM COST ( 2)

Is the node maximum cost value.

NODE MAXIMUM HOPS (1)

Is the node maximum hops value.

NODE MAXIMUM VISITS (1)

type,

Is the node maximum visits value.

NODE MAXIMUM BUFFERS ( 2) : B

Is the node maximum buffers value.

NODE BUFFER SIZE ( 2)

Is the node buffer size value.

Table 9 summarizes the node parameter data blocks.
Table 9
Node Parameters
NOTE
Symbols are explained at the beginning of this appendix.
Par am.
Type
Number

NICE
Data
Type

Inf.
Type

Appl.
Rest.

0
100
101

C-l
AI-32
CM-3
DU-l
DU-1
DU-l
AI-16
H-8
C-l
C-l
AI-255
AI-255
AI-255
C-l
AI-16

S*
C*
C

E
E

C
C
C
C
C
C
C
C
C

A
A
A
A
A
A
A
A
A

110
III

112
113
120
121
122
125
126

Set.
Rest.

NCP
Keywords

E,R

STATE
IDENTIFICATION
MANAGEMENT VERSION
version number
ECO number
User ECO number
SERVICE LINE
SERVICE PASSWORD
SERVICE DEVICE
CPU
LOAD FILE
SECONDARY LOADER
TERTIARY LOADER
SOFTWARE TYPE
SOFTWARE
IDENTIFICATION

(continued on next page)

101

Table 9
(Cont.)
Node Parameters
Paramo
Type
Number

NICE
Data
Type

Inf.
Type

App1.
Rest.

130
131
135
136
140

AI-255
AI-255
DU-4.
DU-4
CM-1/2
DU-2
AI-6

C
C
C
C
C

A
A
A
A
A,E

141
150
151
152
160
500
501
502
510
511
600
601
700

n/a
DU-2
DU-2
C-1
DU-2
n/a
AI-16
n/a
DU-2
DU-2
DU-2
DU-2
CM-3
DU-1
DU-l
DU-l
DU-2
DU-1
DU-1
DU-2
DU-2
C-1
DU-2
DU-1
AI-16
CM-3
DU-1
DU-1
DU-1
C-1
DU-2
DU-2
DU-2
DU-2
DU-1
DU-1
DU-2
DU-2

C
C
C
C
n/a
C*
n/a
C
C
S*
S*
C

A,E
E
E
E
E,R
E,R
L,N
E
E
E
E,R
R
E

C
C
C
C
C
S
S
S
S*
C

E
E
E
E
E
A
R
R
R
E

C
C
C
C
C
C
C
C
C

E
E
E
E
E
E
E
E
E

710
720
721
722
723
810
820
821
822
900

901
910
920
921
922
923
924
930
931

Set.
Rest.

WO
RO
RO
RO
WO
WO
RO
RO
RO

RO
RO
RO
HO
HO

102

NCP
Keywords
DUMP FILE
SECONDARY DUMPER
DUMP ADDRESS
DUMP COUNT
HOST
Node address
Node name (optional
if none)
H'OST
LOOP COUNT
LOOP LENGTH
LOOP WITH
COUNTER TIMER
NAME
LINE
ADDRESS
INCOMING TIMER
OUTGOING TIMER
ACTIVE LINKS
DELAY
NSP VERSION
Version number
ECO number
User ECO number
MAXIMUM LINKS
DELAY FACTOR
DELAY WEIGHT
INACTIVITY TIMER
RETRANSMIT FACTOR
TYPE
COST
HOPS
LINE
ROUTING VERSION
Version number
ECO number
User ECO number
TYPE
ROUTING TIMER
MAXIMUM ADDRESS
MAXIMUM LINES
MAXIMUM COST
MAXIMUM HOPS
MAXIMUM VISITS
MAXIMUM BUFFERS
BUFFER SIZE

A.3.2 Node Counters - Table 10, below, lists the node counters.
The
definition of each counter and the way it is to be incremented is
given in the functional specifications for the layer containing the
counter.
Node counters are specified for the following layers only:
Layer

Type Number
Range

Network Management

Network Services

600's, 700

Transport

900's
Table 10
Node Counters

Appl.

Type Number Bit width

Standard Text

Seconds Since Last Zeroed

DN
DN
DN
DN
DN
DN
DN
DN
E

600
601
610
611
620
621
630
640
700

32
32
32
32
16
16
16
16
16

Bytes Received
Bytes Sent
Messages Received
Messages Sent
Connects Received
Connects Sent
Response Timeouts
Received Connect Resource Errors
Maximum Logical Links Active

E
E
E
E
E
E
E

900
901
902
903
910
920
930

Aged Packet Loss
Node Unreachable Packet Loss
Node Out-of-Range Packet Loss
Oversized Packet Loss
Packet Format Erro~
Partial Routing Update Loss
Verification Reject

16
8
8
8
8
8

103

APPENDIX B
MEMORY IMAGE FORMATS

Since the PDP-8, PDP-II, VAX-II, and DECsystem-10, or DECSYSTEM-20
memory addressing requirements differ, different formats are required
for memory image data. In each case, it is essential to know the
number of bytes that represent the smallest individually addressable
memory location. A format summary is provided below.
PDP-8

Each three bytes represents two l2-bit words.
that is, the memory address is incremented by two
for each three bytes. Byte 1 is the low 8-bits of
memory word 1. Byte 2 is the low 8-bits of memory
word 2, and byte 3 is the high 4-bits of memory
words 1 and 2.

PDP-II
VAX-II

Each byte represents one memory byte.
That is,
the memory address is incremented with each byte.

DECsystem-I0
DECSYSTEM-20

Each five bytes represents one 36-bit word.
That
is, the memory address is incremented by one for
each five bytes. Byte 1 is the highest 8-bits of
the word. Bytes 2 through 4 follow.
The high
4-bits of byte 5 are the low 4-bits of the word.
The low 4-bits of byte 5 are discarded.

104

APPENDIX C
MEMORY IMAGE FILE CONTENTS

The files containing memory images for a down-line load or an up-line
dump have the same contents. The format may vary from one operating
system to another, but the contents are functionally the same in all
cases. The minimum control information required is as follows:
•

The type of the target system (PDP-S, PDP-II,
VAX-II,
DECsystem-10, or DECSYSTEM-20). This is necessary to know how
to interpret and update memory address information.

•

Transfer
program.

address.
This is the startup address for the
This field is generally meaningless for a dump file.

The image information required is as follows:
•

Memory address. This is the address where image
load or comes from a dump.

goes

for

•

Block length.

•

Memory image.
This is the contiguous block of
memory
associated with the above address. The format requirements
are as specified in Appendix B. The memory image can be of
any length.

Number of memory units in image block.

105

APPENDIX D
NICE RETURN CODES WITH EXPLANATIONS

This appendix specifies the NICE return codes.
In all cases, the number specified is for the first byte of the return
code.
The error detail that sometimes follows the return codes is two bytes
long.
Since some systems may have trouble implementing the error
details, a value of 65,535 (all 16 bits set) in the error detail field
means no error detail. In other words, in this case, no error detail
will be printed.
If a response message is short terminated after any field, the
existing fields may still be interpreted according to the standard
format.
A printed error message consists of the standard text for the first
byte.
If the second and third bytes have a defined value, this is
followed b¥ a comma, a blank, and the keyword(s) for the values.
Number

Standard test

Meaning

(none)

Success.

(none)

The request has been accepted,
and more responses are coming.

(none)

Success, partial reply.
More
parameters for entity in next
message. Can only be embedded
in a more/done sequence. Each
message still contains fields up
through ENTITY ID.

-1

Unrecognized function or
option

Either
the function code or
option
field
requested
a
capability not recognized by the
Local
Network
Management
Function.
Also, the error code
for function codes 2-14 (Phase
II) ,
and for system-specific
commands when the system type
matches the receiving system.

-2

Invalid message format

Message too long or too short
(i.e., extra data or not enough
data), or a field improperly
formatted for data expected.
(continued on next page)

106

Number

Standard test

Meaning

-3

Privilege violation

The requestor does not have the
privilege required to perform
the requested function.

-4

Oversized Management
command message

A message size was too long.
The NICE message for the command
was too long for the Network
Management Listener to receive.

-5

Management program error

A software error occurred in the
Network
Management
software.
For example, a function that
could
not
fail
did
fail.
Generally indicates a Network
Management software bug.

-6

unrecognized parameter type

A parameter type included in,
for example, a change parameter
message not recognized by the
Network Management Function.
The error detail is the low and
high bytes of the parameter type
number, interpreted according to
the entity involved.

-7

Incompatible Management
version

The function requested cannot be
performed because the Network
Management version skew between
the command source
and
the
command
destination
is
too
great.

-8

Unrecognized component

An entity (component) was not
known to the node. The error
detail contains the entity type
number.*

-9

Invalid identification

The
format
of
an
entity
identification was invalid. For
example, a node name with no
alpha character, or KNOWN used
where not allowed.
The error
detail contains the entity type
number.*

-10

Line communication error

Error in transmit or receive on
a line.
Can only occur during
direct use of the Data Link user
interface.

-11

Component in
wrong state

An entity (component) was in an
unacceptable
state.
For
example,
a
down
line load
attempted over a line that is
OFF, or a node name to be used
for a loop node already assigned
to a node address. The error
detail contains the entity type
number.*
(continued on next page)

107

Number
-13

Standard test

Meaning

File open error

A file could not be opened.
The error detail is
follows:
Value

o
1
2
3

4
5

defined

Keywords
PERMANENT DATABASE
LOAD FILE
DUMP FILE
SECONDARY LOADER
TERTIARY LOADER
SECONDARY DUMPER

-14

Invalid file contents

The data in a file was invalid.
The error detail is defined as
for error #-13.

-15

Resource error

Some resource was not available.
For example, an operating system
resource not available.

-16

Invalid parameter value

Improper
line-identification
type,
load
address,
memory
length, etc. The error detail
is the low and high bytes of the
parameter
type
number,
interpreted
according to the
entity involved.

-17

Line protocol error

Invalid line protocol message or
operation.
Can
only
occui
during direct line access.
In
the case of a line loop test, it
indicates that an error
was
detected
during
message
comparison that should have been
caught by the line protocol.

-18

File I/O error

I/O error in a file, such as
read error in system image or
loader during down-line load.
The error detail is
for error #-13.

defined

(continued on next page)

108

Number
-19

Standard test

Meaning

Mirror link disconnected

A successful connect was made to
the Loopback Mirror,
but the
logical link then failed.
The error detail is:
Value

o
1

2
3
4

5
6
7
8
9
10

12
13

14
15
16

Standard text
No node name set
Invalid node name
format
Unrecognized node
name
Node unreachable
Network resources
Rejected by object
Invalid object name
format
Unrecognized object
Access control
rejected
Object too busy
No response from
object
Remote node shut
down
Node or object
failed
Disconnect by object
Abort by object
Abort by Management
Local node shut down

-20

No room for new entry

Insufficient table space for new
entry.

-21

Mirror connect failed

A
connect
to
the
Network
Management Loopback Mirror could
not be completed.
The error
detail
is the same as for error
#-19.

-22

Parameter not applicable

Parameter not
applicable
to
entity.
For example, setting a
tributary
address
for
a
point-to-point
line
or
an
attempt to set a controller
to
loopback
mode
when
the
controller does not support that
function.
The
error detail
contains the parameter type of
the
parameter
that
is not
applicable.
(continued on next page)

109

Number

Standard test

Meaning

~----+-------------------------------4-------------------------------------~

-23

Parameter value too long

A parameter value was too long
for
the
implementation
to
handle. The error detail is the
low
and
high bytes of the
parameter
type
number,
interpreted
according to the
entity involved.

-24

Hardware failure

The hardware associated with the
request could not perform the
function requested.

-25

Operation failure

A requested operation failed,
and there is no more specific
error code.

-26

System-specific Management
function not supported

Error return for system-specific
functions unless the system type
is for the system receiving the
command.
May
be
further
explained by a system-specific
error message.

-27

Invalid parameter grouping

The
request
for
changing
multiple
parameters contained
some that cannot be changed with
others.

-28

Bad loopback response

A loopback message did not match
what
was
expected,
either
content or length.

-29

Parameter missing

A required parameter was not
included.
The error detail is
the low and high bytes of the
parameter
type
number,
interpreted according to
the
entity involved.

-128

(none)

No message printed.
Done with
multiple
response
commands
(e.g., read
information
for
known lines).
*NOTE
Error codes -8, -9, and -11 indicate
problems with the primary entity to
which a command applies. They may also
apply to a secondary entity, such as the
line in a LOAD NODE command.

110

APPENDIX E
NCP COMMAND STATUS AND ERROR MESSAGES

NCP has the following standard status and error messages.
Meaning

Standard Text
Status Messages
COMPLETE

The command was processed successfully.

FAILED

The
command
successfully.

NOT ACCEPTED

The command did not get past syntax and
semantic checking.
No attempt was made
to execute it. The text of the error
message may vary as long as the meaning
is clearly the same.

did

execute

not

Error Messages
Unrecognized command

The command typed by the
recognized.

user

unrecognized keyword

Something in the command keyword was not
recognized.

Value out of range

A parameter value was out of range.
This message may be followed by a comma,
a blank and the parameter keyword(s).

Unrecognized value

A parameter value was unrecognizable.
This message may be followed by a comma,
a blank and the parameter keyword(s).

Not remotely executable

NCP is functionally unable
command to a remote node.

Bad management response

~he

Listener link disconnected

A successful connect was made to the
Network Management Listener,
but the
logical link then failed.
Optional
error detail is as in NICE error message
-19 (Appendix D).

was

send

not

Network Management Access Routines
received unrecognizable information.

(continued on next page)

III

Standard Text

Meaning
Error Messages

Listener connect failed

A connect to the Network Management
Listener could not be completed. The
optional error detail is as in NICE
error message -21 (Appendix D).

Total parameter data
too long

NCP command overflows
maximum
message for this implementation.

Oversized Management
response

NCP could not receive a
because it was too long.

112

NICE

NICE
message

APPENDIX F
EVENTS

F.l

Event Class Definitions

Table 11, following, defines the event classes. The event class as
shown in Table 11 is a composite of the system type and the system
specific event class.
Table 11
Event Classes
Event
Class

7-31

Network Management Layer
Applications Layer
Session Control Layer
Network Services Layer
Transport Layer
Data Link Layer
Physical Link Layer
Reserved for other common classes

32-63

RSTS System specific

64-95

RSX System specific

96-127

TOPS-20 System specific

128-159

VMS System specific

160-479

Reserved for future use

480-511

Customer specific

1
2
3
4

5
6

F.2

Description

Event Definitions

In the following descriptions, an entity related to an event indicates
that the event can be filtered
specific to that entity.
Binary
logging data is formatted under the same rules as the data in NICE
data blocks
(see Appendix A).
Section F.3 describes the event
parameters associated with each event type.
Table 12 shows the events for each class.

113

Table 12
Events

Class Type

Event Parameters
and Counters *

Entity

Standard Text
Event records lost
Automatic node counters
Automatic line counters
Automatic line service

o
o
o
o

o
3

none
node
line
line

o
o
o

4
5
6
7

line
node
line
line

Line counters zeroed
Node counters zeroed
Passive loopback
Aborted service request

none

Local node state change

none

Access control reject

3
3

o
1

none
none

Invalid message
Invalid flow control

node

Data base reused

4
4
4

o
1

none
line
line
line
line
line

Aged packet loss
Node unreachable packet loss
Node out-of-range packet loss
Oversized packet loss
Packet format error
Partial routing update loss

line
line
line

Verification reject
Line down, line fault
Line down, software fault

line

Line down, operator fault

4
4

line
line

line

Line up
Initialization failure,
line fault
Initialization failure,
software fault
Initialization failure,
operator fault

node

Node reachability change

line

Locally initiated state change

4
4
4
4

4
4

2
3
4
5
6
7

none
Node counters
Line counters
Service
Status
Line counters
Node counters
Operation
Reason
Reason
Old state
New state
Source node
Source process
Destination process
User
Password
Account
Message
Message
Current flow control
NSP node counters
Packet header
Packet header
Packet header
Packet header
Packet beginning
Packet header
Highest address
Node
Reason
Reason
Packet header
Reason
Packet header
Expected node
Node
Reason
Reason
Packet header
Reason
Packet header
Received version
Status
Old state
New state
(continued on next page)

114

Table 12
(Cont.)
Events

Class Type

Standard Text

Remotely initiated state change Old state
New state
Protocol restart received in
none
maintenance mode
Send error threshold
Line counters,
including station
Receive error threshold
Line counters,
including station
Select error threshold
Line counters,
including station
Block header format error
Header (optional)
Selected tributary
Selection address error
Received tributary
Previous tributary
Tributary status
Streaming tributary
Received tributary
Local buffer too small
Block length
Buffer length

line

5
5

line
line

line

6
6
6

1
2
3
4
5

line
line
line
line
line
line

6
6

*
F.3

Event Parameters
and Counters *

Entity

Data set ready transition
Ring indicator transition
Unexpected carrier transition
Memory access error
Communications interface error
Performance error

New state
New state
New state
Device register
Device register
Device register

Counters are defined in Appendix A.

Event Parameter Definitions

The following parameter types are defined for the
layer (class 0):
Type

Network

Management

Data Type

Keywords

C-l

SERVICE

CM-l/2/3
C-l
C-2

STATUS
Return code
Error detail (optional if no error
message)
Error message (optional)
OPERATION
REASON

2
3

AI-72
C-l
C-l

115

where:
SERVICE (1): B

Represents the service type as follows:
Value

LOAD
DUMP

STATUS

Keyword

Is the operation status, consisting of:
RETURN
CODE

ERROR
DETAIL

ERROR
MESSAGE

where:
RETURN CODE (1)

Standard NICE return
code,
with
added
interpretation:

Value

0
>0
<0
ERROR DETAIL (2)

: B

ERROR MESSAGE(I-72)

Standard
detail.

Keyword
REQUESTED
SUCCESSFUL
FAILED
NICE

error

A
Standard NICE optional
error message.

OPERATION (1)

Represents the operation performed, as follows:
Value
0

REASON (1)

Keyword
INITIATED
TERMINATED

Represents the reason aborted, as follows:
Value
0
1

2
3
4

Reason
Receive timeout
Receive error
Line state change by higher level
Unrecognized request
Line open error

116

The following parameter types are
layer (class 2):
Type

defined

for

the

Session

Control

Data Type

Keywords

C-l

REASON

C-l

OLD STATE

C-l

NEW STATE

CM-l/2
DU-2
AI-6

SOURCE NODE
node address
node name (optional if none)

CM-l/2/3/4
DU-l
DU-l

SOURCE PROCESS
Object type
Group code, (if specified and process
name present)
User code, (if specified and group
code present)
Process name, if specified

DU-l
AI-16
5

CM-l/2/3/4

DESTINATION PROCESS
Same as for SOURCE PROCESS

AI-39

USER

C-l

PASSWORD

AI-39

ACCOUNT

where:
REASON (1)

Represents
follows:

Value
0
1

OLD STATE (1)

0
1
2
3
B

reason

for

state

change,

Meaning
Operator command
Normal operation

Represents the old node state, as follows:
Value

NEW STATE (1)

the

Meaning
ON
OFF
SHUT
RESTRICTED

Represents the new node state, coded same
STATE.

117

OLD

SOURCE NODE

Is the source node identification, consisting of:
NODE
ADDRESS

NODE
NAME

where:
NODE ADDRESS (2)

Node address

(see

Section

A. 3) •

NODE NAME (1-6)

Is the source process
of:

SOURCE PROCESS

Node name,
none.

length

identification,

consisting

PROCESS
NAME
where:
OBJECT TYPE (1): B

Object type number

GROUP CODE (1): B

Group code number

USER CODE (1): B

User code number

PROCESS NAME(I-16):A

Process name

DESTINATION PROCESS Is the destination process identification, defined
as for SOURCE PROCESS.
USER (1-39)

: A

Is the user identification

PASSWORD (1)

: B

Is the password indicator.
A value of zero
indicates a password was set.
Absence of the
parameter indicates no password was set.

ACCOUNT (1-39)

: A

Is the account information

The following parameter types are defined
layer (class 3):
Type

for

the

Network

Data Type

Keywords

CM-4
H-l
DU-2
DU-2
HI-6

MESSAGE
Message flags
Destination node address
Source node address
Message type dependent data

DU-l

CURRENT FLOW CONTROL

118

Services

where:
MESSAGE (1-12)

Is the
only).

message received
Consists of:

MESSAGE
FLAGS

DESTINATION
NODE

(NSP

SOURCE
NODE

information

DATA

where:

CURRENT FLOW CONTROL (1)

MESSAGE FLAGS(l):B

Message flags

DESTINATION NODE(2):B

Destination
address

SOURCE NODE(2):B

Source node address

DATA(I-6) :B

Message
dependent data

type

: B Is the current flow control value

The following parameter types are
(class 4):

defined

for

the

Transport

Data Type

Keywords

CM-4
H-l
DU-2
DU-2
H-l

PACKET HEADER
Message flags
Destination node address
Source node address
Forwarding data

HI-6

PACKET BEGINNING

DU-2

HIGHEST ADDRESS

CM-l/2
DU-2
AI-6

NODE
node address
node name (optional if none)

CM-l/2
DU-2
AI-6

EXPECTED NODE
node address
node name (optional if none)

C-l

REASON

CM-3
DU-l
DU-l
DU-l

RECEIVED VERSION
Version number
ECO number
User ECO number

C-l

STATUS

Type

node

119

layer

where:
PACKET HEADER

Is the packet header consisting of:
MESSAGE DESTINATION
FLAGS
NODE
ADDRESS

SOURCE FORWARDING
NODE
DATA
ADDRESS

where:
MESSAGE FLAGS (l):B

Message
definition
flags

DESTINATI0N NODE ADDRESS(2):B

Address of
destination
node

SOURCE NODE ADDRESS (2): B

Address of
source node

FORWARDING DATA (l):B

Message
forwarding
data

PACKET BEGINNING (6)

: B

Is the beginning of packet.

HIGHEST ADDRESS (2)

: B

Is the highest unreachable node address.

NODE

Is the node identification in the same
format as SOURCE NODE in Session Control
events.

EXPECTED NODE

Is the expected node identification
same
format as SOURCE NODE in
Control events.

REASON (1)

in the
Session

Is the failure reason:
Value

o
1
2
3

4
5
6
7

8
9

10
11

Meaning
Line synchronization lost
Data errors
Unexpected packet type
Routing update checksum error
Adjacent node address change
Verification receive timeout
version skew
Adjacent node address out of
range
Adjacent node block size too
small
Invalid verification seed value
'Adjacent node listener receive
timeout
Adjacent node listener received
invalid data

120

RECEIVED VERSION

Is the received version
of:

ECO

VERSION

number,

consisting

USER
ECO

where:

STATUS (1)

VERSION (1): B

Version number.

ECO (1): B

ECO number.

USER ECO (1): B

User ECO number.

Represents the node status, as follows:

Meaning

Value

REACHABLE
UNREACHABLE

The following parameter types are defined
(class 5):
Type

for

Data Type

Keywords

C-l

OLD STATE

C-l

NEW STATE

HI-6

HEADER

DU-l

SELECTED TRIBUTARY

DU-l

PREVIOUS TRIBUTARY

C-l

TRIBUTARY STATUS

DU-l

RECEIVED TRIBUTARY

DU-2

BLOCK LENGTH

DU-2

BUFFER LENGTH

the

Data

Link

layer

where:
OLD STATE (1): B

Represents the old DDCMP state, as follows:
Value
0
1

2
3
4

Meaning
HALTED
ISTRT
ASTRT
RUNNING
MAINTENANCE

NEW STATE ( 1) : B

Represents the new DDCMP state,
for OLD STATE.

HEADER (1-6) : B

Is the block header

SELECTED TRIBUTARY(l) : B

Is the selected tributary address

RECEIVED TRIBUTARY (1) : B

Is the received tributary address

121

defined

PREVIOUS TRIBUTARY (1) : B

Is the previously selected tributary address

TRIBUTARY STATUS (I): B

Is the tributary status, as follows:
Meaning

value

Streaming
Continued send after timeout
Continued send after deselect
Ended streaming

0
1

2
3

BLOCK LENGTH (2): B

Is the received block length from header, in
bytes

BUFFER LENGTH (2): B

Is the buffer length, in bytes

The following
(class 6):

pa~ameter

Type

Data Type

Keywords

H-2

DEVICE REGISTER

C-l

NEW STATE

types are defined for the Physical Link

layer

where:
DEVICE REGISTER(2}: B

Represents a single device register.
When
more than one,
they should be output in
standard order.

NEW STATE (I): B

Represents the new modem control
follows:
Meaning

Value

OFF
ON

0
1

122

state,

APPENDIX G
JULIAN HALF-DAY ALGORITHMS

The following algorithms will convert to and from a Julian half-day in
the range 1 January 1977 through 9 November 2021 as used in the binary
format of event logging records.
The algorithms will operate correctly with 16 bit arithmetic.
The
arithmetic expressions are to be evaluated using FORTRAN operator
precedence and integer arithmetic.
In all cases, the input is assumed to be correct, i.e., the day is in
the range 1 to maximum for the month, the month is in the range 1-12,
the year is in the range 1977-2021 and the Julian half-day is in the
range 0-32767.
To convert to Julian half-day:

JULIAN = (3055*(MONTH+2)/100-(HONTH+10)/13*2-91
+(1-(YEAR-YEAR/4*4+3)/4)*(MONTH+10)/13+DAY-1
+(YEAR-1977)*365+(YEAR-1977)/4)*2
To convert from Julian half-day:

HALF = JULIAN/2
TEMPI = HALF/1461
TEHP2 = HALF-TEMP1
YEAR = TEMP2/365
IF TEMP2/1460*1460 = TEMP2 AND (HALF+1)/1460 > TEMP1
YEAR = YEAR-1
ENDIF
TEMP1 = TEMP2-(YEAR*365)+1
YEAR = YEAR+1977
IF YEAR/4*4 = YEAR
TEMP2 = 1
ELSE
TEMP2 = 0
ENDIF
IF TEMP1 > 59+TEHP2
DAY = DAY+2-TEHP2
ELSE
DAY = TEMP1
ENDIF
MONTH = (DAY+91)*100/3055
DAY = DAY+91-MONTH*3055/100
HONTH = MONTH-2
IF HALF*2 = JULIAN
HALF = 0
ELSE
HALF = 1
ENDIF

123

The algorithm was certified -to work using
program running in FORTRAN IV+ on RSX-llM:

the

following

FORTRAN

INTEGER*4 COUNT
INTEGER*2 JULTES,JULIAN,DAY,HONTH,YEAR,JULTEH,HALF

10
1099

DO 1099 COUNT=0,32767
JULTES=COUNT
CALL UNJUL(JULTES,HALF,DAY,HONTH,YEAR>
JULTEM=JULIAN(DAY,MONTH,YEAR>+HALF
IF (JULTEM.EQ.JULTES) GOTO 1099
TYPE 10,JULTES,JULTEH,HALF,DAY,MONTH.YEAR
FORMAT (X,'Error!',617)
CONTINUE
END

INTEGER FUNCTION TO CONVERT DAY, MONTH AND YEAR TO JULIAN HALF-DAY
INTEGER*2 FUNCTION JULIAN(DAY,MONTH,YEAR)
INTEGER*2 DAY,MONTH,YEAR
JULIAN = (3055*(MONTH+2)/100-(MONTH+10)/13*2-91
& +(1-(YEAR-YEAR/4*4+3)/4)*(MONTH+l0)/13+DAY-1
& +(YEAR-1977)*365+(YEAR-1977)/4)*2
RETURN
END
SUBROUTINE TO CONVERT JULIAN HALF-DAY TO DAY, MONTH AND

YEAR

SUBROUTINE UNJUL(JULIAN,HALF,DAY,MONTH,YEAR)
INTEGER*2 JULIAN,HALF,DAY,MONTH,YEAR,TEMP1,TEMP2
HALF = JULIAN/2
.TEMPI = HALF/1461
TEMP2 = HALF-TEMPI
YEAR = TEMP2/36S
IF (TEMP2/1460*1460.EQ.TEMP2.AND.(HALF+l)/1460.GT.TEMP1)
& YEAR = YEAR-1
TEMP1 III TEMP2-(YEAR*365)+1
YEARIIIYEAR+1977
TEMP2
0
IF (YEAR/4*4.EQ.YEAR) TEMP2 = 1
DAY • TEMP1
IF (TEMP1.GT.S9+TEMP2) DAY = DAY+2-TEMP2
MONTH III (DAY+91)*100/30S5
DAY III DAY+91-MONTH*30SS/100
MONTH
MONTH-2
TEMP1 III 0
IF (HALF*2.NE.JULIAN) TEMP1 = 1
HALF := TEMP1
RETURN
END
III

III

124

APPENDIX H
DMC DEVICE COUNTERS

The following counters are the only ones applicable to the DMC device.
Number

Standard Text

1000
100'1
1010
1011
1020

Bytes received
Bytes sent
Data blocks received
Data blocks sent
Data errors inbound
o
NAKs sent, header block check error
1
NAKs sent, data field block check error
Data errors outbound
Remote reply timeouts
Local reply timeouts
Local buffer errors
o
NAKs sent, buffer unavailable

1021
1030
1031
1041

None of the other standard counters can be kept due to the
nature of
the
DMC hardware.
The "Data errors outbound" counter is kept with no
bitmap.
It represents the sum of all NAKs received.
Since the counters kept by the DMC firmware cannot be
zeroed
in
the
way that driver-kept counters can,
the
recommended technique for
providing the zero capability is to copy the base table counters when
a zero 1S requested.
The numbers returned when counters are requested
are then the difference between the saved counters and
the current
base table.

125

APPENDIX I
NCP COMMANDS SUPPORTING EACH NETWORK MANAGEMENT INTERFACE

This appendix shows the NCP commands supporting the Network Management
interface to each of the lower DNA layers.

126

<
A.

{SET

This notation precedes keywords or text returned on SHOW or LIST commands

Network Management Layer Interface

DEFINE

}

EXECUTOR

NODE

destination-node

{LINE

line-id}

ALL
COUNTER TIMER
SERVICE
STATE

seconds
service-control
line-state

{LOGGING

Sink-type}

ALL
EVENT event-list
KNOWN EVENTS
NAME
STATE

source-qual
source-qual
sink-name
sink-state

node-id

ALL
COUNTER TIMER
CPU
DUMP ADDRESS
DUMP COUNT
DUMP FILE
HOST
IDENTIFICATION
LOAD FILE
SECONDARY DUMPER
SECONDARY LOADER
SERVICE DEVICE
SERVICE LINE
SERVICE PASSWORD
SOFTWARE
IDENTIFICATION
SOFTWARE TYPE
TERTIARY LOADER

KNOWN LINE

KNOWN LOGGING

NODE

seconds
cpu-type
number
number
file-id
node-id
string
file-id
file-id
file-id
device-type
line-id
password
file-id
program-type
file-id

sink-node
sink-node

Network Management Layer Interface (Cont.)

{NODE
KNOWN NODES

CLEAR
PURGE

Sink-type}
{LOGGING
KNOWN LOGGING

TRIGGER

{NODE
VIA
{NODE
VIA

LOAD

CLEAR
PURGE

node-id

ALL
COUNTER TIMER
CPU
DUMP ADDRESS
DUMP COUNT
DUMP FILE
HOST
IDENTIFICATION
LOAD FILE
PARAMETERS
SECONDARY DUMPER
SECONDARY LOADER
SERVICE DEVICE
SERVICE LINE
SERVICE PASSWORD
SOFTWARE
IDENTIFICATION
SOFTWARE TYPE
TERTIARY LOADER
EVENT event-list
KNOWN EVENTS
NAME

source-qual
source-qual

nOde-id}

SERVICE PASSWORD
*VIA

password
line-id

nOde-id}

ADDRESS
CPU
FROM
HOST
NAME
SECONDARY LOADER
SERVICE DEVICE
SERVICE PASSWORD
SOFTWARE
IDENTIFICATION
SOFTWARE TYPE
TERTIARY LOADER
*VIA

node-address
cpu-type
load-file
node-id
node-name
file-id
device-type
password

line-id
line-id

not allowed when first option is VIA

file-id
program-type
file-id
line-id

sink-node
sink-node

Network Management Layer Interface (Cont.)

DUMP

faDE

nOde-id}

VIA

LOOP

DUMP ADDRESS
DUMP COUNT
SECONDARY DUMPER
SERVICE DEVICE
SERVICE PASSWORD
TO dump-file
*VIA line-id

number
number
file-id
device-type
password

NODE

node-id

line-id}

COUNT
WITH
LENGTH

count
block-type
length

{LINE

line-id}

CHARACTERISTICS

(SERVICE

COUNTERS

(seconds since last.
zeroed

STATUS

(STATE-substate

fINE

{SHOW}
LIST

line-id

KNOWN LINES

.
~LOGGING

KNOWN LOGGING
ACTIVE LOGGING

Sink-type}

{SINK nOde-id}

STATUS

(STATE

KNOWN SINKS

CHARACTERISTICS

NAME

EVENTS

See
Section A.2

Network Management Layer Interface (Cont.)

{SHOW}
LIST

{ACTIVE
NODES
EXECUTOR
LOOP NODES
KNOWN NODES
NODE

CHARACTERISTICS

ADDRESS
COUNTER TIMER
CPU
DUMP ADDRESS
DUMP COUNT
DUMP FILE
HOST
IDENTIFICATION
LOAD FILE
MANAGEMENT VERSION
NAME
SECONDARY DUMPER
SECONDARY LOADER
SERVICE DEVICE
SERVICE LINE
SERVICE PASSWORD
SOFTWARE IDENTIFICATION
SOFTWARE TYPE
TERTIARY LOADER

COUNTERS

(secondS since last
zeroed

nOde-id}

I-'
W

SHOW
ZERO

QUEUE

{LINE
KNOWN LINES

line-id}

COUNTERS

{NODE
KNOWN NODES

nOde-id}

COUNTERS

Session Control Layer Interface

}

{NODE

nOde-id}

{CLEAR}

{NODE

nOde-id}

{SET

DEFINE

PURGE

KNOWN NODES

I-'

ALL
ADDRESS
INCOMING TIMER
LINE
NAME
OUTGOING TIMER
STATE
ALL
INCOMING TIMER
LINE
NAME
OUTGOING TIMER

node-address
seconds
line-id
node-name
seconds
node-state

line-id

I-'

{SHOW}

LIST

{EXECUTOR

KNOWN NODES
ACTIVE NODES
LOOP NODES
NODE

CHARACTERISTICS

NAME
OUTGOING-TIMER

nOde-id}

{ EXECUTOR

KNOWN NODES
ACTIVE NODES
LOOP NODES
NODE

nOde-id}

LINE

line-id

TIMER
~INCOMING
LINE

STATUS

<NAME

STATE

STATUS

<NODE-NAME

Network Services Layer Interface

{SET

DEFINE

}

EXECUTOR

ALL
DELAY FACTOR
DELAY WEIGHT
INACTIVITY TIMER
MAXIMUM LINKS
RETRANSMIT FACTOR

EXECUTOR

{SHOW}

LIST

CHARACTERISTICS

number
number
seconds
number
number
DELAY FACTOR
DELAY WEIGHT
INACTIVITY TIMER
MAXIMUM LINKS
NSP VERSION
RETRANSMIT FACTOR

COUNTERS

See Table 10

STATUS

<ACTIVE LINKS

DELAY
ZERO

{EXECUTOR

KNOWN NODES

{SET

COUNTERS

}

Transport Layer Interface

DEFINE

}

{ LINE

KNOWN LINES

{NODE

KNOWN NODES

line-id}
nOde-id}

ALL
COST

cost

ALL
BUFFER SIZE
MAXIMUM ADDRESS
MAXIMUM BUFFERS
MAXIMUM COST
MAXIMUM HOPS
MAXIMUM LINES
MAXIMUM VISITS
ROUTING TIMER
TYPE

memory-units
number
number
number
number
number
number
seconds
node-type

Transport Layer Interface (Cont.)

{SHOW}
LIST

{LINE
KNOWN LINES
ACTIVE LINES

{SHOW}
LIST

{LINE
KNOWN LINES
ACTIVE LINES

{LINE
KNOWN LINES

line-id}
line-id}
line-id}

CHARACTERISTICS

(COST

STATUS

<BLOCK SIZE

COUNTERS

See Table 7

ACTIVE LINES

{ EXECUTOR
KNOWN NODES
ACTIVE NODES
LOOP NODES
NODE
t-'

CHARACTERISTICS

nOde-id}

W
W

{EXECUTOR
KNOWN NODES
ACTIVE NODES
LOOP NODES
NODE

STATUS

nOde-id}

{EXECUTOR
KNOWN NODES
ACTIVE NODES
LOOP NODES
NODE
ZERO

{ LINE
KNOWN LINES

COUNTERS

nOde-id}
line-id}

COUNTERS

BUFFER SIZE
MAXIMUM ADDRESS
MAXIMUM BUFFERS
MAXIMUM COST
MAXIMUM HOPS
MAXIMUM LINES
MAXIMUM VISITS
ROUTING TIMER
ROUTING VERSION
COST
HOPS
LINE
STATE
TYPE
See Table 10

Data Link/Physical Link Layers Interface

{SET
DEFINE }

{LINE

line-id}

ALL
CONTROLLER
DUPLEX
NORMAL TIMER
SERVICE TIMER
TRIBUTARY
TYPE

{CLEAR}

LINE

line-id

ALL

KNOWN LINES

controller-mode
duplex-mode
milliseconds
milliseconds
tributary-address
line-type

PURGE

{SHOW}

LIST

{ACTIVE LINES

LINE
KNOWN LINES

line-id}
CHARACTERISTICS

{ACTIVE LINES

LINE
KNOWN LINES

line-id}

COUNTERS

DUPLEX
CONTROLLER
PROTOCOL
TRIBUTARY
TIMER
SERVICE
See Table 7

GLOSSARY

NOTE
Terms that derive from other related
specifications
(such as hops, cost,
delay, etc.) are defined
in
those
specifications.
active lines
Active lines are known lines in the ON or SERVICE state.
active logging
Active logging describes all known sink types that are in the
or HOLD state.

active nodes
All reachable nodes as
active nodes.

perceived

from

the

executor

node

are

adjacent node
A node removed from the executor node by a

singl~

physical line.

characteristics
Parameters that are generally static values in volatile memory or
permanent values in a permanent data base. A Network Management
information type. Characteristics can be set or defined.
cleared state
Applied to a line: a state where space is reserved for line data
bases, but none of them is present.
command node
The node where an NCP command originates.
controller
The part of a line identification that denotes the control
hardware for a line. For a multiline device that'controller is
responsible for one or more units.

135

counters
Error and performance
information type.

statistics.

Management

Network

data link
A physical connection between two nodes.
In the
multipoint line, there can be mUltiple data links.

case

entity
LINE, LOGGING, or NODE. These are the major Network Management
keywords.
Each one has several parameters with options. LINE
and NODE also have specified counters.
There are also plural
entities: KNOWN and ACTIVE LINES, LOGGING, and NODES.
executor node
The node in which the active Local Network Management Function is
running (that is, the node actually executing the command); the
active network node physically connected to one end of a line
being used for a load, dump, or line loop test.
filter
A set of flags for an event class that indicates whether
each event type in that class is to be recorded.

not

global filter
A filter that applies to all entities within an event class.
hold state
Applied to logging.
A state where the sink
unavailable and events for it should be queued.

temporarily

host node
The node that provides services for another
during a down-line task load).

node

(for

example,

information type
One of CHARACTERISTICS, COUNTERS, EVENTS or SUMMARY. Used in the
SHOW command to control the type of information returned. Each
entity parameter and counter is associated with one or more
information types.
known lines
All lines addressable by Network Management in the appropriate
data base (volatile or permanent) on the executor node. They may
not all be in a usable state.
known logging
All logging sink-types addressable by ~etwork Management
appropriate data base.

136

the

known nodes
All nodes with address I to maximum address that are either
reachable or have a node name plus all names that map to a line.
line
A physical path.
In
tributary is treated
Management entity.

the case of a multipoint line, each
as a separate line. Line is p Network

line identification
The device, controller, unit and/or tributary assigned to a line.
line level loopback
Testing a specific data link by sending a repeated message
directly to the data link layer and over a wire to a device that
returns the message to the source.
logging
Recording information from an occurrence that has potential
significance in the operation and/or maintenance of the network
in a potentially permanent form where it can be accessed by
persons and/or programs to aid them in making real-time or
long-term decisions.
logging,console
A logging sink that is to receive a human-readable
events, for example, a terminal or printer.

record

line

record

logging event type
The identification of a particular type of event,
restarted or node down.

such

logging file
A logging sink that is to receive a
events for later retrieval.

machine-readable

logging identification
The sink type associated with the logging entity
or monitor).

(file,

console

logging sink
A place that a copy of an event is to be recorded.
logging sink flags
A set of flags in an event record that
which the event is to be recorded.

indicate

logging sink node
A node to which logging information is directed.

137

the

sinks

logging source node
The node from which logging information comes.
logging source process
The process that recognized an event.
logical link
A connection between two nodes ~hat is established and controlled
by the Session Control, Network Services, and Transport layers.
loopback node
A special name for a node, that is associated with a line for
loop testing purposes.
The SET NODE LINE command sets the
loopback node name.
monitor
An event sink that is to receive a machine-readable
events for possible real-time decision making.

record

An implementation that supports Transport, Network Services,
Session Control. Node is a Network Management entity.

and

node

node address
The required unique numeric identification of a specific node.
node identification
Either a node name or a node address. In some cases an address
must be used as a node identification. In some cases a name must
be used as a node identification.
node name
An optional alphanumeric identification associated with a node
address in a strict one-to-one mapping. No name may be used more
than once in a node. The node name must contain at least one
letter.
node level loopback
Testing a logical link using repeated messages that flow with
normal
data
traffic through the Session Control, Network
Services, and Transport layers within one node or from one node
to another and back. In some cases node level loopback involves
Ilsing a loopback node name associated with a particular line.
off state
Applied to a node: a state where it will no longer process
network traffic.
Applied to a line: a state where the line is
unavailable for any kind oE traffic.
A.pplied to logging:
a
state where the sink is not availablp., ancl rlrlY '~":~ ~1 i:::; r. ) ~_. i. ::
l~l·J~ll J b8 discarded.

138

on state
Applied to a node: a state of normal network operation. Applied
to a line: a state of availability for normal usage. Applied to
logging: a state where a sink is available for receiving events.
physical link
An individually hardware addressable communications path.
processed event
An event after local processing, in final form.
raw event
An event as recorded by the source process, incomplete
of total information required.

terms

reachable node
A node to which the executor node's Transport believes it
usable communications path.

has

remote node
To one node, any other network node.
restricted state
A node state where no new logical
allowed.

links

from

other

nodes

are

service password
The password required to permit triggering of a node's

bootstrap

ROM.

service slave mode
The mode where the processor is taken over and the adjacent,
executor node 1S 1n control, typically for execution of a
bootstrap program for down-line loading or for up-line dumping.
service state
A line state where such operations as down-line load, up-line
dump, or line loopback are performed. This state allows direct
access by Network Management to the line.
shut state
A node state where existing logical links
new ones are prevented.

are

undisturbed,

but

sink
(see logging sink)
specific filter
A filter that applies to a specific entity within an event
and type.

139

class

station
A physical termination on a line, having both a hardware and
software implementation, that is a controller and/or a unit and
is part of a line identification.
status
Dynamic information relating to entities, such as their state. A
Network Management information type. Also, a message indicating
whether or not an NCP command succeeded.
subs tate
An intermediate line state that is displayed as a tag on
state display.

line

summary
An information type meaning most useful information.
target node
The node that receives a memory image during a down-line
generates an up-line dump, or loops back a test message.

load,

tributary
A physical termination on a multipoint line that is not a control
station. Part of the line-identification for a multipoint line.
unit
Part of a line-identification.
forms a station.

140

Together

with

the

controller

DECnet DIGITAL
Network Architecture
Network Management
Functional Specification
AA-K181A-TK

READER'S COMMENTS

NOTE:

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

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

CI,)

o
o

Did you find errors in this manual?
page number.

If so, specify the error and the

Please indicate the type of reader that you most nearly represent.
[] Assembly language programmer
[] Higher-level language programmer
[] Occasional programmer (experienced)
[] User with little programming experience
[] Student programmer
[] Other (please specify) _______________________________________

Name

Da te _ _ _ _ _ _ _ _ _ _ _ __

Organization ____________________________________________________
Street ______________________________________________________
ci ty_ _ _ _ _ _ _ _ _ _ _ _ _ _ Sta te _ _ _ _ _ _ _ Zip Code __________
or
Country

I
,. - -

-Do Not Tear - Fold Here and Tape -

- - --l

- - - - -

No Postage

111II1

Necessary
if Mailed in the
United States

BUSINESS REPL V MAIL

FIRST CLASS PERMIT NO.33 MAYNARD MASS.

I
POSTAGE WILL BE PAID BY ADDRESSEE

SOFTWARE DOCUMENTATION
146 MAIN STREET ML 5-5/E39
MAYNARD, MASSACHUSETTS 01754

- -

Do Not Tear - Fold Here and Tape -

I
I
I