DECnet DIGITAL Network Architecture Network Management Functional Specification Version 4.0.0 July 1983 .-------. `=======' .------. .---. .-------. | | .-------. `======' `===' `=======' | | `=======' \\ ..| |\ \\ \ | | / / \...| .-----. .-------------. ......| | \ \ \ .-------. .-------. o\.--------------. o `--/ /--' `---|\--' o `-----\\ \-----' o / / | \ o \\ \ o / / | \ O \\ \ O ------------. .----------------. .-----------------. /| | \ \ \ / | \ \ \ \ /.-----| \------.\ \ / `-----| \-----' \ \ --------. / .---------------------. \ .----------------------. / | | | \| \ \ | / /----' `---------------------' `--------\ \ \-------' / / \ \ \ / / \ \ \ / .------------------------ / |\ \ \ \ \ \ \ \ \ \ \ \ \ .---------------- \ | \ \| \ \ `---------\ \ Page 2 ________ 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. _______ _________ ___________ MAYNARD, MASSACHUSETTS 01754 Copyright (c) 1980, 1983 by Hewlett-Packard Company This material may be copied, in whole or in part, provided that the above copyright notice is included in each copy along with an acknowledgment that the copy describes protocols, algorithms, and structures developed by Digital Equipment Corporation. This material may be changed without notice by Digital Equipment Corporation, and Digital Equipment Corporation is not responsible for any errors which may appear herein. Table of Contents Page 3 CONTENTS 1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . 7 1.1 Intended Audience . . . . . . . . . . . . . . . . 7 1.2 Network Management Architecture, DECnet Networks, and DNA . . . . . . . . . . . . . . . . . . . . . 7 1.3 Protocols and Interfaces . . . . . . . . . . . . . 7 1.4 Requirements for Implementations . . . . . . . . . 7 1.5 Related Documents . . . . . . . . . . . . . . . . 8 2 FUNCTIONAL DESCRIPTION . . . . . . . . . . . . . . . 9 2.1 Design Scope . . . . . . . . . . . . . . . . . . 10 2.2 Relationship to DIGITAL Network Architecture . . 11 2.3 Network Management Model of DNA from the User Perspective . . . . . . . . . . . . . . . . . . 14 2.3.1 Nodes . . . . . . . . . . . . . . . . . . . . 15 2.3.2 Areas . . . . . . . . . . . . . . . . . . . . 16 2.3.3 Logging . . . . . . . . . . . . . . . . . . . 17 2.3.4 Circuits and Lines . . . . . . . . . . . . . . 17 2.3.5 Modules . . . . . . . . . . . . . . . . . . . 18 2.4 Model of Network Management Components in the DNA Layers . . . . . . . . . . . . . . . . . . . . . 19 3 NETWORK MANAGEMENT AS SEEN BY THE USER . . . . . . 23 3.1 Nodes . . . . . . . . . . . . . . . . . . . . . 23 3.1.1 Node Parameters . . . . . . . . . . . . . . . 25 3.1.2 Node Counters . . . . . . . . . . . . . . . . 35 3.2 Areas . . . . . . . . . . . . . . . . . . . . . 36 3.3 Logging . . . . . . . . . . . . . . . . . . . . 37 3.3.1 Source Qualifiers . . . . . . . . . . . . . . 38 3.3.2 Logging Parameters . . . . . . . . . . . . . . 38 3.4 Circuits . . . . . . . . . . . . . . . . . . . . 39 3.4.1 Circuit Parameters . . . . . . . . . . . . . . 40 3.4.2 Circuit Counters . . . . . . . . . . . . . . . 48 3.5 Lines . . . . . . . . . . . . . . . . . . . . . 49 3.5.1 Line Parameters . . . . . . . . . . . . . . . 49 3.5.2 Line Counters . . . . . . . . . . . . . . . . 54 3.6 Circuit and Line State and Substate Model . . . 55 3.6.1 High Level Link User States . . . . . . . . . 56 3.6.2 Data Link States . . . . . . . . . . . . . . . 58 3.6.3 Network Management Data Link Service States . 60 3.6.4 Controllable and Observable States and Substates . . . . . . . . . . . . . . . . . . 63 3.7 Modules . . . . . . . . . . . . . . . . . . . . 65 3.7.1 X.25 Access Module . . . . . . . . . . . . . . 65 3.7.2 X.25 Protocol Module . . . . . . . . . . . . . 66 3.7.3 X.25 Server Module . . . . . . . . . . . . . . 72 3.7.4 Link Maintenance Modules . . . . . . . . . . . 75 3.8 Events . . . . . . . . . . . . . . . . . . . . . 78 3.8.1 Events Not Related to an Entity . . . . . . . 78 3.8.2 Node Events . . . . . . . . . . . . . . . . . 79 3.8.3 Circuit Events . . . . . . . . . . . . . . . . 79 3.8.4 Line Events . . . . . . . . . . . . . . . . . 80 3.8.5 Module Events . . . . . . . . . . . . . . . . 81 3.9 Event Parameters . . . . . . . . . . . . . . . . 81 Table of Contents Page 4 3.9.1 Network Management Layer . . . . . . . . . . . 81 3.9.2 Session Control Layer . . . . . . . . . . . . 82 3.9.3 End Communication Layer . . . . . . . . . . . 83 3.9.4 Routing Layer . . . . . . . . . . . . . . . . 84 3.9.5 Data Link Layer . . . . . . . . . . . . . . . 85 3.9.6 Physical Link Layer . . . . . . . . . . . . . 87 4 NETWORK CONTROL PROGRAM (NCP) . . . . . . . . . . 88 4.1 Network Control Program Functions . . . . . . . 88 4.1.1 Changing Parameters . . . . . . . . . . . . . 89 4.1.2 Gathering Information . . . . . . . . . . . . 89 4.1.3 Down-line Loading . . . . . . . . . . . . . . 90 4.1.4 Up-line Dumping . . . . . . . . . . . . . . . 90 4.1.5 Triggering Bootstrap . . . . . . . . . . . . . 90 4.1.6 Testing Link and Network . . . . . . . . . . . 90 4.1.7 Zeroing Counters . . . . . . . . . . . . . . . 91 4.2 Network Control Program Operation . . . . . . . 91 4.2.1 Specifying the Executor . . . . . . . . . . . 91 4.2.2 Program Invocation, Termination, and Prompting 91 4.2.3 Privileged Commands . . . . . . . . . . . . . 92 4.2.4 Input Formats . . . . . . . . . . . . . . . . 92 4.2.5 Output Characteristics . . . . . . . . . . . . 94 4.2.6 Status and Error Messages . . . . . . . . . . 94 4.3 Network Control Program Commands . . . . . . . . 96 4.3.1 SET and DEFINE Commands . . . . . . . . . . . 96 4.3.2 CLEAR and PURGE Commands . . . . . . . . . . . 104 4.3.3 TRIGGER Commands . . . . . . . . . . . . . . . 108 4.3.4 LOAD Commands . . . . . . . . . . . . . . . . 109 4.3.5 DUMP Commands . . . . . . . . . . . . . . . . 110 4.3.6 LOOP Commands . . . . . . . . . . . . . . . . 111 4.3.7 SHOW QUEUE Command . . . . . . . . . . . . . . 112 4.3.8 SHOW and LIST Commands . . . . . . . . . . . . 112 4.3.9 ZERO Commands . . . . . . . . . . . . . . . . 118 4.3.10 EXIT Command . . . . . . . . . . . . . . . . . 119 5 NETWORK MANAGEMENT OPERATION . . . . . . . . . . . 120 5.1 NICE Access Routines and Listener . . . . . . . 120 5.2 Local Network Management Functions . . . . . . . 121 5.3 Link Watcher . . . . . . . . . . . . . . . . . . 122 5.4 Data Link Service Functions . . . . . . . . . . 122 5.4.1 States and Substates . . . . . . . . . . . . . 123 5.4.2 Priority Control . . . . . . . . . . . . . . . 124 5.4.3 Link State Algorithms . . . . . . . . . . . . 125 5.4.4 Link Handling Functions . . . . . . . . . . . 126 5.5 Event Logger . . . . . . . . . . . . . . . . . . 127 5.5.1 Event Logger Components . . . . . . . . . . . 129 5.5.2 Suggested Formats for Logging Data . . . . . . 132 5.6 Down-line Load Operation . . . . . . . . . . . . 133 5.7 Up-line Dump Operation . . . . . . . . . . . . . 138 5.8 Trigger Bootstrap Operation . . . . . . . . . . 139 5.9 Loop Test Operation . . . . . . . . . . . . . . 140 5.9.1 Node Level Testing . . . . . . . . . . . . . . 140 5.9.2 Data Link Testing . . . . . . . . . . . . . . 149 5.10 Change Parameter Operation . . . . . . . . . . . 152 5.11 Read Information Operation . . . . . . . . . . . 154 Table of Contents Page 5 5.12 Zero Counters Operation . . . . . . . . . . . . 154 5.13 Loopback Mirror Operation . . . . . . . . . . . 154 5.14 NICE Logical Link Handling . . . . . . . . . . . 155 5.15 Algorithm for Accepting Version Numbers . . . . 157 5.16 Return Code Handling . . . . . . . . . . . . . . 157 6 NETWORK MANAGEMENT MESSAGES . . . . . . . . . . . 159 6.1 NICE Function Codes . . . . . . . . . . . . . . 159 6.2 Message Format Notation . . . . . . . . . . . . 160 6.3 Request Down-line Load Message Format . . . . . 161 6.4 Request Up-line Dump Message Format . . . . . . 163 6.5 Trigger Bootstrap Message Format . . . . . . . . 164 6.6 Test Message Format . . . . . . . . . . . . . . 165 6.7 Change Parameter Message Format . . . . . . . . 166 6.8 Read Information Message Format . . . . . . . . 167 6.9 Zero Counters Message Format . . . . . . . . . . 168 6.10 NICE System Specific Message Format . . . . . . 168 6.11 NICE Response Message Format . . . . . . . . . . 169 6.12 NICE Connect Initiate and Connect Accept Data Formats . . . . . . . . . . . . . . . . . . . . 170 6.13 Event Message Binary Data Format . . . . . . . . 170 6.14 Logical Loopback Message Formats . . . . . . . . 172 6.14.1 Connect Accept Data Format . . . . . . . . . . 172 6.14.2 Command Message Format . . . . . . . . . . . . 172 6.14.3 Response Message Format . . . . . . . . . . . 172 7 PARAMETER AND COUNTER BINARY FORMATS AND VALUES . 173 7.1 Introduction to Binary Format Descriptions . . . 173 7.1.1 Type Numbers . . . . . . . . . . . . . . . . . 173 7.1.2 Entity Parameter Identifier Format . . . . . . 173 7.1.3 String Identifier Format . . . . . . . . . . . 174 7.1.4 Node Identifier Formats . . . . . . . . . . . 174 7.1.5 Area Identifier Format . . . . . . . . . . . . 175 7.1.6 Object Format for Entity Types . . . . . . . . 175 7.1.7 Numeric Range . . . . . . . . . . . . . . . . 176 7.1.8 Parameter Display Format and Descriptive Encoding Notation . . . . . . . . . . . . . . 176 7.1.9 NICE Returns . . . . . . . . . . . . . . . . 176 7.1.10 Information Types . . . . . . . . . . . . . . 179 7.1.11 Applicability Restrictions . . . . . . . . . 179 7.1.12 Setability Restrictions . . . . . . . . . . . 179 7.2 Circuit Parameters . . . . . . . . . . . . . . . 180 7.3 Circuit Counters . . . . . . . . . . . . . . . . 183 7.4 Line Parameters . . . . . . . . . . . . . . . . 185 7.5 Line Counters . . . . . . . . . . . . . . . . . 187 7.6 Logging Parameters . . . . . . . . . . . . . . . 189 7.7 Module Parameters . . . . . . . . . . . . . . . 191 7.7.1 Console Module Parameters . . . . . . . . . . 191 7.7.2 Loader Module Parameters . . . . . . . . . . . 191 7.7.3 Looper Module Parameters . . . . . . . . . . . 192 7.7.4 Configurator Module Parameters . . . . . . . . 192 7.7.5 X.25 Access Module Parameters . . . . . . . . 194 7.7.6 X.25 Protocol Module Parameters . . . . . . . 194 7.7.7 X.25 Server Module Parameters . . . . . . . . 196 7.8 Module Counters . . . . . . . . . . . . . . . . 197 Table of Contents Page 6 7.8.1 X.25 Protocol Module Counters . . . . . . . . 197 7.8.2 X.25 Server Module Counters . . . . . . . . . 197 7.9 Node Parameters . . . . . . . . . . . . . . . . 197 7.10 Node Counters . . . . . . . . . . . . . . . . . 201 7.11 Area Parameters . . . . . . . . . . . . . . . . 202 7.12 Event Definitions . . . . . . . . . . . . . . . 202 7.13 Event Parameters . . . . . . . . . . . . . . . . 205 APPENDIX A VERSION COMPATIBILITY A.1 Versions 2.0 and 3.0 . . . . . . . . . . . . . . . A-1 A.1.1 Module Entity . . . . . . . . . . . . . . . . . A-2 A.1.2 Node Entity . . . . . . . . . . . . . . . . . . A-2 A.1.3 Logging Entity . . . . . . . . . . . . . . . . . A-2 A.1.4 Circuit and Line Entities . . . . . . . . . . . A-2 A.1.5 Event Logging . . . . . . . . . . . . . . . . . A-4 A.2 Versions 3.0 and 4.0 . . . . . . . . . . . . . . . A-4 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 INTRODUCTION Intended Audience This document is written primarily for those who implement Network Management on DECnet systems. However, it may also be of interest to anyone who wants to know the details of the Network Management structure. Knowledge of communications software technology, DECnet, and X.25 is prerequisite to understanding this document. Sections 1-4 describe Network Management mainly from the user perspective. Sections 5-7 describe Network Management internals. Network Management 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. Networks consist of software modules, 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.25 circuits. Network Management is part of the DIGITAL Network Architecture (DNA). DNA is the model on which DECnet network software implementations are based. 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. 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 certification.) Moreover, commands and functions specific to one particular operating system are not described herein. 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. 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: ___ ____ ______ ________ _____ __________ _____________ 5.6.0, Order No. AA-K177A-TK ___ _______ ____ ______________ _______ ________ _______ __________ _____________ ___ ________ ____ ____ __________ _____________ Order No. AA-Y298A-TK ___ ________ ____ _______ ____________ _____________ 1.0.0, Order No. AA-X440A-TK ___ ___________ __________ __________ _____________ 3.0.0, Order No. AA-X436A-TK ___ _______ ________ ________ __________ _____________ 4.0.0, Order No. AA-X439A-TK ___ _______ _____ __________ _____________ No. AA-X435A-TK ___ _______ _______ __________ _____________ No. AA-K182A-TK ______ _______ _______ ____________ ______ ___ _______ ___________ (Order No. AA-N149A-TC) provides an overview of the network architecture and an introduction to each of the functional specifications. Functional Description 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 to user programs for performing the following control functions: Loading remote systems. load a system in another node in the same network. Configuring resources. network configuration and modify message traffic patterns. Setting parameters. parameters (for example, node names) can be set and changed. Initiating and terminating network functions. manager or operator can turn the network on or off and perform loopback tests and other functions. Network Management also enables the user to monitor network functions, configurations, and states, as follows: Dumping remote systems. dump a system to another node in the same network. Examining configuration status. nodes can be obtained. For example, an operator can display the states of lines and nodes or the names of adjacent nodes. Examining parameters. settings, line type, or node names) can be read. Examining the status of network operations. monitor network operations. For example, the operator can find out what operations are in progress and whether any have failed. Examining performance variables. examine the contents of counters in lower DNA layers to measure network performance. In addition, Network Management's Event Logger provides automatic logging of significant network events. Besides controlling and monitoring the day-to-day operation of the network, the functions listed above work to collect information for future planning. These functions furnish basic operations (primitives) for detecting failures, isolating problems, and repairing and restoring a network. Functional Description Design Scope Network Management functions satisfy the following design requirements: Common interfaces. 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. Management components or functions. Ease of use. functions are easy for the operator or user programmer. Network efficiency. and memory efficient. It is line efficient where this does not conflict with other goals. Extensibility. management functions, leaving earlier functions as a compatible subset. This specification serves as a basis for building more sophisticated network management programs. Heterogeneity. of network node types, communication lines, topologies, and among different versions of Network Management software. Robustness. errors, protocol errors, and hardware errors are minimized. Security. mechanisms in the DIGITAL Network Architecture (for example, the access control mechanism of the Session Control Layer). Simplicity. Functions provided elsewhere in the architecture are not duplicated. Support of diverse management policies. covers a range between completely centralized and fully distributed management. Integrated abstractions. different Data Link protocols, are combined where possible into consistent higher level abstractions. The following are not within the scope of this version of Network Management: Functional Description Accounting. recording of usage data that would be used to keep track of individual accounts for purposes of reporting on or charging users. Automation. 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. protection against malicious use or gross errors by operators or programs. Upward compatibility of user interfaces. 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 by the integration of X.25 Network Management functions, the DMP device, and multipoint software functions. (See Appendix A.) Compatibility with versions before Version 2.0 is not supported. 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 general design of DNA is as follows in order from the highest to the lowest layer: The User Layer. supports user services and programs. The Network Control Program (NCP) resides in this 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. Network Application Layer support I/O device and file access functions. The Network Management software component in this layer is the Loopback Mirror, providing logical link loopback testing. Functional Description The Session Control Layer. the system-dependent aspects of logical link communication. The End Communication Layer. controls the creation, maintenance, and destruction of logical links, using the Network Services Protocol. The Routing Layer. route messages between source and destination nodes. The Data Link Layer. 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 Link Layer. 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 .----------------------------. ! User Modules ! `----------------------------' ! ! ! ! ! V .- ! ------- ! ------------------------------------. .------! ! Network ! Management Modules ! ! `- ! ------- ! ------------------------------------' ! ! ! ! ! ! ! ! V V ! ! ! .- ! -------------------------------- ! ------. ! :----> ! ! Network Application Modules ! ! ! ! `- ! -------------------------------- ! ------' ! ! ! ! ! ! ! ! V V V ! ! ! .---------------------------------------. ! ! :----> ! Session Control Modules ! ! ! ! `---------------------------------------' ! ! ! ! ! ! ! V ! ! ! .---------------------------. ! ! :------------> ! End Communication Modules ! ! ! ! `---------------------------' ! ! ! ! ! ! ! V ! ! ! .---------------------------. ! ! :------------> ! Routing Modules ! ! ! ! `---------------------------' ! ! ! ! ! ! ! V V V ! .-------------------------------------------. :------------> ! Data Link Modules ! ! `-------------------------------------------' ! ! ! V ! .--------------------------. `------------> ! Physical Link Modules ! `--------------------------' ! `-------------------------> Figure 1. Network Management Relation to DNA Functional Description Network Management contains two models: 1. 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). 2. The model for Network Management as part of DNA (Section 2.4). Network Management 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 entering commands of the form: verb entity 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 system with associated CPU and peripherals. Nodes are further described in the section entitled Nodes. Area areas for hierarchical routing purposes. Logging automatically of important aspects of the network operation. Logging is further explained in Section 2.3.3. Circuits described in Section 2.3.4. Lines Section 2.3.4. Modules 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 word "component" or "element" may be used in place of "entity". The user can observe, and, in some cases, control various aspects of entities. The entity-option qualifies the aspect of the entity upon 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 volatile data base permanent data base Counters are only kept in the volatile data base. Events are not kept in any data base. Events are captured by the event logging mechanism as they occur. Parameters 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. Of these, some can be cleared to a default value or to no operation. Parameters can be read. Counters counters are: Seconds since last zeroed Bytes received Bytes sent Counters can only be read, zeroed, or read and zeroed. Events 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. The user can, however, control aspects of the logging of events. The user program interface uses specified messages to pass the same types of requests as the interactive user can make. 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 Functional Description Network Management function. All other nodes in relation to the remote. 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, command, host, or target nodes. Loop node associated with one of the executor's circuits, and logical links to that node are routed out the line with the expectation that they will be looped back. command node Management function from the executor. It can be the executor itself or some remote node. host node system. target node level line test message, or generate a dump. In any particular operation, 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 target 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. Areas area 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 "1", which will not be displayed, thus hiding the unnecessary addressing hierarchy from the Network Manager. Functional Description Logging Logging is the automatic event recording mechanism of Network sink node sink source node 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 destination nodes. The Network Management software at each destination node knows the actual name and state of its resident sinks. Some examples of logging entity-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. 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. circuit 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. line 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 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 that 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 Routing. 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 level user's protocol. An Ethernet circuit is a path to many nodes 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 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. 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 Functional Description identification. The X.25 server module contains the data base needed to map an incoming X.25 call to a DECnet 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.25 protocol handler module contains the common data base needed to multiplex switched and permanent X.25 circuits over its line or lines. These parameters are from X.25 level 3, the packet level. This data base is organized by one or more local DTE (Data Terminal Equipment -- the X.25 equivalent of a node) addresses. The protocol handler module contains an X.25 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 assigned 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 information 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 of 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 Link layers. Model of Network Management Components in the DNA Layers The functional components of Network Management are as follows: user layer components Network Control Program (NCP). enables the operator to control and observe the network from a terminal. Section 4 specifies the NCP commands. Functional Description 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. programs and NCP with generic Network Management functions, and either convert them to Network Information and Control Exchange (NICE) protocol messages or pass them on to the Local Network Management Function. Section 5.1 describes the Network Management Access Routine's operation. 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. 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. 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. 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. 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 substates. Section 5.4 describes the Data Link Service operation. Event Logger. logging significant events for operator intervention or future reference. The process concerned with the event (for example, Routing) provides the data to the Event Logger, which can then record it. Section 5.5 describes the Event Logger operation. Functional Description Network Application layer components Loopback Mirror. the Loopback Mirror Protocol to provide node level loopback on logical links. Section 5.13 describes this Network Application layer component. Object Types The Network Management architecture requires three separate object types. Each has a unique object type number. The object types and numbers are: Type Object Type Number Network Management Listener 19 Loopback Mirror 25 Event Receiver 26 Table 0 - Network Management Object Types Functional Description .--------. | Interfaces for function / \________`. V requests ' !.-----. ! ` !! ! !----------. -> Control Interfaces \ ``-----'--'. | \ `%%%%%%\ \ V `===========' .----------. .------------------. | NCP | | User Program | `----------' `------------------' USER LAYER | | ============================== | ====== | =========================== .---------. | | Network Management | Link | | | commands from other | Watcher | V V nodes------------. `---------' .------------. .-----------. | | | | Network | | Network | | | | Network NICE | Management | NICE | Management|<--' | | Management Protocol| Access | Protocol | Listener | | | commands<-------------| Routines |--------->| | | | to other `------------' `-----------' | | nodes | | | V V V | .------------------------------------------------------------. | | Local Network Management Functions | | `------------------------------------------------------------' | | | | | | | | | | V | | | | | | | .------------. | | | | | | | | Maintenance|<-' | | | | | | | Functions | | | | | | | `------------' | | | | | | | | | | | V V V | | | | Events from .-----------. | | | | Events to other nodes---. | Data Link | | | | | other nodes | | Service |<------------' | | | <----------.-----------. | | Functions | | | | | Event |<--' `-----------' | | `----------->| Logger | | | | `-----------' NETWORK MANAGEMENT LAYER | | | | ==== | ===================== | == | ================ | ====== | ===== LOWER LAYERS | | | | | | V V | V | System dependent calls to | Service interface to | application layer and local | Data Link Layer | operating system functions | | (file access, logical link | Control over lower <----' loopback, set timer, etc.) | level functions V (examine line state, Control interface to turn on NSP, etc.) read event queues Figure 2. Network Management Layer Modules and Interfaces in a Single Node. Network Management as Seen by the User 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 Management 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. id-string to describe an identification. In all of these cases, an id-string 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 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-0E-01. In the following descriptions keywords (words that Network Management reserves for use in NCP commands) are capitalized. Brackets enclose optional input or output. Nodes A node is an implementation of a computer system that supports Routing, End Communication, 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 in Network Management as Seen by the User the format: NODE node-identification The node-identification is one of the following: node-name A node name consists of one to six upper case alphanumeric characters with at least one alpha character. A node name must be unique within a node and should be unique within the network. 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 number. 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 different areas. Only the address of 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. 2. Specify the executor node with the keyword EXECUTOR, as follows: EXECUTOR Node group identifications are as follows: ACTIVE NODES For a nonrouting 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 Network Management as Seen by the User circuit (i.e., loop nodes). LOOP NODES All nodes that are associated with a circuit for loop testing purposes. SIGNIFICANT NODES All nodes that have significant information associated with them for display purposes. When obtaining node information, that pertaining to the executor node is returned first, and that for loop nodes, last. 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 adjacency 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. 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 2. A data base of remote node parameters (for each remote node) and of optional adjacent node parameters. 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 as 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. Network Management as Seen by the User 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 an up-line dump of the adjacent node. 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 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 that the adjacent node receives when it is down-line loaded. This value defaults to the executor node. IDENTIFICATION string This is a text string that describes the executor node (for example, "Research Lab"). The string is 32 characters of any type. When entered in NCP, if the string contains blanks or tabs, it must be enclosed in quotation marks. A quotation mark within a quoted string is indicated by two adjacent quotation marks (""). 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 of the executor. LOOP ASSISTANT NODE node-id This identifies the loop-only parameter 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 Network Management as Seen by the User only. Its value is 40. LOOP NODE node-id This identifies the loop-only parameter 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 is the loop-only default block type for loop testing. This parameter applies to the executor node only. Its value is MIXED. PHYSICAL ADDRESS ethernet-address This read-only executor parameter is the Ethernet address currently in use to identify itself. 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 down-line loading the adjacent node. 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 (Section 5.4). The device type is one of the standard line device mnemonics (Table 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 ___ ___________ __________ __________ _____________ Network Management as Seen by the User (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 (64 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 the adjacent node. Program type is one of: SECONDARY [LOADER] TERTIARY [LOADER] SYSTEM STATE node-state This represents the operational state of the executor node. The possible states are: ON Allows logical links. OFF Allows no new links, terminates existing links, 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 other nodes. 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. Session Control Layer ADDRESS node-address This value is the address of the executor node. This parameter applies to the executor node only. Network Management as Seen by the User 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 maximum 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 user within the number of seconds specified, Session Control rejects 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. End Communication Layer ACTIVE LINKS number This read-only parameter represents the number of active logical links from the executor to the destination node. DELAY seconds This read-only parameter is the average round trip delay in seconds to the destination node. This parameter is kept on a 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 (End Communication specification). The number is decimal in the range Network Management as Seen by the User 1-255. 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 version number of the node End Communication. The format is the same as for the Network Management version. 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. If 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. 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 The AREA MAXIMUM HOPS number is decimal in the range 1-30. This parameter is only applicable if the executor node is of 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 routing update is forced. With a standard calculation, Routing also 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 the 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 a constant value of 6. (This value of 6 is included to provide compatibility with the parameter definition in Phase III, 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 the maximum size messages that the Routing 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 III. CIRCUIT circuit-id This read-only parameter identifies the circuit used to get to a 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 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 applicable 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 total 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 total number of routers the executor node can have on its Ethernet 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 Routing 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. The MAXIMUM COST number is decimal in the range 1-1022. 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 the length of the shortest path between the two nodes is too long. For correct operation, this parameter must not be less than the network diameter. (The 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 can 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 network 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 the 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 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. (This 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 constant 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 decimal integer in the range 0-9999. If two subaddresses are provided, the second must be greater than the first. TYPE node-type This parameter indicates the type of the executor node. The node-type is one of the following: ROUTING III NONROUTING III ROUTING IV NONROUTING IV AREA A routing node has full routing capability. A nonrouting node contains a subset of the Routing routing modules. The III and IV indicate the DNA phase of the node. Nonrouting nodes can deliver and receive packets to and from any node, but cannot route packets from 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 indicates the type of the reachable adjacent node. Node Counters Network Management displays or zeroes node counters as a group. The following Network Management counter is kept for nodes: 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 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 specifications for further explanation of the type of information counted. Areas An area is a group of nodes. The network manager groups nodes for hierarchical routing purposes. (Refer to the Routing specification.) The user can identify areas in two major ways: 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 III node. Area group identifications are as follows: ACTIVE AREAS All areas that the executor perceives Routing can reach. KNOWN AREAS Same as ACTIVE AREAS. All of the area parameters are owned by the routing layer and are as follows: CIRCUIT circuit-id This read-only parameter identifies the circuit used to get to a remote area. Circuit-id is an id-string. 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 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 the number of hops over to a destination area. A hop is Routing value representing the logical distance between two areas in a network. NEXT NODE node-id This read-only value indicates the next node on the circuit used to get to the area under scrutiny. STATE state This read-only value indicates the state of the area, either REACHABLE, or UNREACHABLE. 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 executor node ACTIVE LOGGING All known sink types that are in ON or HOLD state 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 The default sink-node is the executor node. 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 node-id, circuit-id, line-id, and module-id. Logging Parameters All the logging parameters are owned by the Network Management layer. These parameters are as follows: 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: 3.0-2 4.1-4,8,10 6.1,3,5 wild card notation indicates all types of events for a particular class. For example, 3.* 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: Network Management as Seen by the User Type Sink-name CONSOLE device-id FILE file-id MONITOR process-id The sink name format depends on what the executor system understands. 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 node name or a node address (Section 3.1). STATE sink-state This value indicates the executor node's logging state for the sink type. The possible values of sink-state are: ON 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 logging counters. Section 3.8 describes event parameters. 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 - All circuits that have at least one parameter. owner Network Management as Seen by the User for the exclusive use of the owner. For example, the owner may be the executor node (Routing) or some other network component. user 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. 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). 2. Executor node circuit parameters -- These are parameters that apply only to circuits whose owner is the executor node. (Refer to the section entitled Executor Node Circuit Parameters.) 3. DDCMP circuit parameters -- These are parameters that apply to DDCMP circuits only. (Refer to the section entitled DDCMP Circuit Parameters.) 4. X.25 circuit parameters -- These parameters apply to X.25 circuits only (Refer to the section entitled X.25 Circuit Parameters.) 5. 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 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, the 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. Setting 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 the 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 read-only Network Management substate (Section 3.6). 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 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. Executor Node Circuit Parameters The following parameters apply to circuits that are owned by the executor node: 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 1-65535. This parameter is qualified by ADJACENT NODE. LOOPBACK NAME node-name 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. DDCMP Circuit Parameters DDCMP circuits support the Network Management service functions of dump, load, and active and passive circuit loopback. The following parameters apply to DDCMP circuits: 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 and/or service functions are allowed. DISABLED SERVICE state and/or service functions are not allowed. 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 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, 16. 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 is 8. DYING THRESHOLD count This value represents the number of times to 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. If 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. Network Management as Seen by the User POLLING STATE polling-state This value represents the state of the tributary relative to the multipoint polling algorithm. If not set the default is AUTOMATIC. The possible states are: AUTOMATIC The tributary's state is allowed to vary according to the operation of the polling algorithm. ACTIVE/INACTIVE/DYING/DEAD The tributary is locked in the specified state. Polling-substate This value represents the tributary's state as determined by the polling algorithm. This applies only when the polling state is AUTOMATIC and is read-only to Network Management. Polling-substate is one of ACTIVE, INACTIVE, DYING, or DEAD. It is displayed as a tag on the polling state, for example: AUTOMATIC-INACTIVE TRANSMIT TIMER milliseconds This value represents the number of milliseconds to delay between data message transmits. Milliseconds is a decimal integer in the range 0-65535. If not set, the default is 0. X.25 Circuit Parameters X.25 circuits do not support any of the Network Management service functions. The following parameters apply to X.25 circuits: MAXIMUM DATA byte-count For permanent circuits, this value represents the Data Link maximum X.25 data size allowed on the circuit. For switched circuits owned by the executor node, this value represents the size that Routing is to request from X.25 for the circuit. Byte-count is a decimal integer in the range 1-65535. It must be <= to the maximum data size allowed within the X.25 protocol module. MAXIMUM WINDOW block-count For permanent circuits, this value represents the Data Link maximum number of X.25 blocks outstanding on the circuit. For switched circuits owned by the executor node, this value represents the window size that Routing is to request from X.25 for the circuit. Block-count is a decimal integer in the range Network Management as Seen by the User 1-255. USAGE usage-type This Data Link parameter defines the usage type of an X.25 circuit. The usage-type values are as follows: 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, and does not need to be dynamically switched. BLOCKING blocking-control This parameter applies to X.25 circuits that are owned by the executor node. The value indicates whether or not Routing 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. If 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 only to permanent circuits. A channel-number is a decimal integer in the range 0-4095. DTE dte-address This parameter is the Data Link X.25 local DTE address to which the circuit belongs. This applies only to permanent circuits. Dte-address is a decimal integer of one to sixteen digits. Network Management as Seen by the User 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 using the circuit. Object-id is as described for module X25-SERVER. 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. 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 by SERVICE PHYSICAL ADDRESS. Circuit Counters Network Management displays or zeroes counters as a group when the executor node (Routing) owns the circuit. The 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 Adjacency 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 errors outbound 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 Link counters are kept for a permanent X.25 circuit: Bytes received Bytes sent Data blocks received Data blocks sent 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 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 known lines that have at least one parameter. 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. Line Parameters There are five groups of line parameters: 1. Common line parameters (Section 3.5.1.1) 2. Non-Ethernet line parameters (Section 3.5.1.2) 3. DDCMP line parameters (Section 3.5.1.3) 4. LAPB line parameters (Section 3.5.1.4) Network Management as Seen by the User 5. 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 the line. A device-specification contains the following: dev A device mnemonic (Table 10, Section 7.4) c A controller number u A 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 or dev-c-u PROTOCOL protocol-name This value represents the Data Link protocol to be used on the line. The protocol-name values are as follows: 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. Network Management as Seen by the User DDCMP POINT This line is one end of a point-to-point DDCMP connection. It can be the line for only one circuit. DDCMP TRIBUTARY This line is a tributary end of a DDCMP multipoint group. It can be the line for only one circuit. LAPB This line uses the X.25 level 2 protocol and can be a line for the X25-PROTOCOL module. ETHERNET This line uses the Ethernet protocol for the Ethernet. RECEIVE BUFFERS number This value represents the number of receive buffers reserved for the line. It is a decimal number in the range 1-65535. STATE line-state This value represents Network Management operational state as described in the state and substate model in Section 3.6. Substate This value represents the line's read-only Network Management substate as described in Section 3.6. 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 mode for the line device. The values for clock-mode are: 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 is supplied externally to the controller. CONTROLLER controller-mode This value represents the Physical Link hardware controller mode for the line device. The values for controller-mode are: LOOPBACK For software controllable loopback of the controller. On those devices that can support this mode, it causes all transmitted messages to be looped back from within the controller itself. This is accomplished without 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 mode of the line device. The possible modes are: FULL Full-duplex HALF Half-duplex 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. If not set, the default is 3000 (3 seconds). 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. If not set, the default is 10000 Network Management as Seen by the User (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. Milliseconds is a decimal integer in the range 1-65535. If not set, there is no delay. SCHEDULING TIMER milliseconds This value represents 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 can also be applied to half-duplex lines of type DDCMP POINT. 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. If 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 the line. Byte-count is a decimal integer in the range 1-65535. 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 MAXIMUM WINDOW block-count This value represents the Data Link maximum number of unacknowledged transmitted blocks on the line. Block count is 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. 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 with the line device hardware. 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 Remote buffer errors Local buffer errors Remote process errors Local process errors The following Data Link counters are kept for an Ethernet line: Bytes received Bytes sent Data blocks received Data blocks sent Multicast bytes received Multicast data blocks received Data blocks sent, initially deferred Data blocks sent, single collision Data blocks sent, multiple collisions Send failure Collision detect check failure Receive failure Unrecognized frame destination Data overrun System buffer unavailable User buffer unavailable Circuit and Line State and Substate Model This section describes the Network Management state and substate model. This model applies to both circuits and lines, referred to generically as links. There is one model for the relationships between the states and substates. This model is applied independently to both circuits and lines. In other words, 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 model, 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 interest, one each for the high level user's internal view of a link, the Data Link protocol's exhibited view of a link, 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 Link, 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 Operation of various algorithms on circuits and lines differs according to how maintenance traffic is handled within their data link protocol. In some data link protocols (i.e. DDCMP and LAPB) 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 In the case of a circuit, the high 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 one of four states: 1. Off -- the link is not to be used. 2. 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 high level.