Digital PDFs

AA-X437A-TK

December 1983

254 pages

Original

2.6MB

Document:	DECnet Digital Network Architecture Phase IV Network Management Functional Specification
Order Number:	AA-X437A-TK
Revision:	000
Pages:	254
Original Filename:	http://decnet.ipv7.net/docs/dundas/aa-x437a-tk.pdf

OCR Text

OECnet Digital Network Architecture

sonware

DECnet Digital Network Architecture
Phase IV
Network Management Functional Specification
Order No. AA-X437A-TK

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

SUPERSESSIONIUPDATE INFORMATION: This is a new manual.
VERSION:

4.0.0

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

digital equipment corporation maynard, massachusetts

First Printing, December 1983

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

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

The following are trademarks of Digital Equipment Corporation:

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

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

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

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

MGTPEALL

Page 3

Table of Contents
CONTENTS

. . . . . . . . . . . . . . . . . . . .7
................7
.....................7
.............7
. . . . . . . . .
. . . . . . . . . . . . . . . . 87
FUNCTIONAL DESCRIPTION . . . . . . . . . . . . . . . 9
~ e s i g n s c o p e . . . . . . . . . . . . . . . . . . 10
Relationship to DIGITAL Network Architecture . . 11
Network Management Model of DNA from the User
Perspective . . . . . . . . . . . . . . . . . . 14
Nodes . . . . . . . . . . . . . . . . . . . . 15
Areas . . . . . . . . . . . . . . . . . . . . 16
Logging . . . . . . . . . . . . . . . . . . . 17
CircuitsandLines . . . . . . . . . . . . . . 17
Modules . . . . . . . . . . . . . . . . . . . 18
Model of Network Management Components in the DNA
Layers . . . . . . . . . . . . . . . . . . . . . 19
NETWORK MANAGEMENT AS SEEN BY THE USER . . . . . . 23
Nodes . . . . . . . . . . . . . . . . . . . . . 23
Node Parameters . . . . . . . . . . . . . . . 25
Nodecounters . . . . . . . . . . . . . . . . 35
Areas . . . . . . . . . . . . . . . . . . . . . 36
Logging . . . . . . . . . . . . . . . . . . . . 37
SourceQualifiers . . . . . . . . . . . . . . 38
Logging Parameters . . . . . . . . . . . . . . 38
Circuits . . . . . . . . . . . . . . . . . . . . 39
Circuit Parameters . . . . . . . . . . . . . . 40
Circuit Counters . . . . . . . . . . . . . . . 48
Lines . . . . . . . . . . . . . . . . . . . . . 49
Line Parameters . . . . . . . . . . . . . . . 49
Line Counters . . . . . . . . . . . . . . . . 54
Circuit and Line State and Substate Model . . . 55
High Level Link User States . . . . . . . . . 56
Data Link States . . . . . . . . . . . . . . . 58
Netwdrk Management Data Link Service States . 60
Controllable and Observable States and
Substates . . . . . . . . . . . . . . . . . . 63
Modules . . . . . . . . . . . . . . . . . . . . 65
X.25 Access Module . . . . . . . . . . . . . . 65
X.25 Protocol Module . . . . . . . . . . . . . 66
X.25 Server Module . . . . . . . . . . . . . . 72
Link Maintenance Modules . . . . . . . . . . . 75
Events . . . . . . . . . . . . . . . . . . . . . 78
Events Not Related to an Entity . . . . . . . 78
Node Events . . . . . . . . . . . . . . . . . 79
INTRODUCTION
IntendedAudience
Network Management Architecture. DECnet Networks.
and DNA
Protocols and Interfaces
Requirements for Implementations
RelatedDocuments

Circuit Events
Line Events
ModuleEvents
Event Parameters

. . . . . . . . . . . . . . . . 79
. . . . . . . . . . . . . . . . 81

. . . . . . . . . . . . . . . . . 80

. . . . . . . . . . . . . . . . 81

Page 4

Table of Contents

. . . . . . . . . . . 81
. . . . . . . . . . . . 82
. . . . . . . . . . . 83
. . . . . . . . . . . . . . . . 84
. . . . . . . . . . . . . . . 85
. . . . . . . . . . . . . 87

Network Management Layer
Session Control Layer
End Communication Layer
outing Layer
Data Link Layer
Physical Link Layer

NETWORK CONTROL PROGRAM (NCP) . . . . . . . . . . 88
Network Control Program Functions
88
89
Changing Parameters
89
Gathering Information
Down-lineLoading
90
Up-lineDumping
90
Triggering Bootstrap
90
90
Testing Link and Network
91
Zeroing Counters
Network Control Program Operation
91
91
Specifying the Executor
Program Invocation. Termination. and Prompting 91
privileged Commands
92
Input Formats
92
94
Output Characteristics
94
Status and Error Messages
Network Control Program Commands
96
96
SET and DEFINE Commands
CLEAR and PURGE Commands
104
TRIGGERCommands
108
LOADCommands
109
DUMP Commands
110
LOOPCommands
111
SHOW QUEUE Command
112
SHOW and LIST Commands
112
ZERO Commands
118
EXIT Command
119

.......
.............
. . . . . . . . . . . .
..............
. . . . . . . . . . . . . . .
. . . . . . . . . . . . .
...........
. . . . . . . . . . . . . . .
. . . . . . .
...........
.............
. . . . . . . . . . . . . . . .
............
. . . . . . . . . .
........
. . . . . . . . . . .
...........
...............
................
. . . . . . . . . . . . . . . .
................
. . . . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
NETWORK MANAGEMENT OPERATION . . . . . . . . . . . 120
NICE Access Routines and Listener . . . . . . . 120
Local Network Management Functions . . . . . . . 121
ink Watcher . . . . . . . . . . . . . . . . . . 122
Data Link Service Functions . . . . . . . . . . 122
States and Substates . . . . . . . . . . . . . 123
Priority Control . . . . . . . . . . . . . . . 124
Link State ~lgorithms . . . . . . . . . . . . 125
Link Handling Functions . . . . . . . . . . . 126
Event Logger . . . . . . . . . . . . . . . . . . 127
Event Logger Components . . . . . . . . . . . 129
Suggested Formats for Logging Data . . . . . . 132
Down-line Load Operation . . . . . . . . . . . . 133
up-line Dump Operation . . . . . . . . . . . . . 138
Trigger Bootstrap Operation . . . . . . . . . . 139
Loop Test Operation . . . . . . . . . . . . . . 140
Node Level ~ e s t i n g . . . . . . . . . . . . . . 140
Data LinkTesting . . . . . . . . . . . . . . 149
Change Parameter Operation . . . . . . . . . . . 152
Read Information Operation . . . . . . . . . . . 154

Page 5

Table of Contents

. . . . . . . . . . . . 154
. . . . . . . . . . . 154
. . . . . . . . . . . 155
. . . . 157
. . . . . . . . . . . . . . 157
NETWORK MANAGEMENT MESSAGES . . . . . . . . . . . 159
NICE unction Codes . . . . . . . . . . . . . . 159
Message Format ~ o t a t i o n . . . . . . . . . . . . 160
Request Down-line Load Message Format . . . . . 161
Request Up-line Dump Message Format . . . . . . 163
Trigger Bootstrap Message Format . . . . . . . . 164
Test Message Format . . . . . . . . . . . . . . 165
Change Parameter Message Format . . . . . . . . 166
Read ~nformationMessage Format . . . . . . . . 167
Zero Counters Message Format . . . . . . . . . . 168
NICE System Specific Message Format . . . . . . 168
NICE Response Message Format . . . . . . . . . . 169
NICE Connect Initiate and Connect Accept Data
Formats . . . . . . . . . . . . . . . . . . . . 170
Event Message Binary Data Format . . . . . . . . 170
Logical Loopback Message Formats . . . . . . . . 172
Connect Accept Data Format . . . . . . . . . . 172
Command Message Format . . . . . . . . . . . . 172
Response Message Format . . . . . . . . . . . 172
PARAMETER AND COUNTER BINARY FORMATS AND VALUES . 173
Introduction to Binary Format Descriptions . . . 173
Type Numbers . . . . . . . . . . . . . . . . . 173
Entity Parameter Identifier Format . . . . . . 173
String Identifier Format . . . . . . . . . . . 174
Node Identifier Formats . . . . . . . . . . . 174
Area Identifier Format . . . . . . . . . . . . 175
Object Format for Entity Types . . . . . . . . 175
NumericRange . . . . . . . . . . . . . . . . 176
Parameter Display Format and Descriptive
~ n c o d i n q ~ o t a t i o n. . . . . . . . . . . . . . 176
NICE Returns
. . . . . . . . . . . . . . . . 176
~nformationTypes . . . . . . . . . . . . . . 179
. . . . . . . . . 179
Applicability Restrictions
Setability Restrictions . . . . . . . . . . . 179
Circuit Parameters . . . . . . . . . . . . . . . 180
Circuit Counters . . . . . . . . . . . . . . . . 183
Line Parameters . . . . . . . . . . . . . . . . 185
Line Counters . . . . . . . . . . . . . . . . . 187
Logging Parameters . . . . . . . . . . . . . . . 189
Module Parameters . . . . . . . . . . . . . . . 191
Console Module Parameters . . . . . . . . . . 191
Loader Module Parameters . . . . . . . . . . . 191
Looper Module Parameters . . . . . . . . . . . 192
Configurator Module Parameters . . . . . . . . 192
X.25 Access Module Parameters . . . . . . . . 194
X.25 Protocol Module Parameters . . . . . . . 194
X.25 Server Module Parameters . . . . . . . . 196
Zero Counters Operation
Loopback Mirror Operation
NICE Logical Link Handling
Algorithm for Accepting Version Numbers
Return Code Handling

Modulecounters

. . . . . . . . . . . . . . . . 197

Table of Contents
7.8.1
7.8.2
7.9
7.10
7.11
7.12
7.13
APPENDIX A

A I
A.l.1
A.1.2
A.1.3
A.1.4
A 1.5
A.2

Page 6

. . . . . . . . 197
. . . . . . . . . 197
. . . . . . . . . . . . . . . . 197
. . . . . . . . . . . . . . . . . 201
. . . . . . . . . . . . . . . . 202
. . . . . . . . . . . . . . . 202
. . . . . . . . . . . . . . . . 205

X.25 Protocol Module Counters
X.25 Server Module Counters
Node Parameters
Nodecounters
Areaparameters
Event Definitions
Event Parameters
VERSION COMPATIBILITY

. . . . . . . . . . . . . . . A-1
. . . . . . . . . . . . . . . . . A-2
. . . . . . . . . . . . . . . . . . A-2
. . . . . . . . . . . . . . . . . A-2
. . . . . . . . . . . A-2
. . . . . . . . . . . . . . . . . A-4
. . . . . . . . . . . . . . . A-4

Versions 2.0 and 3.0
ModuleEntity
NodeEntity
Logging Entity
C-rcuit and Line Entities
Event Logging
Versions 3.0 and 4.0

APPENDIX B

MINIMUM SUBSET

APPENDIX C

STATE MAPPING TABLES

APPENDIX D

X.25 NATIVE ONLY SUBSET

APPENDIX E

MEMORY IMAGE FORMATS AND FILE CONTENTS

APPENDIX F

NICE RETURN CODES WITH EXPLANATIONS

APPENDIX G

NCP COMMAND STATUS AND ERROR MESSAGES

APPENDIX H

JULIAN HALF-DAY ALGORITHMS

APPENDIX I

DMC DEVICE COUNTERS

APPENDIX J

GLOSSARY

Introduction
1

INTRODUCTION

1.1

Page 7

Intended Audience

This document is written primarily for those who implement Network
Management on DECnet systems. However, it may also be of interest to
anyo'ne who wants to know the details of the Network Management
structure.
Knowledge of communications software technology, DECnet,
and X . 2 5 is prerequisite to understanding this document.
Sections 1-4 describe Network Management mainly from the
user
perspective. Sections 5-7 describe Network Management internals.

1.2

Network Manaqepnt Architecture, DECnet Networks, and DNA

This document describes the structure, functions, operation, and
protocols of Network Management. Network Management models software
that enables operators and programs to plan, control, and maintain the
operation of centralized or distributed DECnet networks. ~ e t w o r k s
consist of software nodules, data bases, and hardware components that
connect
computing
systems
for
resource
sharing, distributed
computation, or remote system communication. DECnet networks connect
DIGITAL computing systems together, and also connect to public data
networks with X . 2 5 circuits.
Network Management is part of the DIGITAL Network Architecture (DNA).
DNA is the model on which DECnet network software implementations are
based.

1.3

Protocols and Interfaces

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.
This document describes Network
Management's interface to each layer by describing elements in each
layer that Network Management controls or examines.

1.4

Requirements for Implementations

This document describes user commands that can be standardized across
different DECnet implementations.
An implementation may use only a
subset of the commands described herein. (Appendix B describes the
minimum
subset
of
Network
Management functions required for

Introduction

Page 8

certification.) Moreover, commands and functions specific
particular operating system are not described herein.

one

This document uses both algorithms and English descriptions to explain
the Network Management functions. An implementation is not required
to follow these algorithms exactly, as long as the functions operate
as described.

1.5

Related Documents

This is one of a series of functional specifications for the DIGITAL
Network Architecture, Phase IV.
The other current DNA functional
specifications are:
DNA Data Access Protocol (DAP) Functional
5.6.0, Order No. AA-K-TK

Specification, Version

DNA D i g i ~ a l Data
-

Communications
Messaqe
Protocol
(DDCMP)
Functional Soecification. Version 4.1.0. Order No. AA-K175A-TK

DNA Ethernet Data Link Functional
-

Specification,

Version

1.0.0,

Order No. AA-Y298A-TK

DNA Ethernet Node Product Architecture
1.0.0, Order No. AA-X440A-TK

Specification, Version

DNA

Specification,

Version

Specification,

Version

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

DNA Network Services Protocol
-

Functional
4.0.0, Order No. AA-X439A-TK
,

DNA Routing Layer Functional Specification, Version
-

2.0.0,

Order

NO. AA-X435A-TK

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

TJie --Ethernet
- - -A.LoxaJ .Axe3 Network- Data Link Layer and Physical
Layer
-Spe-Gfica-t-ions,
Version 2.0, ( Digital, Intel, and
Xerox) , Order No. AA-K759B-TK
The DECnet DIGITAL Network Architecture (Phase IV) General Description
(Order
No.
AA-N149A-TC)
provides an overview of the network
architecture and an introduction to
each
of
the
functional
specifications.

Page 9

Functional Description
2

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 performi~g the following control functions:

user

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

Configuring resources.
A system manager can change the
network conf-quration and modify message traffic patterns.

Setting parameters. Circuit, line, module, node, and logging
parameters (for 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 loopkack tests and other functions.

down-line

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

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

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.
Parameters
(for
example,
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 o f
significant network events.

up-line

timer

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.

Page 10

Functional Description
2.1

~ e s i g nScope

Network
Management
requirements:

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.

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.

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

11.

Integrated abstractions. Diverse low level policies, such as
different Data Link protocols, are combined where possible
into consistent higher level abstractions.

The following are not within the scope
Management:

this

version

Network

Functional Description

Page 11

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 compatioility of user interfaces. The interfaces to
the User Layer are not necessarily frozen with this version.
Observable data may change with the next version.
Version
4.0 is compatible with Version 3.0 except for the changes
necessary to distinguish network areas, while Version 3.0 is
compatible
with
Version 2.0 except for those changes
necessitated b y the integration of X.25 Network Management
functions, the DMP device, and multipoint software functions.
S e e Appendix 1.) Compatibility with versions before Version
2.0 is not supported.

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 software components, protocols, and interfaces
to adjacent layers. Network Management software components reside in
the three highest layers.
The g e n e r a l d e s i g n of DNA is a s follows in order from the

highest

the lowest layer:
1.

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.
Software components in this layer
provide user control over, and access to, network parameters
and counters as well as up-line dumping, down-line loading,
and testing functions.

The Network Application Layer. Software components in the
Network Application Layer support 1/0 device and file access
functions. The Network Management software component in this
layer is the Loopback Mirror, providing logical link loopback
testing.

Functional Description

Page 12

The Session Control Layer. The Session Control Layer manages
the system-dependent aspects of logical link communication.
The End Communication Layer.
The End communication Layer
controls
the creation, maintenance, and destruction of
logical links, using the Network Services Protocol.
The outing Layer. Software components in the Routing
route messages between source and destination nodes.

Layer

The Data Link Layer.
The Data Link Layer manages the
communications over a physical link, using a data link
protocol, for example, the Digital Data
Communications
Message Protocol (DDCMP) or the X.25 Protocol.
The Physical L:nk Layer. The Physical Link Layer provides
the hardware interfaces (such as EIA RS-232-C or CCITT V.24)
to specific system devices.
Figure 1 shows the relationship of the Network Management Layer to the
other DNA layers.

Functional Description

.-----------> ! Data Link Modules

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

Figure 1.

Network Management Relation to DNA

Page 13

I
I

Page 14

Functional Description
Network Manaqement contains two models:

2.3

A simplified network model that is intended for network
management use.
This model is in a sense a simplified view
of DNA (Section 2.3).

The model for Network Management
2.4).

part

DNA

(Section

Network Manaqement Model of DNA from the User Perspective

Because one of the primary goals of the Network Management design is
ease of use, the person who uses the Network Management software is
presented with a different, less complicated view of the network than
that of the entire DNA model. This model is addressed at two levels:
the interactive user at a terminal and the user program.
The interactive user manages the network mainly by
of the form:
verb

entity

entering

commands

entity-option

The verb is an English verb such as SET, CLEAR, SHOW, LOAD, or LOOP.
The entity is one of five classes of controllable network elements:
Node - Each node in a network represents a distinct operating
system with associated CPU and peripherals.
Nodes are
further described in the section entitled Nodes.
Area - An area is a group of nodes. Nodes are
areas for hierarchical routing purposes.

grouped

into

Logging - Logging is the
mechanism
that
keeps
track
automatically of important aspects of the network operation.
Logging is further explained in Section 2.3.3.
Circuits - Circuits
are
logical
described in Section 2.3.4.

communications

paths

Lines - Lines are physical communications paths described
Section 2.3.4.

Modules - Modules are any entity that does not fit into the
above classifications but represents a distinct function
and/or database.
For the present, all the modules are
related to either X.25 or maintenance functions.
Note that in particular implementations, the
"element" may be used in place of "entity".

word

"component"

The user can observe, and, in some cases, control various aspects of
entities.
The entity-option qualifies the aspect of the entity upon

Page 15

Functional Description

which the verb is to act. For each entity, DNA specifies associated
parameters. For some entities DNA also specifies counters and events.
The parameters and counters are information kept in data bases.

Data bases are of two types: volatile and permanent.
The volatile
data base describes the running network. If the system crashes or
shufs down, the volatile data base disappears.
The permanent data
base specifies the initial content of the volatile data base.
Counters are only kept in the volatile data base.
Events are not kept in any data base.
event logging mechanism as they occur.

Events

are

captured

the

Parameters are values in a data base indicating characteristics or
status of an entity. For example, some of the node parameters are:
NODE STATE
NODE NAME
NODE ADDRESS
Some parameters can be changed or set.
to a default value or to no operation.

Of these, some can be clea'red
Parameters can be read.

Counters are variables kept
counters are:

memory.

main

Examples

circuit

Seconds since last zeroed
Bytes received
Bytes sent
Counters can only be read, zeroed, or read and zeroed.
Events are occurrences in the network that the Network Management
event logging mechanism keeps track of. Only the logging entity has
events. Examples of logging events are:
Invalid message
Verification reject
Line counters zeroed
Node reachability change
The user cannot directly control events.
control aspects of the logging of events.

user

can,

however,

The user program interface uses specified messages to
types of requests as the interactive user can make.

pass

the

2.3.1

The

same

Nodes

Nodes are the major controllable entity of the network. They are the
addressable objects of the Routing algorithms. From the standpoint of
Network Management, there are two major classifications of nodes:
executor and remote.
The executor is the node actually executing a

Functional Description

Page 16

Network Management function. All other nodes in relation to the
executor are remote. Network concepts and functions described in this
document are described from the vantage point of the executor node.
Note that from the point of view of a user, the terminal he is using
is at the local node.
This is usually also the executor node.
However, if this user should set his terminal as a virtual terminal to
access
Network Management functions at another node, then his
"physically" local node is a "remote" node from the point of view of
Network Management.
In some contexts, nodes are also referred to as loop,
or target nodes.

command,

host,

Loop node is a special name for the executor node.
This name is
associated with one of tze executor's circuits, and logical links to
that node are routed out the line with the expectation that they will
be looped back.
The command node is the node requesting a high level Network
Management function from the executor. It can be the executor itself
or some remote node.
A host node is a node that provides
system.

some

service,

such

A tarqet node is the node that is to receive a load, loop back
level line test message, or generate a dump.

file
a

low

In any particular operatior-, functions can be distributed among nodes.
For example, a down-line system load can use different command,
executor, host, and target nodes. Alternatively, the down-line load
can use just the executor and tarqet nodes; or executor, command and
target; or executor, host, and target.
The node entity is associated with functions, parameters, counters,
and
events
from the Network Management, Session Control, End
Communication, and Routing layers of the general DNA model.

2.3.2

Areas

An area is a group of nodes. The Network Manager groups nodes into
areas for hierarchical routing purposes.
The use of areas in a
network allows node identification within an area to be independent of
node identification within other areas.
Each area is uniquely
identified.
The addition of an area identification to a node
identification uniquely identifies a node within the network. Nodes
in a single area network will, by convention, have the default area
number "l", which will not be displayed, thus hiding the unnecessary
addressing hierarchy from the Network Manager.

Functional Description
2.3.3

Page 17

Logging

Logging is the automatic event recording mechanism of
Network
Management.
A logged even: is directed to a sink node for output. A
sink may be a system console, a file, or a monitor program. The node
at which the event occurs is the source node. The system manager must
use Network Management commands to tell the source node what kinds of
events are to be logged and to what kinds of sinks. The sinks can be
located at one or more nodes. These nodes are the destination nodes.
The Network Management software at each destination node knows the
actual name and state of its resident sinks.
Some examples of logging eniity-options are:
LOGGING STATE
LOGGING SINK NODE
LOGGING EVENTS
Logging sink functions and parameters, other than the actual creation
of event data, are completely within the Network Management layer.

2.3.4

Circuits and Lines

The circuit and line entities are presented together as a reflection
of the close coupling of the Data Link and Physical Link layers.
A circuit is a high level communications path.
Circuits provide
logical communication between protocol handling modules. They are the
communications paths that are visible, for example, to Routing and the
X.25 Gateway server.
A circuit may be a permanent or switchable
connection. Unknown to its high level user, a circuit may be in
one-to-one correspondence to a physical link, multiplexed with many
other circuits, and/or traffic split over multiple physical links.
Some characteristics of circuits can affect the way that they are
used, so in many cases the higher level can or must be aware of these
differences.
In other words, the line to circuit mapping is
invisible, but other characteristics may not be.
A line is a low level communications path.
Lines provide physical
communications. They are the media over which circuits operate.
There are currently three major classes of circuits - - DDCMP, X.25 and
Ethernet.
DDCMP
circuits
are subdivided into point-to-point,
multipoint control, and multipoint tributary.
X.25 circuits are
subdivided
into
permanent and switched, with switched further
subdivided into incoming and outgoing. X.25 circuit parameters are
from X.25 level 3, the packet level. X.25 line parameters are from
X.25 level 2, the frame level.
DDCMP point-to-point circuits have a one-to-one correspondence between
the circuit and the line.
For DDCMP, each multipoint tributary is a separate circuit, and all of

Functional Description

Page 18

the tributaries in a group use the same line. The line must be of
protocol type DDCMP CONTROL. In other words, at the master end, there
is one DDCMP control line.
It is associated with one or more
circuits, each of which has its own physical tributary address.
At
the slave end, there is a one-to-one correspondence of circuit and a
DDCMP tributary line.
X.25 circuits differ from DDCMP circuits in that there is no direct
correspondence between circuit and line.
All X.25 circuits pass
through the X.25 protocol handler module.
Lines belong to the
protocol handler module, and it is responsible for establishment and
maintenance of the circuits :hat use them.
X.25 permanent circuits are very similar to DDCMP circuits in that
both have predefined end points that are assumed in the usage of the
circuit.
X.25 switched circuits can only be individually named in the context
of a higher level user, such as outing. This provides a handle for
higher level user parameters or counters. For other users, they have
no individual existence that is visible to Network Management.
Ethernet circuits are rather different from the other types in that
there is not a single node at the other end. Rather, Ethernet
circuits are distinguished from one another according to the higher
A-n Ethernet circuit is a path to many nodes
level user's protocol.
and the visibility of these nodes to Network Management varies
according to the higher level user.
Use of an Ethernet circuit requires a station identification.
This
station identification is an Ethernet address. The address that the
station is currently using is called the physical address.
Some
stations will also respond to a group identification called a
multicast address. Some stations also have an address, or addresses,
built into their hardware.
This hardware address may sometimes be
used as the physical address. DNA currently requires that stations
cabable of anything other than maintenance operations use a physical
address that is a function of the DNA node address. This requirement
is found in the DNA Ethernet Node Product Architecture Specification.
Circuit functions, parameters, counters, and events are from the
Network Management, Routing, Data Link, and Physical Link layers.
Line functions, parameters, counters, and events are from the Network
Management, Data Link, and Physical Link layers.

2.3.5

Modules

Modules currently comprise the access routines, server and protocol
handler for X.25, and Network Management maintenance handlers.
The X.25 access routine module contains the data base needed to
connect the program using the access routines to a server for the
desired public data network. This data base is organized by network

F'unctional Description

Page 19

identification.
The X . 2 5 server module contains the data base needed to map an
incoming X . 2 5 call to a DECret process and form the connection. This
data base is organized by destination identification.
The server
module also keeps one set of counters relative to its internal
resources.
The X . 2 5 protocol handler mocule contains the common data base needed
to multiplex switched and permanent X.25 circuits over its line or
lines. These parameters are from X . 2 5
level 3 , the packet level.
This data base is organized by one or more local DTE ( ~ a t a~ e r m i n a l
Equipment -- the X . 2 5 equivalent of a node) addresses.
The protocol
handler module contains an X . 2 5 user group data base organized by
group name. The protocol handler module also keeps counters relative
to each of its local DTE addresses.
The Network Management maintenance modules are responsible
for
handling maintenance functions on circuits and/or lines. They have
implied responsibility for handling maintenance for all DDCMP and X.25
data links and specific responsibility for Ethernet circuits assiq'ned
to them by the network manager. The maintenance modules represent a
simplification for the network manager. They actually cover parts of
the Network Management Link Watcher and Data Link Service Functions
described in a later section.
Each of the maintenance modules contains the low level data base
necessary to perform their respective functions on Ethernet circuits.
Within the modules, the infor-nation is organized by circuit.
The looper module is necessary for Ethernet loopback testing.
The loader module is necessary for Ethernet up-line dump and down-line
load.
The console module is necessary for Ethernet remote console functions.
The configurator module is necessary for determining the list
stations on an Ethernet line. It is a user of the console module.

Module functions, parameters, counters, and events are currently from
the Network Applications, Network Management, and Data ink layers.

2.4

Model of Network Management Components in the DNA Layers

The functional components of Network Management are as follows:
user layer components
The Network Control Program
Network Control Program (NCP).
enables the operator to control and observe the network from a
terminal. Section 4 specifies the NCP commands.

Functional Description

Page 20

Network Management layer components
Section 5 specifies the Network Management layer components and
their operation. Figure 2 , following, shows the relationship of
Network Management layer modules in a single node.
The components are:
Network Management Access Routines. These routines provide user
programs and NCP with ceneric 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.
Section
5.1
describes
the
Network
Management Access Routine's operation.
Network Management Lister-er. 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. Section
5.1 describes the Network Management Listener.
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.
Section 5.2 describes the Local Network
Management Function's operation.
Link Watcher. The Link Watcher is a component in a node that can
sense service requests on a data link from a physically adjacent
node. it controls automatically-sensed down-line load or up-line
dump requests. Section 5.3 describes the Link Watcher operation.
Maintenance Functions.
These are
the
actual
maintenance
operations, such as down-line load or link loop test, that are
specified in
the
DNA
Low
Level
Maintenance
Operation
specification.
Data Link Service Functions. These provide the Link 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 line state).
The Data Link Service software (or
hardware) component maintains internal states as well as line
5.4
describes the Data Link Service
substates.
Section
operation.
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,
outing) provides the data to the Event Logger, which can then
record it. Section 5.5 describes the Event Logger operation.

Page 21

Functional Description
Network Application layer components

Loopback Mirror. Access and service routines communicate using
the Loopback Mirror Protocol to provide node level loopback on
logical links. Section 5.13 describes this Network Application
layer component.
Obj ect 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
Table 0 - Networx Management Object Types

separate

Functional Description

Page 22

1
I
1

Interfaces for function
requests

Control Interfaces

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

Local Network Management Functions

-------------------------------------------------------------g

I
I
I
1
1

I
v

I 1
I 1
I , - - - - - - - _ - - _ -I 1
1 1 MaintenanceI<-' 1
1 1 Functions 1
I
1
1
I
I
I
I
I
V
V
V
I
----------1
1 Data Link 1
1
1 Service
1 Functions 1

'------------I

\<------------I

----------- I

NETWORK MANAGEMENT LAYER

I
I
I

I
I

I
1
I
1
I
I

1
I
1
I

I
-------

I
!

I
1
1
I
I
I
1
1

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

LOWER LAYERS

I
V

Service interface to
Data Link Layer
Control over lower
level functions
(examine line state,
turn on NSP, etc.)

<----I

Figure 2.

I
I
I
1
I
I
I
1
Events from
I Events to
other nodes---.
1 other nodes
I
I <---_______ _____-----. I
1

1 Event
Logger

----------- > I

<--I

----------- I

I1 = = = = = = = = = = = = = = = = I1 = = = = = = 1I = = = = =

1
v

1
I
1
1
1
V
Control interface to
read event queues

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

Network Management Layer Modules and Interfaces in a Single
Node.

Network Management as Seen by the User
3

Page 23

NETWORK MANAGEMENT AS SEEN BY THE USER

This section describes in detail the entities and their related
parameters,
counters,
events and other entity options.
These
descriptions are both an introduction to and a reference for the NCP
commands described in Section 4. Section 4.1 describes the Network
~anagement functions for NCP commands that use the
parameters
described in this section. User programs can access these functions
using the NICE protocol (Section 6). The NICE protocol binary formats
associated with the entities, parameters, counters, and events are
specified in Section 7.
The descriptions in this section relate parameters, counters, and
events to the architectural layers to which they belong. Some
parameters are specified as read-only.
This means that Network
Management can only read the value, and cannot directly change it.
Changes to parameter values are typically under control of the DNA
layer that "owns" the parameter.
In some of the descriptions in this section the term id-string is used
to describe an identification. In all of these cases, an id-str'ing
consists of one to sixteen characters from the set of upper-case
alphabetics, numerics, period and hyphen. An id-string must contain
at least one alphabetic character.
Ethernet addresses appear several times
as
parameters
called
ethernet-address.
An ethernet-address is a string of 12 hexadecimal
digits, bytes separated by hyphens. The bytes are ordered from left
to right as transmitted and received on the Ethernet. An example
address is AA-00-04-00-OE-01.
In the following descriptions keywords (words that Network Management
reserves for use in NCP commands) are capitalized. Brackets enclose
optional input or output.

3.1

Nodes

A node is an implementation of a computer system that supports
Routing, End Communicat!ion, and Session Control. Each node has a
unique address assigned by the manager of each node.
The Routing
layer sends user data to nodes according to the node address. Since
it is easier for humans to address nodes by names, DNA allows one node
name for each node. The network manager should make sure that each
node name and address in the network is unique.
(An implementation
may also provide the ability to assign additional node names to nodes,
but these names can be known to the local node only.
Refer to the
Routing specification.)
The user can identify nodes in two major ways:
individually and in
groups.
To identify a node individually, there are, again, two major
ways :
1.

Specify the keyword NODE along with a node-identification

Page 24

Network Management as Seen by the User
the format:
NODE node-identification
The node-identification is one of the following:

node-name

A node zame 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.

node-address

A node address is a hierarchically structured
number assigned to a particular node. It
consists of two parts, an area number and a
node nunber.
Each of these is an unsigned
decimal integer.
They are displayed
or
entered separated by a single period. If the
area number is not specified, it defaults to
the area of the executor node. Each node
address must be unique. Node numbers must be
unique within an area, but may be re-used in
differer-t areas. Only the address o f the
executor node can be set. Note: In a single
area network, the area number defaults to "1"
(by convention), and is hidden from the user.

Specify the executor
follows:

node

with

the

keyword

EXECUTOR,

EXECUTOR
Node group identifications are as follows:
ACTIVE NODES

For a nonroutinq node, all nodes that the
executor sees on the other end of a logical
link, or as adjacent, or as designated router.
For an intra-area routing node, all of the
above plus all nodes
that
the
executor
perceives as reachable within its area. For an
inter-area router, all of the above plus all
nodes the executor sees as adjacent inter-area
routers.

ADJACENT NODES

All nodes that the executor perceives Routing
can reach and that are physically adjacent
(i.e. separated from the executor by a single
circuit).
Each occurrence of a node on a
different circuit appears
as
a
separate
adjacent node.
In other words, the adjacency
of a node is qualified by the circuit on which
it is adjacent.

KNOWN NODES

As defined for ACTIVE NODES, plus all nodes
that have a name, including names that map to a

Page 25

Network Management as Seen by the User
circuit (i-e., loop nodes).
LOOP NODES

All nodes that are associated
for loop testing purposes.

with

circuit

SIGNIFICANT NODES All nodes that have significant information
associated with them for display purposes.
When obtaining node information, :hat pertaining to the executor
is returned first, and that for loop nodes, last.

node

The format for displaying node identification is:
NODE = node-address [(node-name)]
For example:
NODE = 19 (Elrond)
NODE = 3.19 (Fargon)
A node-related routing concept that is visible in Network Management
is that of an adjacency.
An adjacency is an adjacent node as
reachable over a particular circuit.
Each different circuit that
leads to an adjacent node counts as a separate adjacency. Each
different adjacent node on a circuit counts as a separate adjacency.

3.1.1

Node Parameters

The node parameters following are listed in alphabetical order
according to the DNA layer that owns them, starting with the highest
layer that contains node parameters.
The executor node keeps two data bases relative to nodes:
1.

A data base of its own node parameters

A data base of remote node parameters (for each remote
and of optional adjacent node parameters.

node)

Many types of parameters kept in the executor node data base are not
kept in the data bases the executor keeps for remote nodes. Also,
some remote node parameters can only be kept for adjacent nodes.
Thus, in the descriptions below some parameters are distinguished
applying to the executor node, remote node, or the adjacent node.

Some parameters are described as loop-only. This means that they are
parameters that only exist for use with the LOOP command and the Test
message. Some of them have fixed, default values.

Page 26

Network Management as Seen by the User
3.1.1.1

Network Management Layer

COUNTER TIMER seconds
This value is the number of seconds between node counter log
events.
The expiration of the timer causes a node counter
logging event.
Refer to the two sections entitled
"Node
Counters" and "Events" for lists of node counters and events.
When the counter timer expires, the node counters are recorded as
data in the event and then zeroed. If no value is set, node
counters are not automatically logged. Seconds is specified as a
decimal number in the range 1-65535.
CPU cpu-type
This value indicates the default target node CPU type for
down-line loading the adjacent node. The possible values are:
PDP8
PDP11
DECSYSTEM1020
VAX
DIAGNOSTIC FILE file-id
This is the identification of the file to read from when the
adjacent
node
is
down-line
loaded
and
has
requested
"diagnostics". The file identification is a string that is
interpreted depending on the file system of the executor.
DUMP ADDRESS octal-number
This value represents the address in memory to begin
dump of the adjacent node.

up-line

DUMP COUNT number
This value is the default number of memory units to up-line

dump

from the adjacent node.
DUMP FILE file-id
This value is 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 according to the file system of the
executor.
HARDWARE ADDRESS ethernet-address
This value is the Ethernet hardware address of the adjacent node.
It is the Ethernet address that is assigned to the node system
hardware. This address is necessary for communication with the
system for such purposes as down-line load before it has been
able to meet the DNA requirements for setting its physical
address.

Network Management as Seen by the User

Page 27

HOST node-id
For the executor node, this value identifies the node from which
the executor receives its services. This value defaults to the
executor node.
For adjacent nodes, this value is the host identification
the adjacent node receives when it is down-line loaded.
value defaults to the executor node.

that
This

IDENTIFICATION string
This is a text string that cescribes the executor node (for
example, "Research Lab").
The string is 32 characters of any
type. When entered in NCP, i t the string contains blanks or
tabs, it must be enclosed ir quotation marks. A quotation mark
within a quoted string is indicated by two adjacent quotation
marks ( " I
')

LOAD FILE file-id
This is the identification of the file to read from when the
adjacent node is down-line loaded and has requested "operating
system". The file identification is a string that is interpreted
depending on the file system cf the executor.
LOOP ASSISTANT NODE node-id
This identifies the loop-only oarameter used only as input on the
LOOP CIRCUIT command for Ethernet third-party circuit loop
testing. This parameter applies to the executor node only.
LOOP ASSISTANT PHYSICAL ADDRESS ethernet-address
This is the loop-only parameter used only as input on the LOOP
CIRCUIT command for Ethernet third-party circuit loop testing.
It cannot be a multicast address. This parameter applies to the
executor node only.
LOOP COUNT count
This is the loop-only default count for the number of times to
loop the data for a loop test. This parameter applies to the
executor node only. Its value is 1.
LOOP HELP help-type
This is the loop-only default help type for Ethernet circuit loop
testing.
This parameter applies to the executor node only. Its
value is FULL.
LOOP LENGTH length
This is the loop-only default length for the data that is looped
in a loop test.
This parameter applies to the executor node

Page 28

Network Management as Seen by the User
only.

Its value is 40.

LOOP NODE node-id
This identifies the loop-only sarameter used only as input on the
LOOP CIRCUIT command for Ethernet circuit loop testing. This
parameter applies to the executor node only.
LOOP WITH block-type
This
This is the loop-only default clock type for loop testing.
parameter applies to the executor node only. Its value is MIXED.
PHYSICAL ADDRESS ethernet-address
This read-only executor parameter
currently in use to identify itself.

the

Ethernet

address

MANAGEMENT VERSION n.n.n
This is the read-only Network Management Version, consisting of
the version number, the Engineering Change Order (ECO) number,
and the user ECO number (for example, 3.0.0).
This parameter
applies to the executor node only.
SECONDARY DUMPER file-id
This identifies the secondary dumper file for up-line dumping the
adjacent node. The file identification is interpreted depending
on the file system of the executor.
SECONDARY LOADER file-id
This identifies the secondary loader file for
the adjacent node.

down-line

SERVICE CIRCUIT circuit-id
This identifies the'circuit to the adjacent node for down-line
loading and up-line dumping. This is the default parameter if
the circuit-id is not included in a down-line load command.
SERVICE DEVICE device-type
This is the identification of the device type that the adjacent
node uses for service functions when in service slave mode
S e c t i o n 5.4). The device type is one of the standard line
device mnemonics able 10, Section 7.4).
SERVICE NODE VERSION node-version
This is the DNA version of the adjacent node, which is used to
determine
the TARGET SYSTEM ADDRESS parameter in the MOP
Parameter Load ~i th Transfer Address messabe (see DNA Maintenance
Operations Functional Specification).
The default value is 1

Network Management as Seen by the User

Page 29

(Phase IV).
SERVICE PASSWORD password
This is the password required to trigger the bootstrap mechanism
on the adjacent node. The password is a hexadecimal number in
the range 0 - FFFFFFFFFFFFFFFF < 6 4 bits).
SOFTWARE IDENTIFICATION software-id
This identifies the software to be loaded when the adjacent node
is down-line loaded. Software-id is a string of 1-16 characters.
SOFTWARE TYPE program-type
This value represents the target node initial software program
type for down-line loading tie adjacent node. Program type is
one of:
SECONDARY [LOADER]
TERTIARY [LOADER]
SYSTEM
STATE node-state
This represents the operational state of the executor node.
possible states are:

The

Allows logical links.

OFF

Allows no new links, terminates existing
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 no new incoming logical links from
nodes.

links,

other

TERTIARY LOADER file-id
This identifies the tertiary loader file for down-line loading
the adjacent node.
The file identification is interpreted
according to the executor node file system.

3.1.1.2

Session Control Layer

ADDRESS node-address
This value is the address of the executor node.
applies to the executor node only.

This

parameter

Network Management as Seen by the User

Page 30

CIRCUIT circuit-id
This value identifies a loop node for testing and sets the
identification of the circuit to be used for all traffic to the
node. The circuit-id can be associated with only one loop node
name. Refer to the section entitled Testing Link and Network.
INCOMING TIMER seconds
This value represents the maximu-n duration between the time a
connect is received for a process at the executor node and the
time that process accepts or rejects it. If the connect is not
accepted or rejected by the Jser within the number of seconds
specified, Session Control rejec-is it for the user. If no value
is set, there is no timer.
NAME node-name
This parameter represents the name to be associated with the node
identification.
Only one name can be assigned to a node address
or a circuit identification. No name should be used more than
once
in a network.
Node-name is one to six upper case
alphanumeric characters with at least one alpha character.
OUTGOING TIMER seconds
This value represents the duration between the time the executor
requests a connect 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. If no value is set, there is no timer.
The range is
1-65535.

3.1.1.3

End Communication Layer

ACTIVE LINKS number
This read-only parameter represents the number of active
links from the executor to the destination node.

logical

DELAY seconds
This read-only parameter is the average round trip delay in
his parameter is kept on a
seconds to the destination node.
remote node basis.
DELAY FACTOR number
This is 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 ( ~ n d
Communication specification). The number is decimal in the range

Page 31

Network Management as Seen by the User

DELAY WEIGHT number
This number represents 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 (End Communication specification).
INACTIVITY TIMER seconds
This value represents 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 minimum number of seconds, End Communication generates
artificial traffic to test
the
link
(End
Communication
specification). The value range is 1-65535.
MAXIMUM LINKS number
This value represents the maximum active logical link count
allowed for the executor. The count is a decimal number in the
range 1-65535.
NSP VERSION n.n.n
This read-only parameter represents the
node End Communication.
The format
Network Management version.

version
is the

number of the
same as for the

RETRANSMIT FACTOR number
This value represents the maximum number of times the source End
Communication
at
the
executor
node
will
restart
the
retransmission timer when it expires. I f the number is exceeded,
Session Control disconnects the logical link for the user (End
Communication specification). The number is decimal in the range
1-65535.

3.1.1.4

Routing Layer

AREA MAXIMUM COST number
This value represents the maximum total path cost allowed from
the executor to any other level 2 routing node. The AREA MAXIMUM
COST number is decimal in the range 1-1022.
This parameter is
only applicable if the executor node is of type AREA.
AREA MAXIMUM HOPS number
This value represents the maximum number of routing
hops
allowable from the executor to any other level 2 routing node.

Network Management as Seen by the User

Page 32

The AREA MAXIMUM HOPS number is decimal in the range 1-30.
This
parameter is only applicable :f the executor node is o f type
AREA.
BROADCAST ROUTING TIMER seconds
This value determines the maximum time allowed between Routing
updates on Ethernet circuits. When this timer expires before a
routing update occurs, a routine update is forced.
with a
standard calculation, Routing a-so uses this timer to enforce a
minimum delay between routing updates.
Seconds is a decimal
integer in the range 1-65535.
BUFFER SIZE bytes
This parameter value determines tr-e maximum size of a Routing
message.
It therefore determines the maximum size message that
can be forwarded. The size is a decimal integer in the range
1-65535.
This size is in bytes. This size includes protocol
overhead down to and including the End Communication layer, plus
his value of 6 is included to provide
a constant value of 6.
compatibility with the parameter definition in Phase 1 1 1 , which
included the Routing overhead.) It does not include Routing or
Data link overhead (except for the constant value of 6).
There
is one buffer size for all circuits.
NOTE
The BUFFER SIZE defines tne maximum size messages
that the outing layer can forward. The SEGMENT
BUFFER SIZE (defined below) defines the maximum
size messages that the End Communication layer
can transmit or receive. The SEGMENT BUFFER SIZE
is always less than or equal to the BUFFER SIZE.
Normally the two parameters will be equal.
They
may be different to allow the network manager to
alter buffer sizes
on
all
nodes
without
interruption of service.
They both include an
extra 6 bytes for compatibility with Phase 1 1 1 .
CIRCUIT circuit-id
This read-only parameter identifies the circuit used to get to
remote node. Circuit-id is an id-string.

This parameter can be used when displaying a list of nodes to
indicate that the display is to be restricted to those nodes
adjacent on the specified circuit.
COST cost
This read-only parameter represents the total cost over the
current path to the destination node. Cost is a positive integer
value associated with using a circuit. Routing routes messages
(data) along the path between two nodes with the smallest cost.

Network Management as Seen by the User

Page 33

COST is kept on a remote node basis.
HOPS hops
This read-only parameter represents the number of hops over to a
destination node.
A hop is Routing value representing the
logical distance between two nodes in a network. HOPS is kept on
a remote node basis.
MAXIMUM ADDRESS number
This value represents the largest node number and, therefore,
number of nodes that can be known about by the executor node's
home area. The number is an integer in the range 1-1023.
MAXIMUM AREA number
This value represents the largest area number and, therefore,
number of areas that can be known about by the executor node's
Routing. This parameter is only aoplicable if the executor node
is of type AREA. The number is an integer in the range 1-63.
MAXIMUM BROADCAST NONROUTERS number
This value represents the maximum rota1 number of nonrouters the
executor node can have on its Ethernet circuits. The number is
an integer in the range 0-65535.
MAXIMUM BROADCAST ROUTERS number
This value represents the maximum :otal number of routers the
executor node can have on its Et-iernet circuits. The number is
an integer in the range 0-65535.
MAXIMUM BUFFERS number
This value represents the maximum number of transmit buffers that
Routing may use for all circuits.
The number is a decimal
integer in the range 1-65535.
MAXIMUM CIRCUITS number
This value represents the maximum number of outing circuits that
the executor node can know about. The number is decimal in the
range 1-65535.
MAXIMUM COST number
This value represents the maximum total path cost allowed from
the executor to any node within an area. The path cost is the
sum of the circuit costs along a path between two nodes.
This
parameter defines the point where the executor node's Routing
routing decision algorithm declares another node unreachable
because the cost of the least costly path to the other node is
excessive. For correct operation, this parameter must not be

Network Management as Seen by the User
less than the maximum path cost of the network.
number is decimal in the range 1-1C22.

Page 34
The MAXIMUM COST

MAXIMUM HOPS number
This value represents the maximum number of routing
hops
allowable from the executor to any other reachable node within an
area. ( A hop is the logical distance over a circuit between two
adjacent nodes.) This parameter defines the point where the
executor node's Routing routing decision algorithm declares
another node unreachable because tne length of the shortest path
between the two nodes is too long. For correct operation, this
he
parameter must not be less than the network diameter.
network diameter is the reachability distance between the two
nodes of the network having the greatest reachability distance,
where reachability distance is the length of the shortest path
between a given pair of nodes.) The MAXIMUM HOPS number is
decimal in the range 1-30.
MAXIMUM VISITS number
This value represents the maximum number of nodes a message
coming into the executor node car. have visited. If the message
is not for this node and the MAXIMUM VISITS number is exceeded,
the message is discarded. The MAXIMUM VISITS parameter defines
the point where the packet lifetime control algorithm discards a
packet that has traversed too many nodes. For correct operation,
this parameter must not be less than the maximum path length of
the network.
(The maximum path length is the routing distance
between the two nodes of the networn having the greatest routing
distance, where routing distance is the length of the least
costly path between a given pair of nodes.) The MAXIMUM VISITS
number is decimal in the range MAXIMUM HOPS to 63.
NEXT NODE node-id
This read-only value indicates the next node on the circuit

used

to get to t h e node under scrutiny.

ROUTING TIMER seconds
This value determines the maximum time allowed between Routing
updates on non-Ethernet circuits. When this timer expires before
a routing update occurs, a routing update is forced. Seconds is
a decimal integer in the range 1-65535.
ROUTING VERSION n.n.n
This read-only parameter identifies the executor node's Routing
version number.
The format is the same as for the Network
Management version number.
SEGMENT BUFFER SIZE bytes

This parameter value determines the maximum size of an end-to-end

Network Management as Seen by the User

Page 35

segment.
The size is a decimal integer in the range 1-65535.
This size is in bytes. This size includes protocol overhead down
to and including the End Communication layer, plus a constant
value of 6.
his value of 6 is included to provide
compatibility with the BUFFER SIZE parameter definition.) It
does not include Routing or Data link overhead (except for the
co'nstant value of 6). See additional note for BUFFER SIZE.
SUBADDRESSES subaddress-range
This parameter is the range of local DTE subaddresses that are
acceptable
on
any
X.25
circuit
for an incoming call.
Subaddress-range consists of either a single subaddress or two
subaddresses separated by only a hyphen.
A subaddress is a
I f two subaddresses are
decimal integer in the range 0-9999.
provided, the second must be greater than the first.
TYPE node-type
This parameter indicates the type of
node-type is one of the following:

the

executor

node.

The

ROUTING I 1 1
NONROUTING I 1 1
ROUTING IV
NONROUTING IV
AREA
A routing node has full routing capability.
A nonrouting node
contains a subset of the Routing routing modules. The I 1 1 and IV
indicate the DNA phase of the node. Nonroutinq nodes can deliver
and receive packets to and from any node, but cannot route
packets frorh other nodes through to other nodes.
An area node
routes between areas.
Refer to the Routing specification for
details.
For adjacent nodes, this is a read-only parameter that
the type of the reachable adjacent node.

3.1.2

indicates

Node Counters

Network Management displays or zeroes node counters as a
following Network Management counter is kept for nodes:

group.

Seconds since last zeroed
The following End Communication counters are kept for nodes:
User bytes received
User bytes sent
User messages received
User messages sent
Total bytes received

The

Page 36

Network Management as Seen by the User
Total bytes sent
Total messages received
Total messages sent
Connects received
Connects sent
Response timeouts
Received connect resource errors
Maximum logical links active (executor only)
The following Routing counters are kept for the executor node:
Aged packet loss
Node unreachable packet loss
Node out-of-range packet loss
Oversized packet loss
Packet format error
Partial routing update loss
Verification reject
Refer to the relevant soecifications for further
type of information counted.

3.2

exolanation

the

Areas

An area is a group of nodes. The network manager groups nodes for
hierarchical routing purposes. ( ~ e f e rto the Routing spec ification.)
The user can identify areas in two major vays:
individually and in
groups.
To identify an area individually, use the area number. An
area number is a decimal integer in the range 1-63.
By convention,
Area "1" is used to designate a single area network and Area "0" is
used when communicating with a Phase I 1 1 node.
Area group identifications are as follows:
ACTIVE AREAS

All areas that the executor perceives Routing
reach.

KNOWN AREAS

Same as ACTIVE AREAS.

All of the area parameters are owned by the routing layer and
follows:

can

are

This read-only parameter identifies the circuit used to get to
remote area. Circuit-id is an id-string.

CIRCUIT circuit-id

COST cost
This read-only parameter represents the total cost over the
current path to the destination area. Cost is a positive integer

Network Management as Seen by the User

Page 37

value associated with using a circuit. Routing routes messages
(data) along the path between two areas with the smallest cost.
HOPS hops
This read-only parameter represents tne number of hops over to a
area.
A hop is Routing value representing the
logical distance between two areas in a network.

destination

NEXT NODE node-id
This read-only value indicates the next node on the circuit
to get to the area under scrutiny.

used

STATE state
This read-only value indicates the
REACHABLE, or UNREACHABLE.

3.3

state

the

area,

either

Logging

Logging is the Network Management automatic event-recording mechanism.
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:
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

SIGNIFICANT LOGGING All known sink types that have significant
information for display purposes.
A sink type is one of the following:

CONSOLE
FILE
MONITOR
Network Management sends information about logged events to sink
nodes.
The user establishes sink nodes with NCP commands. Sink node
identification is as follows:
SINK NODE node-identification
or
SINK EXECUTOR

Network Management as Seen by the User

Page 38

The default sink-node is the executor node.

3.3.1

Source Qualifiers

Events occur at logging sources. Since logging for a specific entity
can be different from logging for that entity as a group, the user can
specify that specific sources be logged by using the source-qualifier
option. Source-qualifier can be one of the following:
AREA area-id
CIRCUIT circuit-id
LINE line-id
MODULE module-id
NODE node-id

Refer to Sections 3.1, 3.4, 3.5, and 3.7 for descriptions of
circuit-id, line-id, and module-id.

3.3.2

node-id,

Logging Parameters

All the logging parameters are owned by the Network Management
These parameters are as follows:

layer.

EVENTS event-list
This set of values indicates the types and classes of events to
be recorded at the sink-node. Tables 22 and 23, Section 7.12,
specify event classes and types. Event-list consists of event
class.event type(s).
The types are specified in ranges using
hyphens, in lists using commas, or a combination of both.
Examples of event-lists are:

wild card notation indicates all types of events for a particular
class. For example,

The keywords KNOWN EVENTS can replace EVENTS event-list in NCP
commands.
KNOWN EVENTS imply all events known to the executor
node for the specified sink node and source.
If no source is
specified, source specific events are not affected.
NAME sink-name
This is the identification of the executor node's logging sink.
Sink-name has one of three forms depending on the sink-type:

Page 39

Network Management as Seen by the User

device-id
f ile-id
process-id

CONSOLE
FILE
MONI TOR

The sink name
understands.

format

depends

what

the

executor

system

SINK NODE node-id
This parameter identifies the sink node to which the other
parameters in a command or response apply. The default sink node
is the executor. Node-id is either a rode name or a node address
(Section 3.1).
STATE sink-state
This value indicates the executor node's logging state
sink type. The possible values of sink-state are:

the

The sink is available for receiving events.

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.

There are no
parameters.

3.4

for

logging

counters.

Section

describes

3.8

event

Circuits

Circuits are logical communications paths providing communications
between adjacent nodes.
A circuit may be identical to a physical
link, multiplexed with many other circuits, and/or traffic split over
multiple physical links.
Circuit identification is a circuit name with the format of an
id-string.
Network Management keeps a master list of circuit names,
ensuring their uniqueness for the Data Link layer.
Circuits can be identified in groups as follows:
KNOWN CIRCUITS - All circuits that have a name.
ACTIVE CIRCUITS - All circuits in the ON or SERVICE state.
SIGNIFICANT CIRCUITS parameter.
A circuit can have an owner.

All

circuits

that

have

This means that the circuit is

least

one

reserved

Network Management as Seen by the User

Page 40

for the exclusive use of the owner. For example, the owner may be the
executor node (Routing) or some other network component.
Whether or not it has an owner, a circuit has a user whenever it is
open for use through the mechanisms of the Data Link interface. User
in this sense is a network component, not a person.
Currently, the
user can be either the owner or the X.25 protocol module.
When Network Management uses a circuit, the user's rights are
overridden.
For example, Network Management must take over the
circuit to execute such service functions as down-line loading and
loop
testing.
When Network Management finishes its prescribed
function, the circuit is returned to the user.

3.4.1

Circuit Parameters

There are five groups of circuit parameters:
1.

Common circuit parameters -- These are parameters common to
all circuits (Refer to the section entitled Common Circuit
Parameters).

Executor node circuit parameters - - These are parameters that
apply only to circuits whose owner is the executor node.
( ~ e f e r to the section entitled Executor
Node
Circuit
Parameters.)

DDCMP circuit parameters - - These are parameters that apply
to DDCMP circuits only. (Refer to ihe section entitled DDCMP
Circuit Parameters.)

X . 2 5 circuit parameters - - These

circuits only
Parameters.)
5.

3.4.1.1

(Refer

parameters apply to X . 2 5
the section entitled X . 2 5 Circuit

Ethernet circuit parameters - - These parameters apply to
Ethernet
circuits only (Refer to the section entitled
Ethernet Circuit Parameters.)

Common Circuit Parameters

The following parameters are common to all circuits:
COUNTER TIMER seconds
This value represents the number of seconds
the
Network
Management counter timer will run. The expiration of the counter
timer causes a circuit counter logging event.
The types of
counters
logged depends on the circuit protocol.
Circuit
counters are described in Section 3.4.2.
The circuit counters

Network Management as Seen by the User

Page 41

are recorded as data in a logging event and then zeroed. If no
counter timer value is set, the circuit's counters are not
automatically logged. Seconds is a decimal integer in the range
1-65535.

OWNER owner-id
This value identifies the circuit owner.
Except for overrides
through Network Management, the owner has exclusive rights to use
the circuit. If no owner value is set, "he circuit is available
on a first-come, first-served basis.
To use a circuit, the owner must open it according to the rules
of the particular Data Link interface. Ownership of a circuit
has no implication as to whether the circuit is actively open by
its owner or any other process. Sexting the OWNER parameter
merely reserves the circuit.
An owner-id consists of an entity type and entity identification.
The executor node can be owner of any circuit. This implies that
the circuit is actually reserved the DECnet routing module.
Ethernet circuits can be owned by MODULE LOOPER, CONSOLE, or
LOADER. These are circuits over which t-ie management module can
perform such management functions as loop tests or down-line
loads.
From the standpoint of Network Management, Ethernet circuits
automatically take on the proper Ethernet protocol types and
multicast addresses according to their owner's requirements.
STATE circuit-state
This value
represents
the
circuit's
Network
Management
operational state as described in the state and substate model
presented in Section 3.6.
SUBSTATE
This is the circuit's
Section 3.6).

read-only

Network

Management

substate

TYPE circuit-type
This value represents the type of the circuit.
For X.25
circuits, the value must be set to X25. For DDCMP and Ethernet
circuits it is read only and is the same value as the protocol of
the associated line (see PROTOCOL in section entitled Common Line
Parameters).
USER user-id
This is the read-only identification of the active user of the
circuit.
It tells the network manager what module is using the
circuit.

Network Management as Seen by the User

Page 42

In the case of a circuit with an owner, the user is the owner,
but only when the owner has the circuit open. In the case of a
circuit with no owner, the user is the network component that
opened the circuit.
A user-id consists of an entity type and entity identification.
The only user-ids currently defined are EXECUTOR and MODULES
X25-SERVER, LOOPER, LOADER, CONSOLE, and CONFIGURATOR.

3.4.1.2

Executor Node Circuit Parameters

The following parameters apply to
executor node:

circuits

that

are

owned

the

ADJACENT NODE node- id
This read-only value indicates an adjacent node on the circuit.
For Ethernet circuits there can be many adjacent nodes. This
parameter can be used when displaying a list of circuits to
indicate that the display is to be restricted to those circuits
leading to the specified adjacent node.
BLOCK SIZE byte-count
This read-only parameter is the block size that was negotiated
with the adjacent Routing layer during Routing initialization
over a particular circuit. It includes the routing header, but
excludes the data link header. This parameter is qualified by
ADJACENT NODE.
COST cost
This value represents the Routing routing cost of the circuit.
The cost is a decimal integer in the range 1-25. Routing routes
messages along the path between two nodes having the smallest
cost.
HELLO TIMER seconds
This value determines the frequency of Routing Hello messages
sent to the adjacent node on the circuit. Seconds is a decimal
integer in the range 1-8191.
LISTEN TIMER seconds
This read-only value determines the maximum time allowed to
elapse before Routing receives some message (either a Hello
message or a user message) from the adjacent node on the circuit.
It was agreed during Routing initialization with the adjacent
Routing layer.
Seconds is a decimal integer in the range
his parameter is qualified by ADJACENT NODE.
1-65535.
LOOPBACK NAME node-name

Page 43

Network Management as Seen by the User

This parameter is the Session Control node name associated with a
circuit as a result of the "SET NODE node-id CIRCUIT circuit-id"
command. From the circuit standpoint, this is a read-only
parameter.
ORIGINATING QUEUE LIMIT queue-size
This parameter indicates the maximum number of originating
packets that may be outstanding on this circuit. This does not
include route-thru traffic.
RECALL TIMER seconds
This parameter represents the minimum number of seconds to wait
before restarting the circuit. If no value is set, there is no
wait. Seconds is a decimal integer in the range 1-65535.

3.4.1.3

DDCMP Circuit Parameters

DDCMP circuits support the Network Management service
dump, load, and active and passive circuit -0opback.
parameters apply to DDCMP circuits:

functions of
The following

LINE line-id
This value is the Data Link layer identification of the line that
is to be used for traffic on the circuit. Line-id is a line name
(Section 3.5).
SERVICE service-control
This value indicates whether or not Network Management allows
service operations on a circuit. The values for service-control
are as follows:
ENABLED

SERVICE state
allowed.

and/or

DISABLED

SERVICE state and/or
a1 lowed.

service
service

functions

are

are
not

TRIBUTARY tributary-address
This value represents the Data Link physical tributary address of
the circuit.
The tributary address is a decimal integer in the
range 1-255.
The following parameters apply to DDCMP CONTROL circuits.
In those
cases where a value is specified in milliseconds, there is no
assumption that all implementations can provide such fine resolution.
ACTIVE/INACTIVE/DYING BASE base

Network Management as Seen by the User

Page 44

This value represents the base priority to which a tributary is
reset each time it has been polled. A separate base can be set
for each of the indicated polling states.
Base is a decimal
integer in the range 0-255.
If not set, the defaults are:
active, 255; inactive, 0; and dying, 0.
ACTIVE/INACTIVE/DYING

INCREMENT increment

This value represents the increment added to the tributary
priority each time the scheduling timer expires. Increment is a
decimal integer in the range 0-255. If not set, the defaults
are: active, 0; inactive, 64; and dying, -6.
BABBLE TIMER milliseconds
This value represents the number of milliseconds that a selected
tributary or remote half-duplex station is allowed to transmit.
Milliseconds is a decimal integer in the range 1-65535.
If not
set, the default is 6000 (6 seconds).
DEAD THRESHOLD count
This value represents the number of times to poll the active,
inactive, or dying tributary before changing its polling state to
dead because of receive timeouts. Count is a decimal integer in
the range 0-255. If not set, the default 1s 8.
DYING THRESHOLD count
This value represents the number of times 10 poll the active or
inactive tributary before changing its polling state to dying
because of receive timeouts. Count is a decimal integer in the
range 0-255. If not set, the default is 2.
INACTIVE THRESHOLD count
This value represents the number of times to poll the active
tributary before changing its polling state to inactive because
of no data response. Count is a decimal integer in the range
0-255. I f not set, the default is 8.
MAXIMUM BUFFERS count
This value represents the maximum number of buffers the tributary
can use from a common buffer pool. If not set, there is no
common buffer pool and buffers are explicitly supplied by the
higher level.
Count is a decimal integer in the range 1-254 or
the keyword UNLIMITED.
MAXIMUM TRANSMIT count
This value represents the maximum number of data messages that
can be transmitted at one time. Count is a decimal integer in
the range 1-255. If not set, the default is 4.

Page 46

Network Management as Seen by the User

USAGE usage-type
This Data ink parameter defines the usaae type
circuit. The usage-type values are as follows:

X.25

INCOMING

Used only for switched incoming calls. Useful only for
circuits that are owned by the executor node.

OUTGOING

Used only for switched outgoing calls. Useful only for
circuits that are owned by the executor node.

PERMANENT Permanently connected to the same remote station,
does not need to be dynamically switched.

and

BLOCKING blocking-control
This parameter applies to X.25 circuits that are owned by the
executor node.
The value indicates whether or not outing will
block messages before they are sent over the circuit. The values
for blocking-control are as follows:
ENABLED

Perform blocking as possible.

DISABLED

No blocking.

NUMBER call-number
This parameter applies to either incoming or outgoing X.25
circuits that are owned by the executor node.
The value
represents the Routing full remote DTE address used to receive
calls and to call out on the circuit. Call-number is a decimal
integer of one to sixteen digits.
MAXIMUM RECALLS retry-count
This parameter applies to outgoing X.25 circuits that are owned
by the executor node. The value represents the maximum number of
Routing automatic call retries. Retry-count is a decimal integer
in the range 0-255. I f no value is set, there is no maximum.
CHANNEL channel-number
This parameter is the Data Link X.25 logical channel number to be
used in running the X.25 protocol on the circuit. This applies
A channel-number is a decimal
only to permanent circuits.
integer in the range 0-4095.
DTE dte-address
This parameter is the Data Link X.25 local DTE address to which
his applies only to permanent circuits.
the circuit belongs.
Dte-address is a decimal integer of one to sixteen digits.

Network Management as Seen by the User

Page 47

CONNECTED NODE node-id
This parameter is the read-only Application module identification
of the node on which the DECnet object using the circuit resides.
Node-id is a standard Network Management node identification
(section 3.1).
This parameter applies only to permanent X.25
circuits being used by module X25-SERVER.
CONNECTED OBJECT object-id
This parameter applies only to permanent X.25 circuits being used
by module X25-SERVER.
The read-only Application module value
identifies the DECnet object usinq the circuit. Object-id is as
described for module X25-SERVER.

3.4.1.5

Ethernet Circuit Parameters

Ethernet circuits support all of the Network Management service
functions through circuits that are owned by MODULE LOOPER, CONSOLE,
or LOADER. The following parameters apply to Ethernet circuits:
DESIGNATED ROUTER node-id
This read-only value is the Routing layer identification of the
node that is to be used for routing on circuits that are owned by
the executor node.
LINE line-id
This value is the Data Link layer identification of the line that
is to be used for traffic on the circuit. Line-id is a line name
(section 3.5).
MAXIMUM ROUTERS number
This parameter is the maximum number of routers (other than the
executor itself) allowed on the circuit by Routing for circuits
that are owned by the executor node. Number is a decimal integer
in the range 0-255.
ROUTER PRIORITY number
This parameter is the priority that this router is to have in the
selection of designated router for the circuit on circuits that
are owned by the executor node. Number is a decimal integer in
the range 0-127. The default value is 64.
SERVICE PHYSICAL ADDRESS ethernet-address
This parameter indicates the Ethernet physical address of an
adjacent node that is being serviced on this circuit. This
parameter is a qualifier for SERVICE SUBSTATE.

Page 48

Network Management as Seen by the User
SERVICE SUBSTATE

This is the circuit's read-only Network Management substate
(Section 3.6). It identifies the kind of service being performed
on the circuit. This parameter is qualified o y SERVICE PHYSICAL
ADDRESS.

3.4.2

Circuit Counters

Network Management displays or zeroes counters as a group when the
executor node
outing) owns the circuit.
Tne following Network
Management counter is kept for circuits:
Seconds since last zeroed
The following Routing counters are kept for all circuits:
Terminating packets received
Originating packets sent
Terminating congestion loss
Transit packets received
Transit packets sent
Transit congestion loss
Circuit down
Ad j acency down
Initialization failure
The following Data Link counters are kept for DDCMP circuits:
Bytes received
Bytes sent
Data blocks received
Data blocks sent
Data errors inbound
Data e r r o r s o u t b o u n d

Remote reply timeouts
Local reply timeouts
Remote buffer errors
Local buffer errors
Selection intervals elapsed
Selection timeouts
The following Routing counter is kept for X.25 circuits:
Corruption loss
The following Data
circuit:

Link

Bytes received
Bytes sent
Data blocks received
Data blocks sent

counters

are

kept

for

permanent

X.25

Page 49

Network Management as Seen by the User
Locally initiated resets
Remotely initiated resets
Network initiated resets

The following Data Link counters are kept for Ethernet circuits:
Bytes received
Bytes sent
Data blocks received
Data blocks sent
User buffer unavailable

3.5

Lines

Lines are the lowest level communications path.
Lines provide
physical communications.
Lines are the media over which circuits
operate.
A line is identified individually with a line name.
The Data Link
layer contains the master list of line names and ensures their
uniqueness. A line name is an id-string.
Group line identifications are as follows:
ACTIVE LINES - All lines that are in the ON or SERVICE state.
KNOWN LINES - All lines that have a name.
SIGNIFICANT LINES - All
parameter.

known

lines

that

have

least

one

Many line parameters,
counters,
and
events
depend
on
the
communications protocol being used for a particular line. There are
currently three protocols: DDCMP, LAPB, and Ethernet. DDCMP is for
DECnet communications. LAPB is for DECnet and/or X.25 communications.
Ethernet is for DECnet or Ethernet communications.

3.5.1

Line Parameters

There are five groups of line parameters:
1.

Common line parameters (Section 3.5.1.1)

Non-Ethernet line parameters (Section 3.5.1.2)

DDCMP line parameters (Section 3.5.1.3)

LAPB line parameters (Section 3.5.1.4)

Page 50

Network Management as Seen by the User
5.

3.5.1.1

Ethernet line parameters (Section 3.5.1.5)

Common Line Parameters

The following parameters are common to all lines:
COUNTER TIMER seconds
This value represents the Network Management
timer
whose
expiration causes a line counter logging event. The counters
logged depend on the line protocol and are described elsewhere.
The line counters are recorded as data in a logging event and
then zeroed. If no counter timer value is set, the line's
counters are not automatically logged.
Seconds is a decimal
integer in the range 1-65535.
&

DEVICE device-specification
This value represents the Physical Link device to be used on
line. A device-specification contains the following:
dev

A device mnemonic

A controller number

the

able 10, Section 7.4)

unit number

These fields represent the actual local hardware for the device.
If the device is not a multiple line controller, the unit number
is not allowed. The device-specification is an id-string in the
following format:
dev-c

dev-c-u
PROTOCOL protocol-name
This value represents the Data Link protocol to be
line. The protocol-name values are as follows:

used

the

DDCMP CONTROL
This line is the control station for a DDCMP multipoint
group.
It can be the line for multiple circuits, each of
which has a unique physical tributary address.
DDCMP DMC
This line is in DMC emulator node.

Page 51

Network Management as Seen by the User
DDCMP POINT
This line is one end of a point-to-point
It can be the line for only one circuit.

DDCMP

connection.

DDCMP TRI BUTARY
This line is a tributary end of a DDCMP
It can be the line for only one circuit.

multipoint

group.

LAPB
This line uses the X.25 level 2 protocol and can be
for the X25-PROTOCOL module.

line

ETHERNET
This line uses the Ethernet protocol for the Ethernet.
RECEIVE BUFFERS number
This value represents the number of receive buffers reserved
the line. It is a decimal number in the range l-65535.

for

STATE line-state
This value represents Network Management operational state
described in the state and substate model in Section 3.6.

Substate
This value represents the line's read-only
substate as described in Section 3.6.

3.5.1.2

Network

Management

Non-Ethernet Line Parameters

The following parameters are common to all non-Ethernet lines:
CLOCK clock-mode
This value represents the Physical Link hardware clock
the line device. The values for clock-mode are:

mode

for

INTERNAL

For software controllable loopback use of the clock.
On those devices that can support this mode, it causes
the device to supply a clock signal such that all
transmitted messages can be looped back from outside
the device. This may require manual intervention other
than the setting of this parameter value. For example,
the operator may have to connect a loopback plug in
place of the normal line.

EXTERNAL

For normal clock operating mode, where the clock signal

Network Management as Seen by the User

Page 52

is supplied externally to the controller.
CONTROLLER controller-mode
This value represents the Physical Link hardware controller
for the line device. The values for controller-mode are:

mode

LOOPBACK

For software controllable loopback o f the controller.
On those devices that can support this mode, it causes
all transmitted messages to be looped 3ack from within
the controller itself.
This is acc~mplishedwithout
any manual intervention other than the setting of this
parameter value.

NORMAL

For normal controller operating mode.

DUPLEX duplex-mode
This value represents the Physical Link hardware duplex
the line device. The possible modes are:
FULL

Full-duplex

HALF

Half-duplex

mode

RETRANSMIT TIMER milliseconds
This value represents the amount of time before the Data Link
retransmits a block on the line. On half-duplex lines, this
parameter is the select timer. Milliseconds is a decimal integer
in the range 1-65535.
I f not set, the default is 3000 (3
seconds)

3.5.1.3

DDCMP Line Parameters

DDCMP lines support the Network Management service functions of dump,
load, and active and passive line loopback. The following parameter
applies to DDCMP lines:
SERVICE TIMER milliseconds
This value represents the amount of time allowed to elapse before
a Data Link receive request completes while doing service
operations. Milliseconds is a decimal integer in the range
1-65535.
The following parameters apply to DDCMP CONTROL lines:
DEAD TIMER milliseconds
This value represents the number of milliseconds between polls of
one of the set of dead tributaries. Milliseconds is a decimal
integer in the range 1-65535. I f not set, the default is 10000

Network Management as Seen by the User

Page 53

(10 seconds).
DELAY TIMER milliseconds
This value represents the minimum number of milliseconds to delay
between polls. The delay timer limits the effect of a very fast
control station on slow tributaries. Milliseconas is a decimal
integer in the range 1-65535. If not set, there is no delay.
SCHEDULING TIMER milliseconds
This value re~resents the number of
milliseconds
between
recalculation of tributary polling priorities. Milliseconds is a
decimal integer in the range 50-65535. If not set, the default
is 200.
STREAM TIMER milliseconds
This value represents the number of milliseconds a tributary or a
half
duplex remote station is allowed to hold the line.
Milliseconds is a decimal integer in the range 0-65535.
If not
set, the default is 6000 (6 seconds).
NOTE
This parameter~,canalso be applied to
half-duplex lines of type DDCMP POINT.

3.5.1.4

LAPB Line Parameters

LAPB lines support the Network Management service function of active
loop.
The following parameters apply to lines using the LAPB
protocol:
HOLDBACK TIMER milliseconds
This parameter defines the length of time
a
Data
Link
acknowledgment can be held back to wait for a chance to
piggy-back on a data message. I f no value is set, no holdback is
allowed. Milliseconds is a decimal integer in the range 1-65535.
MAXIMUM BLOCK byte-count
This value represents the Data Link maximum block size on
line. Byte-count is a decimal integer in the range 1-65535.

the

MAXIMUM RETRANSMITS block-count
This value represents the maximum number of Data Link retransmits
of a block on the line. If no value is set, there is no maximum.
Block-count is a decimal integer in the range 1-255.

Network Management as Seen by the User

Page 54

MAXIMUM WINDOW block-count
This value represents the Data
Link
maximum
number
of
unacknowledged transmitted blocks on the line. Block c ~ u n tis a
decimal integer in the range 1-255.
SERVICE service-control
This value indicates whether or not Network Management service
operations (loading, dumping, loopback testing) are allowed for
the line. The service-control values are as follows:
ENABLED

SERVICE state and/or service functions are allowed.

DISABLED

SERVICE state and/or service functions are not allowed.

3.5.1.5

Ethernet Line Parameters

Ethernet lines do not support any Network
Management
service
functions. The following parameters apply to lines using the Ethernet
protocol:
HARDWARE ADDRESS ethernet-address
This read-only parameter is the Ethernet address associated
the line device hardware.

3.5.2

with

Line Counters

Network management displays or zeroes line counters pertaining to a
particular line as a group. Some line counters are specific to DDCMP
lines, some to LAPB lines, and some to Ethernet lines. The following
Network Management counter is kept for lines:
Seconds since last zeroed
The following Data Link counters are kept for DDCMP lines:
Remote station errors
Local station errors
The following Data Link counters are kept for an LAPB line:
Bytes received
Bytes sent
Data blocks received
Data blocks sent
Data errors inbound
Data errors outbound
Remote reply timeouts
Local reply timeouts

Network Management as Seen by the User

Page 55

Remote buffer errors
Local buffer errors
Remote process errors
Local process errors
The following Data Link counters are kept for an Ethernet 1:ne:
Bytes received
Bytes sent
Data blocks received
Data blocks sent
Multicast bytes received
Multicast data blocks received
Data blocks sentl initially deferred
Data blocks sentl single collision
Data blocks sentl multiple col~isions
Send failure
Collision detect check failure
Receive failure
unrecognized frame destination
Data overrun
System buffer unavailable
User buffer unavailable

3.6

Circuit and Line State and Substate Model

This section describes the Network Management state ana substate
model.
This model applies to both circuits and linesl referred to
generically as links.
There is one model for the relationships
between the states and substates. This model is applied inaependently
to both circuits and lines. In other wordsl all of the states and
substates that apply to circuits apply equally and independently to
lines. Note that this is an architectural model and the functions and
states that can be applied to a particular circuit or line will vary
depending upon the Data Link protocol and the actual implementation.
In the following discussion of the modell the term link is used to
include either circuit or line. This Network Management function is
called Data Link Service ,to include both circuits and lines.
There are three internal state machines that are of interestl one each
for the high level user's internal view of a linkl the Data Link
protocol's exhibited view of a linkl and the Network Management Data
Link Service view of a link. These state machines are first presented
independently. They are then related to one another through the
externally visible states and substates.
The purpose of these state machines is to define the Network
Management
abstractions
for
the
operation
of links.
These
abstractions can represent any high level user or low level Data Linkl
within the bounds of the functions actually provided by that module.
A mapping of the Network Management link state machines to actual
internal states of other architectural components is in Appendix C.

Network Management as Seen by the User

Page 56

Operation of various algorithms on circuits and lines
differs
according to how maintenance traffic is handled within their data link
DDCMP and L A P B )
protocol.
In some data link protocols (i.e.
maintenance traffic is exclusive of normal traffic and vice versa.
The link is either in normal mode or maintenance mode.
In others
(i.e.
Ethernet) maintenance traffic is completely independent of
normal traffic and thus can occur concurrently. Whenever this makes a
difference in the remainder of this specification, these will be
referred to as exclusive maintenance or concurrent maintenance links,
respectively.

High Level Link User States

3.6.i

In the case of a circuit, the hiqh level user is either the circuit
owner for a circuit that has an owner or the current user for an
opened circuit that does not have an owner.
For a line, the high
level user is the Data Link protocol module. The state machine
presented here models the Network Management view of the high level
user.
The user's internal operation may actually be different, but
Network Management must be able to view it essentially according to
this model.
The high level user internally considers the link as being in
four states:

one

Off - - the link is not to be used.

Start - the link is to be or is being initialized.
This
includes both the low level going to run state and any
initialization needed by the hiqh level.

Fail -- the link startup process failed permanently.
state may not exist in some high level users.

Run - - the link is in normal running state.

Figure 3 shows the states and the allowed transitions.

This

Page 57

Network Management as Seen by the User

- - - ->

Network Management Command

---- >

Protocol Operation

figure 3.

High Level Link User State Diagram

Taole 1 defines the state transitions and the events that cause them.
Network Management commands are represented by the phrase "SET STATE
state" where state is the controllable state. A hyphen indicates no
change of state, N/A indicates Not Allowed (impossible).
Table 1
High Level Link State Transitions and Their Causes
Off

Start

Fail

Run

SET STATE OFF

Off

SET STATE ON

Start

SET STATE SERVICE

Off

Startup successful

N/A

Run

N/ A

Startup failed

N/A

*Fail

N/ A

Lower level left run state

N/ A

N/A

Start

Event

Old State

* This transition takes place according to the user's algorithms or
not at all if not supported by the user.

Network Management as Seen by the User
3.6.2

Page 58

Data Link States

The Data Link states are those exhibited for any higher level user.
The actual internal states may differ according to the particular Data
Link protocol, but Network Management and the high level user must be
able to perceive them as described here.
Data Link exhibits the link as being in one of four states.
In this
context, Data Link means a lower level perception of the link, since
in the case of a line the high level user is actually part of Data
Link. the low level Data Link states are:
1.

Off -- the link is not to be used.

Synch -- the link is to be or is being initialized.

Maint -- the link is to be used for maintenance purposes.
This state only applies to exclusive maintenance links.

Run -- the link is in normal running state.

Figure 4 shows the states and the allowed transitions.

Page 59

Network Management as Seen by the User

- - - - - - - I ---

------ - - - -

I
I
I
I
I
I1
I
I<+++++++++.
---------------> I
1
OFF
SYNCH
1
+
.--> I
I i
. O O O O O O O ~ O O I- ~
+ + + .
+
I
I ------ - - - - l
o
I
I
+
+
l
o
+---0---.---I
+
+
I
1
A 1
0
+
o
1
+
+
I
I I
l
o
+
0
I
+
+
1
I I
l
o
+
0
I
+
+
I
I I
l
o
+
0
I
+
+
I
I I
l o
+
0
I
+
+
I
I I
l
o
+
0
I
+
+
I
I I
l
o
+
0
I
+
+
I
I I
l
o
+
0
I
+
+
I
I I
l
o
+
0
I
+
+
I
I I
l
o
v
0
I
v
+
-------+--- - - - 0-----.
I
I I
0
I
I
I
I < -00000000
I
I
I
I I
1<-------------'
1
I
I
>I
I
1
1
1
MAINT
1
1
RUN
1-------- I
I
I
I
I
I
I
I
I
I
-----------_+-- - - 0I
1
A
A
A
+ I
0
I
I
I
+
+ I
0
'----

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

--->

Network Management Command

00->

Network Management Operation

+++>

Protocol Operation

Figure 4.

Data Link State ~ i a g r a m

Network Management as Seen by the User

Page 60

Table 2 defines the Data Link state transitions and the events that
cause them. Network Management commands are represented by the phrase
'SET STATE state" where state is the controllable state.
A hyphen
indicates no change of state, N/A indicates Not Allowed (impossible).
Table 2
Data Link State Transitions and Their Causes
Event

Old State

Off

Synch

Maint

Run

SET STATE OFF

Off

SET STATE ON

Synch

SET STATE SERVICE

Maint

*Set state ON-AUTOSERVICE

N/A

Maint

N/ A

Maint

*Reset ON-AUTOSERVICE state

N/A

N/ A

Synch

N/A

Data Link Service open

N/A

Maint

Data Link Service close

N/ A

N/A

**Synch

N/A

Maintenance message received

N/A

Maint

Synchronization successful

N/A

Run

N/ A

Synchronization lost

N/ A

N/A

Synch

* Controllable states for Link Watcher only.
* * If controllable state in ON, otherwise no change.
3.6.3

Network Management Data Link Service States

Network Management Data Link Service is the arbiter of link states,
maintaining
the
proper
relationships
as required by Network
Management. Data Link service maintains its own internal states for a
link according to the following description.
This discussion is directed only at exclusive maintenance links.
Concurrent maintenance links are either on or off, regardless of
whether they carry normal or maintenance traffic.
Furthermore, all
their maintenance functions are handled by the link maintenance
modules, which are dedicated to the processing of
maintenance
functions on the links that they own.
Network Management Data Link Service perceives the link

being

Page 61

Network Management as Seen by the User
one of seven states:
Off -- the link is not to be used.
Passive -- the link is in use by its user and
monitored by Network Management Data Link Service.

being

Passive open -- the link is temporarily in use for some
Network Management operation such as down-line load and is to
return to its user when done.
Reflecting -- the link is reflecting loopback messages and is
to return to its user when done.
Closed -- the link is reserved for
operation.
Open -- the
operation.

link

open

for

some
some

Network

Management

Network

Management

Closed reflecting - - the link is reflecting loopback messages
but is reserved for some Network Management operation on
demand.
Figure 5 shows the states and the allowed transitions.

Network Management as Seen by the User

1
I
1
1

.1 - > I

I
I
I

i i

- -----

I - - -

------ - --

- - - - - - - - - .<-I

Page 62

'-------_-I

-----

----

I
->,----------

1 ------ > 1
I <00000 I
1 PASSIVE IOOOOO>~ PASSIVE I<-----1 OPEN
1
I
1
I
1
*
=
=
=
=
I
I
I
I

I
I
I
I
----------

I<-.

l00000>

CLOSED

I<OOOOO~

1 ===

---------- 1

I,
I
I

.ll'---------- I
1 1

A
I\

OPEN

1
I

I
I

I
I
1

/I I \
I I/
0
\/
11
II
\/
0
11
0
I
.I .I - - - - - I
I
I=====
00
I
1
I
REFL. 1
I
CLOSED
1
------ 1
I---------------------------------> 1 REFL.
I ----- I
I
I<-------__----------_-----_----_-I ----------- I
~

I
I
I
I

0
0
0 .---------a
00

I I/

--->

Network Management Command

ooo>

Network Management Operation

--->

Protocol Operation

Figure 5.

Network Management Data Link Service State Diagram

Table 3 defines the state transitions and the events that cause them.
Network Management commands are represented by the phrase "SET STATE
state" where state is the controllable state. A hyphen indicates no
change of state, N/A indicates Not Allowed (i.e., impossible).
Table 3
Data Link Service State Transitions and Their Causes

Event

Off

Pass

Pass
Open

Refl

Clos

Clos
Open Refl

SET STATE OFF

Off

SET STATE ON

Pass

Pass Ref1

Off

Page 63

Network Management as Seen by the User
SET STATE SERVICE

Clos

Clos
Refl

Data Link Service open

N/A

Pass
Open

N/A

Pass
Open

Open

N/A

Open

Data LLnk Service close

N/A

Pass

N/A

Clos N/A

Loop message received

N/A

Ref1

N/A

Clos
Ref1

N/A

Communication failure
or non-maint message
received

N/A

Pass

N/A

Clos

3.6.4

Controllable and Observable States and Substates

This section shows the relationships between the three previously
defined state machines, and relates them to the states and substates
that can be controlled and observed through Network Management.
There are four link states that
Management.

can

controlled

through

Network

CLEARED - - Some space is reserved for the link, but no other
data bases or parameters for the link are present. The link
cannot be used in any way. If they exist, all three state
machines are in the off state.

OFF - - The link data bases and parameters are present, but
the link is not to be used by any network or network-related
software. The link is functionally non-existent. All three
state machines are in the off state.

ON - - The link is available to a high level user for normal
use, w i t h t h e exception of temporary overrides for service
functions. The high level user is in any state but off.
Data Link is in any state but off. Data Link Service is in
passive, passive open, or reflecting state.

SERVICE -- The link is reserved for the active service
functions:
load, d u m p , and loop.
The link can provide
passive loop if no active service function is in progress.
The high level user is in the off state. Data Link is in the
maint state. Data Link Service is in the closed, open, or
closed reflecting state.
This state does not apply to
concurrent maintenance links.

There is one additional state
Watcher:

that

can

requested

the

Link

ON-AUTOSERVICE -- The link is temporarily reserved for the active
It is to be returned to its high level user
service functions.

Network Management as Seen by the User

Page 64

when the Link Watcher is done. The hiqh level user is in the off
state. Data Link is in the maint state. Data Link Service is in
the closed state.
This state does not apply to concurrent
maintenance links.
There are fourteen substates that can be observed through Network
Management. These substates apply to the ON and SERVICE states unless
otherwise noted. OFF and CLEARED do not have substates.
The only
substates that apply to concurrent maintenance links are running and
FA1 LED.
1.

Running -- The link is in normal use by its high level user.
This is the default substate of ON. The high level user and
Data Link are in the run state. Data Link Service is in the
passive state.

Idle - - The link is not being used for anything. This is the
default substate of SERVICE. The high level user is in the
off state. Data Link is in the maint state.
Data Link
Service is in the closed state.

SYNCHRONIZING - - The link is engaged in low level Data Link
his is a substate of ON. The high level
synchronization.
user is in the start state. Data Link is in any state except
run or off. Data Link Service is in the passive state.

STARTING -- The link is synchronized and is in its high level
user's startup cycle.
This is a substate of ON. The hiqh
level user is in the start state. Data Link is in the run
state. Data Link Service is in the passive state.

FAILED -- The link permanently failed its high level user's
his is a substate of ON. The high level
startup cycle.
Data
user is in the fail state. Data Link is in any state.
Link Service is in the passive state.

The
REFLECTING -- The link is engaged in passive loopback.
hiqh level u s e r i s i n t h e o f f o r s t a r t s t a t e . D a t a L i n k i s
in the maint state. Data Link Service is in the reflecting
or closed reflecting state.

LOADING -- The link is engaged in down-line load.
The high
level user is in the off state. Data ink is in the maint
state. Data Link Service is in the open state.

The high
DUMPING -- The link is engaged in up-line dump.
level user is in the off state. Data Link is in the maint
state. Data Link Service is in the open state.

LOOPING -- The link is engaged in active loopback. The high
level user is in the off state. Data Link is in the maint
state. Data Link Service is in the open state.

Network Management as Seen by the User

Page 65

10.

TRIGGERING -- The link is engaged in a down-line trigger.
The high level user is in the off state. Data Link is in the
maint state. Data Link Service is in the open state.

11.

AUTOSERVICE -- The link is reserved for Link Watcher use.
This appears as a substate of ON. The high level user is in
the off state. Data Link is in the maint state.
Data Link
Service is in the closed state.

12.

AUTOLOADING -- The link is engaged in down-line load for the
Link Watcher.
This appears as a substate of ON. The high
level user is in the off state. Data Link is in the maint
state. Data Link Service is in the open state.

13.

AUTODUMPING -- The link is engaged in up-line dump for the
Link Watcher.
This appears as a substate of ON. The high
level user is in the off state. Data Link is in the maint
state. Data Link Service is in the open state.

14.

AUTOTRIGGERING - - The link is engaged in a down-line trigger
for the Link Watcher. This appears as a substate of ON. The
high level user is in the off state. Data Link is in the
maint state. Data Link Service is in the open state.

3.7

Modules

Modules are components that do not fit into the other entity
classifications. Module identification is a module name. The Network
Management layer contains the master'list of module names and ensures
their uniqueness. A module name is an id-string. Since module names
are predefined by Network Management, they can be
abbreviated
according to the same rules applied to keywords (Section 4.2.4).

3.7.1

X.25 Access Module

The name of the X.25 access module is X25-ACCESS.
The access module data base contains the information necessary to
connect to the X.25 Server for one or more networks. This information
is indexed by network name. Functions that reference this data base
must indicate to which network name they apply, except for the case
where only one network name is defined.
The user can add and remove network names and parameters.
The user
can also modify parameters for a network name or names. Network
Management can display information about the X.25 access module by
network name or by all known network names.
The network name parameter formats are as follows:

Page 66

Network Management as Seen by the User
KNOWN NETWORKS
All of the network names known to the access module.
NETWORK network-name
The name of a specific network for the access module.
name is an id-string.
Each network name is associated with a
optionally, access control information.
network name are as follows:

node
The

network

identification and,
parameters kept by

ACCOUNT account
This is the access control account field value.
The access
routines use this value when connecting to the server. I f no
account is set, none is included in the access control on connect
by the access module.
Account is a string of one to 39
characters.
NODE node-id
The identification of the node to be used by the access routines
in connecting to a server.
Node-id is a standard Network
Management node identification (Section 3.1).
PASSWORD password
The access control password field value to be used by the access
routines in connecting to the server. I f no password is set,
none is included in the access control on connect by the access
module. Password is a string of one to 39 characters.
USER user
The access control user field value to be used by the access
routines in connecting to the server. I f no user is set, none is
included in the access control on connect by the access module.
User is a string of one to 39 characters.

3.7.2

X.25 Protocol Module

The name of the X.25 protocol module is X25-PROTOCOL.
The protocol module data base contains the information necessary to
maintain switched and permanent virtual circuits through a public data
network over its assigned X.25 lines. Most of this information is
indexed by the local DTE addresses. Functions that reference this
data base must indicate to which DTE address they apply, except for
the case where only one local DTE address is defined.
The user can add and remove local DTE addresses and

parameters.

The

Network Management as Seen by the User

Page 67

user can also modify parameters for a local DTE address or addresses.
Network Management can display information from the X.25 protocol
module data base by local DTE address or for all known local DTE
addresses.

unctions
Closed user group information is indexed by group name.
that' reference this part of the protocol module data base must
indicate to which group they apply. Groups can be added and removed,
along with their parameters. Information can be requested by group
name or for all known groups.
There are also protocol module counters
independent of local DTE addresses.

3.7.2.1

and

parameters

that

are

X.25 Protocol Module Parameters

The local DTE address independent protocol module
follows:

parameters

CALL TIMER seconds
This value indicates the maximum elapsed seconds before the X.25
protocol module will send a clear on outqoing calls from the
local DTE for which no response has been received. If no timer
is set, there is no clear sent. Seconds is a decimal integer in
the range 1-255.
CLEAR TIMER seconds
This is the retransmit timer for outqoing clear packets from the
I f no timer is set, there is no retransmission.
local DTE.
Seconds is a decimal integer in the range 1-255.
DEFAULT DATA byte-count
This parameter is the default data size for switched
Byte-count is a decimal integer in the range 1-65535.

circuits.

DEFAULT WINDOW block-count
This parameter is the
default
number
of
unacknowledged
transmitted blocks on' a switched circuit.
Block-count is a
decimal integer in the range 1-255.
MAXIMUM DATA byte-count
This parameter is the maximum data size for all
Byte-count is a decimal integer in the range 1-65535.

circuits.

MAXIMUM CLEARS retry-count
This value is the maximum number of times that the X.25 protocol
handler is to retry the sending of a clear for switched circuits.

Page 68

Network Management as Seen by the User
If no value is set, there is no maximum.
decimal integer in the range 1-255.

Retry-count

MAXIMUM RESETS retry-count
This value is the maximum number of times that the X.25 protocol
handler is to retry the sendinq of a reset. I f no maximum is
set, there is no maximum. Retry-count is a decimal integer in
the range 1-255.
MAXIMUM RESTARTS retry-count
This value is the maximum number of times that the X.25 protocol
handler is to retry the sendinq of a restart. If no maximum is
set, there is no maximum. Retry-count is a decimal integer in
the range 1-255.
MAXIMUM WINDOW block-count
This value is the maximum number of unacknowledged transmitted
blocks on a switched circuit. Block count is a decimal integer
in the range 1-255.
NETWORK network-name
This network name value can be used by the X.25 protocol handler
to determine network specific characteristics and values. It is
also used as the network name for outgoing and incoming calls.
The network-name is an id string.
RESET TIMER seconds
This parameter is the retransmit timer for outgoing reset packets
I f no timer is set, there is no
from
the
local DTE.
retransmission. Seconds is a decimal integer in the range 1-255.
RESTART TIMER seconds
This parameter is the retransmit timer for outgoing restart
packets from the local DTE.
If no timer is set, there is no
retransmission. Seconds is a decimal integer in the range 1-255.
To access the local DTE indexed parameters, a local DTE address must
be specified or assumed. A local DTE address can only be assumed if
only one is known. The local DTE address parameter is as follows:
KNOWN DTES
This parameter refers to all of the local DTE addresses known
the protocol module.

DTE die-address
This parameter represents a particular local DTE address for

the

Network Management as Seen by the User

Page 69

protocol module. A local DTE address is a decimal integer of one
to sixteen digits.
Each local DTE address is to be associated with the information needed
to process the virtual circuits associated with that local DTE.
The parameters kept by local DTE address are as follows:
ACTIVE CHANNELS count
This read-only value is the number of switched virtual circuit
logical channel numbers that are currently in use. These are the
channels specifically defined with the channels parameter (see
below). Active channels include those allocated from the channel
list for either outgoing or incoming switched virtual circuits.
ACTIVE SWITCHED circuit-count
This read-only value is the number of currently active switched
circuits.
This is the total number of switched virtual circuits
active. It includes both those that were included in the active
channels count plus any incoming calls that did not use one of
the channels in the channel list.
CHANNELS 1i st
This parameter is the list of logical channel numbers that can be
used for outgoing calls or possibly taken by incoming calls.
List is one or more logical channel numbers.
Multiple channel
numbers are separated with hyphens to indicate ranges and commas
to indicate individual numbers. The order of the numbers in the
list defines the order in which the logical channel numbers are
to be allocated by the protocol module.
For example, the command
SET MODULE X25-PROTOCOL CHANNELS 20-10,8,3
Sets 20 as the first channel number to use,
there to 10, then 8 , and finally 3.

counting

down

from

COUNTER TIMER seconds
This parameter is the Network Management timer whose expiration
causes a module counter logging event. The module counters are
recorded as data in a logging event and then zeroed.
If no
counter timer is set, the module counters are not automatically
logged.
Seconds is a decimal integer in the range 1-65535.
LINE line-id
This value represents a LAPB line to be used by the X.25 protocol

Network Management as Seen by the User

Page 70

module.
MAXIMUM CHANNELS count
This value is the read-only number of logical channels defined.
MAXIMUM CIRCUITS count
This is the parameter that indicates the maximum number of
circuits that the DTE can open at one time. This includes both
outgoing and incoming calls. Incoming calls can be given logical
channel numbers outside the given channels list. The count is a
decimal integer in the range 1-65535. Default is 255.
STATE dte-state
This value represents the operational state of a local DTE.
possible states are as follows:

The

The DTE is allowed to operate normally.
OFF

The local DTE is not allowed to operate at all.
existing virtual circuits are terminated immediately.

Any

SHUT
The local DTE will not allow any new virtual circuits to be
formed.
Existing virtual circuits are undisturbed. When
the final existing virtual circuit terminates, the state
automatically goes to OFF.
SUBSTATE dte-substate
There are a number of substates a DTE can be in while it is in ON
state.
The substate depicts the link status between the DTE and
the DCE.
The possible substates are:
UNSYNC
The link to the DCE not in the "RUNNING" state.
SYNC
The packet level has initiated a RESTART for the DTE.
RUNNING
Normal operation.

Page 71

Network Management as Seen by the User
The group name parameter is as follows:

KNOWN GROUPS
This represents all of
protocol module.

the

closed

user

groups

known

the

protocol

GROUP group-name
This indicates a particular closed user group
module. A group-name is an id string.

for

Each group name is to be associated with the information needed to use
the group through the X . 2 5 network.
The parameters kept by group name are as follows:
DTE dte-address
This value represents the local DTE address to which the group
number belongs. When setting this value, it must be accompanied
by a group number parameter. Dte-address is a decimal integer of
1 to 16 digits.
NUMBER group-number
This is the closed user group number. When setting
it must be accompanied by a dte address parameter.
is a decimal integer in the range 0-9999.

this value,
Group-number

TYPE group-type
This is the closed user group type. The only group type defined
is BILATERAL. If no type is set, the group is not bilateral.

3.7.2.2

X . 2 5 Protocol Module Counters

These counters are:
Seconds since last zeroed
Bytes received
Bytes sent
Data blocks received
Data blocks sent
Calls received
Calls sent
Fast selects received
Fast selects sent
Maximum switched circuits active
Maximum channels active
Received call resource errors
Locally initiated resets
Remotely initiated resets

Page 72

Network Management as Seen by the User
Network initiated resets
Restarts

3.7.3

X.25 Server Module

The name of the X.25 Server module is X25-SERVER.
The server module data base contains the information necessary to map
incoming X.25 calls to a DECnet process. This information is indexed
by destination name. Functions that reference this data base must
indicate to which destination name they apply, except for the case
that there is only one destination name defined.
Destination names can be added and removed, along with
their
parameters.
Parameters for a destination name or names can be
modified. Information can be requested by destination name or for all
known destination names.
There are also server counters and some
independent of destination names.

3.7.3.1

server

parameters

that

are

X.25 Server Module Parameters

The destination name independent server parameters are as follows:
ACTIVE CIRCUITS count
This is the read-only module parameter that indicates the
of circuits that the module currently has open.

number

COUNTER TIMER seconds
This is the Network Management timer whose expiration causes a
module counter logging event. The module counters are recorded
as data in a logging event and then zeroed. If no counter timer
is set, the module counters are not automatically logged.
Seconds is a decimal integer in the range 1-65535.
MAXIMUM CIRCUITS count
This is the module parameter that indicates the maximum number of
circuits that the module can have open at one time. Count is a
decimal integer in the range 1-65535.
The destination name parameter is as follows:
KNOWN DESTINATIONS
This refers to all of the destination names known to
module.

the

server

Network Management as Seen by the User

Page 73

DESTINATION destination-name
This indicates the name of a specific destination for the
module. A destination name is an id-string.

server

Each destination name is to be associated with a DECnet node and
object identification and with the necessary X . 2 5 related information
to recognize the incoming call.
The algorithms for incoming call
recognition are in the X . 2 5 Gateway Access specification.
The parameters kept by destination name are as follows:
ACCOUNT account
This is the access control account field value to be used in
connecting to the DECnet destination of an incoming call. If no
account value is set, the server will not use one in the connect.
Account is a string of 1 to 3 9 characters.
CALL MASK hex-value
This is the call mask value to be used to identify the
destination for an incoming call. If no call mask is set, none
will be used in the identification process.
Hex-value is a
hexadecimal number of 1 to 3 2 digits.
CALL VALUE hex-value
This is the call data value to be used to identify the
destination for an incoming call. I f no call value is set, none
will be used in the identification process.
Hex-value is a
hexadecimal number of 1 to 3 2 digits.
GROUP group-name
This is the closed user group name to be used to identify the
destination for an incoming call. If no group name is set, none
will be used in the identification process. The group-name value
is an id string.
NODE node-id
This is the identification of the node to be used in connecting
to the DECnet destination of an incoming call. Node-id is a
standard Network Management node identification.
NUMBER call-number
This is the full remote DTE address to be used to identify the
destination for an incoming call. If no remote DTE address is
set, none will be used
in
the
identification
process.
Call-number is a string of 1 to 16 numeric digits and/or
asterisks ( * ) .
OBJECT object-id

Network Management as Seen by the User

Page 74

This is the object identification to be used in connecting to the
DECnet destination of an incoming call. Object-id is either a
string of 1 to 16 characters for named objects or a decimal
number in the range 1-255 for numbered objects. If a named
object has a name that looks like a number for a numbered object,
the name is specified on input in quotes to indicate that the
object-id is a string rather than a number. On output there is
no differentiation.
PASSWORD password
This is the access control password field value to be used in
connecting to the DECnet destination of an incoming call. If no
password value is set, the server will not use one in the
connect. Password is a string of 1 to 39 characters.
PRIORITY priority
This is the priority with which the X.25 set of information is to
be used.
The highest priority is 255 and the lowest is 0.
Priority is a decimal integer in the range 0-255.
SUBADDRESSES range
This is the range of local DTE subaddresses to be used r o
identify
the
destination
for
an incoming call.
I f no
subaddresses are set, none are used in the identification
process. The range value consists of one or two subaddresses. A
subaddress is a decimal integer in the range 0-9999.
If two
subaddresses are provided, specifying a range, they are separated
by only a single hyphen and the second must be greater than the
first.
USER user
This is the access control user field value to be used in
connecting to the DECnet destination of an incoming call. I f no
user value is set, the server will not use one in the connect.
User is a string of 1 to 39 characters.

3.7.3.2

X.25 Server Module Counters

These counters are:
Seconds since last zeroed
Maximum circuits active
Incoming calls rejected, no resources
Logical links rejected, no resources

Network Management as Seen by the User
3.7.4

Page 75

Link Maintenance Modules

The names of the link management modules are LOOPER, LOADER,
and CONFIGURATOR.

CONSOLE,

The link maintenance modules provide the network manager with entities
that can own Ethernet circuits for link service functions such as ioop
testing and down-line load. Some of the link maintenance modules have
parameters for controlling or observing their operation.
The looper, loader, and console modules are the only link maintenance
modules that can be CIRCUIT owners. They each own one circuit on
every Ethernet line that is to have their related service functions.
The configurator module is a user of the services represented by the
console module. The configurator module can provide information from
a single console request for system identification or can listen
through the console and construct a list of the systems on an Ethernet
line.

3.7.4.1

Console Module Parameter

The console module parameter is as follows:
RESERVATION TIMER seconds
This value indicates the number of seconds that the console will
stay reserved without hearing from the system that reserved it.
Seconds is a decimal integer in the range 1-65535.

3.7.4.2

Loader Module Parameter

The loader module parameter is as follows:
ASSISTANCE control
This value indicates whether or not this node will respond to the
dump/load assistance multicast address. The control values are
as follows:
ENABLED

The node will respond.

DISABLED

The node will not respond.

3.7.4.3

Looper Module Parameter

The looper module parameter is as follows:
ASSISTANCE control

Network Management as Seen by the User

Page 76

This value indicates whether or not this node will respond 70 the
loopback assistance multicast address. The control values are as
follows:
ENABLED

The node will respond.

DISABLED

The node will not respond.

3.7.4.4

Configurator Module Parameters

All configurator module parameters are qualified with the circuit
identification of the Ethernet circuit to which they relate. The
circuit identification parameter is as follows:
CIRCUIT circuit-id
This indicates the circuit of interest.
circuit. Circuit-id is an id-string.

It must be

Ethernet

The parameters kept by circuit identification are as follows:
ELAPSED TIME hours:minutes:seconds
This read-only value is the amount of time that surveillance has
been enabled on the channel. Hours is a decimal integer :n the
range 0-65535, minutes and seconds are decimal integers in. the
range 0-59.
SURVEILLANCE control
This value indicates whether or not a list of active systems is
to be kept for the circuit. The control values are as follows:
ENABLED

The list is kept.

DISABLED

The list is not kept.

The default value is DISABLED.
Within a circuit, many parameters are further qualified by the remote
system's physical address.
The physical address parameter is as
follows:
PHYSICAL ADDRESS ethernet-address
This read-only value is the Ethernet address of a remote system
on the circuit. When used as a qualifier on a display request,
it causes an active request to the console at the specified
address and returns the resulting information.
The parameters qualified by physical address are as follows:
COMMAND SIZE bytes

Network Management as Seen by the User

Page 77

This read-only value is the number of bytes in the remote
system's console carrier protocol command buffer. By:es
is a
decimal number in the range 1-65535.
CONSOLE USER ethernet-address
This read-only value is the Ethernet address of the
has the remote system's console reserved.
It
Ethernet address or the word "NONE".

system that
is either an

DATA LINK data-link-type
This read-only value is the type of data link protocol being used
on the circuit over which the remote system is communicating.
Its values are defined in the DNA Low Level Maintenance O ~ e r a t i o n
specification.
DATA LINK BUFFER SIZE data-link-type
This read-only value is the size of data link buffer being used
on the circuit over which the remote system is communicating.
Its values are defined in the DNA Low Level Maintenance O ~ e r a t i o n
specification.
DEVICE device-type
This read-only value is the type of device over which the remote
system is communicating on the circuit.
It is one of the
standard line devices.
FUNCTIONS function-list
This read-only value is the list of maintenance functions that
the remote system supports. The list of items is one or more of
the following:
BOOT

CARRIER
COUNTERS
DUMP
LOAD
LOOP
PRIMARY

Remote controlled boot
Console carrier protocol
Data link counter read
Up-line dump
Multi-block down-line load
Loopback
Primary loader

HARDWARE ADDRESS ethernet-address
This read-only value is the Ethernet address that is attached to
the remote system hardware. It may be relative to the particular
device through which the remote system is communicating on the
circuit.
LAST REPORT day-month hour:minute:second
This read-only value is the date and time of the
on a circuit
remote
system
reported
in

last
that

time the
is under

Network Management as Seen by the User

Page 78

surveillance. Day is a decimal integer in the range 1-31. Month
is the name of the month. Hour is a decimal integer in the range
0-23. Minute and second are decimal integers in the range 0-59.
MAINTENANCE VERSION n.n.n
This read-only value is the maintenance protocol version of the
remote system, consisting of the version number, the Engineering
Change Order (ECO) number, and the user ECO number (for example,
3.0.0).

RESERVATION TIMER seconds
This read-only value is the maximum time that the remote system's
console will remain reserved without a message from tie console
user. Seconds is a decimal integer in the range 1-65533.
RESPONSE SIZE bytes
This read-only value is the number of bytes in the remote
system's console carrier protocol response buffer. Bytes is a
decimal number in the range 1-65535.
SYSTEM PROCESSOR processor-type
This read-only value is the type of main processor on tne remote
system.
Its values are defined in the DNA Low Level Maintenance
Operation specification.
SOFTWARE IDENTIFICATION software-id
This read-only value identifies the software that the remote
system is supposed to be running. It is defined the same as NODE
SOFTWARE IDENTIFICATION.

3.8

Events

Events are significant occurrences in the DNA layers that the Network
Management Event Logger records.
This section lists the events
recorded according to the entity and layer with which they are
associated.
Section 3.9 describes the event parameters. Section 5.5
describes the operation of the Event Logger. Section 6.13 specifies
the Event message binary data format. Section 7.12 specifies the
events. Section 7.13 specifies the binary formats and values for the
event parameters.

3.8.1

Events Not Related to an Entity

The Event Logger records the following Network Management event.
Event records lost

Page 79

Network Management as Seen by the User
The Event Logger records the followinq Session Control events:
Local node state change
Access control reject

The Event Loqger records the followinq End communication events:
Invalid message
Invalid flow control

3.8.2

Node Events

The Event Logger records the following Network Management node events:
Automatic counters
Counters zeroed
The Event Logger records the followinq End Communication node event:
Data base reused
The Event Logger records the following Routing node event:
Node reachability change

3.8.3

Circuit Events

The Event Logger records
events:

the

following

Network

Management

Automatic counters
Automatic service
Counters zeroed
Passive loopback
Aborted service request
The Event Loqger records {the followinq Routing circuit events:
Node unreachable packet loss
Node out-of-range packet loss
Oversized packet loss
Packet format error
Partial routing update loss
Verification reject
Circuit down, circuit fault
Circuit down
Circuit down, operator initiated
Adjacency down
Adjacency down, operator initiated
Circuit up
Adjacency up

circuit

Page 80

Network Management as Seen by the User
Initialization failure, circuit fault
Initialization failure
Initialization failure, operator initiated
Area reachability change
Adjacency rejected

The Event Logger records the following events for DDCMP circuits:
Locally initiated state change
Remotely initiated state change
Protocol restart received in maintenance mode
Send error threshold
Receive error threshold
Select error threshold
Block header format error
Selection address error
Streaming tributary
Local buffer too small

3.8.4

Line Events

The Event Loqqer records the following events for all lines:
Automatic counters
Counters zeroed
Passive loopback
The Event Loqqer records the following Data Link LAPB line events:
Locally initiated state change
Remotely initiated state change
Block header format error
The Event Loqqer records the following Data f ink Ethernet line events:
Initialization failed
Send failed
Collision detect check failed
Receive failed
The Event Logger records the following Physical
Data set ready transition
Ring indicator transition
Unexpected carrier transition
Memory access error
Communications interface error
Performance error

ink line events:

Page 81

Network Management as Seen by the User
3.8.5

Module Events

The Event Logger records the following Data Link X.25 protocol
events:

module

Restart
State change
Retransmit maximum exceeded
Block header format error
DTE up
DTE down

3.9

Event Parameters

This section describes the event parameters related to
events
described in Section 3.8. The user cannot directly control or observe
these parameters.
The Event Logger records parameters upon the
occurrence of related events, if event logging of those parameters is
enabled.
There are also events that relate to counters.
These counters are
those already described for nodes, circuits, lines, and modules. The
event parameters are described in alphabetical order by layer,
starting with the highest layer that maintains event ~arameters.

3.9.1

Network Management Layer

OPERAT ION
This parameter represents
following values:

the

operation

performed,

with

the

aborted,

with

INITIATED
TERM1NATED
REASON
This parameter indicates the reason the
the following values:

function

Receive t imeout
Receive error
Line state change by higher level
Unrecognized request
Line open error
SERVICE
This parameter represents the service type,
values:

with

the

following

Page 82

Network Management as Seen by the User
LOAD
DUMP
STATUS
This parameter is the operation status, consisting of:
RETURN
CODE

ERROR
DETAIL

ERROR
MESSAGE

where:
RETURN CODE
A standard NICE return code
interpretation, as follows:

(Appendix

F),

with

added

REQUESTED
SUCCESSFUL
FA1 LED
ERROR DETAIL
A standard NICE error detail ( ~ p p e n d i xF ) .
ERROR MESSAGE
A standard NICE optional error message (Aopendix F).

3.9.2

Session Control Layer

ACCOUNT
This value contains any account information in a string of one to
39

characters.

Account

information is used for access control

purposes.
DESTINATION PROCESS
This identifies the process to be connected
Management. The identification consists of:

OBJECT TYPE - An object type number.
GROUP CODE - A group code number.
USER CODE - A user code number.
PROCESS NAME - A process name.
The Session Control specification specifies these values.
NEW STATE

Network

Network Management as Seen by the User

Page 83

This represents the new node state, with the following values:
ON
OFF
SHUT
RESTRICTED
OLD STATE
This represents the old node state, with the same values
NEW STATE.

for

PASSWORD
This is the access control password field value used
in
connecting to the DECnet destination of an incoming call. If no
password is specified, then none will be used.
Password is a
string of 1 to 39 characters.
REASON
This represents the reason for the state change, as follows:
Operator command
Normal operation
SOURCE NODE
This identifies the source node, where the source process resides
which sent the session control protocol message which caused the
event. The identification consists of a node address followed by
a node name.
The format is the same as for the node entity
S e c t i o n 3.1).
SOURCE PROCESS
This identifies the source process on behalf of which the source
node sent the session control protocol message which caused the
event.
The identification is the same as for DESTINATION
PROCESS.
USER
This is a string of 1 to 39 characters identifying the user.

3.9.3

End Communication Layer

CURRENT FLOW CONTROL
This is the current flow control
Communication specification).
MESSAGE

value

(refer

the

End

Page 84

Network Management as Seen by the User
This is the message received (NSP information only).
consists of:

The message

MESSAGE FLAGS - NSP message flags.
DESTINATION ADDRESS - Destination l i m address.
SOURCE ADDRESS - Source link address.
DATA - Message-type-dependent data.
SOURCE NODE
This is the identity of the node sending tne
source node consists of:

ECL

message.

The

SOURCE NODE ADDRESS - Node address of the source node.
SOURCE NODE NAME - Name of the source node (optional).

3.9.4

Routing Layer

ADJACENT NODE
This is the identification of the adjacent node on the circuit.
HIGHEST ADDRESS
This is the highest reachable node address.
NODE
This is the identification of the node, in the same format
SOURCE NODE in the list of Session Control event parameters.

PACKET BEGINNING
This is the beginning of the packet.
PACKET HEADER
This is the packet header.
of:

For non-Ethernet packets, it consists

MESSAGE FLAGS - Message definition flags.
DESTINATION NODE ADDRESS - The address
node.

the

destination

SOURCE NODE ADDRESS - The address of the source node.

VISIT COUNT - The number of nodes the packet has visited.

Page 85

Network Management as Seen by the User
For Ethernet packets, it consists of:
MESSAGE FLAGS - Message definition flags.

DESTINATION AREA - The area number of the destination node.
DESTINATION SUBAREA - The sub-area number of the destination
node.
DESTINATION ETHERNET ADDRESS - The Ethernet address
destination node.

the

SOURCE AREA - The area number of the destination node.
SOURCE SUBAREA - The
node.

sub-area

SOURCE ETHERNET ADDRESS
destination node.

number

The

Ethernet

the

destination

address

the

NEXT AREA ROUTER - The number of the next area router.
VISIT COUNT - The number of nodes the packet has visited.
SERVICE CLASS - The packet service class.
PROTOCOL TYPE - The protocol type of the packet contents.
REASON
This is the reason for failure. The values are listed
Table 27 in section 7.13.

following

RECEIVED VERSION
This is the received version number, with the same format as
Network Management version (Section 3.1.1).
STATUS
This is the node status, with the following values:
REACHABLE
UNREACHABLE

3.9.5

Data Link Layer

BLOCK LENGTH
This is the received block length from header, in bytes.
BUFFER LENGTH

for

Page 86

Network Management as Seen by the User
This is the buffer length, in bytes.
CAUSE

This represents the cause for the X.25 protocol module event.
For detailed explanation of the value see the CCITT X.25
Recommendation.
DIAGNOSTIC
This represents the diagnostic for the X.25 protocol module
event.
For detailed explanation of the value see the CCITT X.25
Reconunendation.
D I STANCE
This is the distance, in bit times, to a short or open
an Ethernet line.

cable

DTE
This identifies the DTE associated with the X.25 protocol
event.

module

ETHERNET HEADER
It
This is the header of the Ethernet block.
destination address, source address, and protocol type.

includes

FAILURE REASON
This is the reason for an Ethernet transmit or receive failure.
HEADER
This is the block header
NEW STATE
This is the new DDCMP state, with the following values:
HALTED
I STRT
ASTRT
RUNN ING
MAINTENANCE
NEW STATE
This represents the X.25 protocol module new state associated
with event 5.12, with the same values as for the DDCMP NEW STATE.

OLD STATE
This is the old DDCMP state, with the

same

values

for

NEW

Page 87

Network Manaqement as Seen by the User
STATE.
OLD STATE

This is the X.25 protocol module old state associated with
5.12, with the same values as for tne DDCMP NEW STATE.

event

PARAMETER TYPE
This is the Network Manaqement paraneter type
involved in the event.

the

parameter

PREVIOUS TRIBUTARY
This is the previously selected trioutary address.
REASON
This is the reason for a state change.
RECEIVED TRI BUTARY
This is the received tributary address.
SELECTED TRIBUTARY
This is the selected tributary address.
TRIBUTARY STATUS
This is the tributary status, with the following values:
Streaming
Continued send after timeout
Continued send after deselect
Ended streaming

3.9.6

Physical Link Layer

DEVICE REGISTER
This is a copy of the contents of a single device register.
more than one, they are output in standard order.
NEW STATE
This represents the new modem control state, as follows:
OFF
ON

When

Network Control Program (NCP)
4

Page 88

NETWORK CONTROL PROGRAM (NCP)

This section is divided into three parts. Section 4.1 describes the
NCP functions.
Section 4.2 provides rules for the operation of NCP,
including such topics as input and outsut formatting and status and
error messages.
Section 4.3 presents a complete list of all the NCP
commands as well as specific formats for the output on SHOW and LIST
commands.

4.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. These 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.

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
Network Management Access
Management
Listener, via :he
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; however, passing requests internally
is recommended.

The keyword ALL can be used with many of the NCP commands.
In
general, it means that the command should be executed for all
parameters in the appropriate data base associated with the specified
entity.
The NCP command language enables an operator to perform the
network functions:
o

Changing parameters (Section 4.1.1)

Gathering information (Section 4.1.2)

Down-line loading (Section 4.1.3)

Up-line dumping (Section 4.1.4)

Triggering bootstrap (Section 4.1.5)

Testing link and network (section 4.1.6)

following

Network Control Program (NCP)
o

4.1.1

Page 89

Zeroing counters (Section 4.1.7)

Changing Parameters

NCP can set or change many of the parameters described in Section 3 .

Some examples of changing parameters are:
o

Setting a line state to ON

Changing a node name associated with a node address

Setting the routing cost fcr 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.
Section 5.10 describes the internal operation for changing parameters.

Gathering Information

4.1.2

NCP can display current values for the parameters and counters
described in Section 3. Examples of gathering information are:
o

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

Counters are error and performance statistics such as messages sent
and received, time last zeroed, and maximum number of logical links in
use. Section 5.11 describes the read information operation.

Network Control Program (NCP)
4.1.3

Page 90

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 link 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 5.6 describes the down-line load operation in
the Network Management layer.

4.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 5.7
describes the up-line dump operation.

4.1.5

Triggering Bootstrap

An operator can use NCP to trigger the
unattended remote target node.
Section
bootstrap operation.

4.1.6

bootstrap loader of an
5.8 describes the trigger

Testing Link and Network

Testing link and network can be accomplished by message looping at the
line,
circuit, 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 data link usage. The
data links involved are in the ON state, and the Session Control, End
Communication, and Routing layers are used.
During circuit level testing, a DDCMP circuit being tested is in the
SERVICE state; normal usage is precluded. An X.25 circuit cannot be
loop tested. An Ethernet circuit to be tested must be in the ON state
and be owned by the LOOPER module. For all circuit tests, Network
Management accesses the Data
Link
layer
directly,
bypassing
intermediate layers.
During line loop testing, the line being tested is in the SERVICE
state.
As with the circuit loop test, normal usage is precluded.
Network Management accesses the Data Link layer directly. A LAPB line
loop is at the physical connection level, but is limited to hardware
loopback only. Section 5.9 further describes line, circuit, and node
testing.

Page 91

Network Control Program (NCP)
4.1.7

Zeroing Counters

Using NCP, an operator
counters to zero.

4.2

can

set

module,

line,

circuit,

and

node

Network Control Program Operation

This section describes general rules concerning the operation on NCP.
Multiple parameters on SET, DEFINE, CLEAR, and PURGE commands are
15 they are allowed, either all must be
implementation optional.
successfully acted on, or none.

4.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 command

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

4.2.2

Program Invocation, Termination, and Prompting

The way NCP is invoked or terminated is system-dependent. I f a name
is used for the program, it must be "NCP." 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:

prompt

For an NCP that accepts

several

outstanding

commands

where

Network Control Program (NCP)

Page 92

obvious that NCP is prompting, the prompt is:

For the multiple-outstanding-command case where it is not obvious that
NCP is prompting, the prompt is:

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.

4.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
t ime.

4.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. I f 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:
Command

1 Entity

1 Parameter

------------------+-----------+---------------------------------------

LOOP NODE
I node-id
SET EXECUTOR NODE 1
1
TELL

[USER user-id]

1 [PASSWORD password]
1 [ACCOUNT account]

------------------+-----------+-----------_--_----__-_-__---___-__---_

where:

Page 9 3

Network Control Program (NCP)
LOOP NODE node-id

Is an NCP command used to initiate a
node loopback test. 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.
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.

For example:
TELL BOSS USER [211,1] PASSWORD secret ACCOUNT xyz CLEAR KNOWN LINES
SET EXECUTOR NODE 97 ACCOUNT xyz
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 NCP1s parsing
algorithm for these types of arguments:
o

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 quotat ion marks ( "xXXXX" )
A quote
within the string will be indicated by a double quotation
mark ("XXX""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.

Network Control Program (NCP)

Page 94

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.

4.2.5

Output Characteristics

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.
#23>LOAD NODE MANILA
#24>LOAD NODE TOKYO
#25
REQUEST #24; LOAD FAILED, LINE COMMUNICATION ERROR
SHOW QUEUE
REQUEST #25; SHOW QUEUE
REQUEST
NUMBER

EXECUTOR

COMMAND

21
6 (HNGKNG) SHOW
22
6 (HNGKNG) SET
23
6 (HNGKNG) LOAD
24
6 (HNGKNG) LOAD
25
N/A
SHOW
#26>
REQUEST #23, LOAD COMPLETE

STATUS
COMPLETE
COMPLETE
IN PROGRESS
FAILED
IN PROGRESS

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

4.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
where:

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

Page 95

Network Control Program (NCP)
n

Is the command's request number.

entity

Is a specific entity.

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
When a loop test succeeds on an Ethernet circuit and the user did not
specify
a
physical
address, the command output includes the
ethernet-address of the responding system from the loopback assistant
multicast group in the form:
PHYSICAL ADDRESS = ethernet-address
When a loop test fails, the error message contains
information, in the form either

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.
NCP prints unrecognized return
numbers. For example:

codes

error

details

decimal

Request #5; SHOW failed, Management return #-34
SET FAILED, parameter not applicable, detail #2300
Error messages are either those from the set of NCP error messages in
Appendix G , the NICE error returns in Appendix F or implementation

specific.

Network Control Program (NCP)
4.3

Page 96

Network Control Program Commands

This section describes NCP commands.
The following symbols are used in NCP command syntax descriptions:
Brackets indicate optional input. In
these
are
the entity parameters
carameter options for a command.

most cases
and entity

UPPER CASE

Lpper case letters signify actual input,
~ e y w o r d sthat are part of NCP commands.

lower case

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

spaces

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

hyphens

Multi-word variables are hyphenated.

{

Braces indicate that
any
parameters are applicable.

the

that

enclosed

All NCP commands have the following common syntax:
verb

entity

entity-option(s)

where:
verb

Specifies the operation to be performed,
SHOW or LOAD.

entity

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

entity-option(s)

Qualifies the command
specific information.

4.3.1

providing

such

further

SET and DEFINE Commands

These commands modify volatile and permanent parameters.
The SET
command modifies the volatile data base; the DEFINE command changes
the permanent data base. Section 5.10 describes the internal change
parameter operation.
The general form of the commands is:
SET
DEFINE

entity

parameter

Entity is one of the following:

Network Control Program (NCP)

Page 97

CIRCUIT circuit-id
EXECUTOR
KNOWN CIRCUITS
KNOWN LINES
KNOWN LOGGING
KNOWN MODULES
KNOWN NODES
LINE line-id
LOGGING sink-tvpe
MODULE module-piame
NODE node-id
Parameter is one (or more, i f allowed by the implementation)
parameter options defined for the specified entity.

4.3.1.1

the

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

4.3.1.2

SET and DEFINE KNOWN Entity Commands

These commands set volatile and permanent parameters for each
the specified entities known to the system. The format is:

SET
DEFINE

one

1 KNOWN plural-entity I ALL
1
1 parameter

----.+--_-__----_----------+---------------------------------------

Plural-entity is one of CIRCUITS, LINES, LOGGING, MODULES, or NODES.
The parameters are the same as for the SET and DEFINE entity commands
following.
However, DEFINE KNOWN plural-entity ALL has no meaning.
SET KNOWN plural-entity ALL loads all permanent entity parameters into
the volatile data base.

4.3.1.3

SET and DEFINE CIRCUIT Commands

These commands control the setting of parameters for the circuit
entity.
Some of the parameters only apply to certain circuit types.
Refer to Section 3.3.1.
The format of these commands is:

Page 98

Network Control Program (NCP)
Command 1 Entity
--------+---------------------

SET
DEFINE

I CIRCUIT circuit-id
1 KNOWN CIRCUITS
I
I
I

I BLOCKING blocking-control

I CHANNEL channel-number
I COST cost
I COUNTER TIMER seconds
I DEAD THRESHOLD count
I DTE dte-address
I DYING BASE base
I DYING INCREMENT increment
I DYING THRESHOLD count
I HELLO TIMER seconds
I INACTIVE BASE base
I INACTIVE INCREMENT increment
I INACTIVE THRESHOLD count
I LINE line-id
I MAXIMUM BUFFERS count
I MAXIMUM DATA byte-count
I MAXIMUM RECALLS retry-count
I MAXIMUM ROUTERS number
I MAXIMUM TRANSMITS count
I MAXIMUM WINDOW block-count
I NUMBER call-number
I ORIGINATING QUEUE LIMIT queue-size
I OWNER owner-id
I POLLING STATE polling-state
I RECALL TIMER seconds
I ROUTER PRIORITY number
I SERVICE service-control
I STATE circuit-state
I TRANSMIT TIMER milliseconds
I TRIBUTARY tributary-address
I TYPE circuit-type
I USAGE usage-type

I
I
I
I
I

I
I
I
I
I
I
I
I
I
I
I
I

I
I
I
I
I
I
I
I
I
I
I

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

--------+-_------------------_+

4.3.1.4

I Parameter
+.......................................
1 ACTIVE BASE base
1 ACTIVE INCREMENT increment
I ALL
I BABBLE TIMER milliseconds

SET and DEFINE LINE Commands

These commands control the setting of parameters for the line entity.
Some of the parameters are only applicable to certain line protocols.
Refer to Section 3.5.1 The format of these commands is:
Command I Entity

1 Parameter

----_---+--------------_-+------------------------------------------

SET
DEFINE

I LINE line-id
I KNOWN LINES
1
1
1

I ALL
1
1
1
1

CLOCK clock-mode
CONTROLLER controller-mode
COUNTER TIMER seconds
DEAD TIMER milliseconds

Page 99

Network Control Program (NCP)
DELAY TIMER milliseconds
DEVICE device-specification
DUPLEX duplex-mode
HOLDBACK TIMER milliseconds
MAXIMUM BLOCK byte-count
MAXIMUM RETRANSMITS block-count
MAXIMUM WINDOW block-count
PROTOCOL protocol-name
RECEIVE BUFFERS number
RETRANSMIT TIMER milliseconds
SCHEDULING TIMER milliseconds
SERVICE service-control
SERVICE TIMER milliseconds
STATE line-state
STREAM TIMER milliseconds

4.3.1.5

SET and DEFINE LOGGING Commands

This set of commands is used to control event sinks (where events
logged) and event lists (that control which events get logged).
command format is :
Command I Entity

1 Parameter

are
The

1 Qualifier

-----+_-_-_-------_------+------------------+----------------------

1
1

I NAME sink-name
1 STATE sink-state

------+-------------------+------------------+----------------------

Section 3.3 describes source qualifiers, sink nodes, and sink types.

4.3.1.6

SET and DEFINE MODULE Commands

These commands vary considerably depending on the module named.
The
following descriptions take this into account by describing the
options independently for each defined module identification.

4.3.1.6.1

SET and DEFINE MODULE CONSOLE Commands

These commands control the parameters necessary
console. The format of these commands is:

the

maintenance

Network Control Program (NCP)

4.3.1.6.2

Page 100

SET and DEFINE MODULE LOADER Commands

These commands control the parameters necessary to
loader and dumper. The format of these commands is:
Command I Entity
SET
DEFINE

1 MODULE LOADER
1

4.3.1.6.3

the

maintenance

the

maintenance

1 Parameter

1 ALL
1 ASSISTANCE control

SET and DEFINE MODULE LOOPER Commands

These commands control the parameters necessary
looper. The format of these commands is:
Command I Entity

1 Parameter

--------+----------------+---------------------------_-------_-----

SET
DEFINE

I MODULE LOOPER

4.3.1.6.4

I ALL
1 ASSISTANCE control

SET and DEFINE MODULE CONFIGURATOR Commands

These commands control the parameters necessary
configurator. The format of these commands is:

the

I f only one circuit is known, it is the default.
circuit is known, the qualifier must. be included.

4.3.1.6.5

maintenance

than

one

SET and DEFINE MODULE X25-ACCESS Commands

These commands control the parameters necessary to
Access Routines. The format of these commands is:

the

X.25

Gateway

Network Control Program (NCP)
Command I Entity

Page 101

1 Parameter

1 Qualifier

-+--------------+----------------------+-----------------------

SET
DEFINE

I MODULE
I
1

1
1

I ACCOUNT account
X25-ACCESS I ALL
1 NODE node-id
1 PASSWORD password
1 USER user

I [KNOWN NETWORKS]
1 [NETWORK network-name]
1
1

----+--------------+----------------------+-----------------------

I f only ore network is known, it is the default.
network is known, the parameter must be included.

4.3.1.6.6

than

one

SET and DEFINE MODULE X25-PROTOCOL Commands

These commands control the parameters for the
module. The format of these commands is:
Command I Entity

X.25

protocol

control

1 Qualifier

I Parameter

-----+----------------+-------------------------+------------------

SET
DEFINE

I MODULE
I ALL
I [dte-qualifier]
1
X25-PROTOCOL 1
1 [group-qualifier]
+-_-----------_-------_---+-----------------I
1
I GROUP group-name group-options
1
1 CALL TIMER seconds
CLEAR TIMER seconds
DEFAULT DATA byte-count
DEFAULT WINDOW block-count
MAXIMUM DATA byte-count
MAXIMUM CLEARS retry-count
I MAXIMUM RESETS retry-count
1 MAXIMUM RESTARTS retry-count
1 MAXIMUM WINDOW block-count
1 NETWORK network-type
1 RESET TIMER seconds
1 RESTART TIMER seconds
Ã

+--_---_----___--_--------+------------------

I CHANNELS 1ist

1
1
1
1

COUNTER TIMER seconds
LINE line-id
MAXIMUM CIRCUITS count
STATE dte-state

[dte-qualifier]

-+---_----------_----------+------------------

Dte-qualifier indicates to
applies. It is of the form:

which

local

DTE

address

the

command

KNOWN DTES
DTE dte-address
If more
I f only one local DTE address is known, it is the default.
than one local DTE address is known, the parameter must be included.
Group-qualifier indicates to

which

closed

user

group

the

command

Page 102

Network Control Program (NCP)
applies.

It is of the form:

KNOWN GROUPS
GROUP group-name
Group-options are:
DTE dte-address
NUMBER group-number
TYPE group-type
Both DTE and NUMBER must be included, TYPE is optional.

4.3.1.6-7

SET and DEFINE MODULE X25-SERVER Commands

These commands control the parameters necessary to
Server. The format of these commands is:
Command I Entity

1 Parameter

the

X.25

Gateway

1 Qualifier

-------+----------------+------------------------+-------------------

SET
DEFINE

I MODULE
1
X25-SERVER
1
1
I

I ALL

I [destination-qua11

1 COUNTER TIMER seconds
1 MAXIMUM CIRCUITS count
+_-----------------------+_-_--_--__----_----

ACCOUNT account
CALL MASK hex-value
CALL VALUE hex-value
GROUP group-name
NODE node-id
NUMBER dte-address
OBJECT object-id
PASSWORD password
PRIORITY priority
SUBADDRESSES range
USER user

[destination-qua11

1
1
1
1
1
1
1
1
1

Destination-qua1 indicates to which destination the
It is of the form:

command

applies.

KNOWN DESTINATIONS
DESTINATION destination-name
I f only one destination is known, it is the default. I f more than one
destination is known, the parameter must be included.

4.3.1.7

SET and DEFINE NODE Commands

These commands set volatile
Certain parameters can be

or permanent parameters for a node.
set only for the executor node or for

Page 103

Network Control Program (NCP)
adjacent nodes.
command is:

SET
DEFINE

See Table

1 EXECUTER
1 KNOWN NODES

1 NODE node-id
I
I
I
I
I
I
I

I
I
I
I
I
I
I
I
I
I
I

I
I
I
I
I
I

I
I
I
I
I

20,

Section

7.9.

The

format

for

ADDRESS node-address
ALL
AREA MAXIMUM COST number
AREA MAXIMUM HOPS number
BROADCAST ROUTING TIMER seconds
BUFFER SIZE bytes
CIRCUIT circuit-id
COUNTER TIMER seconds
CPU cpu-type
DELAY FACTOR number
DELAY WEIGHT number
DIAGNOSTIC FILE file-id
DUMP ADDRESS number
DUMP COUNT number
DUMP FILE file-id
HARDWARE ADDRESS ethernet-address
HOST node-id
IDENTIFICATION id-string
INACTIVITY TIMER seconds
INCOMING TIMER seconds
LOAD FILE file-id
MAXIMUM ADDRESS number
MAXIMUM AREA number
MAXIMUM BROADCAST NONROUTERS number
MAXIMUM BROADCAST ROUTERS number
MAXIMUM BUFFERS number
MAXIMUM CIRCUITS number
MAXIMUM COST number
MAXIMUM HOPS number
MAXIMUM LINKS number
MAXIMUM VISITS number
NAME node-name
OUTGOING TIMER seconds
RETRANSMIT FACTOR number
ROUTING TIMER seconds
SECONDARY DUMPER file-id
SECONDARY LOADER file-id
SEGMENT BUFFER SIZE bytes
SERVICE CIRCUIT circuit-id
SERVICE DEVICE device-type
SERVICE NODE VERSION node-version
SERVICE PASSWORD password
SOFTWARE IDENTIFICATION software-id
SOFTWARE TYPE program-type
STATE node-state
SUBADDRESSES range
TERTIARY LOADER file-id
TYPE node-type

the

Page 104

Network Control Program (NCP)
4.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.
If the parameter has a default value, it reverts to that value. The
general form of the command is:

CLEAR
PURGE

I entity
1

I parameter
I

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

4.3.2.1

(Section

CLEAR and PURGE EXECUTOR NODE Commands

The CLEAR EXECUTOR NODE command resets the executor to the command
node.
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 to the command node.
Access control is reset as well.

4.3.2.2

CLEAR and PURGE KNOWN Entity Commands

These commands clear and purge parameters for all of the specified
entities known to the system. The format of the command is:

CLEAR
PURGE

I KNOWN plural-entity I parameter
1
1

Plural-entity is one of CIRCUITS, LINES, LOGGING, MODULES, or NODES.
Parameter is one or possibly more of the parameters
the CLEAR and PURGE entity commands (following).

4.3.2.3

CLEAR and PURGE CIRCUIT Commands

The format of these commands is:

associated

with

Network Control Program (NCP)

Page 105

DEAD THRESHOLD
DYING BASE
DYING INCREMENT
DYING THRESHOLD
INACTIVE BASE
INACTIVE INCREMENT
MAXIMUM BUFFERS
MAXIMUM RECALLS
MAXIMUM TRANSMITS
OWNER
RECALL TIMER
TRANSMIT TIMER

4.3.2.4

CLEAR and PURGE LINE Commands

The format of these commands is:

CLEAR
PURGE

1 LINE line-id
1 KNOWN LINES
I
I
I
I
I
I

4.3.2.5

ALL
COUNTER TIMER
DEAD TIMER
DELAY TIMER
HOLDBACK TIMER
MAXIMUM RETRANSMITS
SCHEDULING TIMER
STREAM TIMER
......................

CLEAR and PURGE MODULE Commands

These commands vary considerably depending on the module named.
The
following descriptions take this into account by describing the
options independently for each defined module identification.

4.3.2.5.1

CLEAR and PURGE MODULE X25-ACCESS Commands

The format of these commands is:

Network Control Program (NCP)

Page 106

I f only one network is known, it is the default.
If more
network is known, the network qualifier must be included.

than

4.3.2.5.2

one

CLEAR and PURGE MODULE X25-PROTOCOL Commands

The format of these commands is:

Dte-qualifier indicates to
applies. It is of the form:

which

local

DTE

address

the

command

KNOWN DTES
DTE dte-address
I f more
I f only one local DTE address is known, it is the default.
than one local DTE address is known, the parameter must be included.

Group-qualifier indicates to
applies. It is of the form:

which

GROUP group-name
KNOWN GROUPS
Group-options is one or more of:
DTE dte-address
TYPE

closed

user

group

the

command

Page 107

Network Control Program (NCP)
4.3.2.5.3

CLEAR and PURGE MODULE X25-SERVER Commands

The format of these commands is:
Command I Entity

1 Parameter

1 Qualifier

-+-------------------+--------------------+-------------------

I MODULE X25-SERVER +I - _COUNTER
TIMER
_---__-_---__-----+-_----------------1
I [destination-qua11
1
I ACCOUNT

CLEAR
PURGE

1
1
1
1
1
1
1
1

ALL
CALL MASK
CALL VALUE
GROUP
NUMBER
PASSWORD
PRIORITY
USER

1
1
1
1
I
1
1
I

--------+-------------------+--------------------+-------------------

Destination-qua1 indicates to which destination the
It is of the form:

command

applies.

KNOWN DESTINATIONS
DESTINATION destination-name
I f only one destination is known, it is the default. I f more than one
destination is known, the parameter must be included.

4.3.2.6

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 apply here.

1
1

1 EVENT event-list
1 KNOWN EVENTS

I [sink-node]
1 [source-qualifier]

-+-------------------+--------------------+-------------------

4.3.2.7

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 CIRCUIT option where it must be
a
name.
EXECUTOR
may
substitute
for
NODE
executor-nodeidentification.

Network Control Program (NCP)
Command I Entity

Page 108

1 Parameter

-+--_-_______________+-------------------------------------

CLEAR
PURGE

1 NODE node-id
1
1
I
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1

I ALL
1 CIRCUIT
1 COUNTER TIMER
I CPU
1 DIAGNOSTIC FILE
1 DUMP ADDRESS
1 DUMP COUNT
1 DUMP FILE
1 HARDWARE ADDRESS
1 HOST
1 IDENTIFICATION
1 INCOMING TIMER
1 LOAD FILE
1 NAME
1 OUTGOING TIMER
1 SECONDARY DUMPER
1 SECONDARY LOADER
1 SERVICE DEVICE
1 SERVICE CIRCUIT
1 SERVICE PASSWORD
1 SOFTWARE IDENTIFICATION
1 SOFTWARE TYPE
1 TERTIARY LOADER

--------+_-------_-_--___--_+_-__-____-___-________--__---_-------

4.3.3

TRIGGER Commands

These commands trigger the bootstrap of the target node so that the
node will load itself. I t 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. Parameters specified with a command override the
default parameters of the same type. If the circuit is an Ethernet
circuit, the PHYSICAL ADDRESS must be included in the TRIGGER VIA
command. The format of the commands is:
Command I Entity

1 Parameter

TRIGGER I NODE node-id

1
1

1 [PHYSICAL ADDRESS ethernet-address]
1 [[SERVICE] PASSWORD password]
I [VIA circuit-id1

1 VIA circuit-id
1

1 [PHYSICAL ADDRESS ethernet-address]
1 [[SERVICE] PASSWORD password]

Network Control Program (NCP)
4.3.4

Page 109

LOAD Commands

These commands initiate a down-line load. There are two variations.
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.

4.3.4.1

LOAD NODE Commands

These commands load the node identified on the circuit identified or
on the circuit obtained from the volatile data base. Any parameter
not specified in the command line defaults to whatever is specified in
the volatile data base at the executor node.
Command I Entity

1 Parameter

- -------+---------------------+---------------------------------------

LOAD

1 NODE node-id
I
1
1
1
1
1
1
1
1
1
1
1
1

1 [ADDRESS node-address]
I [CPU cpu-type1
I [FROM load-file]
I [HOST node-id]
1 [NAME node-name]
1 [PHYSICAL ADDRESS ethernet-address]
1 [SECONDARY [LOADER] file-id]
1 [SERVICE DEVICE device-type]
1 [SERVICE NODE VERSION node-version]
1 [[SERVICE] PASSWORD password]
1 [SOFTWARE IDENTIFICATION software-id]
1 [SOFTWARE TYPE program-type]
1 [TERTIARY [LOADER] file-id]
I [VIA circuit-id1

-+----__---------------+---------------------------------------

4.3.4.2

LOAD VIA Commands

With these commands, the executor loads the target over the specified
circuit, obtaining the node identification from the volatile data base
if necessary. I f the circuit is an Ethernet circuit, the PHYSICAL
ADDRESS must be included in the command. The command format is:
Parameter
[ADDRESS node-address]
[CPU cpu-type]
[FROM load-file]
[HOST node-id1
[NAME node-name]
[PHYSICAL ADDRESS ethernet-address]
[SECONDARY [LOADER] file-id]
[SERVICE DEVICE device-type]
[SERVICE NODE VERSION node-version]

Network Control Program (NCP)

4.3.5

Page 110

DUMP Commands

These commands perform an up-line dump.
Parameters not supplied
default to those in the volatile data base at the executor node.
There are two variations.

4.3.5.1

DUMP NODE Commands

The format for these commands is:
Command I Entity

1 Parameter

------+---------------------+---------------------------------------

DUMP

I NODE node-id
1
1
1
1
1
1

I
1
1
I
1
1
1
1

[[DUMP] ADDRESS number]
[[DUMP] COUNT number]
[PHYSICAL ADDRESS ethernet-address]
[TO dump-file]
[SECONDARY [DUMPER] file-id]
[SERVICE DEVICE device-type]
[[SERVICE] PASSWORD password]
[VIA circuit-id]

----.+----------_-_--------+---------------------------------------

4.3.5.2

DUMP VIA Commands

I f the circuit is an Ethernet circuit, the PHYSICAL ADDRESS
included in the command. The format for these commands is:
Command I Entity

must

1 Parameter

--+---------------------+---------------------------------------

DUMP

I VIA circuit-id
1
1
1
1
1
1

I
1
1
I
1
1
1

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

---+---------------------+---------------------------------------

Page 111

Network Control Program (NCP)
4.3.6

LOOP Commands

These commands cause test blocks to loop back from the specified line
or node.
There are three variations, as described in the next three
sect ions.

4.3.6.1

LOOP CIRCUIT Commands

These perform loop testing on a specific circuit.
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:
Command I Entity

1 Parameter

--------+ - - - - - - _ _ - - - - - _ - - - - - - - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

LOOP

I CIRCUIT circuit-id
1
1
I
1
1
1
1
1

[ASSISTANT NODE node-id]

1 [ASSISTANT PHYSICAL ADDRESS
I
ethernet-address]
I [COUNT count1

I [HELP help-type]

1
1
1
I

[LENGTH length]
[NODE node-id]
[PHYSICAL ADDRESS ethernet-address]
[WITH block-type]

-----+--.-------------------+---------------------------------------

If the circuit is an Ethernet circuit, and PHYSICAL ADDRESS is not
included in the command, the Ethernet address used will be the
loopback assistant multicast address. This will result in an output
of the physical address that responded first.
HELP and ASSISTANT PHYSICAL ADDRESS can only be used with Ethernet
I f HELP is specified, an ASSISTANT PHYSICAL ADDRESS or
circuits.
ASSISTANT NODE must be included.
Ethernet circuits must be owned by MODULE LOOPER.

4.3.6.2

LOOP LINE Commands

The line loop performs loop 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:

Page 112

Network Control Program (NCP)
4.3.6.3

LOOP NODE Commands

A node loop will not interfere with normal traffic, but will add to
the network load.
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 9 and 10, Section 5.9.1).
EXECUTOR may be
substituted for NODE executor-node-identification. The command format
is as follows:

4.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 # 1 3 ;
REQUEST
NUMBER

4.3.8

SHOW QUEUE
EXECUTOR

COMMAND

STATUS
LOAD

FA1 LED

SHOW
LOAD
SET
SHOW

COMPLETE
IN PROGRESS
COMPLETE
IN PROGRESS

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 format of the
SHOW and LIST commands is:

Page 113

Network Control Program (NCP)
Verb I Entity

1 Parameter

1 Qualifier

SHOW I ACTIVE AREAS
LIST I AREA area-number
1 KNOWN AREAS

I CHARACTERISTICS 1
1 COUNTERS
1
1 STATUS
I

-----+----_--__--___--_---_-+____-___--___-___+-____-_-___---__-------

+_------_-___-___-____-+

SUMMARY

I ACTIVE CIRCUITS

+-----------------------

1
1 CIRCUIT circuit-id
I
1 KNOWN CIRCUITS
1
1 SIGNIFICANT CIRCUITS 1
+---------------------+
1 ACTIVE LINES
1
1 KNOWN LINES
1
1 LINE line-id
1
1 SIGNIFICANT LINES
1
1 ACTIVE MODULES
1
1 KNOWN MODULES
I
+__--__--__--__-___-_-+
I MODULE X25-ACCESS
I
I
I

I [ADJACENT NODE
node- id]
I
1
1

[KNOWN NETWORKS]

1 MODULE X25-PROTOCOL
I
I
I

1
I
I
I

1
I
I
1

[DTE dte-address]
[GROUP group-name]
[KNOWN DTESI
[KNOWN GROUPS]

1 MODULE X25-SERVER
I
I

1
I
I

[DESTINATION

+_----_--_--_____-___-_+

1 [NETWORK network-name]

+-----------------------

I
destination-name1
1 [KNOWN DESTINATIONS]
+-----------------------

1 SIGNIFICANT MODULES
1 ACTIVE NODES

1
1

1 ADJACENT NODES
I

1
I

Network Control Program (NCP)

Page 114

KNOWN plural entities are all those known to the system, regardless of
state. ACTIVE and SIGNIFICANT plural entities are subsets 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.
Sections 2 and 4.1.1 describe the information types, except SUMMARY.
SUMMARY returns the most important information relating to the
specified entity.
The tables in Section 7 specify the parameters and/or counters
returned for each information type and entity.

Qualifiers can be placed either before or after the information type.
When a qualifier is not specified in a command, the default is the
'KNOWN" qualifier. An additional qualifier can be used for all
entities:
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 command,
the phrase "no information" is displayed in place of the data.

4.3.8.1

Information Type Display Format

All of the SHOW and LIST command information-type options
same general output format. The header of that format is:
REQUEST

have

the

n; entity information-type AS OF dd-mon-yy hh-rnrn

For example:
REQUEST

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

REQUEST

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

REQUEST

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

The requested information follows the header.

The general

format

Network Control Program (NCP)

Page 115

the information is:
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.

4.3.8.2

Counter Display Format

Counters are identified by standard type numbers as defined in Tables
6-8, 11-13, 18, and 19, Section 7.
Counters are displayed in
ascending order by type. The display format for counters is:
value description);, INCLUDING:]
qualifier-1

qualifier-n
The value is the value of the counter, up to 10 digits for a 32-bit
counter.
I t 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-bitlcounter would be displayed as ">254."
The description is the standard text that goes with the counter type
as defined in Tables 6-8, 11-13, 18, and 19. 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. I f the standard
text for the bit is not known, the qualifier "QUALIFIER #n" is used,
where n is the bit number. '
For example:
REQUEST #21;

CIRCUIT COUNTERS AS OF 20-MAY-83 15:29

CIRCUIT = DUP-6
532
416
0

TERMINATING PACKETS RECEIVED
ORIGINATING PACKETS SENT
TERMINATING CONGESTION LOSS

Page 116

Network Control Program (NCP)
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

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

Section 7 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.
Section 7 details these
logical groupings.
The general output format of the data fo,r tabular form is:
entity-type

parameter-type

ent ity-id

parameter-value

...
parameter-value ...

'parameter-type

An example of output of the data in tabular form follows:
REQUEST

39;

KNOWN CIRCUITS STATUS AS OF 18-SEP-78 1 5 ~ 2 0

CIRCUIT

STATE

BOSTON- 0

Page 117

Network Control Program (NCP)
CHICAGO
CORUNNA

OFF
ON-LOADING

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, Section 7, for type
numbers. )
4

The general output format of the data for sentence form is:
entity-type = entity-id
par-type = par-value, par-type = par-value,
par-type = par-value,

...

An example of output of the data for sentence form follows.
REQUEST # 3 9 ;

KNOWN CIRCUITS STATUS AS OF 18-SEP-78

15:20

CIRCUIT = BOSTON-0
STATE = ON
CIRCUIT = CHICAGO
STATE = OFF
CIRCUIT = CORUNNA
STATE = ON
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
Logging Summary as of 7-MAR-79 10:55
Logging CONSOLE
State = ON, NAME = COO:
Sink node = 15 (HALDIR), EVENTS =
0.0,6
Line KDZ-0-1.6, 3.6-7
3.6-13
Sink node = 16 (EOWYN), Events =

Page 118

Network Control Program (NCP)
Line KDZ-0-1.6, 6.0-1

4.3.8.4

Restrictions and Rules on Returns

The following restrictions and rules apply to returns on SHOW and LIST
entity information type commands.
Node parameters. The parameters displayed for the SHOW and
LIST NODE commands depend on which node is specified. Table
20, Section 7, indicates these restrictions.
The keywords
EXECUTOR, REMOTE or LOOP must precede NODE in a display of a
node to clarify what is displayed.
Line and circuit states. The returns on the SHOW and LIST
LINE/CIRCUIT STATUS commands must show the link substate as
well as the state.
Loop nodes. Information for a single loop node is returned
when requested by the loop node name.
~nformation 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 with the SHOW
commands, and with line, circuit, module, 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.

4.3.9

ZERO Commands

These commands cause a specified set of counters to be set to zero. A
zero 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:
Command I Entity

1 Parameter

Network Control Program (NCP)

Page 119

For module X25-PROTOCOL the following qualifiers are added:
KNOWN DTES
DTE dte-address
If more
I f only one l o c a l DTE address is known, it is the default.
than one local DTE address is known, the parameter must be included.

4.3.10

EXIT Command

This command terminates an NCP session.

Network Management Operation
5

Page 120

NETWORK MANAGEMENT OPERATION

This section specifies the functionally-correct operation of Network
Management.
Implementations may use algorithms other than those
contained herein, as long as the function is as specified here.
The
operations described in this section are:
NICE Access Routines and Listener (Section 5.1)
Local Network Management Functions (Section 5.2)
Link Watcher (Section 5.3)
Data Link Service Functions (Section 5.4)
Event Logger (Section 5.5)
Down-Line Load (Section 5.6)
Up-Line Dump (Section 5.7)
Trigger Bootstrap (Section 5.8)
Loop Test (Section 5.9)
Change Parameter (Section 5.10)
Read Information (Section 5.11)
Zero Counters (Section 5.12)
Loopback Mirror (Section 5.13)
NICE Logical Link Handling (Section 5.14)
Algorithm for Accepting Version Numbers (Section 5.15)
Return Code Handling (Section 5.16)
For Ethernet circuits, there is a special algorithm necessary in some
cases.
It is needed for Trigger, Dump, or Load Operations when the
Ethernet address is not contained in the request. In this case, there
are two possible Ethernet addresses: the hardware address from the
node data base, or the expansion of the DNA node address.
To choose which of these addresses to use, the executor runs a normal,
single message loop test to the hardware address. If this does not
succeed within 2 seconds, the executor aborts it and tries the same
loop test to the expanded DNA address. If this does not succeed
within 2 seconds, the executor repeats the entire process 3 more
times. If at the end of this procedure no response has been received,
the original request fails with a communication error. If a response
is received, that Ethernet address is used to satisfy the original
request

5.1

NICE 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

Network Management Operation

Page 121

Access Routines can pass all local function requests to the Local
Network Management Functions. Alternatively, the access routines car?
pass NICE messages to the Network Management Listener via a logical
link. The latter method cannot be used for functions, such as turnins
the network on, that occur before a logical link is possible.

5.2

Local Network Management Functions

The Local Network Management Functions receive the following types
requests from other modules:

System-independent function requests from the local
the Network Manaqement Access Routines.

NCP

NICE function requests
Management Listener.

nodes

via

the

Network

NICE function requests from the local node
Manaqement Listener.

via

the

Network

Automatically-sensed service requests from the Link Watcher.

The Local Network Management
to other modules or layers:

from

other

unctions have the

following

via

interfaces

Maintenance
unctions - The
Local
Network
Management
functions have interfaces to the Maintenance Functions as
described in the DNA Low Level
Maintenance
Operation
specification.

Management
Link Service Functions - The Local Network
Functions have a control interface to the Data Link Service
Functions for setting and changing circuit and line states.
The
Local
Network Management Functions have a "user"
interface to the Data Link 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.

Function requests to lower layers and to local operating
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.

Network Management Operation
o

Page 122

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.

Sections 5.6 to 5.16 supply algorithms for handling Network Management
function requests.

5.3

Link Watcher

The Link Watcher module senses data link level service requests to
up-line dump or load coming on an exclusive maintenance link from an
adjacent node.
The Line Watcher senses a request by calling the Data Link Service
Functions.
Using parameters from that message, the Link Watcher then
determines the request type and calls the Local Network Management
Functions to accomplish the request.
The algorithm for implementing the Link Watcher is as follows:
Call Link Service Functions to get Data Link Service request for
link
IF Link Service requested
Set link state to ON-AUTOSERVICE (Local Network Manaqement
Functions)
Determine function needed
Call Network Management Functions to perform needed
function(s)
Reset link state to ON ( ~ o c a lNetwork Manaqement ~unctions)
END I F
Section 5.10 describes the algorithms for setting and
states for the Link Watcher.

5.4

resetting

link

Data Link Service Functions

The Data Link Service Functions provide exclusive maintenance link
state changing and link handling services.
They are used for
functions requiring a direct interface to the Data Link layer.
The
functions that use the Data Link Service Functions are:
o

Down-line load (Section 5.6)

Up-line dump (Section 5.7)

Trigger bootstrap (Section 5.8)

Link test (Section 5 . 9 . 2 )

Page 123

Network Management Operation
1.
2.

Active at the executor node
Passive at the target node (for unattended system)

Set link state (Section 5.10)

The Data Link Service Functions provide the following services:
o

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 "ken
over. Control rests with the executor.

Notify a higher level that active link services (load, aump)
are needed.

Provide transmit/receive interface to higher level for active
link services.

Section 3.6 describes line and circuit states and substates.

5.4.1

States and Substates

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

Link
State

Link
Substate

Link
Service
State

Link
Service
Substate

passive

idle

-STARTING

passive

idle

ON
ON

-REFLECTING
-LOAD ING

passive
open

reflecting
loading

-DUMPING

open

dump i ng

-TRIGGERING

open

triggering

Link Service
Function in
Progress or
Allowed
Pass message to
higher level
Pass message to
higher level
Passive loopback
Receive and
transmit loading
messages
Receive and
transmit dumping
messages
Receive and

Page 124

Network Management Operation

-LOOPING

open

looping

-AUTOSERVICE

closed

idle

-REFLECTING
-AUTOLOADING

closed
open

reflecting
loading

-AUTODUMPING

open

dump i nq

-AUTOTRIGGERING

open

triggering

closed

idle

SERVICE
SERVICE
SERVICE

-REFLECTING
-LOAD ING

closed
open

reflecting
loading

SERVICE

-DUMPING

open

dump i ng

SERVICE

-TRIGGERING

open

triggering

SERVICE

-LOOPING

open

looping

off

idle

OFF

5.4.2

transmit
triggerinq
messages
~ e c e i v eand
transmit looping
messages
Pass messaqe to
higher level
Passive loopback
~ e c e i v eand
transmit -oadinq
messages
Receive and
transmit dumping
messages
Receive and
transmit
triqgerinq
messages
Pass messaqe to
higher level
passive loopback
Receive and
transmit loading
messages
Receive and
transmit dumping
messages
Receive and
transmit
triggering
messages
~ e c e i v eand
transmit looping
messages
-

Priority Control

The Data Link 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.

In some implementations, this

Network Management Operation

5.4.3

Page 125

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

Link State Algorithms

The algorithms that follow are a model for implementation of the Data
I f these algorithms are followed, tne proper
Link Service states.
state transitions will take place. The algorithms refer to Data
ink
maintenance mode.
This is a Data ink layer mode (DDCMP functional
specification).
Set link state to off:
Call Data Link to halt link
Set substate to idle
Set link state to passive:
IF link state is off or closed
IF substate is not reflecting
Set substate to idle
END I F
ELSE
Fail
END I F
Set link state to closed:
IF link state is off, passive, or open
IF link state is off or passive and substate is not
reflecting
Call Data Link to set link mode to maintenance
Set substate to idle
ENDIF
ELSE
Fail
END I F
Set link state to open:
IF link state is passive or closed
Call Data Link to set link mode to maintenance
IF substate is reflecting
Terminate passive loopback
ENDIF
Record substate according to open parameter

Page 126

Network Management Operation
ELSE
Fail
END I F
NOTE

The Data Link call to set the link 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.

5.4.4

Link Handling Functions

The link handling services of the Data Link Service
algorithms for implementing them follow.
1.

unctions and

the

Handling link in passive state (for entering service slave
mode, passive loopback and passing message to a higher
level :
WHILE link state is passive
Call Data Link to see i f link mode has qone to
maintenance
IF link mode has qone to maintenance
Call Data Link to receive the service messaqe
IF enter service slave mode message
Enter service slave mode
ELSE IF loop data message
Perform passive loopback algorithm
ELSE IF looped data message
Ignore
ELSE
On request, pass message to higher level
END IF
IF link state is still passive
Call Data Link to halt link
END I F
END I F
ENDWHI LE

Handling link in closed state (for enterinq
mode and performing passive loopback):
WHILE link state is closed
Call Data Link to receive messaqe
IF enter service slave mode message
Enter service slave mode
ELSE IF loop data message
Perform passive loopback algorithm
ENDIF
ENDWH I LE

service

slave

Network Management Operation
3.

Page 127

Handling link in open state (for entering service slave mode,
receiving a message, and transmitting a message;:
WHILE link state is open
IF transmit requested
Call Data Link to transmit message
ELSE IF receive requested
IF data overrun recorded
Return data overrun error
ELSE
Post receive requested
END I F
END I F
Call Data Link to receive message
IF enter service slave mode message
Enter service slave mode
ELSE
IF receive posted
Return message
ELSE
Record data overrun
END IF
END I F
ENDWHI LE

Handling passive link loopback
target node):

(passive

the

remote

( ~ n i t i a lmessage already received)
Set substate to reflecting
WHILE substate is reflecting
IF loop data message
Call Data Link to transmit looped data message with
received data
Call Data Link to receive a message
IF timeout or start received or error or loopback
terminated
Set substate to idle
ENDIF
ELSE
Set substabe to idle
END I F
ENDWH I LE

5.5

Event Logger

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

Page 128

Network Management Operation
events.
---------------

I Event Monitor 1
I

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- I -- -- --- - - - - 1
I

NETWORK MANAGEMENT LAYER
----------- ------------------1 Event
- - > I Event
- - > I Event /-->I
from Event
:
I ~ e c e i v e r ! . - > I Recorder I - - . [
Queue I
Transmitters :
----- ---------- 1 1
'----------I
I

I
I
I ,------_1
1 Event 1
- > I Queue I - > :

I
I
I
1
1

----------- I

I I

--processed events----.I

1 1
1 1

----------- .vl

oni it or

I Interface 1

--_--Ã‘-

-- - - - - - I

----------Event
1

. .

--- -----

'--------I

Event

---- ---: File
:
I
-------I
1
--------- - -- -- - - .
I
1 Event 1 1 Event
1
I
'--->I
Queue 1 - > I Console 1
'
I

0I
1 Event
o-----------.
I Processor I
I
I
0------I
----------- ' \
1
1
------------ ---A
Event
1
1
1
Filters 1
1
I
I
I
-------------------I
I
I
1
I
I Event I I Event
1
1
1
- - - > I Queue 1 - > I' Transmitter I - - ----------------- --------I
I
â€¢Event - - - - - - > I
1
to
1
event
/
1 Queue I
1
------(
I
I
: receivers

. .

\
raw events

------- > I Queue

1 - > I ~ransmitter 1 -

-------- 1

LOWER LAYERS

------------- I

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

1
<-------I
Figure 6.

Event Queues I<-------raw events

-------------- I

Event Logging Architectural Model

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

Allow events to be logged to multiple
the source node.

sink

nodes

including

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

any

Network Management Operation

Page 129

Allow the definition of subsets of events for
node by event type and source node.
Include the following
monitor program.

logging

Allow sharing of sinks between
local system event logging.

sink

sinks:

console,

file,

and

network

event

logging

and

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

network

Never block progress of network
logging performance limitations.

functions

communication
due

event

Minimize loss of event logging information
limitations.

due

resource

Record loss of event
limitations.

due

resource

logging

information

When required due to resource limitations, discard newer
information (which can often be regained bv 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.
1
Allow independent control of sinks at sink no e l including
sink identification and sink state. Sink stat s include use
of sink, non-use of sink, and temporary unav liability of
sink.

5.5.1

Event Logger Components

As shown in Figure 6, the Event Logger
components, described in this section:
o

Event queue

Event processor

Event transmitter

Event receiver

Event recorder

consists

following

Page 130

Network Management Operation
o

Event console

Event file

Event monitor interface

Event monitor

Event queue - - There are several event queues (Figure 6).
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:
o

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

It fills a queue with one module; empties it with another.

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

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 queue is full
Discard the event
ELSE
IF this event would fill the queue
Discard the event
IF last event on queue is not "events-lost"
Queue an "events-lost" event (which fills the queue)
END I F
ELSE
Queue the event
ENDIF

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

events

according

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

event

queues

and

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 also
filtered.
Specifically, this means that event 0.0 cannot be
filtered unless all other events are filtered.

Event Processor

This component performs the following functions:

Network Management Operation
1.

Scans the lower level
records.

Page 131
event

queues,

collecting

raw

event

Modifies raw events into processed
contain the following fields:

events.

Raw

events

EVENT CODE

DATA

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

The event source node maintains all filters.

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

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

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

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

The filtering algorithm sees first if there is a specific
filter that applies to the event by looking for an event
mask whose source qualifier matches the entity name
field.
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

filters

Network Management Operation

Page 132

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 implementations, 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.

5.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 i f it is possible to
do so.
If not supported, this fieldwill n o t b e p r i n t e d . 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]

Network Management Operation

Page 133

FROM NODE address[ (node-name)]OCCURRED [ d d - m ~ n - ~ ~ I h h : mss:
m :[ .uuul
[entity-typeLentity-name]]
[data]
For example:

Event type 4 . 7 , Packet ageing discard
From node 27 (DOODAH), occurred 9-FEB-79 13:55:38
Packet header = 2 23 91 20
Event type 0.3, Automatic line service
From node 19 (ELROND), occurred 9-FEB-79 16:09:10.009
Line KDZ-0-1.3, Service = Load, Status = Requested
Or, on a node that does not recognize the events:
Event type 4.7
From node 27, occurred 9-FEB-79 13:55:38
Parameter #2 = 2 23 91 20
Event type 0.3
From node 19, occurred 9-FEB-79 16:09:10.009
Line KDZ-0-1.3, Parameter #0 = 0 , Parameter #1 = 0

5.6

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

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

The target node must be running a minimal cooperating program
r e f e r to the DNA Low Level Maintenance specification). This
program may be a primary loader from a bootstrap ROM.
The
down-line load 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 link 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 Maintenance Functions.

SERVICE

Maintenance Function modules are used to obtain local files.
Remote files are obtained via remote file access techniques.

Page 134

Network Management Operation
(Refer to the DAP functional specification.)
Figures 7A and 7 B , following,
access for a down-line load.

snow

local

and

remote

file

which

can

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

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

I
I

-----------

----------- 1

1 Network
1
1 Local File 1
- - - - - - - - - - - 1 Management\--------------\Accessing
1
I
I
I Layer
I
I Processes I

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

. Local File:<---------I
: System

----------- 1

1 -------------------TARGET 1

-----

I
I
1
1

1
1 MOP 1
1
1
'--_----'

NODE

Figure 7A.

1
1
1
I

LEGEND:
MOP - Maintenance Operations Protocol

Down-Line Load Local File Access Operation

I
1
i

I
I
I

Page 135

Network Management Operation

LEGEND:

I
MOP - Maintenance Operations Protocol
FAL - File Access Listener

Figure 7B.

1
I

: Local
: File
: System

:
:

I
I
I

Down-Line Load Remote 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. I f 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 on
which the trigger message came. Or, the target node could request the
load from another executor. The Link 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 t.hat request. Figures 8A and 8B, following,
show the down-line load request operation.

Network Management Operation

Page 136
EXECUTOR NODE

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

I
I
I

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

* - - - - - - - - - - - a

I
I------------1
1

---------- > I Line

I Local

I
I
I
I
1

I
I
1 Management 1
1 Function
1

> I Network

1 Watcher
I
I
1
1
1
I
I
I
I
I
' - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -1 - - - I
----- I - - - - - - - - - - - - - I
------TARGET 1
I
I
1
NODE
I i
I
I
1 1 MOP I<----------------------------------------!
I I
I
I
I
I
,-----------I

II
I

------------I

--------I

'-------I

Figure 8 A .

Target-Initiated Down-Line Load Request Operation
EXECUTOR NODE

Logical Link ( N I C E )

--------- 1 ------------------------I
I
1 COMMAND 1
1 Network
I

1
1
1
I
I
I
I

Figure 8 B .

1 Management I NODE
1
1 Access
1 Routines
1

------------I

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

Operator-initiated Down-Line Load Request operation from a
Remote Command Node

1
I
I
I
I
I
I

Network Management Operation
The executor proceeds with the load according to the
initial request.

Page 137
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
Dump/Load Server portion of 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 circuit.
The name and address parameters may be supplied as overrides to those
in the data bases. The address or link identification key into the
node data base.
I f link 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 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 ~ p p e n d i xE.
The algorithm for handling the down-line load is as follows:

Page 138

Network Manaqement Operation
Call Data Link Service Function to open link for load.
Call Maintenance Functions to perform load.
Call Data Link Service F u n c n o n to close line.

5.7

Up-line Dump Operation

The up-line dump capability of the Network Management layer
system to dump its memory to a file on a network node.

allows

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

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

network

node

The system being dumped must run a minimal cooperative program
that can communicate over the link with the executor. The
protocol used is in the Low Level Maintenance Operation
specification.

If the executor determines that the program is not there, then
executor must supply the program.
This is the secondary
dumper.

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

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. ( ~ e f e r to the DAP Functional
Specification.)

returned

The system to be dumped can indicate that it is capable of being
dumped.
In this case, the Link Watcher at the executor node senses
the possibility of a dump a n d 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 Manaqement Functions then accomplish the dump using the
Maintenance Functions 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

Network Management Operation

Page 139

requesting the operation.
The content of the dump file is specified in Appendix E.
The algorithm for performing the up-line dump is as follows:
Call Data Link Service Function to open line for dump.
Call Maintenance Functions to perform dump.
Call Data Link Service Function to close line.

5.8

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
link. The node on the network side of the link 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.
When 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.
The physical link being used must be in the ON or SERVICE state at the
executor node's end. The executor uses the Maintenance Functions 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 implemen.ting the trigger bootstrap is as follows:
Call Data Link Service function to open link for trigger.
Call Maintenance Functions to perform trigger.
Call Data Link Service function to close link.

Page 140

Network Management Operation
5.9

Loop Test Operation

There are two types of loop rests, node level
Both types are loopback zests that loop
specified number of times.

and data link level.
a standard test block a

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, length1' (~ppendixF) 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 oe 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.
If the test is on an Ethernet circuit and no physical address is
specified, the test is done with the loopback assistance multicast
address. The responding station's physical address is included in the
response.

5.9.1

Node Level Testing

There are two general categories of node level tests (shown in Figures
9 and 10, 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 CIRCUIT 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 circuit to
be used)

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

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.

Network Management Operation
The set up commands for various types
described in Figures 9A through 10D.

Page 141
of

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 circuit is involved in the
test, it must be in the ON state. If the Loopback ~ i r r o ris involved,
the message is passed co the Loopback Mirror Access Routines (see
Section 5.13). One logical link loop test uses a loop node with a
routing node on the remote end of the line ( ~ i g u r e s9A - 9D). This
test returns the test data on the circuit chosen by the Routing
algorithm at the routing node.

Page 142

Network Management Operation
SET LINE line-id CONTROLLER LOOPBACK
SET NODE FISHY CIRCUIT circuit-id
(~ransferfile from FISHY)
NODE BOB

1 1 ----------- / / -------------------I
1 1
/ /
I
I-------------------------1 1 --------- / / .....................
I
1 DATA LINK
1 1
/ /
1
[-------------------------1 1 - - - - - - - / / - - - - - - - - - - - - - - - Hardware
1 PHYSICAL LINK
1 1
/ /
Device in
'-----------------------1 -1 - - - - - - / / - - - - - - - - - - - - - - - - - Loopback
I'
~i
\ Mode
- - - -\ - - - I \ \
( (
I
I--------------------------

ROUTING

Figure 9A.

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

Communications Hardware

Local-to-Loopback Node Test, Single Node (using files as
test data, with a software controlled loopback capability)

Page 143

Network Management Operation
SET NODE FISHY CIRCUIT circuit-id
LOOP NODE FISHY
NODE BOB

I
I
1
1
I
I

NETWORK
MANAGEMENT

Figure 9 B .

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

" 1 -------------------

1 Local Network Management Function
.....................................

Node Test, Single Node (using loopback mirror
messages, and a manually set loopback device)

1
I

and

I
I
I

test

Network Management Operation

Page 144

SET NODE FISHY CIRCUIT circuit-id
(Invoke user task using BOB and FISHY)
NODE BOB

NODE TONY

USER
MODULES
NETWORK
MANAGEMENT
NETWORK
APPLICATION
SESSION
CONTROL
NETWORK
SERVICES
ROUT ING
DATA LINK
PHYS I CAL
LINK

Figure 9C.

Local-to-Loopback Node Test, Two Nodes (using user task)

Network Management Operation

Page 145

SET NODE FISHY CIRCUIT circuit-id
LOOP NODE FISHY
NODE BOB

NODE TONY

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

USER
MODULES

I
1
I

-------

i i
1
I

NCP

------- I

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

I
1

1
I

l-----------l
A ----------I
l-----------------------l
1 *--------" 1 -------- . I I
1 1 Xetwork Management 1 1
1
1 1 Access Routines
I 1 I
1 '-------- 1 A
NETWORK
I I
1 -------- . I
MANAGEMENT 1 * - - - - - - - I
1 1 Local Network
1 1 1
1 1 Management Function 1 1 1
1 '-- 1 A -------------I
1 ---- " 1 ----------------I
I-----------------------[
1 *------------------ . I
I
NETWORK
I I Loopback I I ~oopbacklI I
APPLICATION 1 1 Access
1 1 Mirror 1 1 1
1 1 Routines 1 ' - - - - - - - - - I
1
/ /
I I
I---1 1 ------- / / - - - - I
[-----------------------I
SESSION
I
I I
/ /
I I
CONTROL
I
I I
/ /
I I
I---1 1 ---- / / -------I
I-----------------------[
NETWORK
I
I I
/ /
I I
SERVICES
I
I I
/ /
I I
1 - / /-----------I
I----------- - - - - - - - - - I
l-----l
\ .
ROUT ING
I
I
I
( (
I I
I-------[
1 1 I---------[
I------\
\ \ \-----------I
DATA LINK
I I I I
I
\ \ \ \
I I
\--------\ \ \ \---------I
l-------l
1 1 [---------I
PHYSI CAL
I
\ \ \ \
I
I
I I I I
LINK
I
\ \ \ \
I I
I l l 1
---------- . \ \
\
'---- - - I
1 1 I-1 \ \ \ \ '---------- I l l 1 I
I \ \ \ \
I l l 1 I
1
\ \ \ ' - - - - - - - - - - - - - -gill I
\ \
, - - - - - - - - - - - - - - -I- -l
l I
I
\
'
I
I
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
I
I
1 Communications Hardware
1

--------I

. .

'----------I

a - .

\---.--I

I
1
I
I
I
1
I
I

I
1
1
I
I
I
I

I
I
I
I
I
I

------I

1
I

Figure 9D.

Local-to-Loopback Node Test,
mirror and text messages)

Two

Nodes

(using

loopback

Network Management Operation

Page 146

(LOOP NODE BOB) or (LOOP EXECUTOR)
NODE BOB

I
I
1
1
I

USER
MODULES
-------------

I Network Management Access Routines
NETWORK
MANAGEMENT

1 A -------------------'
------------- " 1 -------------------

I Local Network Management Function

" 1 -------------------

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

NETWORK
APPLICATION

I Loopback

1 Access Routines

1
I

I Loopback I
I - -M- -irror
e
I
--------

[-------------------------- 1 1 - - - - - - - - - - - - - - - - - - - 1 1 -----------I
1 ROUTING
1 ' - - - - - - - - - - - - - - - - - - - - '- 1
1
I----------------------__-_ ' - - - - - - - - - - - - - - - - - - _ - - _ - - _ '
----------_I
1 DATA LINK
1

PHYSICAL LINK

Figure 10A.

Communications Hardware
.......................................

Normal Local-to-Local (using loopback mirror)

Page 147

Network Management Operation
Invoke user task using BOB)
NODE BOB
..................................................................

1
1
1

USER
MODULES

UserTask

-------------- I

User Task

--------------- I

v ------------------- 1 --------------I
I
I
I
1
1
A
v
I
1 ------------------- 1 --------------I

I
1 NETWORK
1 APPLICATION
I
I---------------------------

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

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

PHYSICAL LINK

------------- .........................

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

I
I
I
I
I
1
Figure 10B.

I
..........................

Communications Hardware

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

Normal Local-to-Local (using user tasks)

I
I
I
1
1
I
1
1
I

I
I

Network Management Operation

Page 148

LOOP NODE TONY
NODE BOB

NODE TONY

USER
MODULES

NETWORK
MANAGEMENT

NETWORK
APPLICATION

SESSION
CONTROL
NETWORK
SERVICES
ROUT ING
DATA LINK
PHYS ICAL
LINK

1 Communications Hardware

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

Figure 1 0 C .

I
I

Normal Local-to-Remote (using loopback mirror)

Page 149

Network Management Operation
(Transfer files from BOB to TONY)
NODE BOB

NODE TONY

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

- - - -- - -

I
1
1
I

USER

MODULES

1 User
1 Task

------- I

----- v

I
NETWORK
1
APPLICATION 1
I

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

ROUT ING

1
1
I----------1

DATA LINK

[-----------

Figure 1 0 D .

5.9.2

-----.

1 File Access 1
1 Routines
1

[-----------

NETWORK
SERVICES

1
1

1 -----------I
1
1
1 -----------I
1
1 -----------I
1

i i

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

---- - --

1
1
I

I
1
1
I

1
1

I---------1
1
I----------

1 User
1 Task

1
1

------- I

----- 1 -----

1 File Access 1
1 Listener
I

------------- I

I---------I

1 ----------I
1
1
1 ----------I
1
1 ----------I
1

I
1
I
I
I
1
I
I

1
1

Normal Local-to-Remote (using files as test data)

Data Link Testing

Data Link level testing requires a direct interface between the Data
Link Service Function and the Data Link layer. Figures 11A and 11B,
at the end of this section, show two types of data link level tests:
1.

Direct link loopback, hardware looped

Direct link loopback, software looped

Link loopback requires the use of data link service software (for
example, MOP), with the link to be tested in the ON or SERVICE state.
The hardware-looped option requires an operator-controlled loopback
controller, a modem set to loopback mode, a ROM with loopback

Network Management Operation

Page 150

capabilities at the remote end, or some other equivalent operation.
It is recommended that the operator turn off the link, reconfigure the
hardware, and then turn the link back on. Alternatively, the operator
may leave the link 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 Data Link Service Functions to open link for active loop
WHILE not done
Call Maintenance Functions to loop message
Call Data Link Service Function to receive message
IF error OR count exhausted OR message is not loop data or
looped data OR received data does not match sent data
Set done
ENDIF
ENDWH I LE
Call Data Link Service Function to close link

Page 151

Network Management Operation
[SET CIRCUIT circuit-id STATE OFF]
{ (manually set loopback device)
{ SET CIRCUIT circuit-id STATE ON/SERVICE
{ LOOP CIRCUIT circuit-id

1
1

* }

(circuit in ON or SERVICE state)
{ SET LINE line-id CONTROLLER LOOPBACK
{ (LOOP CIRCUIT circuit-id)

EXECUTOR NODE

I
1
1

1
1
1
1

NETWORK
MANAGEMENT

--.

....................
v I
.
1 Network Management 1
1 Network Management 1
1 Access Routines
<---->I Listener
I
- - - - - - - - - - - - - 1 A --I
'
1 A ----_-I
- - - - - - - v 1 - - - - - - - - - - - - - - - - - - - v 1 -.
1 Local Network Management Functions, 1
1 Maintenance Functions, and
1
1 Link Service Functions
1
-------------

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

implementation dependent

Figure 11A.

Direct Line, Hardware Looped, Data Link Loopback Tests
and Command sequences Effecting Them

I
1
I
I

1
1

Network Management Operation

Page 152

LOOP CIRCUIT circuit-id
(circuit at TARGET NODE in SERVICE or ON state * )
EXECUTOR NODE
..............................
I . -------

USER
MODULES

NETWORK
MANAGEMENT

DATA LINK
PHYSICAL
LINK

' --

NCP

----- f

TARGET NODE

. .. . . . . . . . . . . . . . . . . . . . . . .
I

----------- . I
1 * - - - - v I ---.
1 1 Network
I
I Network 1 1
1 1 Management1
I Management1 1
1 1 Access
< - > I Listener 1 1
1 1 Routines 1
1
11
1 '
1 A ----I
- - - 1 A ---'I
1 .-- v 1 - - - - - - - - - - - - v I - - - . 1
1 1 Local Network
1
1 1 Management Function,
1
1 1 Maintenance Functions,
11
I I
and
1
11
1 1 Link Service Functions
1 ' - - - - 1 A ------------------ ' I
I------ 1 1 -------------------I
1
I I
1
-. .
1
\ \
1
1
\ \
1
-

1
1

1
1
1
I
1

*-------------------

1
1
1
1

i i

I I

I I
I
I

------ I

I---------- 1 1 - - - - - - - - I
1
/ /
1
/ /-----------I
1
/ /
1
1
I
/ /
'
- / / *------------I

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

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

I
I
I
I
I

implementation dependent

Figure 11B.

5.10

---------

1 Communications Hardware
*

1 1
1 1

Maintenance
Functions and
Link Service
Functions

\ \ - - - ------------I
------------------- /
I \ \
/
I \ \
/ /
I \ ' - - - - - - - - - - _ - - - - - _ _'_/- -

I
I
. I

Direct Line, Software Looped, Data Link Loopback Tests
and Command Sequences Effecting Them

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 response is then returned to the
requester.
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.

I f there

are

none,

Network Management Operation

Page 153

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 link state requires the following capabilities:
For operator:
o

Set link state to OFF

Set link state to ON

Set link state to SERVICE

For the Link Watcher:
o

Set link state to ON-AUTOSERVICE

Reset link state from ON-AUTOSERVICE

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

succeed.

Set link state to OFF:
Call link's high level user to set link state to off
Call Line Service Function to set link state to off
Set link state to ON:
Call Data Link Service Function to set link state to passive
IF success
Call link's high level user to set link state to on
ELSE
Fail
END I F
Set link state to SERVICE:
Call Data Link Service Function to set link state to closed
IF success
Call link's high level user to set link state to off
ELSE
Fail
ENDIF

Network Management Operation

Page 154

Set link state to ON-AUTOSERVICE:
IF link state is ON
Perform algorithm to set link state to service
ELSE
Fail
ENDIF
Reset link state from ON-AUTOSERVICE:
IF link state is ON-AUTOSERVICE
Perform algorithm to set link state to on
ENDIF

5.11

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 (Section 7 ) . 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 Section 7.
Additional information is in Section 4.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.

5.12

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

5.13

Loopback Mirror Operation

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

Network Management Operation

Page 155

a simple protocol - - the Logical Loopback Protocol. The loopback
mirror function operates in the Network ~pplicationDNA layer.
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 ( ~ i g u r e10,
Section 5). The Loopback Mirror continues to repeat all traffic
offered. The initiator of the link disconnects it.

5.14

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 6.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 buffer size for NICE messages is 300 bytes.
The Network Management Listener algorithm follows:
Receive connect request
Optionally) Determine privilege 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 message
IF message received
Process command message according to command and
privilege
Send response message(s)
END I F
ENDWH I LE
ELSE
IF received version number not OK
Send connect \reject with version skew reason in reject
data
ELSE
Send connect reject
ENDIF
END I F
NOTE
The algorithms used for connections are implementation
dependent. For example, connections can be maintained
is
set,
permanently, only while
the
executor
timed-out, or one per command.

Network Management Operation

Page 156

The Network Management command source algorithm follows:
Send connect request with version number in connect data
IF connect accepted
IF received version number OK
WHILE desired
Send command message
Receive response message(s)
ENDWHI LE
ELSE
Failure due to version skew
END IF
Disconnect link
ELSE
IF connect rejected by 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
END I F
END I F
Use the following algorithm for an event transmitter:
Send connect request with version number in connect data
IF connect accepted
IF received version number OK
WHILE desired
Send event message
ENDWHI LE
ELSE
Failure due to version skew
END I F
Disconnect link
ELSE
Perform implementation specific error handling
END I F
Use the following algorithm for an event receiver:
Receive connect request
IF resources available and received version number OK
Send connect accept with version number in accept data
WHILE connected
Receive event messages
ENDWH I LE
ELSE
Send connect reject
ENDIF

Network Management Operation
5.15

Page 157

Algorithm for Accepting Version Numbers

A version number consists of three parts -- version, ECO (Engineering
Change Order), and user ECO (Section 6.12). In general, another
version is acceptable if it is greater than or equal to this version.
I f 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

For Event Loqqinq, the lack of a version number implies Version 2.0.

5.16

Return Code Handling

Use the following return code handling algorithm to call
Management access routines:

the

Network

Initiate function
IF return code = more (2)
WHILE return code <> done (-128)
Perform next operation
Process success/failure (1,3,<0)
ENDWH I LE
ELSE
Process success/failure (1,<0)
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
entities).
Use the following algorithm for deciding
Network Management access routines:

return

codes

within

IF multiple returns needed

Return "more" ( 2 )
ENDIF
WHILE more returns
IF success
IF all response data for entity in single return
OR last of multiple responses for this entity
Return "success" (1)
ELSE
Return "partial" (3)
ENDIF
ELSE
Return error code and other error information
ENDIF
ENDWHI LE
IF multiple returns needed
Return "done" (-128)
END I F

the

Network Management Operation

P a g e 158

Example:
T h e following sequence of messages might be returned in response t o
SHOW ACTIVE CIRCUITS command.
(2)
UNA- 0
UNA-0
UNA- 0
UNA- 1
UNA- 1
UNA- 1
UNA- 2
DMC-2
(-128)

Page 159

Network Management Messages

NETWORK MANAGEMENT MESSAGES

This section describes the NICE and Event Logging Messages, the NICE
response message format, the NICE connect and accept data format, and
the Logical Link Message format,

NICE is a command-response protocol.

Because the Network Management
layer is built on top o f the End Communication 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 messag,e should be parsed and checked
any operation is performed.

for

validity

before

The method for indicating that a function should be executed on all
parameters in the data base for a particular entity (NCP ALL option)
is to not include any parameters in the NICE function request message.
Parameters in command and response messages must be in ascending order
by parameter type number, except that qualifiers must proceed the
parameters they qualify. A parameter of the same type may be repeated
for parameters that compose a list.
Qualifiers are restricted to one of the same parameter type per
I f qualified parameters appear in a
command or response message.
message the qualifier must appear in the same message.
Unqualified
parameters may or may not be included in a message with a qualifier.
All qualified parameters in a messaqe with a qualifier must be
associated with that qualifier.
In a sequence of multiple return
messages, when qualifiers are nested, the outer level qualifier is not
repeated until it changes.

6.1

NICE Function Codes

The NICE protocol performs the following message functions. The last
one is for system specific commands, not specified in this document.

Page 160

Network Management Messages
NICE
Function

Function
Code
15
16
17
18
19
20
21
22

6.2

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

Message Format Notation

The Network Management message format descriptions use
notat ion.
FIELD (LENGTH) :

the

following

CODING = Description o f 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. I f
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; i f binary,
then 7 bits from each byte are concatenated into a
single binary field; i f 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.
4.

The letters "I-n" meaning image field with n being a
number which is the maximum length in 8-bit bytes o f the
image. The image is preceded by a 1-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

Network Management Messages

Page 1 6 1

and interpretation of each image field is
that specific field.
5.

defined

with

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

COD ING
Is the representation type used.
where:
A = 7-bit ASCII
B = Binary
BM = Bit Map (where each
independent meaning)

bit

group

bits

has

C = Constant

Notes:

6.3

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

generic
in the

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

shall be
field not

All numeric values in this document are
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 Section 7
described at the beginning of that section.

Request Down-line Load Message Format

FUNCTION
CODE

OPTION

NODE

CIRCUIT

PARAMETER
ENTRIES

shown

decimal

Network Management Messages

Page 162

where:
FUNCTION CODE (1) :
OPTION (1) BM

B = 15

Is one of the following options:
Opt ion bit

~alue/Meaning

0-2

0 = ~dentifytarget by node-id.
3 = Identify target by circuit-id.

NODE

Is the target node identification (see Section 7 )
as key into defaults data base (present only i f
option = 0).
Plural nodes options are
not
allowed.

CIRCUIT

Is the circuit identification (see Section 7 ) .
Plural circuits options not allowed. Present only
if option = 3.

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 Section
7).

DATA

Is the parameter
Section 7 ) .

data

NOTE
The parameters
parameters:

allowed

are

the

following

ADDRESS
CPU
DIAGNOSTIC FILE
HOST
LOAD FILE
NAME
PHYSICAL ADDRESS
SECONDARY LOADER
SERVICE DEVICE
SERVICE CIRCUIT (allowed only if option = 0)
SERVICE PASSWORD
SOFTWARE IDENTIFICATION
SOFTWARE TYPE
TERTIARY LOADER

node

(see

Page 163

Network Management Messages
6.4

Request Up-line Dump Message Format

FUNCTION
CODE

OPTION

NODE

CIRCUIT

PARAMETER
ENTRIES

where:
FUNCTION CODE (1):

OPTION (1) : BM

Is one of the following options:
Value/Meaning

Option bits

0 = Identify target by node-id.
3 = Identify target by circuit-id.

0-2
NODE

Identifies the node to be dumped (present only i f
option = 0). Format is defined in Section 7.10.

CIRCUIT

Specifies the circuit over which to dump (present
only if option = 3). Format is defined in Section
7.4.

PARAMETER ENTRIES

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

DATA

where:
DATA ID ( 2 ) . :

Is the parameter type number
s e e note below and Section
7).

Is the parameter
Section 7 ) .

DATA

data

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
PHYSICAL ADDRESS
SECONDARY DUMPER
SERVICE CIRCUIT (allowed only if option = 0 )
SERVICE PASSWORD

(see

Network Management Messages

6.5

Page 164

Trigger Bootstrap Message Format

FUNCTION
CODE

OPTION

NODE

CIRCUIT

PARAMETER
ENTRIES

where:
FUNCTION CODE (I): B
OPTION (1) :

Is one of the following options:
Option bits

Value/Meaning

0 = Identify target by node-id.
3 = Identify target by
circuit-id.

0-2

NODE

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

CIRCUIT

Identifies the circuit over which to trigger the
boot (present only if option = 3 ) . The format is
defined in Section 7.4.

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 Section
7).

Is the parameter
Section 7).

DATA

data

NOTE
The parameters are selected from the node parameters.
Only certain parameters are allowed in the trigger
message. They are:
PHYSICAL ADDRESS
SERVICE CIRCUIT (allowed only i f option = 0)
SERVICE PASSWORD

(see

Page 165

Network Management Messages
6.6

Test Message Format

FUNCTION
CODE

OPTION

NODE

USER

PASSWORD

ACCOUNTING

LINK

PARAMETER
ENTRIES

where:
FUNCTION CODE (I):

OPTION (1) : BM

Is one of the following options:

Option bits

~alue/Meaning
0 = Node type loop test
1 = Line loop test
3 = Circuit loop test

0-2

I f node type loop test:
0 = Default access controi
1 = Access control included
For node type loop tests only
follows:

four

parameters

are

NODE

Identifies the node to loopback the test block
in node-id format. 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 to
Present only if option bit 7 = 1.

node.

ACCOUNTING

Is the accounting information to use
when
connecting to node. Present only if option bit

(I-39):A

7 = 1.

(option O ) ,

For line or circuit tests only (option 1 or 3 ) , one
follows:

parameter

LINK

Identifies the link to send the test on in
circuit- or line-id format. Plural options not
allowed.

PARAMETER ENTRIES

Are zero or more of PARAMETER ENTRY,
of:
DATA
ID

consisting

DATA

where:
DATA ID ( 2 ) :

Is the parameter

type

number

Page 166

Network Management Messages
(see
7).

note

below

Is the parameter
Section 7 ) .

DATA

and Section
data

(see

NOTE
The parameters are selected from the node parameters.
Only certain parameters are allowed in the test
message. They are:
LOOP ASSISTANT NODE
LOOP ASSISTANT PHYSICAL ADDRESS
LOOP COUNT
LOOP HELP
LOOP LENGTH
LOOP NODE
LOOP WITH
PHYSICAL ADDRESS

6.7

Change Parameter Message Format

FUNCTION
CODE

OPT I ON

ENT ITY
ID

PARAMETER
ENTRIES

where:
FUNCTION CODE (1):
OPTION (1):

Is one of the following options:
Bits
Meaning
7

0 = Change volatile parameters.
1 = Change permanent parameters.

0 = Set/define parameters.
1 = Clear/purge parameters.

0-2

Entity type (Section 7 ) .

ENTITY ID

Identifies the particular entity (Section 7 ) .

PARAMETER ENTRIES

Are zero or more of PARAMETER
of:
DATA
ID
where:

DATA

ENTRY

consisting

Network Management Messages

Page 167

DATA ID (2) :
DATA

Is the parameter
s e e Section 7).
Is the parameter
Section 7).

type
data

number
(see

NOTE
The DATA field is not present when option bit 6 is set
unless the parameter is a qualifier rather than a
parameter that is to be cleared.

6.8

Read Information Message Format

FUNCT ION
CODE

OPTION

ENT ITY
ID

PARAMETER
ENTRIES

where:
FUNCTION CODE (I): B = 20
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-2

Entity type (Section 7 ) .

ENTITY ID

Identifies the particular entity (Section 7 ) .

PARAMETER ENTRIES

0 or more parameter entries, formatted as for
change parameter message. These are limited to
the following qualifiers:
CIRCUIT ADJACENT NODE
LOGGING SINK NODE
MODULE X25-ACCESS NETWORK
MODULE X25-PROTOCOL DTE GROUP
MODULE X25-SERVER DESTINATION
NODE CIRCUIT

Network Management Messages
6.9

Page 168

Zero Counters Message Format

FUNCT ION
CODE

OPT ION

ENTITY
ID

PARAMETER
ENTRIES

where:
FUNCTION CODE (I):

B =

OPTION ( I ) : BM

Is one of the following options:
Bits

Meaning

1 = Read and zero
0 = Zero only

0-2

Entity type (Section 7).
(Circuit, line, module,
or node only).

ENTITY ID

Identifies the particular
Section 7).

PARAMETER ENTRIES

0 or more parameter entries, formatted as for
change parameter message. These are limited to
the following qualifiers:

entity,

required

MODULE X25-PROTOCOL DTE

6.10

NICE System Specific Message Format

FUNCT ION
CODE

SYSTEM
TYPE

REMAINDER

where:
FUNCTION CODE (1) : B = 22
SYSTEM TYPE (1) :

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

command

System
RSTS
RSX family
TOPS-10/20
VMS
RT
CT
Communications Server

REMAINDER ( * ) :

Consists of data, depending on
requirements.

system

specific

Page 169

Network Management Messages
6.11

NICE Response Message Format

RETURN
CODE

ERROR
DETAIL

ERROR
MESSAGE

ENTITY
ID

TEST
DATA

DATA
BLOCK

where:
RETURN CODE ( 1 ) :

[ERROR DETAIL] ( 2 ) :

Is one of the
(Appendix F ) .

standard

NICE

return

codes

B Is more detailed error information according
to the error code (e.g., a parameter type).
Zero if not applicable. I f applicable but not
available, its value is 65,535 (all bits set).
In this case it is not printed.
Applicable
only if 0 > RETURN CODE > -128.
Is a system-dependent error message that may
be output in addition to the standard error
message.
Identifies a particular entity (Section 7) i f
operation is on plural entities, or operation
is read information or read and zero counters.
I f the entity is the executor node, bit 7 of
the name length is set.

[TEST DATA] ( 2 ) :

Is the information resulting from a test
operation ( ~ e s t message only). This is only
required if a test failed and if data is
relevant, or a data block is present in this
message. It is UNLOOPED COUNT or MAXIMUM LOOP
DATA, depending on ERROR DETAIL. Section 5.9
further explains its contents.
Is one of the data blocks described in Section
7 (returned for read information message or
read and zero message). For Test messages it
may contain the parameter PHYSICAL ADDRESS.

I f 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 only 2 with no other fields, 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 id. A return code of -128 indicates the end of multiple
responses.

Page 170

Network Management Messages
6.12

NICE Connect Initiate and Connect Accept Data Formats

The first three bytes of the connect initiate and connect accept
are:
VERSION

DEC
ECO

data

USER
ECO

where:
VERSION (1) : B

Is the version number

DEC ECO (1) : B

Is the DIGITAL ECO number

USER ECO (1) : B Is the user ECO number

6.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
CODE

EVENT
TIME

SOURCE
NODE

EVENT
ENT I TY

EVENT
DATA

where:
FUNCTION CODE (1) : B = 1 , meaning event log
SINK FLAGS (1) :

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

Sink

0
1
2

Console
File
Monitor

receive
The bit

EVENT CODE ( 2 ) : BM Identifies the specific event as follows:

EVENT TIME

Bits

Meaning

0-4
6-14

Event type
Event class

Is the source node date
processing. Consists of:

and

time

event

Paqe 171

Network Management Messages
JULIAN
SECOND
HALF DAY

MILLISECOND

where:
JULIAN HALF DAY (2) :

SECOND (2) :

SOURCE NODE

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
second
current
0-999).
If
not
supported, high order
bit is set, remainder
are clear, and field
is not printed when
formatted for output.

Identifies the source node.
NODE
ADDRESS

It consists of:

NODE
NAME

where:

EVENT ENTITY

NODE ADDRESS (2) :

Node
address
Section 7.9).

see

NODE NAME (1-6) :

Node name,
if none.

length,

Identifies the entity involved in the event, as
applicable. Consists of:
ENTITY ENTITY
TYPE
ID
where:
ENTITY TYPE (2) :

EVENT DATA ( * ) :

Represents the type of
entity.
A
-1
value
indicates no entity.
A
value >= 0 is the entity
type and is followed by
the
entity id in its
usual format.

B Is event specific data, zero or more data entries
as defined for NICE data blocks, parameter types

Page 172

Network Management Messages
according to event class.

6.14

Logical Loopback Message Formats

6.14.1

Connect Accept Data Format

MAXIMUM DATA
where:
MAXIMUM DATA ( 2 ) :

6.14.2

B Is the maximum length,
Loopback Mirror can loop.

bytes,

Command Message Format

FUNCTION DATA
CODE
where:
FUNCTION CODE (1) :
DATA ( * ) :

6.14.3

B = 0

B Is the data to loop.

Response Message Format

RETURN CODE

DATA

where:
RETURN CODE (1) : B Indicates Success (1) or Failure (-1).
DATA ( * ) : B

Is the data as received, if success.

tnat

the

Page 173

Parameter and Counter Binary Formats and Values
7

PARAMETER AND COUNTER BINARY FORMATS AND VALUES

This section describes the binary formats of all entities, parameters,
counters, and events, as well as the returns used in the NICE protocol
and Event Logging messages in response to a request for information.
Section 3 describes the entities, parameters, counters, and events
along with their user level formats.

7.1

Introduction to Binary Format Descriptions

Read this section before the rest of Section 7. This section explains
notation format, symbols, and other general information pertaining to
all entities. Since the symbols and notation are only explained in
this section, you may need to refer back to it when studying Tables 5
thru 29.

7.1.1

Type Numbers

Each entity,
parameter
and counter is assigned
entity type numbers are as follows:
Type Number

type

number.

The

Keyword
NODE
LINE
LOGGING
CIRCUIT
MODULE
AREA

Entity type fields have 3-bit lengths.
The parameter and counter type numbers appear in the
sect ion.

7.1.2

this

entity

type

tables

Entity Parameter Identifier Format

The following format is for input (NCP
parameter:
ENTITY TYPE (1):

NML)

Is the entity type. The values are defined as type numbers in
section 7.1.1.
If the entity type is NODE, it is followed by a
node identification.

Page 174

Parameter and Counter Binary Formats and Values
7.1.3

String Identifier Format

The string type identifiers use the following
describes this format notation.)
ID FORMAT (I):

Is the identification
following values:

format.
format

(Section

type,

with

6.1
the

Number Meaning
-5
-2
-1

>O
ID:

7.1.4

Significant (if applicable)
Active (if applicable)
Known (if applicable)
Length of identification

Is the ASCII identification i f ID FORMAT >0.

Node Identifier Formats

When represented in binary, node identification is one of a number o f
different formats (limited by the particular function). All choices
begin with a format type. This applies to all occurrences of node
identification. The input (NCP to NML) format is as follows:
NODE FORMAT (I): B Represents the node format type, as follows:
Number

-5
-4
-3
-2
-1
0
>O

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

In the ENTITY ID field of a response message bit 7 set
node identification is the executor node.

indicates

the

NODE ADDRESS ( 2 ) :

B Is the node address if NODE FORMAT = 0.
When
used as input, a node address of zero implies the
executor node.

NODE NAME:

Is the node name if NODE FORMAT >0.

The usual binary output (NML to NCP) format is as follows:
NODE
NODE
ADDRESS NAME

Page 175

Parameter and Counter Binary Formats and Values
where:
NODE ADDRESS (2):
NODE NAME (1-6):

7.1.5

Is the node address. When supplied as output
node address of 0 indicates a loo^ node.

Is the node name, 0 length implies none.

Area Identifier Format

When represented in binary, the format of an area identification is as
follows:
AREA FORMAT (I):

B Represents the area format type, as follows:
Number
-2
-1

Active areas, no further data
Known area, no further data
Area number

0
AREA NUMBER (1):

7.1.6

TYPe

B Is the area number if AREA FORMAT = 0.

Object Format for Entity Types

The following format

for input

object parameter:

OBJECT FORMAT ( I ) : B Is the object identification format
the following values:
Value
0

type,

with

object

name,

Meaning
Numeric object number
Length of object name

If the OBJECT FORMAT = 0 3
OBJECT NUMBER (1):

B Is the object type number.

If the OBJECT FORMAT >0:
OBJECT NAME:

Is the ASCII object type.

On output the value is either an object
distinguishable by the data type.

number

Parameter and Counter Binary Formats and Values

Page 176

Numeric Range

7.1.7

All occurrences of a numeric range use a common format.
format is:
BEGINNING (2):
END (2):

On inputl the

Is the range beginning.
Is the range end. If range consists of
numberl END equals BEGINNING.

single

The output format for a range is a coded multiple field with two
numbers for a range and one number for a single vall~e. For multiple
(disjoint) rangesl the parameter must be repeated.

Parameter Display Format and Descriptive Encoding ~ o t a t i o n

7.1.8

Each parameter is assigned a data type at Network Management layer
level that describes the format of the parameter. This information
allows NCP to format and output most parameter values in a simple wayf
even i f NCP does not recognize the parameter type.
The notation used in the parameter tables in this section to
these data types is as follows:
Notat ion

describe

Data Type
Codedl single fieldl n bytes
Codedl multiple fieldf n fields
Not coded (any of the following)
ASCII image fieldf maximum n bytes
Decimal numberl unsignedl n bytes
Decimal numberl signedl n bytes
Hexadecimal numberl n bytes
Hexadecimal imagel maximum n bytes
Octal numberl n bytes

Image formats (AI-n and HI-n) are displayed left to right in the order
in which the bytes of data appear in the NICE messagel i.e.l the order
of printed text. For Ethernet address or protocol type parametersf
each byte of an HI-n data image (two characters) is separated from the
next byte by a hyphen ( - ) .
Numbers are displayed most significant
digits first with no separation of bytes. Hencel hexadecimal images
appear in reverse byte order from hexadecimal numbers.

7.1.9

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 counter entriesf depending on
the information requested.

Parameter and Counter Binary Formats and Values

Page 177

When an imp lementation recognizes the parameter type of a coded fieldl
the value output should be the keyword(s) or other interpretation that
corresponds to the code for that parameter type.
I f the parameter
type is not recognizedl the field should be formatted as hexadecimal.
The format of a data entry is as follows:
DATA ID (2):

BM =

Identifies particular data entity:
Bit Value Meaning
15

Parameter data.
Bits

Meaning

0-11

Parameter type, interpreted according to entity
type
Reserved

12-14
15

The rest of the bits are as follows:

Counter data.
Bits

The rest of the bits are as follows:

Value Meaning

0-11
12

Counter type
not bit mapped
bit 'mapped
reserved
8 bit counter
16 bit counter
32 bit counter

0
1
0
1
2
3

13-14

DATA TYPE (1): BM =
Identifies data typel present only for parameter data:
Bit Value Meaning
7

Not coded.

The rest of the bits are as follows:

Bit Value Meaning
6

Binary number.
follows:

The rest of the bits are as

Bits Value Meaning
0-3
4-5

0
>O
0
1
2
3

implies data is image field.
data length.
Unsigned Decimal Number
Signed Decimal Number
Hexadecimal Number
Octal Number

Parameter and Counter Binary Formats and Values
6

ASCII image field.

Page 178

Bits 0-5 zero.

Coded, interpreted according to PARAMETER TYPE.
The rest of the bits are as follows:
Bit Value Meaning
6

BIT MAP ( 2 ) :

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

Is the counter qualifier bit mapp included
counter and counter is bit mapped.
DATA:

only

DATA

IS the data!

according to data id and type.

The data required for setting a parameter or counter is the entity
identification, the DATA IDl and the DATA. The information required
for clearing a parameter or counter is the entity identification and
the DATA ID. When a parameter is displayedp the information is entity
idl DATA IDl 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:
Range

for

system

Reserved for
RSTS specific
RSX specific
TOPS-10120 specific
VMS specific
RT specific
CT specific
Communication Server specific
Future use

specific

counters

Parameter and Counter Binary Formats and Values
3900-4095

Page 179

Customer specific

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

Keyword

Associated Zntity

CHARACTERISTICS
STATUS
SUMMARY
EVENTS

All entities
All entities
All entities
LOGG I NG
Qualifier

Qualifier indicates that the parameter is used as a qualifier for
parameters that follow it.

7.1.11

the

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

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
Indicates a parameter
must be qualified

7.1.12

Setability Restrictions

Some parameters have user setability restrictions, indicated
section by the following notation:
Symbol

Meaning

Read only

this

Parameter and Counter Binary Formats and Values

Page 180

Write onlyl in the sense that it appears in a
different form in a reaa function. (For example,
a node name can be setl but it is read as part of
a node id. 1
Loop only

7.2

Circuit Parameters

The following table specifies the circuit parameters.
Table 5
Circuit Parameters
TYP~
Number

Data
Type

Inf.
Type

App.
Rest.

c- 1
s*
c-1
s*
c-1
c
DU- 2
C
HI-6
S*rQ
C- 1
S*
Q
CM-112 S*
DU- 2
AI-6
CM-112 S*
DU- 1
AI-16
AI-6
S*
CM-112 s*[~],Q
DU- 2
AI-6
CM-112 S
DU- 2
AI-6
DU-1
DU-1
DU- 1
DU-2

C
C
C
C

DU-1
DU- 2
AI-16

C
C
C

Set.
Rest.

NCP
Keywords
STATE
SUBSTATE
SERVICE
COUNTER TIMER
SERVICE PHYSICAL ADDRESS
SERVICE SUBSTATE
CONNECTED NODE
node address
node name (optional)
CONNECTED OBJECT
object number
object name
LOOPBACK NAME
ADJACENT NODE
node address
node name (optional)
DESIGNATED ROUTER
node address
node name (optional)
BLOCK SIZE
ORIGINATING QUEUE LIMIT
COST
MAXIMUM ROUTERS
ROUTER PRIORITY
HELLO TIMER
LISTEN TIMER
BLOCK I NG
MAXIMUM RECALLS
RECALL TIMER
NUMBER

Parameter and Counter Binary Formats and Values
RO

DU-2

RO
AI-16
c-1
c- 1
AI-16
DU-2
DU-2
DU-1
DU-1
DU-2
DU-2
c-1
DU-1
DU-1
DU- 1
DU- 1
DU- 1
DU- 1
DU-1
DU- 1
DU-1
DU-1

c
c

C
C
C
C
C
C
C

C
C
C
C
C
C
C
C
C
C

Page 181

USER
Entity type
Entity name (if entity is not
node)
Node address (if entity is
node )
Node name ( i f entity is node)
POLLING STATE
Polling substate
OWNER
(Format same as for USER)
LINE
USAGE
TYPE
DTE
CHANNEL
MAXIMUM DATA
MAXIMUM WINDOW
TRIBUTARY
BABBLE TIMER
TRANSMIT TIMER
MAXIMUM BUFFERS
MAXIMUM TRANSMITS
ACTIVE BASE
ACTIVE INCREMENT
INACTIVE BASE
INACTIVE INCREMENT
INACTIVE THRESHOLD
DYING BASE
DYING INCREMENT
DYING THRESHOLD
DEAD THRESHOLD

[l] SHOW CIRCUITS STATUS for broadcast circuits shows all adjacent
nodes.
SHOW CIRCUITS SUMMARY for broadcast circuits shows only
router adjacent nodes.
The values for STATE are:
Value

Keyword

0
1
2

ON
OFF
SERVICE
CLEARED

The values for SUBSTATE and SERVICE SUBSTATE are:
Value

Keyword

STARTING

1
2

REFLECTING
LOOP ING

Page 182

Parameter and Counter Binary Formats and Values
LOAD ING
DUMP ING
TRIGGERING
AUTOSERVICE
AUTOLOADING
AUTODUMPING
AUTOTRI GGERING
SYNCHRONIZING
FAILED
The values for SERVICE are:
Value

Keyword

0
1

ENABLED
DISABLED

The values for BLOCKING are:
Value

Meaning

0
1

ENABLED
DISABLED

The values for entity type and entity name can
7.1.1.
The values for POLLING STATE are:
Value

Keyword

0
1
2

AUTOMAT IC

ACT I VE

I NACT IVE
DYING
DEAD

The values for polling substate are:
Value

Keyword

1
2

ACT IVE
INACT IVE
DYING
DEAD

found

section

Page 183

Parameter and Counter Binary Formats and Values
The values for USAGE are:
Value

Meaning

0
1
,2

PERMANENT
INCOM ING
OUTGO ING

The values for TYPE are:
Value

Meaning
DDCMP POINT
DDCMP CONTROL
DDCMP TRIBUTARY
X25
DDCMP DMC
Ethernet
CI
QP2 (DTE20)
BISYNC

The values for MAXIMUM BUFFERS are:

7.3

Range

Meaning

1-254
255

Number of buffers
UNLIMITED

Circuit Counters

The circuit entity counters are listed in Tables 6-8, following.
The
definition of each counter and the way that it is incremented can be
found in the functional specification for the appropriate layer.
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 ~ p p e n d i x
I.
Circuit counters are specified for the following layers only:
Layer
Network Management
Routing
Data Link

Type Number
Range
000 - 099
800 - 899
1000 - 1999

The following counters are kept for all circuits, with
o f type number 805, which is X.25 only.

the

exception

Parameter and Counter Binary Formats and Values

Page 184

Table 6
Circuit Counters Kept for All Circuits
Type
Number

Bit
Width

Standard Text
Seconds Since Last Zeroed
Terminating Packets Received
Originating Packets Sent
Terminating Congestion Loss
Corruption Loss
Transit Packets Received
Transit Packets Sent
Transit Congestion Loss
Circuit Down
Initialization Failure

The following Data Link counters apply to DDCMP circuits:
Table 7
Data Link Circuit Counters for DDCMP Circuits
Type
Number

Bit
Width

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

Standard Text

Remote Reply Timeouts
Local Reply Timeouts
Remote Buffer Errors

Local Buffer Errors

Selection Intervals
Elapsed
Selection Timeouts

Bit Number
Standard Text

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
0 NAKs Received Buffer
Unavailable
1 NAKs Received ~ u f f e rToo
Sma 11
0 NAKs Sent Buffer
Unavailable
1 NAKs Sent Buffer Too
Small
0 No Reply to Select
1 Incomplete Reply to
Select

Parameter and Counter Binary Formats and Values

Page 185

The following Data Link counters apply to permanent X . 2 5 circuits:
Table 8
Data Link Circuit Counters for Permanent X . 2 5 Circuits

Type

Number

Bit

Width

Standard Text

Bytes received
Bytes sent
Data blocks received
Data blocks sent
Locally initiated resets
Remotely initiated resets
Network initiated resets
The following
circuits:

table

specifies

Data

Link

counters

for

Table 9
Data Link Circuit Counters for Ethernet Circuits
Type
Number

Bit
Width

0
1000
1001
1010
1011
1065

32
32
32
32

Standard Text

Seconds Since Last Zeroed
Bytes Received
Bytes Sent
Data Blocks Received
Data Blocks Sent
User buffer unavailable

Line Parameters

7.4

The following table specifies the line parameters:
Table 10
Line Parameters
Type
Number

Data
Type

Inf.
Type

C-1
C-1
C-1
DU-2
AI-16
DU-2
C-1

S*
S*
C
C
C
C
C

1
100
110
1100
1105
1110

Set.
Rest.
RO

NCP
Keywords
STATE
substate (not a keyword)
SERVICE
COUNTER TIMER
DEVICE
RECEIVE BUFFERS
CONTROLLER

Ethernet

Page 186

Parameter and Counter Binary Formats and Values
c-1
c- 1
c- 1
DU-2
DU- 2
DU- 2
DU-2
DU- 1
DU- 1
DU-2
DU- 2
DU-2
DU- 2
HI-6

DUPLEX
PROTOCOL
CLOCK
SERVICE TIMER
RETRANSMIT TIMER
HOLDBACK TIMER
MAXIMUM BLOCK
MAXIMUM RETRANSMITS
MAXIMUM WINDOW
SCHEDULING TIMER
DEAD TIMER
DELAY TIMER
STREAM TIMER
HARDWARE ADDRESS

The values for STATE, substate, and SERVICE are as listed
7.2 for circuit parameters.

Section

Communication DEVICE mnemonics (names) are:
Value

Name

Device

DP
UNA
DU
CNA
DL
QNA
DO
CI
DA
PCL
DUP
DMC

DP11-DA (OBSOLETE)
DEUNA multiaccess communication link
Dull-DA synchronous line interface

DN
DLV

DN11-BA or -AA automatic calling unit
DLV11-El - F , -J, MXV11-A or - B asynchronous line
interface
DMP11 multipoint interprocessor link
DTE20 PDP-11 to KL10 interface
DV11-AA/BA synchronous line multiplexer
DZ11-A, -B, -C, or -D asynchronous line multiplexer
KMCll/DUPll-DA synchronous line multiplexer
KMCll/DZll-A, - B , - C , or -D asynchronous line
multiplexer
KL8-J (OBSOLETE)
DMV11 interprocessor link
DPV11 synchronous line interface
DMF-32 synchronous line unit
DMR11-AA, -AB, -AC, or -AE interprocessor link
KMS11-PX synchronous line interface with X.25 level 2
microcode
KMS11-BD/BE synchronous line interface with X.25

DL11-C, -E or -WA asynchronous line interface
DQ11-DA (OBSOLETE)
Computer Interconnect interface
DA11-B or -AL UNIBUS link
PCL11-B multiple CPU link
DUP11-DA synchronous line interface
DMC11-DA/AR, -FA/AR, -MA/AL or -MD/AL interprocessor
link

DMP
DTE
DV
DZ
KDP
KDZ
KL
DMV
DPV
DMF
DMR
KMY
KMX

Parameter and Counter Binary Formats and Values

Page 187

level 2 microcode
The values for PROTOCOL are:
Value
0

1
2

3
4
5
6

Meaning
DDCMP POINT
DDCMP CONTROL
DDCMP TRIBUTARY
(reserved)
DDCMP DMC
LAPB
Ethernet

The values for DUPLEX are:
Value
0
1

Keyword
FULL
HALF

The values for CONTROLLER are:
Value

Keyword

0
1

NORMAL
LOOPBACK

The values for CLOCK are:
Value

Meaning

EXTERNAL
INTERNAL

7.5

Line Counters

The following table specifies the Data Link counters for LAPB lines.

Parameter and Counter Binary Formats and Values

Page 188

Table 11
Data Link Line Counters for LAPB Lines
Type
Number

Bit
Width

Standard Text

Bit Number
Standard Text

Seconds Since Last Zeroed
Bytes Received
Bytes Sent
Data Blocks Received
Data Blocks Sent
3 Block too long
Data Errors Inbound
4 Block check error
5 REJ sent
Data Errors Outbound
3 REJ received
Remote Reply Timeouts
Local Reply Timeouts
Remote Buffer Errors
2 RNR received, buffer
unavailable
Local Buffer Errors
2 RNR sent, buffer
unavailable
Remote Station Errors
4 Invalid N(R) received
5 FRMR sent, header
format error
Local Station Errors
2 Transmit underrun
4 Receive overrun
5 FRMR received, head
format error
The following table specifies Data Link counters for DDCMP lines:
Table 13
Data Link Line Counters for DDCMP Lines
Type
Number

Bit
Width

Standard Text

1020

Data Errors Inbound

1100

Remote Station Errors

1101

Local Station Errors

Bit Number
Standard Text

0 NAKs sent, header block
check error
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

Parameter and Counter Binary Formats and Values

Page 189

The following table specifies Data Link counters for Ethernet lines:
Table 13.1
Data Link Line Counters for Ethernet Lines
Type
Number

Bit
Width

0
1000
1001
1002
1010
1011
1012
1013
1014
1015
1060

1061
1062
1063
1064
1065
1066

7.6

Standard Text

Bit Number
Standard Text

Seconds Since Last Zeroed
Bytes Received
Bytes Sent
Multicast Bytes Received
Data Blocks Received
Data Blocks Sent
Multicast Blocks Received
Blocks sent, initially deferred
Blocks sent, single collision
Blocks sent, multiple collisions
Send failure
0 Excessive collisions
1 Carrier check failed
2 Short circuit
3 Open circuit
4 Frame too long
5 Remote failure to defer
Collision detect check failure
0 Block check error
Receive failure
1 Framing error
2 Frame too long
Unrecognized frame destination
Data overrun
System buffer unavailable
User buffer unavailable

Logging Parameters

When represented in binary, sink type is:
SINK TYPE (I):

Represents the logging sink type as follows:
Value

Meaning

-2
-1
1
2
3

Active sink types
Known sink types
CONSOLE
FILE
MONITOR

Sections 7.11 and 7.12 define all the event classes and their
associated events and parameters (not to be confused with the logging
parameters).

Parameter and Counter Binary Formats and Values

Page 190

Line and node counters provide information for event logging.
There
are
no
logging
entity
counters
specified,
just
status,
characteristics, and events.
The following table specifies the logging parameters:
Table 14
Logging Parameters
Param.

NICE
Data Type

Info
Type

APP~
Restr.

E
E

c*
EV*
EV*

s
s

The values for STATE are:
Value

0
1
2

Keyword
ON
OFF
HOLD

The values for entity type are:
Value

Meaning

-1
0
1

No entity
NODE
LINE
CIRCUIT
MODULE
AREA

3
4

The event class specification is:

NCP
Keywords
STATE
NAME
SINK NODE
Node address
Node name (optional)
EVENTS
Entity type
Node address (if entity type
is node)
Node name ( i f entity type is
node) (optional)
Entity id (if entity type is
not node)
Event class
Event mask (if single event
class indicated)

Page 191

Parameter and Counter Binary Formats and Values
Bits

Meaning

14-15

0 = Single class
2 = All events for class
3 = KNOWN EVENTS

0-8

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

The event mask specification is:
Event mask, bits set to correspond to event types (Table 22,
Section 7.11).
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 bits set (Section 3.2). 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.

7.7

Module Parameters

7.7.1

Console Module Parameters

The following
parameters.

table

specifies

the

maintenance

console

module

Table 14a
Console Module Parameters
Type
Number

Data
Type

Inf.
Type

110

DU-2

7.7.2

App.
Rest.

Set.
Rest.

NCP
Keywords
RESERVATION TIMER

Loader Module Parameters

The following
parameters.

table

specifies

the

maintenance

loader

module

Page 192

Parameter and Counter Binary Formats and Values
Table 14b
Loader Module Parameters
Type
Number

Data
Type

Inf.
Type

C- 1

App.
Rest.

Set.
Rest.

NCP
Keywords

ASSISTANCE

The values for ASSISTANCE are:
Value

Meaning

0
1

ENABLED
DISABLED

7.7.3

Looper Module Parameters

The following
parameters.

table

specifies

the

maintenance

looper

module

Table 14c
Looper Module Parameters
Type
Number

Data
Type

Inf.
Type

C- 1

App.
Rest.

Set.
Rest.

NCP
Keywords
ASSISTANCE

The values for ASSISTANCE are:
Value

Meaning

ENABLED
DISABLED

7.7.4

Configurator Module Parameters

The following table
parameters.

specifies

the

maintenance

configurator

module

Parameter and Counter Binary Formats and Values

Page 193

Table 14d
Configurator Module Parameters
Type
Number
100

Data
Type

Inf.
Type

APP
Rest.

AX-16

Q
s*

Set.
Rest.

110

c-1

Ill

CM- 3
S*
DU-2
DU- 1
DU- 1
S,Q
HI-6
CM- 5
S
DU- 1
c-1
DU- 1
DU-1
DU- 1
S
CM- 3
DU- 1
DU- 1
DU- 1
CM-1-16 S
c-1
HI-6
S
DU-2
S
DU- 2
S
DU-2
S
HI-6
S
c-1
s
CM-1/2 S
c- 1
AI-16

Q
Q

RO
RO

Q
Q
Q
Q
Q
Q
Q

RO
RO
RO
RO
RO
RO
RO

c-1

Q
Q
Q

RO
RO
RO

120
130

1001

1002
1003
1004
1005
1006
1007
1100
1200

1300
1400
1401

c- 1
DU- 2

s
s
S

NCP
Keywords
CIRCUIT
SURVEILLANCE
ELAPSED TIME
Hours
Minutes
Seconds
PHYSICAL ADDRESS
LAST REPORT
Day
Month
Hour
Minute
Second
MAINTENANCE VERSION
Version number
ECO number
User ECO number
FUNCT IONS
1-16 functions
CONSOLE USER
RESERVATION TIMER
COMMAND SIZE
RESPONSE SIZE
HARDWARE ADDRESS
DEVICE
SOFTWARE IDENTIFICATION
Generic Software type
Software ID string (present
only if generic software
type > 0)
SYSTEM PROCESSOR
DATA LINK
DATA LINK BUFFER SIZE

The values for SURVEILLANCE are:
Value

Meaning

0
1

ENABLED
DISABLED

The values for SYSTEM PROCESSOR and DATA LINK are found in the DNA Low
Level Maintenance Operation specification. The values for DEVICE are
the same as for the node parameter SERVICE DEVICE.
The format and
values of SOFTWARE IDENTIFICATION are found in the DNA Low level
Maintenance Operation specification.

Page 194

Parameter and Counter Binary Formats and Values
NOTE

The parameter type values for the information taken
from the DNA Low Level Maintenance Operation System
Identification message are the parameter types from
that message plus 1000.
The values for FUNCTIONS are the corresponding bit numbers for the
functions in the similar fields in the System Identification message.
The values for LAST REPORT month are 1-12
keywords JAN through DEC, respectively.

7.7.5

corresponding

month

X.25 Access Module Parameters

The following table specifies the X.25 access module parameters.
Table 15
X.25 Access Module Parameters
Type
Number

Data
Type

Inf.
Type

App.
Rest.

320

CM-1/2
DU- 2
AI-6
AI-39
AI-39
C-1
AI-39
AI-16

C
C
C
C
Q

Q
Q
Q
Q

330
331
331
332
1110

Set.
Rest.

WO
RO

NCP
Keywords
NODE
node address
node name (optional if none)
USER
PASSWORD (to set)
PASSWORD (to read!
ACCOUNT
NETWORK

On output, the PASSWORD parameter is not present
password. I f it is present, its value is:
Value
0

7.7.6

there

Meaning
Password set

X.25 Protocol Module Parameters

The following table specifies the X.25 protocol module parameters.

Parameter and Counter Binary Formats and Values

Page 195

Table 16
X.25 Protocol Module Parameters
Type
Number

Data
Type

Inf.
Type

c-1
c-1

100
1000
1010
1100
1101
1110
1120
1130

DU- 2
DU- 2
DU-2
AI-16
AI-16
AI-16
AI-16
CM-i/2
DU-2
DU-2

1131
1132
1140
1141
1150
1151
1152
1153
1154
1160
1161
1162
1163
1170
1171
1172

DU- 2
DU-2
DU- 2
DU- 1
DU-2
DU- 1
DU- 1
DU- 1
DU-1
DU- 1
DU- i
DU- 1
DU-1
AI-16
DU-2
c- 1

App.
Rest.

s*
C
S*
S*
Q
Q
C
C
C

C
C
C
C
C
C
C
C
C
C
C
C
C
C
C

The values for STATE are:
Value
0
1
2

Meaning
ON
OFF
SHUT

The values for Substate are:
Value Meaning
0
1

Running
Sync
Unsync

Set.
Rest.

NCP
Keywords
STATE
Substate (not a keyword)
COUNTER TIMER
ACTIVE CHANNELS
ACTIVE SWITCHED
DTE
GROUP
NETWORK
LINE
CHANNELS
range beginning
range end (none if same as
beginning'.
MAXIMUM CHANNELS
MAXIMUM CIRCUITS
DEFAULT DATA
DEFAULT WINDOW
MAXIMUM DATA
MAXIMUM WINDOW
MAXIMUM CLEARS
MAXIMUM RESETS
MAXIMUM RESTARTS
CALL TIMER
CLEAR TIMER
RESET TIMER
RESTART TIMER
DTE (qualified by GROUP)
NUMBER (qualified by GROUP)
TYPE (qualified by GROUP)

Parameter and Counter Binary Formats and Values

Page 196

The value for TYPE is:
Value

Meaning

B ILATERAL

7.7.7

X.25 Server Module Parameters

The following table specifies the X.25 server module parameters.
Table 17
X.25 Server Module Parameters
Type
Number

Data
Type

100
200
300
310
320

350
351
352
353

DU- 2
C
DU- 2
S*
AI-16
Q
DU- 2
C
CM-1/2 C
DU- 2
AI-6
AI-39
C
AI-39
C
c
c- 1
AI-39
C
CM-1/2 C
DU-1
AI-16
DU- 1
C
HI-16
C
HI-16
C
AI-16
C

354

AI-16

355

CM-1/2
DU-2
DU- 2

330
331
33 1
332
340

Inf.
Type

APP
Rest.

Set.
Rest.
RO

Q
Q
Q
Q
Q
Q

wo
RO

NCP
Keywords
COUNTER TIMER
ACTIVE CIRCUITS
DESTINATION
MAXIMUM CIRCUITS
NODE
node address
node name (optional)
USER user
PASSWORD (to set)
PASSWORD (to read)
ACCOUNT
OBJECT
object number
obj ect name
PRIORITY
CALL MASK
CALL VALUE
GROUP
NUMBER

SUBADDRESSES
range beginning
range end (none if same as
beginning)

An output, the PASSWORD parameter is not
password. If it is present, its value is:
Value
0

Meaning
Password set

present

there

Page 197

Parameter and Counter Binary Formats and Values
7.8

Module Counters
X . 2 5 Protocol Module Counters

7.8.1

The following table specifies
counters.

the

X.25

protocol

module

local

Table 18
X . 2 5 Protocol Module Counters
Bit
Width

Type
Number

16
32
32
32
32

16
16
16
16
16
16
16
8
8
8
8

7.8.2

Standard Text
Seconds since last zeroed
Bytes received
Bytes sent
Data blocks received
Data blocks sent
Calls received
Calls sent
Fast selects received
Fast selects sent
Maximum switched circuits active
Maximum channels active
~eceivedcall resource errors
Locally initiated resets
Remotely initiated resets
Network initiated resets
Restarts

X . 2 5 Server Module Counters

The following table specifies the X . 2 5 server module counters.
Table 19
X . 2 5 Server Module Counters

Type
Number

Bit
Width

0
200
210

16
16
8
8

211

7.9

Standard Text
Seconds since last zeroed
Maximum circuits active
Incoming calls rejected, no resources
Logical links rejected, no resources

Node Parameters

The following table specifies the node parameters:

DTE

Parameter and Counter Binary Formats and Values

Page 198

Table 20
Node Parameters
Param.
Type
Number

NICE
Data
Type

0
10
100
101

c- 1
s*
HI-6
S
AI-32
C*
CM- 3
C
DU- 1
DU- 1
DU- 1
AI-16
C
H-8
C
c-1
c
c-1
c
HI-6
C
c- 1
c
AI-255 C
AI-255 C
AI-255 C
AI-255 C
c-1
c
AI-16
C
AI-255 C
AI-255 C
0-4
C
DU-4
C
CM-1/2 C
DU-2
AI-6
n o d e - id)
DU-2
C
DU-2
C
c
c-1
HI-6
c- 1
c
node-id)
node-id)
DU-2
C
id-string)
AI-16
C*
DU-2
n/a
DU-2
C
DU-2
C
DU-2
S*
DU-2
S*
CM- 3
C
DU-1
DU-1
DU-1
DU-2
C
DU- 1
C

110
Ill
112
113
114
115
120
121
122
123
125
126
130
131
135
136
140
141
150
151
152
153

154
155
156
160
500
501
502
510
511
600
601
700

710
720

InÂ£
Type

Appl.
Rest.

Set.
Rest.

NCP
Keywords
STATE
PHYSICAL ADDRESS
IDENTIFICATION
MANAGEMENT VERSION
version number
ECO number
User ECO number
SERVICE CIRCUIT
SERVICE PASSWORD
SERVICE DEVICE
CPU
HARDWARE ADDRESS
SERVICE NODE VERSION
LOAD FILE
SECONDARY LOADER
TERTIARY LOADER
DIAGNOSTIC FILE
SOFTWARE TYPE
SOFTWARE IDENTIFICATION
DUMP FILE
SECONDARY DUMPER
DUMP ADDRESS
DUMP COUNT
HOST
Node address
Node name (optional)
HOST
LOOP COUNT
LOOP LENGTH
LOOP WITH
LOOP ASSISTANT PHYSICAL ADDRESS
LOOP HELP
LOOP NODE
LOOP ASSISTANT NODE
COUNTER TIMER
NAME
CIRCUIT
ADDRESS
INCOMING TIMER
OUTGOING TIMER
ACTIVE LINKS
DELAY
NSP VERSION
version number
ECO number
User ECO number
MAXIMUM LINKS
DELAY FACTOR

Parameter and Counter Binary Formats and Values

822

DU- 1
DU-2
DU-2
C- 1
DU- 2
DU- 1
AI-16

830

CM- 1/2

721
722
72 3
810
820
821

900

901
910
911

912
920
921
922
923
924
925
926
927
928
929
930
931
932

DU- 2
AI-6
CM- 3
DU- 1
DU- 1
DU- 1
c- 1
DU-2
CM-1/2
DU-2
DU- 2
DU- 2
DU-2
DU- 2
DU-2
DU- 1
DU- 1
DU- 1
DU-2
DU-2
DU-2
DU- 1
DU-2
DU-2
DU-2

c
c
c
s
s
s
s*

E
E
E
A
R
R
R
R

RO
RO
RO
RO
RO

c
c
c

E
E
E

c
c
c
c
c
c
c
c
c
c
c
c
c
c

E
E
E
E
E
E
E
E
E
E
E
E
E
E

Page 199

DELAY WEIGHT
INACTIVITY TIMER
RETRANSMIT FACTOR
TYPE
COST
HOPS
CIRCUIT
NEXT NODE
Node address
Node name (optional)
ROUTING VERSION
Version number
ECO number
User ECO number
TYPE
ROUTING TIMER
SUBADDRESSES
range beginning
range end (none i f same as
beginning)
BROADCAST ROUTING TIMER
MAXIMUM ADDRESS
MAXIMUM CIRCUITS
MAXIMUM COST
MAXIMUM HOPS
MAXIMUM VISITS
MAXIMUM AREA
MAXIMUM BROADCAST NONROUTERS
MAXIMUM BROADCAST ROUTERS
AREA MAXIMUM COST
AREA MAXIMUM HOPS
MAXIMUM BUFFERS
BUFFER SIZE
SEGMENT BUFFER SIZE

The values for STATE are:
Value
0
1
2
3

4
5

Keyword

Node

ON
OFF
SHUT
RESTRICTED
REACHABLE
UNREACHABLE

Executor
Executor
Executor
Executor
Destination
~estination

The values for SERVICE DEVICE are the same as found in the DNA Low
Level Maintenance Operation specification. They are also defined in
section 7.4, following Table 10, under Communication DEVICE mnemonics.

Parameter and Counter Binary Formats and Values
The values for CPU are:
Value
0
1
2
3

Type
PDP8
PDP11
DECSYSTEM1020
VAX

The values for SOFTWARE TYPE are:
Value
0
1
2

Program Type
SECONDARY LOADER
TERTIARY LOADER
SYSTEM

The values for HOST are:
NODE ADDRESS (2):

Host node address.
NODE NAME (1-6): A
Host node name, zero length i f none.
The values for LOOP WITH are:
TYPe

Contents

0
1
2

ZEROES
ONES
MIXED

The values for LOOP HELP are:
Type

Contents

0
1
2

TRANSMIT
RECE I VE
FULL

Page 200

Parameter and Counter Binary Formats and Values

Page 201

The values for executor and adjacent node TYPE are:
Value

Keyword

0
1
3

ROUTING I 1 1
NONROUTING 1 1 1

AREA

4
5

ROUTING IV
NONROUTING IV

The values for SERVICE NODE VERSION are:

7.10

Value

Keyword

0
1

PHASE I 1 1
PHASE IV

Node Counters

The definition of each
Table 21, below, lists the node counters.
is
to
be
incremented
is
given in the functional
counter and the way it
layer
containing
the
counter.
specifications for the
Node counters are specified for the following layers only:
Layer
Network Management
End Communication
Rout ing

Type Number
Range
000 - 099

Table 21
Node Counters
Type Number

Bit width

Standard Text
Seconds Since Last Zeroed
User Bytes Received
User Bytes Sent
User Messages Received
User Messages Sent
Total Bytes Received
Total Bytes Sent
Total Messages Received
Total Messages Sent
Connects Received
Connects Sent
Response Timeouts
Received Connect Resource Errors
Maximum Logical Links Active

Parameter and Counter Binary Formats and Values

8
16
8
8
8
8
8

7.11

Page 202

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

Area Parameters

The following table specifies the area parameters:
Table 21a
Area Parameters
Param.
Type
Number

NICE
Data
Type

Appl.
Type

Set.
Rest.

NCP
Keywords

c-1
DU- 2
DU-1
AI-16
CM-1/2
DU-2
AI-6

S*
S
S
S*
S*

RO
RO
RO
RO
RO

STATE
COST
HOPS
CIRCUIT
NEXT NODE
Node address
Node name (optional)

The values for STATE are:
Value
4
5

7.12

Keyword

Node

REACHABLE
UNREACHABLE

Destination
Destination

Event Definitions

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

Description
Network Management Layer
Applications Layer

Parameter and Counter Binary Formats and Values

Page 203

Session Control Layer
End Communication Layer
Rout ing Layer
Data Link Layer
Physical Link Layer
Reserved for other common classes
RSTS System specific
RSX System specific
TOPS 10/20 System specific
VMS System specific
RT System specific
CT System specific
Communication Server specific
Reserved for future use
Customer specific
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 (see Section 7.1).
Table 23 shows the events for each class.
Table 23
Events
Class Type

Entity

Standard Text

none
node
line
circuit

Event records lost
Automatic node counters
Automatic line counters
Automatic service

Event Parameters
and Counters
none
Node counters
Line counters
Service
Status
Node

line
node
circuit
circuit

Line counters zeroed
Node counters zeroed
Passive loopback
Aborted service request
Automatic counters
Counters zeroed

none

Local node state change

Fi lespec
Software type
Circuit counters
Node counters
Operat ion
Reason
Node
Qualifier
Counters
DTE
Qualifier
Counters
DTE
Reason
Old state
New state

Parameter and Counter Binary Formats and Values
none

none
none
node
none
circuit
circuit
circuit
circuit
circuit
circuit
circuit
circuit
circuit
circuit
circuit
circuit
circuit
node
circuit
circuit
area
circuit
circuit
circuit

Page 204

Source node
Source process
Destination process
User
Password
Account
Message
Invalid message
Source Node
Message
Invalid flow control
Source Node
Current flow control
NSP node counters
Data base reused
Packet header
Aged packet loss
Node unreachable packet Packet header
Adjacent node
loss
Packet header
Node out-of-range
Adjacent node
packet loss
Packet header
Oversized packet loss
Adjacent node
Packet beginning
Packet format error
Adjacent node
Packet header
Partial routing update
Highest address
loss
Adjacent node
Node
Verification reject
Reason
Circuit down, circuit
Adjacent node
fault
Reason
Circuit down
Packet header
Adjacent node
Reason
Circuit down, operator
Packet header
initiated
Adjacent node
Adj acent node
Circuit up
Initialization failure, Reason
line fault
Initialization failure, Reason
Packet header
software fault
Initialization failure, Reason
Packet header
operator fault
Received version
Node reachability change Status
Adjacent node
Adjacency up
Adjacent node
Adjacency rejected
Reason
Area reachability change Status
Reason
Adjacency down
Packet header
Adjacent node
Reason
Adjacency down,
Packet header
operator initiated
Adjacent node
Locally initiated state Old state
change
New state

Access control reject

Page 205

Parameter and Counter Binary Formats and Values

Remotely initiated state Old state
New state
change
none
circuit Protocol restart
received in maintenance
mode
Circuit counters
circuit Send error threshold
Circuit
counters
circuit Receive error threshold
Circuit
counters
circuit Select error threshold
Header
(optional)
circuit Block header format
error
circuit Selection address error Selected tributary
Received tributary
Previous tributary
Tributary status
circuit Streaming tributary
Received tributary
lock length
circuit Local buffer too small
Buffer length
DTE
Restart
modu 1e
Cause
X . 2 5 protocol)
~iagnostic
DTE
State
change
modu 1e
Reason
X . 2 5 protocol)
Old state
New state
DTE
Retransmit
maximum
module
Parameter type
exceeded
none
Initialization failure
line
Failure reason
Send
failed
line
Distance
Failure reason
line or Receive failed
Ethernet header
circuit
Collision detect check
line
failed
DTE
DTE up
module
DTE
DTE down
modu 1e
New state
line
Data set ready
transition
New state
Ring indicator
line
transition
New state
Unexpected carrier
line
transition
Device register
Memory access error
line
~ommunications interface Device register
line
error
Performance error
Device register
line
circuit

7.13

Event Parameters

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

Network

Management

Parameter and Counter Binary Formats and Values
Table 24
Network Management Layer Event Parameters
Type

Data Type

Keywords

C- 1

SERVICE
STATUS (as in NICE)
Return code
Error detail (optional if no error
message
Error message (optional)
OPERAT ION
REASON
Qualifier
Parameter type
ID string
NODE
Node address
Node name (optional)
DTE
Fi lespec
SOFTWARE TYPE

The values for SERVICE are:
value
0
1

Keyword
LOAD
DUMP

The values for Return code added interpretation are:
Value
0

>o
<o

Keyword
REQUESTED
SUCCESSFUL
FAILED

The values for OPERATION are:
Value
0
1

Keyword
INITIATED
TERMINATED

Page 206

Page 207

Parameter and Counter Binary Formats and Values
The values for REASON are:
Value

0
1

2
3
4

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

The values for SOFTWARE TYPE are the same as those in Node Parameters.
The following parameter types are
layer (class 2):

defined

for

the

Session

Control

Table 25
Session Control Layer Event Parameters
Type

Data Type

Keywords

c-1
c-1
c- 1
CM-1/2
DU-2
AI-6
CM-1/2/3/4
DU- 1
DU-2

REASON
OLD STATE
NEW STATE
SOURCE NODE
node address
node name (optional if none)
SOURCE PROCESS
Object type
Group code (if specified and process
name present)
User code (if specified and group
code present)
Process name (if specified)
DESTINATION PROCESS
Same as for SOURCE PROCESS
USER
PASSWORD
ACCOUNT

The values for REASON are:
Value
0
1

Meaning
Operator command
Normal operation

Page 208

Parameter and Counter Binary Formats and Values
The values for OLD STATE and NEW STATE are:
Value
0
1
2
3

Meaning
ON
OFF
SHUT
RESTRICTED

A value of zero for PASSWORD indicates a password was set.
the parameter indicates no password was set.
The following parameter types are defined for
layer (class 3 ) :

the

End

Absence of

Communication

Table 26
End Communication Layer Event Parameters
Type
0

1
2

Data Type

Keywords

CM-4
H-1
DU-2
DU-2
HI-6
DS-1
CM-1/2
DU-2
AI-6

MESSAGE
Message flags
Destination logical link address
Source logical link address
Message type dependent data
CURRENT FLOW CONTROL REQUEST COUNT
SOURCE NODE
Node address
Node name (optional)

The following parameter types are defined for the Routing layer (class
4):

Table 27
Routing Layer Event Parameters
Type

Data Type

Keywords

CM-2/4
H-1
DU-2

PACKET HEADER (non-~thernet)
Message flags
Destination node address
(not present for control packet)
Source node address
Visit count
(not present for control packet)

DU-2
DU-1

Parameter and Counter Binary Formats and Values
CM- 11
H- 1
DU-1
DU- 1
HI-6
DU- 1
DU- 1
HI-6
DU- 1
DU- 1
H- 1
DU- 1
HI-6
DU-2
CM-1/2
DU-2
AI-6
CM-1/2
DU-2
AI-6
c- 1
CM- 3
DU- 1
DU-1
DU- 1
c-1
CM-1/2
DU-2
AI-6

Page 209

PACKET HEADER (Ethernet)
Message flags
Destination area
Destination subarea
Destination Ethernet address
Source area
Source subarea
Source Ethernet address
Next area router
Visit count
Service class
Protocol type
PACKET BEGINNING
HIGHEST ADDRESS
NODE
node address
node name (optional if none)
EXPECTED NODE
node address
node name (optional if none)
REASON
RECEIVED VERSION
Version number
ECO number
User ECO number
STATUS
ADJACENT NODE
node address
node name (optional if none)

The values for REASON are:
Value

Meaning
Circuit synchronization lost
Data errors
Unexpected packet type
Routing update checksum error
Adjacency address change
Verification receive timeout
Version skew
Adjacency address out of range
Adjacency block size too small
Invalid verification seed value
Adjacency listener receive timeout
Adjacency listener received invalid data
Call failed
Verification password required from Phase I 1 1 node
Dropped by adjacent node

Page 210

Parameter and Counter Binary Formats and Values
The values for STATUS are:
Value
0

Meaning
REACHABLE
UNREACHABLE

The following parameter types are defined
class 5 ) :

for

the

Data

Table 28
Data Link Layer Event Parameters
Data Type

Keywords

c-1
c-1

OLD STATE
NEW STATE
HEADER
SELECTED TRIBUTARY
PREVIOUS TRIBUTARY
TRIBUTARY STATUS
RECEIVED TRIBUTARY
BLOCK LENGTH
BUFFER LENGTH
DTE
REASON
OLD STATE (for event 5.12)
NEW STATE (for event 5.12)
PARAMETER TYPE
CAUSE
DIAGNOSTIC
FAILURE REASON
D I STANCE
ETHERNET HEADER
Destination address
Source address
Protocol type
HARDWARE STATUS

HI-6
DU- 1
DU-1
c-1
DU- 1
DU- 2
DU-2
AI-16
c- 1
c-1
c-1
c-2
DU- 1
DU- 1
C-1
DU-2
CM- 3
HI-6
HI-6
HI-2
NC

The values for OLD STATE and NEW STATE are:
Value
0
1
2

Meaning
HALTED
I STRT
ASTRT
RUNNING
MAINTENANCE

Link

layer

Parameter and Counter Binary Formats and Values

Page 211

The values for FAILURE REASON are:
Value

~eaning

Excessive collisions
Carrier check failed
(OBSOLETE)

Short circuit
Open circuit
Frame too long
Remote failure to defer
Block check error
Framing error
Data overrun
System buffer unavailable
User buffer unavailable
Unrecognized frame destination
The values for REASON are:
Value

0
1

Meaning
Operator command
Normal operation

The values for OLD STATE and NEW STATE are:
Value

0
1
2

Meaning
ON
OFF
SHUT

The values for TRIBUTARY STATUS are:
Value

0
1
2
3

Meaning
Streaming
Continued send after timeout
Continued send after deselect
Ended streaming

The following parameter types are defined for the Physical Link
class 6 ) :

layer

Parameter and Counter ~ i n a r yFormats and Values
Table 29
Physical Link Layer Event Parameters
Type

Data Type

Keywords
DEVICE REGISTER
NEW STATE

The values for NEW STATE are:
Value
0
1

Meaning
OFF
ON

Page 212

APPENDIX A
VERSION COMPATIBILITY

This appendix
describes
the
mapping
necessary
to
maintain
compatibility between different versions of Network Management. It
has separate sections for 2.0 and 3.0 and for 3.0 and 4.0.
The
mapping between 2.0 and 4.0 is simply the combination of the two
sect ions.

A.1

Versions 2.0 and 3.0

There are two cases where compatibility is at issue: version 3.0 NCP
with version 2.0 Listener .and version 2.0 NCP with version 3.0
Listener. In both cases, i t is the responsibility of the module with
the later version to provide compatibility, if such compatibility is
part of the individual products requirements.
When
possible,
functions are to be mapped between versions, but new version 3.0
functions are not available from version 2.0 modules.
Version 3.0 NCP supports only the version 3.0 command syntax.
I f it
is to be compatible with a version 2.0 Listener, it must map 3.0
commands to 2.0 NICE protocol and 2.0 responses to 3.0 output.
Any
2.0 responses that do not map to 3.0 output should be handled through
the normal unrecognized response logic.
Version 3.0 Listener supports version 2.0 commands by mapping them to
3.0 functions. It then maps the 3.0 responses into 2.0 responses. In
cases where a response cannot be mapped and does not conflict with a
2.0 response, it can be returned unmapped to be handled by the 2.0
systems normal unrecognized response logic.
In the following mapping specifications, parameters that did not
change between version 2.0 and 3.0 are not mentioned. All mappings
apply to both commands and responses unless otherwise stated.

Page A-2

Version Compatibility
A.I.1

Module Entity

None of the 3.0 module entity functions can be mapped to version 2.0.

A.1.2

Node Entity

The following mappings apply to the node entity.

A.1.3

Version 3.0 Parameter

Version 2.0 Parameter

CIRCUIT

LINE

SERVICE CIRCUIT

SERVICE LINE

MAXIMUM CIRCUITS

MAX IMUM L INES

Logging Entity

For the logging entity, the only mapping is
identification that goes with specific filters.

for

the

entity

For a version 3.0 NCP with a version 2.0 Listener, version 3.0 circuit
and line identifications become version 2.0 line identifications.
For a version 2.0 NCP with a version 3.0 Listener, the version 2.0
line identification becomes a version 3.0 circuit identification and,
where necessary, is applied to the associated version 3.0 line by
implication.

A.1.4

Circuit and Line Entities

The following statements apply to the case of a version 3.0 NCP with a
version 2.0 Listener.
The following version 3.0 circuit parameters map to
line parameters of the same name.
STATE
Substate
SERVICE
COUNTER TIMER

the

version

2.0

Page A - 3

Version Compatibility
LOOPBACK NAME
ADJACENT NODE
BLOCK SIZE
COST
TYPE TRIBUTARY

None o f the other version 3.0 circuit parameters can be mapped to
version 2.0 line.

the

The following version 3.0 line parameters map to the version 2.0
parameters of the same name.

line

DUPLEX
CONTROLLER
SERVICE TIMER
2.0

line

None of the other version 3.0 line parameters map to version
line parameters.

2.0

The following version 3.0 line parameters
parameters of a different name.
Version 3.0

Version 2.0

PROTOCOL
RETRANSMIT TIMER

TYPE
NORMAL TIMER

map

version

The version 3.0 LOOP CIRCUIT and LOOP LINE commands both map to
version 2.0 line as do the SHOW, LIST, TRIGGER, LOAD, and DUMP
commands.
The following statements apply to the case of a version
with a version 3.0 Listener.

2.0

NCP

Version 2.0 commands can only be applied to version 3.0 circuits.
Their
application
to
version
3.0 lines occurs only by
implication. The version 3.0 line parameters are referenced
indirectly by the line's association with the circuit and thus
appear to the version 2.0 system to belong to the circuit.
Version 3.0 lines that are not directly associated with a circuit
are not visible to t?he version 2.0 system.
The following version 2.0 line parameters map to the version
circuit parameters of the same name.
STATE
Substate
SERVICE
COUNTER TIMER
LOOPBACK NAME
ADJACENT NODE
BLOCK SIZE
COST
TRI BUTARY

3.0

Version Compatibility

Page A-4

The following version 2.0 line parameters map to the version 3.0
parameters of the same name.

line

CONTROLLER
DUPLEX
SERVICE TIMER
The following version 2.0 line parameters
parameters of a different name.

A.1.5

Version 2.0

Version 3.0

TYPE
NORMAL TIMER

PROTOCOL
RETRANSMIT TIMER

map

version

3.0

line

Event Logging

A version 3.0 event transmitter does not send new version

3.0 events
to a version 2.0 event receiver. Version 3.0 circuit events become
version 2.0 line events unless they are X.25 specific, in which case
they are not sent.
A version 3.0 event receiver translates version 2.0

line

events

for

data link and above into circuit events.

A.2

Versions 3.0 and 4.0

The only mapping between version 3.0 and version 4.0 is in the
handling of area numbers.
Version 3.0 does not recognize the high
byte of the address field as the area number.
Therefore, a version
4.0 node sending NICE messages to a version 3.0 node must zero the
area portion of any address field for nodes in the same area as the
version 3.0 node.
Otherwise, the normal responses to
parameters, etc. will suffice.

unrecognized

functions,

options,

APPENDIX B
MINIMUM SUBSET

The intent of the Network Management minimum subset is to ensure that
all
DNA
products
will
provide sufficient Network Management
capabilities to manage both individual nodes and the network as a
whole.
It places strict requirements on the implementers of the
Network Management
architecture
and
provides
guidelines
for
configuring nodes and networks.
The minimum subset must be interpreted in the light of specific
product requirements.
The Network Management requirements of an
unattended routing node in a centrally managed network are obviously
different from those of an attended non-routing node in a network with
fully distributed management. Before the proper minimum subset can be
determined for a particular network product, its potential uses as a
network node must be defined.
The minimum subset defines those capabilities that must be provided by
the product implementers.
I f the product is capable of widely
different responsibilities within the network, the implementers should
allow for different Network Management subsets within the product, so
that the configurations that require fewer functions are not burdened
by the requirements of more complex situations.
The minimum subset contains the smallest set of Network Management
functions necessary to diagnose network problems that have a general
level of negative effect, and remove the communications paths or nodes
that are at fault.
It does not contain sufficient functions to
provide complete fault diagnosis, network planning, or
general
control.
Following are the minimum, general capabilities that are required for
node and network management. Unattended nodes, nodes with no console,
or nodes that are to be remotely controlled must provide these
capabilities via the NICE protocol.
Nodes that are to be locally
managed must provide the capabilities via NCP. Nodes that are to be
both remotely and locally controlled must provide these capabilities
via both NCP and the NICE protocol.
Each capability below is followed by the NICE
syntax that implements it.

messages

and

the

NCP

Page B-2

Minimum Subset
1.

Display and zero of all existing counters.
The Data Link layer counters must exist on all multipoint control
nodes and on at least one end of each point-to-point link.
All DECnet nodes must support remote and local read
of the Ethernet data linkcounters via the NICE

capabilities

NICE messages:
Read information
counter options.

message,

circuit

counter

and

line

Zero counters message, circuit and line options.
NCP commands:
SHOW CIRCUIT circuit-id COUNTERS
SHOW LINE line-id COUNTERS
ZERO CIRCUIT circuit-id COUNTERS
ZERO LINE line-id COUNTERS
The Routing layer counters must exist at all routing nodes.
NICE messages:
Read information message,
counters options.

circuit

counters

and

node

Zero counters message,
counters options.

circuit

counters

and

node

NCP commands:
SHOW CIRCUIT circuit-id COUNTERS
SHOW NODE node-id COUNTERS
ZERO CIRCUIT circuit-id COUNTERS
ZERO NODE node-id COUNTERS
The End Communication layer counters must exist on one node of
any pair of nodes that will communicate via logical links and
that are more than one hop away from each other.
Communicating
nodes that are only one hop away from each other are not required
to support the End Communication Layer counters.
NICE messages:
Read information message, node counters option.

Page B-3

Minimum Subset
Zero counters message, node counters option.
NCP commands:
SHOW NODE node-id COUNTERS
ZERO NODE node-id COUNTERS

All other counters not mentioned above must exist if the node
provides the service for which the counters are defined. For
example a node that provides an X.25 gateway server must provide
the corresponding counters.
2.

Display and control of Routing events for all routing nodes.
Display, control and logging of routing event messages are
optional on non-routing nodes. Routing nodes must be capable o f
sending routing event messages to at least a sink node, which can
be set to be any node in the network. (Note: The routing node
sending the message is not required to serve as a sink node.) Any
network incorporating routing nodes must have at least one node
that may serve as a sink for events.
NICE messages:
Change parameter message, set and clear
parameters for FILE, CONSOLE or MONITOR.

all

logging

Read information message, logging summary
sink node qualifier.

option

with

NCP commands:
SET LOGGING sink-type

EVENTS event-list [source-qualifier] [sink-node]
NAME sink-name
STATE sink-state

CLEAR LOGGING sink-type EVENTS event-list [source-qualifier] [sink-node1
NAME
SHOW LOGGING sink-type
3.

SUMMARY [sink-node]

Test communication using the node level logical link loop test.
Note that this implies that all nodes must implement the Loopback
Mirror.
NICE messages:
Test message, node level loop test option.

Page B-4

Minimum Subset

Change parameter message, set and clear node option,
circuit and name
parameters.
Read information message, node summary option.
NCP commands:
SET NODE node- id

NAME node-name
CIRCUIT circuit-id

CLEAR NODE node-id

NAME
CIRCUIT

SHOW NODE node-id

SUMMARY

LOOP NODE node-id [access-control] [WITH block-type]
[COUNT count]
[LENGTH length]
4.

Disable a point-to-point communications link by setting its state
to OFF.
NICE messages:
Change parameter message,
parameter, off value.

set

circuit

option,

state

option,

state

NCP commands:
SET CIRCUIT circuit-id STATE OFF
5.

Disable a node by setting its state to OFF.
NICE messages:
Change parameter message,
parameter, off value.

set

node

NCP commands:
SET NODE node-id STATE OFF

Display minimal information about a point-to-point communications
link or node.
NICE messages:
Read information
opt ions.

message,

circuit

NCP commands:

SHOW CIRCUIT circuit-id SUMMARY

and

node

summary

Page B-5

Minimum Subset
SHOW NODE node-id SUMMARY
7.

From NCP, send command to remotely managed nodes from central
management nodes. Note that any product that could be a central
management node must be able to parse all possible NCP commands
and format all possible responses. This must be true even though
the product does not itself implement the particular options.
NCP commands:

TELL node-id [access-control] command
SET EXECUTOR NODE node-id [access-control]
CLEAR EXECUTOR NODE
8.

Display and control minimal multipoint control
lines running protocol type DDCMP control.

parameters

for

NICE messages:
Change parameter message, set line option,
and delay timer parameters.

dead

timer

Read information message, line summary option.
NCP commands:
SET LINE line-id DEAD TIMER milliseconds
DELAY TIMER milliseconds
SHOW LINE line-id SUMMARY
It is the responsibility of Product Management to set the product
requirements so that the applicability of the minimum subset can be
determined.
I t is the responsibility of Development to build products that can
configured to minimum subset requirements.

It is the responsibility of Software Services or the user to configure
nodes so that the requirements are met for the network. This has to
be done while taking into account the specific characteristics of the
node and network involved.

APPENDIX C
STATE MAPPING TABLES

The
following
tables
relate
the
Network
Management
controllable/observable states to the Network Management link states
and to the states from the actual specifications for the high level
users and data link protocols.
The high level circuit users are Routing and the X.25 Gateway Server.
The high level line users are point-to-point and multi-point DDCMP and
the X.25 protocol handler.
Mapping
Number

Net. Man.
State

Net. Man.
Substate

D.L. Serv.
State

High Lev.
State

D. L.
State

CLEARED

N/A

off

OFF

N/A

off

running

passive

run

START ING

passive

start

run

synchronizing

passive

start

synch

FAILED

passive

fail

REFLECTING

ref1

start

maint

LOAD ING

pass-open

off

maint

DUMP ING

pass-open

off

maint

LOOP ING

pass-open

off

maint

TRIGGERING

pass-open

off

maint

AUTOSERVICE

closed

off

maint

REFLECTING

clos-ref1

off

maint

State Mapping Tables

Page C-2

AUTOLOADING

open

off

rnaint

AUTODUMPING

open

off

maint

AUTOTRIGGERING

open

off

rnaint

17'

SERVICE

idle

closed

off

maint

SERVICE

REFLECTING

clos-ref1

off

rnaint

SERVICE

LOAD ING

open

off

rnaint

SERVICE

DUMP ING

open

off

maint

SERVICE

TRIGGERING

open

off

rnaint

SERVICE

LOOP I NG

open

off

maint

The following tables relate the internal states from each component's
his relationship
own specification to the Network Management states.
is indicated through the mapping numbers which correspond to the
preceding table.
when

the

circuit

user

owner

The following mappings
EXECUTOR.

apply

Mapp i ng
Number

Routing
State

DDCMP
State

Perm Cir.
X.25 P.L.
State

Inc. Cir.
X.25 P.L.
State

Out. Cir.
X.25 P.L.
State

1-2

OP
HA

halt

unaloc
unun

listening
clearing
cleared

open
clearing
cleared

run

running

runn ing

running

run

running

halt
astrt
istrt

synch
unsynch
no-corn

synch
unsynch
no-corn
listening
called
taken

synch
unsynch
no-corn
calling

N/ A

listening

open

rnaint

N/A

N/ A

Page C-3

State Mapping Tables

halt

maint

halt

maint

14-16

N/A

17-18

halt

19-21

N/ A

halt

maint

The following table applies when the line protocol
line belongs to the X.25 protocol handler module.
Mapping
Number

Low Level
Link State

Low Level
Port State

1-2

halted
disconnecting

unsync
unun

inf. trans.

running

inf. trans.

running

connecting
re-synch

unsynch
synch

loopback

unsynch

11-16

N/A

loopback

18-21

N/ A

loopback

unload

running

LAPB

and

the

APPENDIX D
X.25 NATIVE ONLY SUBSET

In the case of a system that only provides native mode X.25 usage,
many Network Management functions do not apply.
These are the
functions that relate to a node that is part of a DECnet network. The
functions that do apply should still be available through NCP but are
not subject to any architectural minimum subset.
The following functions apply to an X.25 native only system.
1.

For the circuit entity, the following parameters:
CHANNEL
CONNECTED OBJECT
COUNTER TIMER
DTE
MAXIMUM BLOCK
MAXIMUM WINDOW
STATE
Substate
USER

The X.25 permanent virtual circuit counters.

For the line entity, the following parameters.
CLOCK
CONTROLLER
COUNTER TIMER
DEVICE
HOLDBACK TIMER
MAXIMUM DATA
MAXIMUM RETRANSMITS
MAXIMUM WINDOW
RETRANSMIT TIMER
SERVICE
STATE
Substate

The LAPB line counters.

Page D-2

X.25 Native Only Subset
5.

The following Data Link events.
Locally initiated state change
Remotely initiated state change

For the logging entity, all parameters except SINK NODE.

For module X25-ACCESS, the NETWORK parameter.

For module
events.

For module X25-SERVER,
except the following.

X25-PROTOCOL,

all

parameters,

counters,

and

counters,

and

all

parameters

The following NCP commands, supporting
entities and parameters.

the

above

mentioned

ACCOUNT
NODE
PASSWORD
USER
10.

CLEAR
DEFINE
PURGE
LIST
LOOP LINE
SET
SHOW
ZERO

APPENDIX E
MEMORY IMAGE FORMATS AND FILE CONTENTS

Since the PDP-8, PDP-11, VAX-11, 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.
Each three bytes represents two 12-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
words 1 and 2.
Each byte represents one memory byte. That is,
the memory address is incremented with each byte.

PDP-11
VAX- 11

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 high
the word. Bytes 2 through 4 follow.
4-bits of byte 5 are discarded.
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:
t

The type of the target system (PDP-8, PDP-11,
VAX-11,
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:
o

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

Block length.

goes

Number of memory units in image block.

for

Memory Image Formats and File Contents
o

P a g e E-2

Memory image.
T h i s is the contiguous block of
memory
associated with t h e above address. T h e format requirements
are a s specified in Appendix B. The memory image can be o f
any length.

APPENDIX F
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.
I f 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.
I f the second and third bytes have a defined value, this is
followed by a comma, a blank, and the keyword(s) for the values.
Number

Standard test

Meaning

(none)

Success.

(none)

The request has been accepted,
and separated data 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
to and including ENTITY ID.

-1

Unrecognized function or
opt ion

Either
the function code or
a
option
field
requested
capability not recognized by the
Local
Network
Management
Function.
Also, the error code
for function codes 2-14 (phase

Page F-2

NICE Return Codes With Explanations

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.

-3

Privilege violation

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

-4

Oversized Management
command message

-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

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

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
Manaqement 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. *

Page F-3

NICE Return Codes With Explanations
-10

Line communication error

Error in transmit or receive on
a line.
Can only occur during
directed 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. *

-13

File open error

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

defined

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

-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
type
number ,
parameter
interpreted
according to the
entity involved.

-17

Line protocol error

Invalid line protocol message or
operation.
Can
only
occur
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.

Page F-4

NICE Return Codes With Explanations
-18

File 1/0 error

1/0 error in a file, such as
read error in system image or
loader during down-line load.

The error detail is
for error # - 1 3 .
-19

Mirror link disconnected

defined

A successful connect was made to
the Loopback Mirror, but the
logical link then failed.

The error detail is:
Value

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
a
tributary
address
for
point-to-point
line
or
an
attempt to set a controller to
loopback
mode
when
the

Page F-5

NICE Return Codes With Explanations

controller does not support that
function.
The
error detail
contains the parameter type of
the
parameter
that
is not
applicable.

-128

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.

Hardware failure

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

Operation failure

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.

Invalid parameter grouping

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

Bad loopback response

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

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.

(none

No message printed.
Done with
multiple
response
commands
(e.g., read
information
for
known lines).

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

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

NICE Return Codes With Explanations

a LOAD NODE command.

Page F-6

APPENDIX G
NCP COMMAND STATUS AND ERROR MESSAGES

NCP has the following standard status and error messages.
Standard Text

Meaning
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

not

execute

Error Messages
Unrecognized command

The command typed by the
recognized.

Unrecognized keyword

Something in the command keyword was n o t
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

The Network Management Access Routines
received unrecognizable information.

Listener link disconnected

A successful connect

was

user

made

was

not

send

the

NCP Command Status and Error Messages

Page G-2

Network Management Listener, but the
logical link then failed.
Optional
error detail is as in NICE error message
-19 (Appendix F).
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 F).

Total parameter data too long NCP command overflows
maximum
message for this implementation.
Oversized Manaqement response NCP could not receive a
because it was too long.

NICE

NICE
message

APPENDIX H
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:

To convert from Julian half-day:
HALF = JULIAN/2
TEMPI = HALF/1461
TEMP2 = HALF-TEMPI
YEAR = TEMP2/365
IF TEMP2/1460*1460 = TEMP2 AND ( ~ A ~ ~ + 1 ) / 1 4>6 TEMPI
0
YEAR = YEAR-1
END I F
TEMPI = TEMP^-(~~~~*365)+1
YEAR = YEAR+1977
IF YEAR/4*4 = YEAR
TEMP2 = 1
ELSE
TEMP2 = 0
END IF
IF TEMPI > 59+TEMP2
DAY = DAY+2-TEMP2
ELSE
DAY = TEMPI
ENDIF

Julian Half-day Algorithms
MONTH = MONTH-2
TEMPI = 0
IF (HALF*~.NE.JULIAN)TEMPI = 1
HALF = TEMPI
RETURN
END

Page H-3

APPENDIX I
DMC DEVICE COUNTERS

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

Standard Text
Bytes received
Bytes sent
Data blocks received
Data blocks sent
Data errors inbound
0
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
0
NAKs sent, buffer unavailable

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
p r o v i d i n g the zero capability is to copy the base table counters when
a zero is requested. The numbers returned when counters are requested
are then the difference between the saved counters and the current
base table.

APPENDIX J
GLOSSARY

NOTE
Terms that derive from other related
specifications
(such as hops, cost,
delay, etc.) are defined
in
those
specifications.
active areas
Active areas are known areas which are currently reachable.
active circuits
Active circuits are known circuits in the ON or SERVICE state.
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 perceived
active nodes. (See Section 3.1)

from

the

executor

node

are

ad j acent node
A

node removed from the executor node by a single physical line.

characteristics
Parameters that are generally static values in volatile memory or

GLOSSARY

Page J-2

permanent values in a permanent data base. A Network Management
information type. Characteristics can be set or defined.
circuit
A logical communications path
providing
a
communications
connection between adjacent nodes. A circuit may be identical to
a physical link, multiplexed with many other circuits, and/or
traffic split over multiple physical links. (See Section 3.4)
circuit level loopback
Testing a specific data link circuit 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.
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 device identification that denotes the control
hardware for a line. For a multiline device that controller is
responsible for one or more units.
counters
Error and performance
information type.

statistics.

Network

Management

entity
AREA, CIRCUIT, LINE, LOGGING, MODULE or NODE.
These are the
major Network Management keywords. Each one has parameters with
options, and most have specified counters. There are also plural
entities, such as, KNOWN LINES, ACTIVE LOGGING, SIGNIFICANT
NODES, etc.
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 or
circuit 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

Page J-3

GLOSSARY
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, STATUS 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 circuits
All circuits 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 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 Network Management
appropriate data base.

the

known nodes
All nodes with address 1 to
reachable or have a node
circuit line.

maximum address that are either
name plus all names that map to a

line
A physical communications path.
entity.

Line

Network

Management

line level loopback
Testing a specific physical link by sending a repeated message
directly to the physical link layer and over a wire to a device
that returns the message to the source.

Page J-4

GLOSSARY
logg ing

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

the

sinks

logging sink node
The node from which logging information comes.
logging source process
The process that recognized an event.
logical link
connection between two nodes that is established and controlled
by the Session Control, End Communication, and Routing 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.

Page J-5

GLOSSARY
module
A module is a component that
classifications.

does

not

fit

into

other

entity

monitor
An event sink that is to receive a machine-readable
events for possible real-time decision making.

record

An implementation that supports Routing, End Communication,
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, End
Communication, and Routing layers within one node or from one
node to another and back.
In some cases node level loopback
involves using 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 or circuit: a state where
the line is unavailable for any kind of traffic.
Applied to
logging: a state where the sink is not available, and any events
for it should be discarded.
on state
Applied to a node: a state of normal network operation. Applied
to a line or circuit: a state of availability for normal usage.
Applied to logging: a state where a sink is available for
receiving events.

Page J-6

GLOSSARY

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

has

reachable node
A node to which the executor node's Routing
usable communications path.

believes

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
ROM

bootstrap

service slave mode
The mode where the processor is taken over and the adjacent ,
executor node is in control, typically for execution of a
bootstrap program for down-line loading or for up-line dumping.
service state
A line or circuit 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 state where existing logical links or X.25
undisturbed, but new ones are prevented.

virtual

calls

are

least

one

significant
A subset of known entities
parameter or counter.
sink
(see logging sink)
specific filter

for

which

there

GLOSSARY

Page J-7

A filter that applies to a specific entity within an event
and type.

class

stat ion

A physical termination on a line,

having

both

hardware

and

software implementation.
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.
substate
a

state

The node that receives a memory image during a down-line
generates an up-line dump, or loops back a test message.

load,

An intermediate state that is displayed
display.

tag

summary
An information type meaning most useful information.
target node

tributary
A station on a multipoint line that is not a control station.

DECnet Digital Network Architecture Phase IV
Network Management Functional Specification
AA-X437A-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.

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

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

0
0
0
0
0

Name

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

Date

Organization

City

State

Zip Code

or
Country

- - - - -Do Not Tear - Fold Here and Tape - - - - - - - - - - - - - - - - - - - - - - 1I
Postage
Necessary
i f Mailed in the
NO

United States

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

-1
-1

-1
SOFTWARE DOCUMENTATION
1925 ANDOVER STREET TWlE07
TEWKSBURY, MASSACHUSETTS 01876

-1

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