DECnet DIGITAL Network Architecture Maintenance Operations Functional Specification Version 3.0.0 September 1983 .-------. `=======' .------. .---. .-------. | | .-------. `======' `===' `=======' | | `=======' \\ ..| |\ \\ \ | | / / \...| .-----. .-------------. ......| | \ \ \ .-------. .-------. o\.--------------. o `--/ /--' `---|\--' o `-----\\ \-----' o / / | \ o \\ \ o / / | \ O \\ \ O ------------. .----------------. .-----------------. /| | \ \ \ / | \ \ \ \ /.-----| \------.\ \ / `-----| \-----' \ \ --------. / .---------------------. \ .----------------------. / | | | \| \ \ | / /----' `---------------------' `--------\ \ \-------' / / \ \ \ / / \ \ \ / .------------------------ / |\ \ \ \ \ \ \ \ \ \ \ \ \ .---------------- \ | \ \| \ \ `---------\ \ Maintenance Operations Functional Specification Page 2 ________ This document describes the structure, functions, interfaces, and protocols needed for the low level maintenance of a DECnet network. _______ _________ ___________ MAYNARD, MASSACHUSETTS 01754 Copyright (c) 1980, 1983 by Digital Equipment Corporation Table of Contents Page 3 CONTENTS 1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . 6 1.1 Functional Description . . . . . . . . . . . . . . 7 1.2 Design Scope . . . . . . . . . . . . . . . . . . . 8 1.2.1 Requirements . . . . . . . . . . . . . . . . . . 8 1.2.2 Goals . . . . . . . . . . . . . . . . . . . . . 8 1.2.3 Non-goals . . . . . . . . . . . . . . . . . . . 9 2 MODELS . . . . . . . . . . . . . . . . . . . . . . . 9 2.1 Relationship to DIGITAL Network Architecture . . . 9 2.2 Simplified Network Model . . . . . . . . . . . . 12 2.2.1 Low Level Maintenance Operation Model . . . . 12 3 INTERFACES . . . . . . . . . . . . . . . . . . . . 13 3.1 Data Link Interface . . . . . . . . . . . . . . 13 3.1.1 Maintenance-check . . . . . . . . . . . . . . 15 3.1.2 Open . . . . . . . . . . . . . . . . . . . . . 15 3.1.3 Close . . . . . . . . . . . . . . . . . . . . 16 3.1.4 Transmit . . . . . . . . . . . . . . . . . . . 16 3.1.5 Transmit-poll . . . . . . . . . . . . . . . . 17 3.1.6 Receive . . . . . . . . . . . . . . . . . . . 18 3.1.7 Receive-poll . . . . . . . . . . . . . . . . . 19 3.1.8 Receive-abort . . . . . . . . . . . . . . . . 19 3.2 User Level Maintenance Operation Interface . . . 20 3.2.1 Dump/Load Functions . . . . . . . . . . . . . 21 3.2.2 Loop Test Functions . . . . . . . . . . . . . 29 3.2.3 Remote Console Functions . . . . . . . . . . . 33 3.3 Network Management Interface . . . . . . . . . . 45 3.3.1 Set-state . . . . . . . . . . . . . . . . . . 45 3.3.2 Read-state . . . . . . . . . . . . . . . . . . 46 3.3.3 Add-dump/load-entry . . . . . . . . . . . . . 47 3.3.4 Remove-dump/load-entry . . . . . . . . . . . . 48 3.3.5 Set-dump/load-parameter . . . . . . . . . . . 48 3.3.6 Read-dump/load-list . . . . . . . . . . . . . 49 3.3.7 Read-dump/load-parameters . . . . . . . . . . 49 3.3.8 Set-console-parameter . . . . . . . . . . . . 50 3.3.9 Read-console-parameters . . . . . . . . . . . 51 3.4 Interface Usage Examples . . . . . . . . . . . . 51 3.4.1 A System Boot Monitor . . . . . . . . . . . . 52 3.4.2 A Minimal ASCII Console Carrier . . . . . . . 52 4 OPERATION . . . . . . . . . . . . . . . . . . . . 54 4.1 Common Algorithms . . . . . . . . . . . . . . . 54 4.2 Dump/Load . . . . . . . . . . . . . . . . . . . 55 4.2.1 Dump/Load Server . . . . . . . . . . . . . . . 56 4.2.2 Dump/Load Requester . . . . . . . . . . . . . 60 4.3 Loop Test . . . . . . . . . . . . . . . . . . . 62 4.3.1 Loop Server . . . . . . . . . . . . . . . . . 62 4.3.2 Loop Requester . . . . . . . . . . . . . . . . 63 4.4 Remote Console . . . . . . . . . . . . . . . . . 63 4.4.1 Console Server . . . . . . . . . . . . . . . . 63 4.4.2 Console Requester . . . . . . . . . . . . . . 66 Table of Contents Page 4 5 PROTOCOL MESSAGES . . . . . . . . . . . . . . . . 69 5.1 Dump/Load . . . . . . . . . . . . . . . . . . . 70 5.1.1 Memory Load with Transfer Address . . . . . . 70 5.1.2 Memory Load . . . . . . . . . . . . . . . . . 71 5.1.3 Request Memory Dump . . . . . . . . . . . . . 72 5.1.4 Request Program . . . . . . . . . . . . . . . 72 5.1.5 Request Memory Load . . . . . . . . . . . . . 73 5.1.6 Request Dump Service . . . . . . . . . . . . . 74 5.1.7 Memory Dump Data . . . . . . . . . . . . . . . 75 5.1.8 Parameter Load with Transfer Address . . . . . 75 5.1.9 Dump Complete . . . . . . . . . . . . . . . . 78 5.1.10 Assistance Volunteer . . . . . . . . . . . . . 78 5.2 Loop Test . . . . . . . . . . . . . . . . . . . 78 5.2.1 Loop Data Message . . . . . . . . . . . . . . 78 5.2.2 Looped Data Message . . . . . . . . . . . . . 79 5.3 Remote Console . . . . . . . . . . . . . . . . . 79 5.3.1 Boot . . . . . . . . . . . . . . . . . . . . . 79 5.3.2 Request ID . . . . . . . . . . . . . . . . . . 81 5.3.3 System ID . . . . . . . . . . . . . . . . . . 81 5.3.4 Request Counters . . . . . . . . . . . . . . . 84 5.3.5 Counters . . . . . . . . . . . . . . . . . . . 85 5.3.6 Reserve Console . . . . . . . . . . . . . . . 85 5.3.7 Release Console . . . . . . . . . . . . . . . 85 5.3.8 Console Command and Poll . . . . . . . . . . . 86 5.3.9 Console Response and Acknowledge . . . . . . . 86 APPENDIX A PREDEFINED VALUES A.1 Communication Devices . . . . . . . . . . . . . . A-1 A.2 Data Links . . . . . . . . . . . . . . . . . . . . A-2 A.3 System Processors . . . . . . . . . . . . . . . . A-2 APPENDIX B DATA LINK SPECIFIC INFORMATION B.1 DDCMP . . . . . . . . . . . . . . . . . . . . . . B-1 B.2 LAPB . . . . . . . . . . . . . . . . . . . . . . . B-1 B.3 Ethernet . . . . . . . . . . . . . . . . . . . . . B-1 APPENDIX C IMPLEMENTATION SPECIFIC DUMP/LOAD CHARACTERISTICS C.1 Secondary Loader . . . . . . . . . . . . . . . . . C-1 C.2 Tertiary Loader . . . . . . . . . . . . . . . . . C-1 APPENDIX D REVISION HISTORY D.1 Changes from Version 1.1 to Version 2.0 . . . . . D-1 D.2 Changes from Version 2.0 to Version 2.1.0 . . . . D-2 D.3 Changes from Version 2.1.0 to Version 3.0.0 . . . D-2 Table of Contents Page 5 APPENDIX E ETHERNET LOOP TESTING E.1 Introduction . . . . . . . . . . . . . . . . . . . E-1 E.1.1 Goals . . . . . . . . . . . . . . . . . . . . . E-1 E.1.2 Loop Testing Functions . . . . . . . . . . . . . E-1 E.1.3 Functional Model . . . . . . . . . . . . . . . . E-2 E.1.4 Conformance Requirements . . . . . . . . . . . . E-3 E.2 Interfaces . . . . . . . . . . . . . . . . . . . . E-3 E.2.1 Data Interface . . . . . . . . . . . . . . . . . E-4 E.2.1.1 LoopDirect . . . . . . . . . . . . . . . . . . E-4 E.2.1.2 LoopAssisted . . . . . . . . . . . . . . . . . E-5 E.2.1.3 LoopPoll . . . . . . . . . . . . . . . . . . . E-6 E.2.1.4 LoopAbort . . . . . . . . . . . . . . . . . . E-7 E.2.2 Network Management Interface . . . . . . . . . . E-7 E.2.2.1 EnableServer . . . . . . . . . . . . . . . . . E-7 E.2.2.2 DisableServer . . . . . . . . . . . . . . . . E-7 E.2.2.3 EnableAssistance . . . . . . . . . . . . . . . E-7 E.2.2.4 DisableAssistance . . . . . . . . . . . . . . E-7 E.2.2.5 ReadStatus . . . . . . . . . . . . . . . . . . E-8 E.3 Loop Test Examples . . . . . . . . . . . . . . . . E-8 E.3.1 Local Control Test Example . . . . . . . . . . . E-8 E.3.2 Remote Control Test Example . . . . . . . . . . E-9 E.4 Operation . . . . . . . . . . . . . . . . . . . . E-9 E.4.1 Loop Server . . . . . . . . . . . . . . . . . E-10 E.4.2 Loop Requester . . . . . . . . . . . . . . . . E-11 E.4.2.1 LoopDirect Function . . . . . . . . . . . . E-11 E.4.2.2 LoopAssisted Function . . . . . . . . . . . E-11 E.4.2.3 LoopPoll Function . . . . . . . . . . . . . E-12 E.4.2.4 LoopAbort Function . . . . . . . . . . . . . E-12 E.5 Protocol Messages . . . . . . . . . . . . . . . E-12 E.5.1 Reply Message . . . . . . . . . . . . . . . . E-13 E.5.2 Forward Data Message . . . . . . . . . . . . . E-13 Introduction Page 6 INTRODUCTION Certain maintenance functions need to be performed remotely at a low level in the overall network architecture. These are functions that cannot depend on high level software being operational in the system being maintained. In the context of this specification, low level implies direct usage of data link services. High level means such network functions as routing and end-to-end, virtual circuit type protocols, both of which are also users of data link services. This specification assumes that only a minimal level of data link services are available to support maintenance operations, and that these maintenance operations provide a base on which any higher level functions can be built. This document describes the structure, functions, interfaces, and protocols needed for low level maintenance. DNA is the model on which DECnet implementations are based. A DECnet network is a family of software modules, data bases, and hardware components used to tie DIGITAL systems together for resource sharing, distributed computation or remote system communication. DNA is a layered structure. Modules in each layer perform distinct functions. Modules within a single DNA layer (but typically in different computer systems) communicate using specific protocols. Modules in different layers (but typically in the same computer system) interface using subroutine calls or a system-dependent method. In this document interfaces are described in terms of calls to subroutines. This document assumes that the reader is familiar with computer communications and DECnet. The primary audience consists of those who implement DECnet systems or other systems under different architectures, but requiring the same functions. However, the document may be useful to anyone interested in the details of DECnet structure. 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 ___ _______ __________ __________ _____________ Order No. AA-X437A-TK ___ _______ ________ ________ __________ _____________ 4.0.0, Order No. AA-X439A-TK Introduction Page 7 ___ _______ _____ __________ _____________ No. AA-X435A-TK ___ _______ _______ __________ _____________ No. AA-K182A-TK ___ ________ _ _ _____ ____ _______ _ ____ ____ _____ ___ ________ _____ ______________ Xerox), Order No. AA-K759B-TK ______ _______ _______ ____________ ______ ___ _______ ___________ (Order No. AA-N149A-TC) provides an overview of the network architecture and an introduction to each of the DNA functional specifications. Functional Description Low level maintenance functions are divided into three categories. Operation within any category depends on the operability of at least part of the preceding category. The categories are: 1. Communications test 2. System console 3. System load/dump Each of these functions can be viewed either from the active or passive end. The active end is the one that is driving the maintenance function and the passive end is the one that is responding. Communications test determines if the data link communications path is operative. System console provides low level access to a system for the functions of: . Identify processor . Read data link counters . Boot system . Console carrier The console carrier is a general purpose console input/output channel. It provides a common communication mechanism to allow remote access regardless of console command specifics. Introduction Page 8 System load/dump copies the contents of processor memory to or from a remote system. boot causing a system to initialize itself. Initialization may include load used to mean the process of transferring a system image into processor memory from some source. This is one potential effect of a boot command. The source of major interest in this specification is a remote system, accessed via a communication channel. Design Scope The low level maintenance operations require certain characteristics to be present, attempt to meet certain goals, and lack some features that are not within the scope of the design. Requirements The maintenance operation design must have the following characteristics: . The functions previously mentioned must be included in the design. . Active and passive sides of maintenance operations can be implemented and used independently. The three categories of maintenance operations are inter-dependent only in simple, clearly defined ways. . Effects of errors (such as operator errors, protocol errors, and hardware errors) are minimized, always leaving a system in a well defined state. . It must be compatible with inter-company standard Ethernet loopback protocol. . Implementations may select subsets of functions based on particular product need. Goals The maintenance operation design tries to have the following characteristics: . Functions and protocols are upward compatible with the DNA Maintenance Operation Protocol (MOP) version 2.1. Introduction Page 9 . Algorithms, particularly those found in memory-only systems, are processing and memory efficient. Communications efficiency is a secondary goal. In the specific case of down-line load and up-line dump, overall speed of operation is an important goal. . Extensible to accommodate newly developed functions or modification of current functions. . Operates independently of the underlying communication mechanism (e.g. DDCMP, Ethernet, etc.). . No complex algorithms or data bases. Minimal state kept in the smallest systems. Non-goals The maintenance operation design does not try to have the following characteristics: . Isolation of components that have failed in a failing system. . System security in the low level maintenance functions. MODELS This section describes the relationship of the low level maintenance operations to other network layers and modules. Although this specification primarily relates the maintenance operations to DNA, the same relationships can also be applied within other network architectures, such as the DIGITAL System Communication Architecture. Relationship to DIGITAL Network Architecture The maintenance operations reside in the DNA Network Management Layer. They are direct users of the DNA Data Link Layer. The other DNA layers are not required in the support of the low level maintenance operations unless such services as remote file access are to be used. The following diagram shows the overall layering of DNA. A later diagram shows the simplified model that is applicable to the low level maintenance operations. Models Page 10 .----------------------------. | 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 | `---------------------------' | `-------------------------------- NOTE Horizontal arrows show direct access for control and observation of parameters, counters, etc. Vertical arrows show interfaces between layers for normal user operations such as file access, down-line load, and logical link usage. Each layer in DNA consists of functional modules and protocols. Generally, modules use the services of the next lower layer. In this document, the service relationship is demonstrated in the way the interfaces are modeled, as calls to subroutines. Note that the Network Management Layer interfaces directly with each of the lower Models Page 11 layers. Also, the layers above Session Control interface directly with it. For this reason the upper three layers are sometimes referred to as the "end user." Modules of the same type in the same layer communicate with each other to provide their services. The rules governing this communication and the messages required constitute the protocol for those modules. Messages are typically exchanged between equivalent modules in different nodes. However, equivalent modules within a single node can also exchange messages. A brief description of each layer follows in order from the highest to the lowest layer: User Layer. services and programs. Programs such as the Network Control Program, which interfaces with the Network Management Layer, and file transfer programs, which interface with the Network Application Layer, reside in the User Layer. Network Management Layer. only one that has direct access to each lower layer for control purposes. Modules in this layer provide user control over and access to network parameters and counters. These modules also perform up-line dumping, down-line loading, and testing functions. Network Application Layer. Layer support network functions, such as remote file access and file transfer, used by the User and Network Management Layers. Session Control Layer. system-dependent aspects of logical link communication, which allows messages to be sent from one node to another in a network. Session Control functions include name-to-address translation, process addressing, and, in some systems, process activation and access control. End Communication Layer. the system-independent aspects of logical link communication. Routing Layer. called packets, between source and destination nodes. Data Link Layer. concerning data integrity and physical channel management. Physical Link Layer. part of the device driver for each communications device plus the communications hardware itself. The hardware includes interface devices, modems, and the communication lines. Models Page 12 Simplified Network Model The following diagram shows a simplified relationship of the maintenance operations to the rest of the network architecture. .------. User | User | Layer `------' . . . . . . . . . . . | . . . . . . . . . . . . . . . . | .-------------. Network | Maintenance | Management | Operations | Layer `-------------' . . . . . . . . . | . | . | . . . . . . . . . . . . . . | | | .-------' | ` --------. Data | | | Link .-------. .----------. .-------. Layer | DDCMP | | Ethernet | | Other | | Data | | Data | | Data | | Link | | Link | | Link | `-------' `----------' `-------' Low Level Maintenance Operation Model The following diagram shows the components within the maintenance operation module. .----------------------------------------------------------------------. | U s e r P r o c e s s e s | `----------------------------------------------------------------------' | | | | | | | | | | | .-----------. | .-----------. | | .-----------. | | | `-| Dump/Load | `-| Dump/Load | | | | Dump/Load | | | | | Data Base |===| Server | | | | Requester | | | | `-----------' `-----------' | | `-----------' | | | | | | | | | | | .-------------------' | | | | | | | | | | | | .-------' | | | .----------' | | | | | | | | | | | | | | | | .-------' | | | | .-----------. | | .---------. | | .--------. .----------. | Console | | `--| Console | | `--| Loop | | Loop | | Requester | | | Server | | | Server | | Requester| `-----------' | `---------' | `--------' `----------' | | | | | | .-----------------------------------------------------------------------. | D a t a L i n k | `-----------------------------------------------------------------------' Models Page 13 Requesters are the processes responsible for initiation of maintenance operations. This can be done either at higher level user request, or because of information obtained from a lower level. Requesters are the active side of a maintenance operation. Servers are the processes that respond to maintenance requesters. They are the passive side of a maintenance operation. Servers should not try to do more than they are capable of. For example, it is not acceptable to always volunteer to load every system that requests it and then take too long to get done because the local resources are overextended. The diagram shows servers and requesters as separate to represent their functional independence. In an implementation that supports multiple servers and/or requesters that use the same protocol type, they may have to be more closely coupled so that messages received through the data link are properly demultiplexed. Also, servers and requesters that allow multiple users must further demultiplex messages to the proper user processes. The Dump/Load Data Base contains default information that the Dump/Load Server uses to fill in necessary values in incomplete requests. Lines to the top of processes indicate flow of the control data that initiates processing. Lines to the side indicate Network Management control. The double horizontal line indicates data base access. INTERFACES The following sections describe the interfaces related to maintenance operations. The function descriptions are in terms of subroutines with input and output arguments. These subroutines are to be understood as abstract, functional descriptions. Actual implementations may vary, for example in synchronization techniques, as long as they provide the same functions. References to buffers in all of the following subroutine descriptions assume a buffer descriptor containing buffer address, maximum buffer length, and, if applicable, length of information in buffer. Data Link Interface Maintenance operations can be performed over communication channels provided by different data link disciplines. All of the potential data link user interfaces are abstracted into the functions required for maintenance operations. This section describes that interface. This section is included to define exactly what services a data link must provide so that the low level maintenance functions can be performed. It is an abstract representation of all possible data link interfaces, in terms that are directly applicable to low level Interfaces Page 14 maintenance operations. From the perspective of maintenance operations, there are two data link configurations: point-to-point and multiaccess. Point-to-point data links are those where there is a single node on the each end of a logical channel. Transmits and receives are always between these two nodes. Multipoint is treated as point-to-point, in the sense that each logical channel (tributary) is identified and used independently. Multiaccess data links are those where the number and identification of all adjacent nodes are not necessarily known. On multiaccess data links, node identification must accompany transmit and receive requests. Additionally, multiaccess data links may provide multicast service for communications with a class of nodes. Independently of configuration, some data links may allow concurrent operation of both normal and maintenance traffic. Others may allow maintenance traffic only in a mode that excludes normal traffic. This interface assumes that all data links offer the same basic services, framing and error checking. The data link frames messages and provides the length of received messages. Messages are sent and received in the order they were offered by the sender. Messages that the data link delivers to the receiver have been checked for bit errors. It is possible for messages to be lost with no notification to either sender or receiver. The interface function descriptions refer to data link configuration and maintenance exclusiveness as necessary to indicate differences of operation. The Data Link Interface contains the following functions: . Maintenance-check -- check to see if maintenance service is needed. . Open -- open a port. . Close -- close a port. . Transmit -- send a frame. . Transmit-poll -- check for completion of a Transmit. . Receive -- receive a frame. . Receive-poll -- check for completion of a Receive. . Receive-abort -- abort a Receive. Interfaces Page 15 Maintenance-check Function: Checks the channel to see if maintenance service is needed. Applicable only on exclusive maintenance channels. Inputs: Channel-id - the unique identification of the channel to check. Outputs: Return-code - the status of the request. One of: Running normally - the channel is running or attempting to run normal user traffic. Maintenance needed - the channel wants to run maintenance traffic. Unrecognized channel - there is no channel with the specified identification. Channel in wrong state - the channel is not in a state where the check can be made. Open Function: Opens a port so that the user can transmit and receive frames. Inputs: Channel-id - the unique identification of the channel on which the port is to be opened. Pad - an indication that the data link is to use its own standard padding technique if padding is necessary. Maintenance operations use this option, when available, for all but the multiaccess channel loop protocol. Id-list - a list of identification data, such as protocol types or multicast addresses, that identify this user of the data link. Data link specific and applicable only on concurrent maintenance channels. For example, in the Ethernet Data Link this abstract id-list function is accomplished using the Ethernet Data Link Open, Enable-protocol, and Enable-multicast functions. Outputs: Return-code - the status of the request. One of: Interfaces Page 16 Success - a port was opened. No resources - the data link does not have sufficient resources to open a port. Unrecognized channel - there is no channel with the specified identification. Channel in wrong state - the channel is not in a state where a port can be opened. Port-id - a port identification to be used in the other data link interface functions. Close Function: Closes an open port and releases all its resources. A port cannot be closed unless all outstanding transmit or receive requests are completed. Inputs: Port-id - a port identification assigned by the Open function. Outputs: Return-code - the status of the request. One of: Success - the port is closed. Unrecognized port - there is no open port with the specified identification. Calls outstanding - there are uncompleted transmit or receive requests outstanding on the port. Transmit Function: Queues a frame to be transmitted. The user tests for completion by using Transmit-poll. Transmission of a frame always succeeds or fails within such a small amount of time that an abort function is not necessary. Inputs: Port-id - a port identification assigned by the Open function. Interfaces Page 17 Destination-address - the address of the frame destination. This can be either a physical address or a multicast address. Applicable only on multiaccess channels. Protocol-type - a protocol type to identify the data at the receiving system. Applicable only on concurrent maintenance channels. Input-buffer - a buffer containing the data to be sent. Until the request is completed, the user must not disturb the contents of the buffer. Outputs: Return-code - the status of the request. One of: Request accepted - the data link will attempt to transmit the frame. Notification of completion is via the Transmit-poll function. No resources - the data link does not have sufficient resources to queue a transmit for this port. Unrecognized port - there is no open port with the specified identification. Channel in wrong state - the channel is not in a state where it can send a frame. Transmit-poll Function: Checks for the completion of a transmit request. The data link transmits frames in the order in which the user submits them. Successful completion of this function implies only that the local transmitter believes that it sent the frame. It does not necessarily imply that the destination received it. Inputs: Port-id - a port identification assigned by the Open function. Outputs: Return-code - the transmit request for this port. One of: Not complete - no transmit for this port is done. None outstanding - there are no outstanding transmits for this port. Interfaces Page 18 Transmit successful - a frame successfully left the local transmitter. Transmit failed - the local transmitter could not transmit the frame. Unrecognized port - there is no open port with the specified identification. Channel in wrong state - the channel is not in a state where it can send a frame. Input-buffer - the buffer that was supplied in the Transmit function. Receive Function: Queues a buffer to receive a frame. On multiaccess or concurrent maintenance channels, the receive is filtered according to the id-list established in the Open function. Inputs: Port-id - a port identification assigned by the Open function. Output-buffer - a descriptor of a buffer to contain the received frame. Outputs: Return-code - the status of the request. One of: Request accepted - if a message is received for the specified port, the data link will put it into the buffer. Notification of completion is via the Receive-poll function. No resources - the data link does not have sufficient resources to queue a receive for this port. Unrecognized port - there is no open port with the specified identification. Channel in wrong state - the channel is not in a state where it can receive a frame. Interfaces Page 19 Receive-poll Function: Check for the completion of a receive request. The data link gives received frames to the user in the order in which they arrived. Inputs: Port-id - a port identification assigned by the Open function. Outputs: Return-code - the status of the receive request. One of: Not complete - no outstanding receive for this port is done. None outstanding - there are no outstanding receives for this port. Receive successful - a frame was successfully received into the buffer. Receive with overrun - a frame was successfully received, but had to be truncated to fit into the buffer. Receive aborted - the user cancelled the receive request with the Receive-abort function. Unrecognized port - there is no open port with the specified identification. Channel in wrong state - the channel is not in a state where it can receive a frame. Destination-address - the address to which the received frame was addressed. Applicable only on multiaccess channels. Source-address - the address from which the received frame came. Applicable only on multiaccess channels. Protocol-type - the protocol type from the received frame. Applicable only on concurrent maintenance channels. Output-buffer - the received data. Receive-abort Function: Aborts all outstanding receive requests. The buffers are returned via the Receive-poll function. They may be returned as aborted or Interfaces Page 20 as normally completed. Inputs: Port-id - a port identification assigned by the Open function. Output-buffer - a descriptor of a buffer for a pending receive. Outputs: Return-code - the status of the request. One of: Success - the request is now complete. Unrecognized port - there is no open port with the specified identification. Unrecognized buffer - the specified buffer is not queued for the specified port. User Level Maintenance Operation Interface This section describes the functions available to the maintenance operation user. The descriptions relate each function to its respective component in the maintenance operation model. The functions are divided into three groups: . Dump/Load Functions . Loop Test Functions . Remote Console Functions The Dump/Load Functions are: . Force-load -- load a remote system. . Force-load-poll -- check for completion of a Force-load. . Load-self -- load the local system. . Load-self-poll -- check for completion of a Load-self. . Force-dump -- dump a remote system. . Force-dump-poll -- check for completion of a Force-dump. . Dump-self -- dump the local system. Interfaces Page 21 . Dump-self-poll -- check for completion of a Dump-self. The Loop Test Functions are: . Loop-direct -- loop test direct with another system. . Loop-assisted -- loop test with third-party assistance. . Loop-poll -- check for completion of a loop. . Loop-abort -- abort a loop. The Remote Console Functions are: . Request-poll -- check for remote execution control request. . Identify-self -- send system identification. . Boot -- force remote system to load. . Read-identity -- read remote identity. . Read-identity-poll -- check for completion of a Read-identity. . Read-counters -- read remote data link counters. . Read-counters-poll -- check for completion of a Read-counters. . Reserve-remote-console -- reserve remote system's console. . Release-remote-console -- release remote system's console. * . Send-console-command -- send command message to remote console. * . Console-response-poll -- check for completion of Send-console- command. * . Send-console-response -- send console response data to remote command Console Requester. * . Console-abort -- abort a pending console function. * Requires that the Console Server be reserved. Dump/Load Functions The following functions are performed by either the Dump/Load Requester or the Dump/Load Server. Interfaces Page 22 Force-load Function: Forces a down-line load of the system on the specified channel. This function is a call to the Dump/Load Server. It is a server function rather than a requester function since the server is the component that will actually service the load request that is forced from the target system. The Force-load function queues the request. The user checks for completion with the Force-load-poll function. Inputs: Channel-id - the unique identification of the channel over which the load is to be performed. If not specified, the channel-id from the Dump/Load Data Base is used. Destination-address - the identification of the target system. If not specified but needed, the destination-address from the Dump/Load Data Base is used. Destination-address is needed on multiaccess channels. NOTE Either the channel-id or the destination-address must be included in order to identify the target system. If both are included, the destination-address is used as the data base search key to find other values in the Dump/Load Data Base. Load-file - the identification of the file that is to be down-line loaded into the target system. If not specified, the file identification from the Dump/Load Data Base is used. Secondary-loader - the identification of the file that contains the secondary loader program to use. If not specified but needed, the file identification from the Dump/Load Data Base is used. Tertiary-loader - the identification of the file that contains the tertiary loader program to use. If not specified but needed, the file identification from the Dump/Load Data Base is used. Outputs: Return-code - the status of the request. One of: Request accepted - the load process will be initiated. Notification of completion is via the Force-load-poll function. Interfaces Page 23 No resources - the Dump/Load Server does not have sufficient resources to queue the request. Unrecognized channel - there is no channel with the specified identification. Channel in wrong state - the channel is not in a state where a load can be done. Receipt-number - a receipt number to identify this request in the Force-load-poll function. Force-load-poll Function: Checks for completion of a pending Force-load function. This function is a call to the Dump/Load Server. Inputs: Receipt-number - the receipt number assigned by the Force-load function to identify the request. Outputs: Return-code - the status of the request. One of: In process - the load is proceeding. Success - the down-line load completed successfully. Force boot failed - could not force the target system to enter a booting state. Memory load error - the target system reported an error in attempting to deposit part of the load. File open error - could not open one of the files. Invalid file contents - invalid data in one of the files. File I/O error - I/O error reading one of the files. Channel communication error - error in transmit or receive on the channel. Channel protocol error - error in protocol usage by the target system. Unrecognized channel - there is no channel with the specified identification. Interfaces Page 24 Unrecognized target - the Dump/Load Data Base was needed but did not contain an entry for the specified target. Channel in wrong state - the channel is not in a state where a load operation can be done. File-indicator - the indication of which file a file error relates to. Not meaningful for non-file related errors. One of: Load file Secondary loader Tertiary loader Load-self Function: Requests a down-line load of the local system. This is the communications channel equivalent of a system loading itself from local mass storage. Note that only one self-load can be in progress at a time. If a second request is made before a previous one completes, the new request simply replaces the old one. This function is a call to the Dump/Load Requester. Inputs: Channel-id - the unique identification of the channel on which the load is to be done. Destination-address - the identification of the system that is to assist in the load. Applicable only on multiaccess channels. If the address is applicable but not specified, the load will be taken from whatever system is able to help (for further details, see operation section). System-processor - the processor type of the local system. If not specified, the assisting system must assume a type. Defined types are in Appendix A. Software-id - the type of software desired. If not specified, the assisting system must assume a type. Other-info - further, implementation-specific information. Zero or more other-info parameters may be included, each consisting of: Parameter-id - identification of the parameter. Identifications are related to the standard parameters (e.g. communications-processor, system-bus) on an implementation-specific basis. Parameter-value - the value of the parameter. Interfaces Page 25 Outputs: Return-code - the status of the request. One of: Request accepted - the load process will be initiated. Notification of completion is via the Load-self-poll function. Unrecognized channel - there is no channel with the specified identification. Channel in wrong state - the channel is not in a state where a load can be done. Load-self-poll Function: Checks for completion of the pending Load-self function. This function is a call to the Dump/Load Requester. Inputs: None. Outputs: Return-code - the status of the request. One of: Requesting - the load is being requested. In process - the load is proceeding. Successful - the load completed successfully. Failure - the load failed. Start-address - on successful load completion, the starting memory address of the loaded image. Local-address - the network address that the local system is to use. Not returned if not received. Local-name - the network name that the local system is to use. Not returned if not received. Host-address - the network address of the host that this system is to use. Not returned if not received. Host-name - the network name of the host that this system is to use. Not returned if not received. Host-date-time - the date and time at the host system. Not returned if not received. Interfaces Page 26 Force-dump Function: Forces an up-line dump of the system on the specified channel. This function is a call to the Dump/Load Server. It is a server function rather than a requester function since the server is the component that will actually dump the target system. The Force-dump function queues the request. The user checks for completion with the Force-dump-poll function. Inputs: Channel-id - the unique identification of the channel over which the dump is to be performed. If not specified, the channel-id from the Dump/Load Data Base is used. Destination-address - the identification of the target system. If not specified but needed, the destination-address from the Dump/Load Data Base is used. Destination-address is needed on multiaccess channels. NOTE Either the channel-id or the destination-address must be included in order to identify the target system. If both are included, the destination-address is used as the data base search key to find other values in the Dump/Load Data Base. Dump-file - the identification of the file that is to be up-line dumped into on the target system. If not specified, the file identification from the Dump/Load Data Base is used. Dump-address - the memory address in the target system to begin dumping from. If not specified and not obtainable from the target, the value from the Dump/Load Data Base is used. Dump-count - the number of memory units to dump. Memory units are whatever is customary for the processor type: usually, but not necessarily, eight-bit bytes. If not specified, and not obtainable from the target, the value from the Dump/Load Data Base is used. Outputs: Return-code - the status of the request. One of: Request accepted - the dump process will be initiated. Notification of completion is via the Force-dump-poll function. Interfaces Page 27 No resources - the Dump/Load Server does not have sufficient resources to queue the request. Unrecognized destination - there is no destination with the specified identification. Unrecognized channel - there is no channel with the specified identification. Channel in wrong state - the channel is not in a state where a dump can be done. Receipt-number - a receipt number to identify this request in the Force-dump-poll function. Force-dump-poll Function: Checks for completion of a Force-dump function. Inputs: Receipt-number - the receipt number assigned by the Force-dump function to identify the request. Outputs: Return-code - the status of the request. One of: In process - the dump is proceeding. Success - the up-line dump completed successfully. Remote dump failed - could not force the target system to cooperate. The higher level may be able to remedy this with a Force-load. Memory read error - the target system reported an error in reading memory. File open error - could not open the dump file. Invalid file contents - invalid data in the dump file. File I/O error - I/O error reading or writing the dump file. Channel communication error - error in transmit or receive on the channel. Channel protocol error - error in protocol usage by the target system. Interfaces Page 28 Unrecognized channel - there is no channel with the specified identification. Unrecognized target - the Dump/Load Data Base was needed, but did not contain an entry for the specified target. Channel in wrong state - the channel is not in a state where a dump operation can be done. Dump-self Function: Requests an up-line dump of the local system. This is the communications channel equivalent of a system dumping itself to local mass storage. Note that only one self-dump can be in progress at a time. If a second request is made before a previous one completes, the new request simply replaces the old one. This function is a call to the Dump/Load Requester. Inputs: Channel-id - the unique identification of the channel on which the dump is to be done. Destination-address - the identification of the system that is to assist in the dump. Applicable only on multiaccess channels. If applicable but not specified, the dump will go to whatever system is able to help. Dump-address - the address in local memory at which the dump is to begin. If not specified, the assisting system must assume an address. Dump-count - the number of memory units to dump. Memory units are whatever is customary for the processor type; usually, but not necessarily, eight bit bytes. If not specified, the assisting system must assume a count. System-processor - the processor type of the local system. If not specified, the assisting system must assume a type. Defined types are in Appendix A. Software-id - the type of software that was running. If not specified, the assisting system must assume a type. Defined types are in Appendix A. Other-info - further, implementation-specific information. Zero or more other-info parameters may be included, each consisting of: Parameter-id - identification of the parameter. Identifications are related to the standard parameters (e.g. communications-processor, system-bus) on an Interfaces Page 29 implementation-specific basis. Parameter-value - the value of the parameter. Outputs: Return-code - the status of the request. One of: Request accepted - the dump process will be initiated. Notification of completion is via the Dump-self-poll function. Unrecognized channel - there is no channel with the specified identification. Channel in wrong state - the channel is not in a state where a dump can be done. Dump-self-poll Function: Checks for completion of the pending Dump-self function. This function is a call to the Dump/Load Requester. Inputs: None. Outputs: Return-code - the status of the request. One of: Requesting - the dump is being requested. In process - the dump is proceeding. Successful - the dump completed successfully. Failure - the dump failed. Loop Test Functions The specific goals in the design of the Loop Test functions are: . Provide for all forms of loop test that are necessary to diagnose a system's ability to communicate. . Allow each system to assume the responsibility to diagnose its own ability to communicate. Interfaces Page 30 . For multiaccess channels, allow a network management system to diagnose some other system's ability to communicate. . Minimize processing and memory requirements, particularly in systems other than the requesting system. The realization of these goals is different for multiaccess channels and point-to-point channels, since multiaccess channels have a broader communication ability. On a point-to-point channel, a system using the Loop Test functions on its own behalf and having all of them available can ascertain its ability to communicate with the system on the other end of the channel. For multiaccess channels, the Loop Test functions are modeled after the Ethernet standard. See Appendix E or the Ethernet Specification, Version 2.0, for a detailed description. Some multiaccess channels may support the concept of a generic loopback assistant. These are systems that are willing to assist in some forms of multiaccess loopback testing. The following descriptions refer to these systems as the loopback assistant multicast group. The amount of the Loop Test interface that is implemented can cover the full range from none at all to full capability. However, those systems that do not provide the full interface capability proportionately limit their capacity for self diagnosis and become more dependent on some centralized test facility. The following functions are all calls to the Loop Requester. Loop-direct Function: Determine if direct communication with a remote system is possible. Inputs: Channel-id - the unique identification of the channel on which the loop is to be done. Destination-address - the identification of the system that is to be looped to. Applicable only on multiaccess channels. If applicable and not included, the loopback assistant group multicast address is used. Interfaces Page 31 Input-buffer - a buffer containing the data to be looped. Output-buffer - a buffer to contain the looped back data. If not present, the looped back data is not returned to the user. Outputs: Return-code - the status of the request. One of: Request accepted - the loop will be attempted. Unrecognized channel - there is no channel with the specified identification. Channel in wrong state - the channel is in a state where a loop cannot be done. Receipt-number - the request identification used in the Loop-poll or Loop-abort function to identify this request. Loop-assisted Function: Determine if some other system can communicate with the specified remote system. Applicable only on multiaccess channels. Inputs: Channel-id - the unique identification of the channel on which the loop is to be done. Destination-address - the identification of the system that is to be looped to. The destination-address cannot be a multicast address. Assistant-address - the identification of the third party system to assist in the test. The address cannot be a multicast address. Assistance-level - the amount of assistance desired: transmit - the assistant station is only to relay the request, the request is to be returned from the destination system. receive - the assistant station is only to relay the reply, the request is to be sent to the destination station. full - the assistant station is to relay both request and reply. Input-buffer - a buffer containing the data to be looped. Interfaces Page 32 Output-buffer - a buffer to contain the looped back data. If not present, the looped back data is not returned to the user. Outputs: Return-code - the status of the request. One of: Request accepted - the loop will be attempted. Unrecognized channel - there is no channel with the specified identification. Channel in wrong state - the channel is in a state where a loop cannot be done. Receipt-number - the request identification used in the Loop-poll or Loop-abort function to identify this request. Loop-poll Function: Used to poll for completion of a Loop-direct or Loop-assisted. Inputs: Receipt-number - the request identification assigned to this request by the Loop function. Outputs: Return-code - the status of the operation. One of: Not complete - the loop is not yet done. Success - the data came back correctly. Aborted - the request was aborted with a Loop-abort. Compare error - the data came back, but it did not match what was sent. Transmit failed - the local transmitter could not send the initial message. Channel communication error - no response was received. Either the initial message or the response did not arrive. Responding-address - the identification of the remote system that satisfied the request. Applicable only on multicast channels. For Loop-assisted with transmit assistance, this is the remote system address. For Loop-assisted with receive or full assistance, it is the assistant system address. Interfaces Page 33 Output-buffer - the looped back data received, whether correct or not. Present only if the buffer was furnished on the Loop call. Loop-abort Function: Used to abort a Loop-direct or Loop-assisted, for example if the user decides that the reply has taken too long. Inputs: Receipt-number - the request identification assigned to this request by the Loop-direct or Loop-assisted function. Outputs: none. Remote Console Functions There is an aspect of the Console Server operational model that affects the user interface in a way that must be explained here. This is the relationship between data access functions and control functions. Data access Read-identity). The model assumes that the Console Server has necessary access abilities without higher level involvement. Control execution of a processor (for example, Boot). The model assumes that the Console Server cannot do this directly. The higher level must therefore poll the Console Server for this type of request and the information needed to honor it. Most of the remote console functions are calls to the Console Requester. Console Requester operations are of two types, those that require exclusive access to the remote console and those that do not. Unless otherwise noted, the following functions are calls to the Console Requester. Request-poll Function: Checks to see if certain remote requests have been made. These are requests that directly modify local system processor Interfaces Page 34 execution. Remote requests are not queued: only the most recent is available. Each remote request can be read only once. The higher level process is responsible for polling often enough to ensure a minimum number of lost requests. This is a call to the Console Server. Inputs: Channel-id - the unique identification of the channel on which to check for remote requests. Outputs: Return-code - the status of the request. One of: No requests - no remote requests have been received. Request read - a remote request has been returned. Request truncated - a console command request has been received; however all of the command data was lost. Unrecognized channel - there is no channel with the specified identification. Channel in wrong state - the channel is not in a state where the request can be received. Request-type - the type of request made by the remote system. One of: Boot Console command Boot-server - for a boot request, an indication of the server system to be used to honor the request. One of: Default-server - the system that this system would normally use. Command-source - the system involved in this request. Boot-device - for a boot request, an indication of the device this system is to use to honor the request. One of: Default-device - the device that this system would normally use. Specified-device - the device specified by the command source. Device-id - for specified-device, identification of the device to boot from. Interfaces Page 35 Verification-code - for a boot request, the 4 or 8 byte verification code sent by the requesting system. Source-address - the identification of the system that sent the request. Applicable only on multiaccess channels. Command-data-buffer - for a console command, the buffer containing the command message. Command-break-flag - for a console command, indicates when a break condition is to precede the command message to the console. Identify-self Function: Causes a system identification message to be sent. This is a call to the Console Server. Inputs: Channel-id - the unique identification of the channel on which to send the identity. Destination-address - the identification of the destination system. Applicable only to multiaccess channels. If applicable and not present, the identity message will be sent to the remote console multicast group. Outputs: Return-code - the status of the request. One of: Success - identity sent. Transmit failed - the data link failed to send the message. Unrecognized channel - there is no channel with the specified identification. Channel in wrong state - the channel is not in a state where the request can be received. Boot Function: Force the remote processor to initialize itself. This may cause the system to reload its system image either locally or remotely. Interfaces Page 36 Inputs: Channel-id - the unique identification of the channel on which to send the boot command. Destination-address - the identification of the destination system. Applicable only to multiaccess channels. Verification code - a code to send to the remote system so it will honor the request. The code can be either 4 or 8 bytes long. If it is 4 bytes, no additional parameters can be sent. If additional parameters are to be sent, the code must be 8 bytes long. Boot-server - for a boot request, an indication of the server system to be used to honor the request. One of: Default-server - the system that this system would normally use. Command-source - the system involved in this request. Boot-device - for a boot request, an indication of the device this system is to use to honor the request. One of: Default-device - the device that this system would normally use. Specified-device - the device specified by the command source. Device-id - for specified-device, identification of the device to boot from. Software-id - the software that the remote system is to load. Outputs: Return-code - the status of the request. One of: Success - request sent. Transmit failed - the local transmitter could not transmit the request. Unrecognized channel - there is no channel with the specified identification. Channel in wrong state - the channel is not in a state where the boot can be done. Interfaces Page 37 Read-identity Function: Reads the identity of the specified system. Inputs: Channel-id - the unique identification of the channel on which to read the identity. Destination-address - the identification of the destination system. Applicable only to multiaccess channels. Outputs: Receipt-number - the receipt number used in the Console-abort or Read-identity-poll functions to identify this request. Read-identity-poll Function: Polls for completion of a Read-identity function. Inputs: Receipt-number - the request identification assigned to this request by the Read-identity function. Outputs: Return-code - the status of the request. One of: Not complete - the operation is still in process. Success - identity read. Transmit failed - the local transmitter could not transmit the request. Unrecognized channel - there is no channel with the specified identification. Channel in wrong state - the channel is not in a state where the read can be done. Maintenance-version - the version number of the Low Level Maintenance Operations Architecture that the system is using. Functions - a list of flags indicating whether or not various maintenance functions are currently supported on the system. The possible functions are: Interfaces Page 38 Loop Dump Primary loader (can only load secondary loader) Multi-block loader (can load tertiary loader or system) Boot Console carrier Data link counters Console carrier reservation Console-user - the identification of the system that has the remote console reserved. Not returned if not received. Reservation-timer - the maximum number of seconds that are allowed with no remote console requests before the reservation expires. Not returned if not received. Console-command-size - the maximum allowable size of a console command message. Not returned if not received. Console-response-size - the maximum allowable size of a console response message. Not returned if not received. Hardware-address - the unique hardware address of the remote system. This may or may not be the address in use to identify the system. Not returned if not received. Communication-device - the device type of the communication subsystem over which the remote system received the request. Not returned if not received. Defined types are in Appendix A. Software-id - the type of software running in the remote system. Not returned if not received. Defined types are in Appendix A. System-processor - the processor type of the remote system. Not returned if not received. Defined types are in Appendix A. Data-link-type - the data link mechanism over which the remote system received the request. Not returned if not received. Defined types are in Appendix A. Data-link-buffer-size - the size of the data link buffer, which determines the maximum size MOP message that the station can accept. It includes all except the DDCMP header. The default value is 262 (256 plus the current MOP header size). A server may ignore this field, so that all requesters must support 262 byte messages. Not returned if not received. Other-info - further, implementation-specific information. Zero or more other-info parameters may be included, each consisting of: Parameter-id - identification of the parameter. Identifications are related to the standard parameters (e.g., communication-device, system-processor) on an implementation- specific basis. Interfaces Page 39 Parameter-value - the value of the parameter. Read-counters Function: Reads the data link counters from the specified system. Inputs: Channel-id - the unique identification of the channel on which to read the counters. Destination-address - the identification of the destination system. Applicable only to multiaccess channels. Outputs: Receipt-number - the receipt number used in the Console-abort or Read-counters-poll functions to identify this request. Read-counters-poll Function: Polls for completion of a Read-counters function. Inputs: Receipt-number - the request identification assigned to this request by the Read-counters function. Outputs: Return-code - the status of the request. One of: Not complete - the operation is still in process. Success - counters read. Transmit failed - the local transmitter could not transmit the request. Unrecognized channel - there is no channel with the specified identification. Channel in wrong state - the channel is not in a state where the read can be done. Interfaces Page 40 Counters - a block of counter information as defined for the particular data link (see Appendix B). Reserve-remote-console Function: Reserves the remote system console for use by this system. This must be done before the console carrier can be used. The remote console stays reserved as long as this system makes any console request before the remote system's reservation timer expires. If the remote console reservation timer expires, this system's console reservation is lost without notification. Reservation of a remote console allocates and initializes a collection of local resources, known as a port. Those console functions that require a reservation are requested via the port identification. Initialization of the port allows the command node to synchronize the command and response data streams with the target node's Console Server. In cases where a remote system console can be accessed over more than one communication channel, it is the responsibility of that system and the user of the remote console to ensure that there are no conflicts of control. Inputs: Channel-id - the unique identification of the channel on which to reserve the remote system console. Destination-address - the identification of the destination system. Applicable only to multiaccess channels. Verification code - a code to send to the remote system so it will honor the request. Outputs: Return-code - the status of the request. One of: Success - request sent. No resources - this system has insufficient resources to assign a port for remote console requests. Transmit failed - the local transmitter could not transmit the request. Unrecognized channel - there is no channel with the specified identification. Interfaces Page 41 Channel in wrong state - the channel is not in a state where the reservation can be made. Port-id - a port identification to be used in the other Remote Console Interface functions that require a reservation. Release-remote-console Function: Releases this system's access to the remote system console. This provides an optimization over allowing the remote system's reservation timer to expire and deallocates the local port resources. Note that even though a message cannot be sent to the remote system, the local resources will still be released. In other words, from the standpoint of the local system, this function does not fail. Inputs: Port-id - a port identification assigned by the Reserve-remote-console function. Outputs: Return-code - the status of the request. One of: Success - request sent. Transmit failed - the local transmitter could not transmit the request. Unrecognized port - there is no open port with the specified identification. Channel in wrong state - the channel is not in a state where a transmit can be done. Send-console-command Function: Sends console command data and polls the Console Server of the target system. This function is used with no command data to achieve a poll of the target system without sending a command. Inputs: Interfaces Page 42 Port-id - a port identification assigned by the Reserve-remote- console function. Command-break-flag - a logical value, where true indicates that the data in the command-data-buffer is to be preceeded by a break condition in the serial byte stream. This is for target system console implementations with an RS232-C type interface. Command-data-buffer - a buffer containing command data to be sent to the remote system. This must not be larger than the maximum size command the remote system can receive, as indicated through the Read-identity function. Response-data-buffer - a buffer to receive data from the remote system. This must be at least as large as the maximum size response the remote system can send, as indicated through the Read-identity-poll function. Outputs: Return-code - the status of the request. One of: Success - console command accepted for transmission. Unrecognized port - there is no open port with the specified identification. Function denied - a previous Send-console-command function was still pending. Invalid buffer size - the command buffer is larger than the target Server allows, or the response buffer is smaller than the target Server allows. Receipt-number - the request identification used in the Console- abort or Console-response-poll functions to identify this request. Console-response-poll Function: Polls for completion of the Send-console-command function. Inputs: Receipt-number - the request identification assigned to the Send- console-command function. Outputs: Return-code - the status of the request. One of: Interfaces Page 43 Pending - the exchange is not yet complete. Success - console data sent and acknowledged. Data lost - success, but data was lost during the exchange. Transmit failed - the local transmitter could not transmit the request. command-data-buffer - the buffer which contained the command sent to the remote system. Invalid if pending status is returned. Response-data-buffer - the buffer with the received response data from the remote system. Invalid if pending status is returned. Data-lost-flags - indicators as to the type and reason for the Data lost return-code. Present only if Data lost code returned. Any of: Command-data-lost - a logical value that is true if the command data in the Console Command And Poll message was lost. Response-data-lost - a logical value that is true if the remote console server detected lost console data due to a buffer overrun or other error condition. The data in the response-data-buffer is possibly incomplete. Receive-data-lost - a logical value that is true if the receive-data-buffer was too small to receive all of the data that was sent. Send-console-response Function: Causes a console response to be sent to the Console Requester of the remote command system. This is a call to the Console Server of the target system. It is used to respond to remote console requests from the console user. Inputs: Channel-id - the unique identification of the channel on which the response is to be made. Destination-address - the identification of the command system. Applicable only to multiaccess channels. If applicable and not present, the console-user address is implied. Command-data-lost-flag - a logical value that is true if the command data in the received console command was lost. Interfaces Page 44 Response-data-lost-flag - a logical value that is true if there was a loss of data in the console response. This is provided for implementations where the user of the Console Server cannot block the source of the console output data stream. Response-data-buffer - a buffer containing data to be sent to the remote system. This must not be larger than the maximum response buffer size in the local system id. Outputs: Return-code - the status of the request. One of: Success - console response data sent. Invalid buffer size - the buffer is larger than the server allows. Function denied - a previous send-console-response request is still active. Unrecognized channel - there is no channel with the specified identification. Channel in wrong state - the channel is not in the reserved state or the console carrier protocol has not been enabled. Invalid destination-address - the supplied destination-address does not match the console-user address in the local system ID. Transmit failed - the local transmitter could not transmit the request. Console-abort Function: Aborts a pending console request. Console-abort only affects an individual request and does not cause any change in console state. Inputs: Receipt-number - the number assigned to the request. The following requests can be aborted: . Read-identity . Read-counters . Send-console-command Interfaces Page 45 Outputs: None. Network Management Interface This section defines the control and observation functions for the maintenance operations. The Network Management Interface functions are: . Set-state -- enable or disable local maintenance function. . Read-state -- read states of switchable functions. . Add-dump/load-entry -- add a new entry to the Dump/Load Data Base. . Remove-dump/load-entry -- Remove an entry from the Dump/Load Data Base. . Set-dump/load-parameter -- set a dump/load parameter. . Read-dump/load-list -- read the list of dump/load entries. . Read-dump/load-parameter -- read dump/load parameters. . Set-console-parameter -- set a local console parameter. . Read-console-parameter -- read a local console parameter. Set-state Function: Enables or disables various local maintenance operation functions or components. Inputs: Channel-id - the unique identification of the channel for which the function state is to be switched. Function - the function whose state is to be switched. One of: Console Server - controls whether the Console Server will respond to any incoming requests. Dump/Load Server - controls whether the Dump/Load Server will respond to any incoming requests. Interfaces Page 46 Dump/Load assistance - controls whether the Dump/Load Server will respond to dump or load requests to the dump/load assistance multicast group. Loop Server - controls whether the Loop Server will respond to any incoming requests. Loop assistance - controls whether the Loop Server will respond to loop requests to the loopback assistance multicast group. Remote console reservation - controls whether any remote system is allowed to reserve the local console. State - the state that the function is to be switched to. One of: On - the function is allowed to operate. Off - the function is not allowed to operate. Outputs: Return-code - the status of the request. One of: Success - state switched. Unrecognized channel - there is no channel with the specified identification. Channel in wrong state - the channel is not in a state where a switch can be done. Read-state Function: Reads the states of the switchable local maintenance functions. All of the states are either on or off as described for the Set-state function. Inputs: Channel-id - the unique identification of the channel to read the states for. Outputs: Return-code - the status of the request. One of: Success - states read. Interfaces Page 47 Unrecognized channel - there is no channel with the specified identification. Channel in wrong state - the channel is not in a state where the read can be done. Console-state - the state of the Console Server. Dump/load-state - the state of the Dump/Load Server. Loop-state - the state of the Loop Server. Loop-assistance-state - the state of loop assistance. Remote-console-reservation-state - the state of remote console reservations. Add-dump/load-entry Function: Adds an entry to the Dump/Load Data Base. Inputs: Channel-id - the unique identification of the channel that identifies the data base entry. Destination-address - the identification of the target system that identifies the data base entry. NOTE Either the channel-id or the destination-address must be included in order to identify the target system. If both are included, the destination- address is used as the data base search key to find the entry in the Dump/Load Data Base. Outputs: Return-code - the status of the request. One of: Success - entry added. Already defined - the Dump/Load Data Base already contains an entry for the specified target. Interfaces Page 48 Remove-dump/load-entry Function: Removes an entry from the Dump/Load Data Base. Inputs: Channel-id - the unique identification of the channel that identifies the data base entry. Destination-address - the identification of the target system that identifies the data base entry. NOTE Either the channel-id or the destination-address must be included in order to identify the target system. If both are included, the destination- address is used as the data base search key to find the entry in the Dump/Load Data Base. Outputs: Return-code - the status of the request. One of: Success - entry removed. Unrecognized target - the Dump/Load Data Base does not contain an entry for the specified target. Set-dump/load-parameter Function: Stores parameter values into the Dump/Load Data Base. Inputs: Channel-id - the unique identification of the channel that identifies the data base entry. Destination-address - the identification of the target system that identifies the data base entry. NOTE Either the channel-id or the destination-address must be included in order to identify the target system. If both are included, the destination- address is used as the data base search key to find other values in the Dump/Load Data Base. Interfaces Page 49 Parameter-type - the particular parameter to set. One of: Load-file Secondary-loader Tertiary-loader Dump-file Secondary-dumper Dump-address Dump-count Parameter-value - the new value of the parameter specified by parameter-type. Outputs: Return-code - the status of the request. One of: Success - parameter set. Unrecognized target - the Dump/Load Data Base does not contain an entry for the specified target. Read-dump/load-list Function: Reads the list of Dump/Load Data Base entries. Inputs: Buffer - descriptor of a buffer to contain the list. Outputs: Return-code - the status of the request. One of: Success - parameters read. Buffer too small - the buffer could not hold all the entries. Those that would not fit are not returned. Buffer - descriptor of buffer containing the list. Each entry consists of destination-address or channel-id if the destination address is not set. Read-dump/load-parameters Function: Reads the Dump/Load Data Base entry for a channel. Interfaces Page 50 Inputs: Channel-id - the unique identification of the channel that identifies the data base entry. Destination-address - the identification of the target system that identifies the data base entry. NOTE Either the channel-id or the destination-address must be included in order to identify the target system. If both are included, the destination- address is used as the data base search key to find other values in the Dump/Load Data Base. Outputs: Return-code - the status of the request. One of: Success - parameters read. Unrecognized target - the Dump/Load Data Base does not contain an entry for the specified target. Parameter-entries - the parameters that are set. Each parameter entry consists of a parameter-type and a parameter-value as described for the Set-dump/load-parameter function. Set-console-parameter Function: Stores parameter values to be used by the remote console server. The User Layer is the source of the values. It may obtain them, for example, through physical switch settings or terminal interaction with a person. Inputs: Channel-id - the unique identification of the channel for which the values are to be changed. Parameter-type - the particular parameter to set. The parameters are described for the Read-identity-poll function. They are: Maintenance-version Functions Reservation-timer Console-command-size Console-response-size Hardware-address Communication-device Interfaces Page 51 Software-id System-processor Data-link-type Other-info (in the form of an other-info parameter-type) Parameter-value - the new value of the parameter specified by parameter-type. Outputs: Return-code - the status of the request. One of: Success - parameter set. Unrecognized channel - there is no channel with the specified identification. Channel in wrong state - the channel is not in a state where the parameter can be stored. Read-console-parameters Function: Reads the console parameters for a channel. Inputs: Channel-id - the unique identification of the channel for which the parameters are to be read. Outputs: Return-code - the status of the request. One of: Success - parameters read. Unrecognized channel - there is no channel with the specified identification. Parameter-entries - the console parameters that are set. Each parameter entry consists of a parameter-type and a parameter-value as described for the Set-console-parameter function. Interface Usage Examples This section contains examples of how the maintenance functions might be used. The examples are not exhaustive and do not restrict the way the functions might be used. Interfaces Page 52 For examples of multicast Loop Test, see Appendix E or the Ethernet Specification, Version 2.0. A System Boot Monitor In this example, a system can be booted by remote command, can decide locally to reboot itself, or can decide it is thoroughly broken and needs expert help. The process responsible for all this is in the User Layer and uses the low level maintenance interface functions. The monitor process is implemented so that it is a highly reliable process. Even if nothing else in the system works, this process has a high probability of running. The monitor process watches for remote boot commands through the Request-poll function. If a boot request is received, it checks the verification code, and if the code is acceptable, the monitor process halts all other processing in the system and calls the Load-self function, requesting normal operating software. The monitor then goes into load polling as described below. On a locally determined timer, the monitor process checks over system operation. If it finds that operation is not proceeding properly, it halts all other processing and calls the Load-self function, requesting diagnostics rather than normal operating software. The monitor then goes into load polling. When the monitor has a Load-self outstanding, it does two things. It continues to watch for remote boot commands through Request-poll. It polls for completion of the Load-self with Load-self-poll. If the load fails or takes too long ("too long" is locally defined), the monitor enables reservation of its console with the Set-state function and periodically does an Identify-self on a timer preset according to system needs and communication speed. If the channel being used is a multiaccess channel, the Identify-self goes to the remote console multicast group. A remote monitor can then assist the system as necessary. A Minimal ASCII Console Carrier A very simple console carrier mechanism can be implemented to process only one transmit and one receive character at a time. This is suitable for systems that have already implemented an ASCII console. This requires a minimum of resources, yet provides a highly reliable connection. Data will be lost only if the connected processes try to "pump" data at a rate greater than the connection can accommodate, at which point overrun errors will occur. The local (command) system initiates a console connection by calling the Reserve-remote-console function, identifying the remote (target) system. It then issues a Read-identity call to the target and waits Interfaces Page 53 for a response from the target by using the Read-identity-poll function. If the target has not reserved the console or a timer expires, the process is repeated. The target system's console server must be able to process the console reservation from the host system and will open its console to the host system if all the necessary conditions are met. Once the console is reserved, the user process in the target system, i.e., that system's console processor, must be periodically polling the Console Server for console commands using the Request-poll function. When both systems are ready to communicate, the command system has the responsibility both to transmit commands and poll for responses from the target system. The target system has to respond to console command and poll messages and maintain the console reservation timer. When the command system has data to send, it calls the Send-console- command function, then waits for the response by periodically calling the Console-response-poll function. If a failure is observed, the command system makes any necessary corrections and reissues the Send- console-command. This process is repeated until all pending command data has been sent and acknowledged. If data was returned with the final acknowledgment, it is processed and another Send-console-command call is made to "flush" the remote console response buffer. Even when there is no data to send or being returned, the command system still must periodically call the Send-console-command function to keep the reservation alive and to receive possible unsolicited "response" data from the remote console. If the command system does not receive a response to a Send-console-command within a specified "no response time," then it calls the Console-abort function and issues a Request- identity to try to ascertain the state of the target system and the reason for its failure to respond. At the other end, the target system's user process must periodically call the Request-poll function. When the user process receives a console command it must process it and acknowledge it by calling the Send-console-response function. At either end, data overrun is blocked by the Console Responder or Server returning an error status code to the user if the previous message has not been acknowledged. Unblocking of a data stream that may have experienced some kind of prolonged discontinuity is achieved by the command system detecting the error condition, releasing and then re-reserving the target console. This will force the target system to reinitialize its Console Server and, hopefully, unblock the data stream. Operation Page 54 OPERATION This section describes the operation that supports the various interfaces. The operation is described in terms of the model section and uses an Algol-like colloquial, high-level language for specification of algorithms. For this version of the specification, operation is not presented in the form of a complete implementation model. Instead, to allow quicker review, and since the protocols are quite simple, descriptions are in English or simplified algorithmic form. The descriptions assume, for example, that transmits and receives will be properly demultiplexed between the Data Link Layer and the simplified processes presented here. They also assume that Data Link Open and Close functions are performed outside themselves. Operation and message formats are, as much as possible, drawn from the existing Maintenance Operation Protocol (MOP) Version 2.1. This means that some algorithms, such as down-line load, are directly drawn from existing products with proven field records. Common Algorithms In all maintenance protocols, an invalid message is treated as if it never arrived or had data errors. Many of the maintenance algorithms require timeout and retransmission of a message when a response is not received. There are two variations of this algorithm. The first is persistent. It will not terminate unless stopped by a hard error or high level intervention. The second terminates when a fixed retry count is exhausted. In the higher level algorithms they are referred to as Must-transact, message for the persistent variety, and Transact, message for the fixed retry variety. Message is the message that is to be sent. A receive buffer, and other outputs of the call, are assumed to avoid obscuring the important algorithms. These algorithms also assume synchronous transmit and receive functions, with a receive timeout calculated according to channel speed and size of receive buffer plus 1 second for remote response time. These algorithms result in either a transmit or receive error or a message received in response to the message transmitted. The algorithms assume that the data link has a service-timer and a suggested maximum-retries for maintenance operation. Control of these parameters is outside the scope of this specification. Operation Page 55 The Must-transact algorithm is: Set no intervention, no error, and no message received. WHILE no intervention AND no error AND no message received. Transmit message. IF successful transmit: Receive message. CASE return-status Receive successful: Set message received. Receive aborted: Set intervention. ENDCASE ELSE IF fatal transmit error: Set error. ENDIF ENDIF ENDWHILE The Transact algorithm is: Set retry counter to 0, no error, and no message received. WHILE no error and no message received. Transmit message. IF successful transmit: Receive message. IF successful receive: Set message received. ELSE IF receive timed out: IF retry counter <= maximum-retries: Increment retry counter. ELSE Set channel communication error. ENDIF ELSE Set error from Receive. ENDIF ENDIF ELSE Set error from Transmit. ENDIF ENDWHILE Dump/Load This section describes the operation of the Dump/Load Server and Requester. In this section the term "target system" describes the system being dumped or loaded (i.e. the one running the Dump/Load Requester). The term "assisting system" describes the system that is providing file services (i.e. the one running the Dump/Load Server). Operation Page 56 NOTE See Appendix C for implementation specific Dump/Load information. Dump/Load Server The Dump/Load Server is by far more complex than the Dump/Load Requester. This is because the Dump/Load Requester is designed to run in systems with minimal resources available. Functions are therefore shifted as much as is practical or possible into the Server. The description of Dump/Load Server operation is divided into two major sections, dump and load. Both sections use the Remote Console to force dump or load cooperation from the target system. This usage is presented in a simplified form that assumes an algorithm similar to that described for the Transact function, where: . Transmit message becomes a request for the required console operation (Boot or Dump). . Receive message becomes a check for the required response (a request program for Boot; a request dump service for Dump). Assistance Volunteer This function is only applicable on multiaccess channels. It requires the following messages: . Request dump service. Sent by a target system to request assistance as a result of a Dump-self function. May contain considerable information as to system configuration as described in the Dump-self function. . Request program. Sent by a target system to request assistance as a result of Load-self function. May contain considerable information as to system configuration as described in the Load-self function. . Assistance volunteer. Sent by a potential assisting system in response to a request dump service or request program message. This function is performed in Dump/Load Servers on systems that are part of a dump/load assistance multicast group. It is performed when a request program or request dump service message is received not the request is for a secondary loader. In that case, a server that Operation Page 57 can do so simply responds with the secondary program rather than volunteering assistance, and maintains no further state relative to the request. The Server determines its ability to assist by checking for the presence of the necessary information, either in the request or in its own Dump/Load Data Base. If it can assist, and the request was not for a secondary loader, it replies with a single transmission of an assistance volunteer message. It maintains no state to recall that any of this has been done, as it may not be selected by the target to be the assistant. Dump Operation Dump operation requires the following messages: . Request dump service. Sent by a target system as a result of a Dump-self function. Says that the system requires assistance in dumping itself. May contain considerable information as to system configuration as described in the Dump-self function. . Request memory dump. Sent by an assisting system to obtain a segment of memory. . Memory dump data. Contains a segment of memory sent by a target system in response to a request memory dump message. . Dump complete. Sent by the assisting system to indicate that the dump is done. The dump algorithm is: Perform dump. IF failure on first message: Use Remote Console to force dump. IF successful: Perform dump. ELSE Set error. ENDIF ENDIF Operation Page 58 The algorithm for a dump server is: Open output file. WHILE no error and more to dump Transact, request memory dump. IF no error: IF message received is memory dump data: Write segment to file. Update memory address to dump from. ELSE Set channel protocol error. ENDIF ENDIF ENDWHILE IF no error: Complete file as necessary. ENDIF Transmit, dump complete. Close output file. Load Operation Load operation requires the following messages: . Request program. Sent by a target system as a result of a Load-self function. Says that the system requires assistance in loading itself. May contain considerable information as to system configuration as described in the Load-self function. Also indicates whether the request is for an intermediate loader or for the final program (the "operating system"). . Memory load with transfer address. Sent by an assisting system to load a secondary loader program. Sent in response to a program request message for a secondary loader or as the last load of a tertiary loader. . Request memory load. Sent by a target system in response to a memory load message. Indicates whether or not the memory was successfully loaded and requests another segment. . Memory load. Contains a segment of memory to load. Sent by an assisting system in response to a program request message for a tertiary loader or operating system, or a request memory load message. Operation Page 59 . Parameter load with transfer address. Contains various system parameters and a final transfer memory address. Sent by an assisting system at the end of a multi- segment load. NOTE See Appendix C for special conventions related to existing PDP-11 down-line load programs. The load algorithm is: Perform load with initial program type determined from higher level request or default data base. IF failure on first message: Use Remote Console to boot target system. IF success: Perform load with initial program type from program request. ELSE Set error. ENDIF ENDIF The algorithm to perform a load is: Set no error and operating system not loaded. Set program to load from input of initial program identification. WHILE no error and not done: Open program image file and determine starting address, number of bytes, and transfer address. IF program type = secondary loader: Read entire program from file. Send memory load with transfer address. Set done. ELSE Perform multi-segment program load. Set retry counter to 0. WHILE no error and received message is request memory load and requested segment number in message = load number: IF program type = tertiary loader: Send memory load (empty) with transfer address. ELSE (must be operating system) Send parameter load with transfer address. ENDIF IF no error and received message is request memory load and requested segment number in message = load number and retry counter < maximum-retries: Increment retry counter. ELSE Set channel communication error. ENDIF ENDWHILE ENDIF IF no error: Operation Page 60 IF program type = operating system: IF message received is request memory load and requested segment number in message = load number + 1: Set operating system loaded. ELSE Set channel protocol error. ENDIF ENDIF ENDIF ENDWHILE The algorithm for a multi-segment program load is: Set load segment number to 0. Set requested segment number to 0. WHILE no error and more to load: Read a segment of memory from file. Set retry count to 0. WHILE no error and requested segment = load segment: Transact, memory load message. IF no error: IF request memory load received: Set requested segment number from message. IF requested segment number = load segment number: IF retry count < maximum-retries: Increment retry count. ELSE Set channel communication error. ENDIF ELSE IF requested segment number <> load segment number + 1: Set channel protocol error. ENDIF ENDIF ELSE Set channel protocol error. ENDIF ENDIF ENDWHILE Increment load segment number. ENDWHILE Dump/Load Requester The Dump/Load Requester is as simple as possible in its operation to avoid burdening a small system that needs to dump or load itself with minimal resources available. The operation is described in stages to indicate how a system with minimal resources could approach the functions. A system with the resources to begin at one of the later stages can and should do so, only implementing needed capabilities (such as initial request) from Operation Page 61 earlier stages. Both dump and load operate similarly from the higher level's perspective. They are invoked with a Dump-self or Load-self function and checked for completion with the matching poll function. The poll function returns a state that depends on the progress being made so that the high level can decide to abort and restart or whatever else it deems appropriate. Both dump and load have a special function available on multiaccess channels. This function allows them to select an assistant from the dump/load assistance multicast group. The initial request message is first sent to the multicast address. The first Assistance Volunteer message responder is selected as the assistant and the operation proceeds from there the same as for a point-to-point channel. The initial request is sent via the Must-transact function. During this stage of the operation, the poll function returns a "requesting" state. Dump Operation The first stage is to get the dump started with a Must-transact of a request dump service message. This succeeds when a request memory message is received. During this stage, the poll function returns a "requesting" state. On success, proceed to the next stage. The second stage is the actual dump. During this stage, the poll function returns an "in-process" state. A dump data message is sent in response to each request memory message. A failure on a transmit or a receive terminates the operation with a failure or receipt of any other message. A timeout on a receive or the receipt of a dump complete message terminates the operation with success. Load Operation The first stage is to load a secondary loader program with a Transact of a request program. This succeeds when a memory load with transfer address is received and started. The message must contain an entire secondary loader. Note that a primary loader accepts only a secondary loader; it does not use the assistance volunteer function. The second stage is to load a tertiary loader program. The first segment is obtained with a Must-transact of a request program message. Subsequent segments are obtained with a simple transmit of a request memory load message. The request memory message is used to acknowledge the successful or failing storage of the previous memory segment and either requests the same one again or the next one. The load is completed by receipt of a memory load with transfer address. The program loaded must be a tertiary loader. Operation Page 62 The third stage is to load the "operating system". This could actually be any type of program. The load procedure is the same as for the tertiary loader, except that the final message is a transfer address and parameters. The transfer address and parameters are passed up to the higher level with the notification of successful completion. Also, the final message is acknowledged with a request memory for the next segment, which the assistant understands as an acknowledgement rather than a request. During the second and third stages, the Dump/Load Requester keeps a timer while waiting for a message from the assistant. If this timer runs out, the Dump/Load Requester declares the load as failed with a "failed" error return. This timer is set according to the service- timer for the particular data link. Also during the second and third stages, the loaders must not accept a Memory Load with Transfer Address message with any memory image in it. This is to avoid confusion with additional secondary loaders received in response to the primary loader. Loop Test This section describes the operation of the Loop Test Server and Requester for point-to-point channels. The operation for multicast channels is the Ethernet standard, found in Appendix E or Version 2.0 of the Ethernet Specification. The operational descriptions assume the following Loop Test protocol messages. . Looped Data - a message identifiable as a response to some request. . Loop Data - a message that is to be looped to its sender. Loop Server The Loop Server always keeps a receive pending for each channel that is turned on. Whenever a receive completes, it is processed and another receive posted. For purposes of not missing messages, it may be necessary to keep more than one receive posted. The received message is processed according to function code: . Loop Data message: The function code is changed to Looped Data and the message is transmitted back to the source system. . Unrecognized function code: The message is ignored. Operation Page 63 Note that in the case of an unintelligent loopback mechanism, such as a simple turn-around connector, the function code will not change. Loop Requester A receipt number is chosen and the state of the operation is set to "not complete". The input data provided is transmitted to the destination system as a Loop Data message. If the transmit is not accepted, the error code is returned and the receipt number marked complete. If the transmit succeeded, a receive is posted. Note that it may be necessary to post the receive first to avoid a race between the posting of the receive and the receipt of the message. When the transmit and receive are both complete, if they were successful the received data is compared to the transmitted data. If they do not match or the receive or transmit failed, the appropriate error is recorded. Otherwise, success and the responding system address are recorded. The Loop-poll function returns the state of the operation. Remote Console This section describes the operation of the Remote Console Server and Requester. For this section, the term "target system" means the system whose remote console is being used (i.e. the one running the Console Server). The term "command system" means the system sending the commands (i.e. the one running the Console Requester). The console carrier protocol is a half-duplex polled protocol. That is, the Console Requester must poll the remote Console Server for information. Console Server The Console Server operates within the following state diagram: Operation Page 64 .-------. | Off |<------------. `-------' | | A | V | | .----------. | | Disabled |<------. | `----------' | | | A | | V | | | .---------. .----------. | |<====| | | | | | | Enabled |====>| Reserved | | | | | | |<++++| | `---------' `----------' In the off state the Console Server will not operate. In the disabled state, the Console Server will send a System ID message in response to a local Identify-self or a remote Read-identity or a Counters message in response to a Read-counters. In the disabled state, the console will accept a Boot message and make the information available to the user through Request-poll. In the enabled state, the Console Server will additionally respond to reservation requests. In the reserved state, the Console Server will respond to console carrier request from the system that reserved it and to other requests from any system. The single line arrows represent action taken because of local Network Management Interface functions. The double line arrows represent action taken because of received messages. The crossed arrow represents action taken because of operation within the Console Server itself. Network Management forces the Console Server in and out of off state or disabled state with the Set-state function. The Console Server moves itself from reserved state to enabled state on the expiration of the reservation timer, whose value is set via Network Management. The Console Server responds to a local Identify-self with a single attempt to send a System ID message. Each of the Console Requester functions maps one-to-one to a simple server action, each function using its corresponding Remote Console Protocol message. The Console Server actions are: . In response to a Request ID message, send a System ID message. . In response to a Request Counters message, send a Counters message. Operation Page 65 . In response to a Boot message, make the request and boot information visible to the local higher level through the Request-poll function. . In response to a Reserve Console message while in the enabled state, initialize the console carrier buffers and enter the reserved state. For multiaccess channels, the identification of the console-user system is saved. . In response to a Release Console message from the console-user, release the console (enter enabled state). For multiaccess channels, the console-user identification parameter is cleared. . In response to a Console Command and Poll message from the console-user, make the command data (if any) visible to the local higher level through the Request-poll function. The higher level user has the responsibility of sending a Console Response and Acknowledge message, including any console output data that is pending. In addition to these protocol-driven actions, the Console Server also times the reservation while in the reserved state. It resets the reservation timer each time a Console Command And Poll message is received from the reserving system. If the reservation timer expires, it clears the reservation. The Console Server algorithm for processing remote console messages follows: CASE Request ID: transmit System ID message. Request Counters: IF function [counters] = on THEN transmit Counters message. ENDIF. Boot: IF function [boot] = on THEN request-type := boot. ENDIF. Reserve Console: IF console state = enabled THEN console reservation := . console state := reserved. message number := 0. CLEAR command buffer. CLEAR response buffer. ENDIF. Operation Page 66 Release Console: IF console user = THEN console user := 0. console state := enabled. IF request-type = console command THEN CLEAR request-type. ENDIF. ENDIF. Console Command And Poll: IF console user = THEN Reset reservation timer. IF message number = THEN IF request-type is clear THEN transmit Console Response and Acknowledge message. ENDIF ELSE command buffer := . COMPLEMENT message number. request-type := console command. ENDIF. ENDIF. ENDCASE. The Console Server user process obtains commands and sends responses via the following algorithm: CALL Request-poll (Channel-id) IF return-code = Request read THEN CASE Request-type Boot: Initiate system boot process. Console command: Read the command buffer. CALL send-console-response (Channel-id, Console-user, Response-data). ENDCASE. CLEAR Request-type. ENDIF Console Requester Console Requester operation is very simple. Requests from the high level user map directly to corresponding Remote Console Protocol messages. With the exception of the Read-identity, Read-counters and Send-console-command functions, none of these messages have responses; therefore, the Requester returns completion when a simple transmit is done. Operation Page 67 In the cases of the Read-identity, Read-counters, and Send-console- command functions, the Requester sends the appropriate message as a Must-transact. The higher level must abort the request if it determines that it has taken too long. Receipt number is initialized to a random, non-zero value at system startup and incremented by one each time one is used. It is used to identify the request between the Console Requester and user. The Console Requester is the "master" of the console carrier mechanism. It initiates a console carrier connection by opening a port to the target system. The Port-id parameter is used to insure that only one Console Requester user can have access to the console carrier connection at one time. It establishes the connection by transmitting a reserve console message to the target system and verifies the connection by sending a Request ID and checking the returned System ID from the target system. The Console Requester accepts commands from the user and transmits them using the console command and poll message. It waits for acknowledgement of the command by receiving a console response and acknowledge message from the target system before accepting another command from the user. If there is data in the response message, it makes that data available to the user through the Console-response- poll function. The algorithms for the console carrier functions in the Console Requester are: ROUTINE Reserve-remote-console (channel-id, destination-address) : ON not successful, EXIT with appropriate return-code. port-id := Open (channel-id, pad, id-list). receipt-number := Next-receipt-number (channel-id). system-id := Transact, Request ID message. IF system-id is on AND system-id is off THEN command-buffer := Allocate-buffer (command-buffer-size). response-buffer := Allocate-buffer (response-buffer-size). transmit, Reserve Console message. receipt-number := Next-receipt-number (channel-id). system-id := Transact, Request ID message. IF system-id = source-address THEN message number := 0. CLEAR command-pending. return-code := success. ELSE return-code := channel in wrong state. ENDIF. ELSE return-code := channel in wrong state. ENDIF. RETURN Reserve-remote-console. ROUTINE Release-remote-console (port-id) : IF port is open THEN Operation Page 68 SET no error. WHILE system-id = source-address AND no error DO transmit, Release Console message. receipt-number := Next-receipt-number (channel-id). Transact, Request ID message. ENDWHILE. Close (port-id). ELSE return-code := unrecognized port. ENDIF. RETURN Release-remote-console. ROUTINE Send-console-command (port-id, command-break-flag, command-data-buffer, response-data-buffer) : IF port is open THEN IF command-pending THEN return-code := function denied. ELSE receipt-number := Next-receipt-number (channel-id). COMPLEMENT message number. SET command-pending. START Must-transact, Send Console Command And Poll message. ENDIF. ELSE return-code := unrecognized port. ENDIF. RETURN Send-console-command. ROUTINE Console-response-poll (receipt-number) : IF command-pending THEN IF Must-transact operation completed THEN IF message number = THEN Response-data-buffer := . CLEAR command-pending. IF OR OR Receive with overrun THEN SET corresponding Data-lost-flags. return-code := Data lost. ELSE return-code := Success. ENDIF. ELSE START must-transact, Send Console Command And Poll message. ENDIF. ELSE return-code := pending. ENDIF. ELSE return-code := unrecognized request. ENDIF. RETURN Console-response-poll. Protocol Messages Page 69 PROTOCOL MESSAGES This section defines the binary formats of the protocol messages that support the operation described in the operation section. In order to operate correctly on exclusive maintenance channels, message identification codes are taken from a single space. Values 16 and 18 are reserved for compatibility with MOP implementations not described here. Some data links have a minimum message size and many of the maintenance protocol messages are quite small. Padding must be requested from the particular data link on the assumption that such a service is provided if needed. The actual size of received messages is also provided by the Data Link Layer, so that messages with a single variable length data field need not include a size field. The following notation is used to describe the messages: FIELD (LENGTH) : CODING = Description of field Where: FIELD Is the name of the field being described. LENGTH Is the length of the field expressed as one of the following: . The number of 8-bit bytes. . The notation "C-n" meaning counted image field with n being a number that is the maximum length in 8-bit bytes of the image. The actual length of the image is encoded into the first byte of the field. Therefore, the minimum length of the field is one byte. The first byte of the field may contain information in addition to the length count. . The notation "I-n" meaning image field with n being a number that is the maximum length in 8-bit bytes of the image. The image is preceded by sufficient information to compute the length of the field. Image fields are variable length and may be null (length=0). All 8 bits of each byte may be used as information bits. . An asterisk (*), indicating that the field consists of the remainder of the message, i.e., the total message length less the length of all of the other fields. CODING Is the representation type used, as follows: B Binary BM Bit map (each bit has independent meaning) Protocol Messages Page 70 A ASCII Null Interpretation depends on data representation Notes: . All numeric values are shown in decimal unless otherwise noted. . Fields are transmitted in the order shown, left to right. . All fields are transmitted low-order or least significant bit first unless otherwise specified. . Bits in a field are numbered from 0 to n where 0 is the low-order or least-significant bit. Dump/Load The messages specified here are a directly compatible extension of MOP version 2.1. Unless otherwise noted, they are identical. Memory Load with Transfer Address The Memory Load with Transfer Address message consists of: CODE LOAD LOAD IMAGE TRANSFER NUMBER ADDRESS DATA ADDRESS Where: CODE (1) : B = The number 0. LOAD NUMBER (1) : B = The load number for multi-segment loads. This message may be preceded by Memory Load without transfer address messages. The load number starts at zero and is incremented for each load message sent in a loading sequence. A load number of zero is always valid and resets the expected load number. Zero must not be used for all load numbers in a sequence of load messages because that nullifies the sequence checking of the protocol. The load number is modulo 256. After load number 255 is load number 0. LOAD ADDRESS (4) : B = The memory load address (physical) for storage of the data image. Protocol Messages Page 71 IMAGE DATA (*) : = The image to be stored into computer memory. The form sent can be machine-dependent, to be defined on an as needed basis. Unless otherwise defined, each byte represents one memory byte. TRANSFER ADDRESS (4) : B = The starting memory address of the image just loaded. NOTE IMAGE DATA or LOAD ADDRESS and IMAGE DATA may be omitted. Valid message lengths are 6 (LOAD ADDRESS and IMAGE DATA omitted), 10 (IMAGE DATA omitted), or greater then 10. Memory Load The Memory Load message consists of: CODE LOAD LOAD IMAGE NUMBER ADDRESS DATA Where: CODE (1) : B = The number 2. LOAD NUMBER (1) : B = As described for Memory Load with Transfer Address. LOAD ADDRESS (4) : B = As described for Memory Load with Transfer Address. IMAGE DATA (*) : = As described for Memory Load with Transfer Address. NOTE IMAGE DATA may be omitted. Valid message lengths may be 6 (IMAGE DATA omitted), or greater than 6. Messages without IMAGE DATA cause nothing to be loaded; however, the LOAD NUMBER value is still incremented for the next load. Protocol Messages Page 72 Request Memory Dump The Request Memory Dump message consists of: CODE MEMORY COUNT ADDRESS Where: CODE (1) : B = The number 4. MEMORY ADDRESS (4) : B = The starting physical memory address for the dump. COUNT (2) : B = The number of locations to dump. The meaning of the count can be machine-dependent, to be defined on an as needed basis. Unless otherwise defined, the count is in bytes. NOTE This request results in a single Memory Dump Data message. A dump should not be requested for more data than can be reliably sent in a single reply on the channel used. The maximum data link message length limits the maximum length for a given channel. Request Program The Request Program message consists of: CODE DEVICE FORMAT PROGRAM SOFTWARE PROCESSOR OTHER TYPE VERSION TYPE ID INFO Where: CODE (1) : B = The number 8. DEVICE TYPE (1) : B = The device type at the requesting system. Used to cause the proper requested program to be loaded if it is device specific. Defined device types are found in Appendix A. Protocol Messages Page 73 FORMAT VERSION (1) : B = The protocol format version. For all current versions, the number 1. PROGRAM TYPE (1) : B = The generic type of program being requested. This is for control of the loading process itself, rather than for final software selection. The defined values are as follows: Value Meaning 0 Secondary loader 1 Tertiary loader 2 System This field and all the following can be omitted, in which case the default for this field is 0. A system in this context is whatever is to end up in the requesting system, and could be any type of program. SOFTWARE ID (C-17) : = Identification of the software being requested. Omitted if PROGRAM TYPE is omitted. The format is the same as defined for the Boot message. PROCESSOR (1) : B = The processor to be booted. This field did not exist in MOP version 2.1. Value Meaning 0 System processor 1 Communication processor OTHER INFO (*) : = Further information to identify the requesting system. This field did not exist in MOP version 2.1. Definition is as described for the Remote Console System ID message. Request Memory Load The Request Memory Load message consists of: CODE LOAD ERROR NUMBER Protocol Messages Page 74 Where: CODE (1) : B = The number 10. LOAD NUMBER (1) : B = The number of the load segment being requested, as defined for the Memory Load with Transfer Address message. ERROR (1) : B = An error indicator for the previously received segment. The values are: Value Meaning 0 No error 1 IMAGE DATA not properly loaded (for example, because of a memory boundary or parity error problem) Request Dump Service The Request Dump Service message is a redefinition of the MOP version 2.1 MOP Mode Running message. Its new meaning is compatible with all known implementations of the old message. The message consists of: CODE DEVICE FORMAT MEMORY BITS OTHER TYPE VERSION SIZE INFO Where: CODE (1) : B = The number 12. DEVICE TYPE (1) : B = As described for the Request Program message. Not used in actual operation. FORMAT VERSION (1) : B = As described for the Request Program message. MEMORY SIZE (4) : B = The size of physical machine memory. Units are as described for COUNT in the Request Memory Dump message. BITS (1) : B = The number 2. Present for compatibility only. Protocol Messages Page 75 OTHER INFO (*) : = Further information to identify the requesting system. This field did not exist in MOP version 2.1. Definition is as described for the Remote Console System ID message. The only valid INFO TYPE is DATA LINK BUFFER SIZE (401). Memory Dump Data The Memory Dump Data message consists of: CODE MEMORY IMAGE ADDRESS DATA Where: CODE (1) : B = The number 14. MEMORY ADDRESS (4) : B = As described for the Request Memory Dump message. IMAGE DATA (*) : = As described for the Memory Load with Transfer Address message. Parameter Load with Transfer Address The Parameter Load with Transfer Address message consists of: CODE LOAD PARAMETERS TRANSFER NUMBER ADDRESS Where: CODE (1) : B = The number 20. LOAD NUMBER (1) : B = As described for the Memory Load with Transfer Address message. PARAMETERS (*) : = Zero or more parameter entries followed by an END MARK. Protocol Messages Page 76 Where: END MARK (1) : B = The number 0. And a parameter entry consists of: PARAMETER PARAMETER PARAMETER TYPE LENGTH VALUE Where: PARAMETER TYPE (1) : B = A type code for the parameter information. The values are: Value Parameter 1 TARGET SYSTEM NAME 2 TARGET SYSTEM ADDRESS 3 HOST SYSTEM NAME 4 HOST SYSTEM ADDRESS 5 HOST SYSTEM TIME PARAMETER LENGTH (1) : B = The number of bytes in the PARAMETER VALUE field. PARAMETER VALUE (I-16) : = A value according to PARAMETER TYPE and PARAMETER LENGTH. Where: TARGET SYSTEM NAME (I-16) : A = ASCII system name target system is to use for itself. TARGET SYSTEM ADDRESS (I-6) : B = Binary system address target system is to use for itself. HOST SYSTEM NAME (I-16) : A = ASCII system name of host assigned to system (for example, host for task loading of core only systems). HOST SYSTEM ADDRESS (I-6) : B = Binary system address of host. Protocol Messages Page 77 NOTE The maximum lengths of the above parameters are longer than for MOP version 2.1. Old system versions may not be able to support more than 6 bytes for a system name or 2 bytes for a system address. The following parameter did not exist in MOP version 2.1. HOST SYSTEM TIME (10) : B = Segmented binary system time of host, consisting of: CENTURY YEAR MONTH DAY HOUR MINUTE SECOND 100TH TDFH TDFM where: CENTURY (1) : B = the century base for reckoning the absolute year. Value is a positive integer (0 through +127). YEAR (1) : B = the year of the base century. Value is in the range 0 through 100. MONTH (1) : B = the month of the year, starting with January = 1. Value is in the range 1 through 12. DAY (1) : B = the day of the month. Value is in the range 1 through 31. HOUR (1) : B = the hour of the day. Value is in the range 0 through 23. MINUTE (1) : B = the minute of the hour. Value is in the range 0 through 59. SECOND (1) : B = the second of the minute. Value is in the range 0 through 59. 100TH (1) : B = the number of hundredths of a second. Value is in the range 0 through 99. TDFH (1) : B = the hours portion of the Time Differential Factor. Value is in the range -12 through +13. TDFM (1) : B = the minutes portion of the Time Differential Factor. Value is in the range -59 through 59. The sign of this value must be the same as the sign of the TDFH value. TRANSFER ADDRESS (4) : B = As described for the Memory Load with Transfer Address message. Protocol Messages Page 78 Dump Complete The Dump Complete message was not part of MOP 2.1. It consists of: CODE Where: CODE (1) : B = The number 1. Assistance Volunteer The Assistance Volunteer message was not part of MOP version 2.1. It consists of: CODE Where: CODE (1) : B = The number 3. Loop Test The protocol messages for multiaccess channels are the Ethernet standard, and are described in Appendix E. They are also described in the Ethernet Specification, Version 2.0, Section 8 (Ethernet Configuration Testing Protocol). The messages specified here are directly compatible with MOP version 2.1. The only change is the specification of a receipt number field which, from the standpoint of a system looping a message back, is just part of the data. Loop Data Message The Loop Data message consists of: CODE RECEIPT DATA Where: CODE (1) : B = The number 24. Protocol Messages Page 79 RECEIPT (2) : B = The receipt number for the loop request. DATA (*) : B = The data to be looped back. Looped Data Message The Looped Data message consists of: CODE RECEIPT DATA Where: CODE (1) : B = The number 26. RECEIPT (2) : B = The receipt number from the Loop Data message. DATA (*) : B = The data from the Loop Data message. Remote Console Unless otherwise stated, the Remote Console messages are additions to MOP version 2.1. Boot When used with a 4 byte verification code, the Boot message is the same as the MOP version 2.1 Enter MOP Mode message and is compatible with all known implementations. When used with an 8 byte code, it is not compatible. It consists of: CODE VERIFICATION PROCESSOR CONTROL DEVICE SOFTWARE ID ID Where: CODE (1) : B = The number 6. Protocol Messages Page 80 VERIFICATION (4/8) : B = A verification code that must match before the receiving system can honor the request. If 4 bytes long, no other fields can be included. If 8 bytes long, the remaining fields are included. PROCESSOR (1) : B = As described for the Request Program message. CONTROL (1) : BM = Instructions to the system as to what device to use for the operation. Values are: Bit Meaning Value Meaning 0 Boot-server 0 System default 1 Requesting system 1 Boot-device 0 System default 1 Specified device DEVICE ID (C-17) : = The device to use. Present only for CONTROL = Specified device. Interpretation is specific to the receiving system. SOFTWARE ID (C-17) : = The software the system is to load. Software identification consists of: FORM ID Where: FORM (1) : B = The general type of software. Values are: Value Meaning 0 No software id >0 The length of the ID field -1 Standard operating system -2 Maintenance system ID (I-16) : A = A specific software ID. Present only if FORM > 0. Interpretation is specific to the receiving system. Protocol Messages Page 81 Request ID The Request ID message consists of: CODE RESERVED RECEIPT NUMBER Where: CODE (1) : B = The number 5. RESERVED (1) : = A one byte field reserved to DEC for future use. Value is 0. RECEIPT NUMBER (2) : B = A receipt number to identify the request. System ID The System ID message consists of: CODE RESERVED RECEIPT OTHER NUMBER INFO Where: CODE (1) : B = The number 7. RESERVED (1) : = A one byte field reserved to DEC for future use. Value is 0. RECEIPT NUMBER (2) : B = A receipt number to identify the request. OTHER INFO (*) : = Further information to describe the system. Consists of zero or more entries in any order. Each entry consists of: INFO INFO INFO TYPE LENGTH VALUE Where: Protocol Messages Page 82 INFO TYPE (2) : B = Is the type of information. The values are: Value Information 1 MAINTENANCE VERSION * 2 FUNCTIONS * 3 CONSOLE USER ** 4 RESERVATION TIMER ** 5 CONSOLE COMMAND SIZE ** 6 CONSOLE RESPONSE SIZE ** 7 HARDWARE ADDRESS * 8 SYSTEM TIME 100 COMMUNICATION DEVICE * 101-199 COMMUNICATION DEVICE RELATED 200 SOFTWARE ID 201-299 SOFTWARE ID RELATED 300 SYSTEM PROCESSOR 301-399 SYSTEM PROCESSOR RELATED 400 DATA LINK 401 DATA LINK BUFFER SIZE 402-499 DATA LINK RELATED * Required field (System ID message only). ** Required field if console carrier available (FUNCTION bit 5). INFO LENGTH (1) : B = The number of bytes in the INFO VALUE field. INFO VALUE (I-17) : = The value according to INFO TYPE and INFO LENGTH. Where: MAINTENANCE VERSION (3) : B = The maintenance version number. The bytes, in order from low to high, are version, ECO, and user ECO. FUNCTIONS (2) : BM = The maintenance functions currently available through this channel. The bit meanings are: Bit Function 0 Loop 1 Dump 2 Primary loader (can only load secondary loader) 3 Multi-block loader (can load tertiary loader or system) Protocol Messages Page 83 4 Boot 5 Console carrier 6 Data link counters 7 Console carrier reservation CONSOLE USER (6) : B = System address of the system that has the console reserved. Not present if not applicable. Must be present if console carrier is available, i.e., FUNCTION bit 5 is ON. Not valid if the console carrier is not reserved, i.e., FUNCTION bit 7 is ON. RESERVATION TIMER (2) : B = The maximum value, in seconds, of the timer used to clear unused console reservations. Not present if not applicable. Must be present if console carrier is available, i.e., FUNCTION bit 5 is ON. CONSOLE COMMAND SIZE (2) : B = The maximum size of the console command buffer. Not present if not applicable. Must be present if console carrier is available, i.e., FUNCTION bit 5 is ON. CONSOLE RESPONSE SIZE (2) : B = The maximum size of the console response buffer. Not present if not applicable. Must be present if console carrier is available, i.e., FUNCTION bit 5 is ON. HARDWARE ADDRESS (6) : B = A hardware established address for this system, relative to the channel being used. SYSTEM TIME (10) : B = A segmented binary system time stamp. The format is the same as defined for the Parameter Load with Transfer Address message. COMMUNICATION DEVICE (1) : B = The hardware device type of the channel being used. Values are in Appendix A. COMMUNICATION DEVICE RELATED (I-16) : = Information specific to the particular COMMUNICATION DEVICE. Not present if not applicable. Values are in Appendix A. Protocol Messages Page 84 SOFTWARE ID (C-17) : = The identification of the software the system is supposed to be running. The format is the same as defined for the Boot message. SOFTWARE ID RELATED (I-16) : = Information specific to the particular SOFTWARE ID. Not present if not applicable. Interpretation is specific to the receiving system (e.g., file specification, which may vary depending on the type of file server). SYSTEM PROCESSOR (1) : B = The type of system processor. Values are in Appendix A. SYSTEM PROCESSOR RELATED (I-16) : = Information specific to the particular SYSTEM PROCESSOR. Not present if not applicable. Values are in Appendix A. DATA LINK (1) : B = The type of data link protocol on the channel being used. Values are in Appendix A. DATA LINK BUFFER SIZE (2) : B = The size of the data link buffer. Not present if not applicable. The default value is 262. DATA LINK RELATED (I-16) : = Information specific to the particular DATA LINK. Not present if not applicable. Values are in Appendix A. Request Counters The Request Counters message consists of: CODE RECEIPT NUMBER Where: CODE (1) : B = The number 9. RECEIPT NUMBER (2) : B = A receipt number to identify the request. Protocol Messages Page 85 Counters The Counters message consists of: CODE RECEIPT COUNTER NUMBER BLOCK Where: CODE (1) : B = The number 11. RECEIPT NUMBER (2) : B = A receipt number to identify the request. COUNTER BLOCK (*) : = A block of counters as defined for the particular data link (see Appendix B). Reserve Console The Reserve Console message consists of: CODE VERIFICATION Where: CODE (1) : B = The number 13. VERIFICATION (8) : B = A verification code that must match before the receiving system can honor the request. Release Console The Release Console message consists of: CODE Where: CODE (1) : B = The number 15. Protocol Messages Page 86 Console Command and Poll This message is issued by the Console Requester in the command system and is received by the Console Server in the target system. The Console Command and Poll message consists of: CODE CONTROL COMMAND FLAGS DATA Where: CODE (1) : B = The number 17. CONTROL FLAGS (1) : BM = The control flags indicate the state of the console carrier message streams. They insure that messages are not lost. bit function 0 Message Number - indicates the current message number. This is a one bit sequence number of the current Console Requester command message. 1 Command Break Flag - indicates if the (possibly null) command data is to be preceded by a break condition in the serial byte stream. This may take on the value of zero, meaning no break, or one, meaning there is a break. COMMAND DATA (*) : = This is a (possibly null) sequence of bytes to be provided as input to the receiving system's higher level user of the Console Server. Console Response and Acknowledge This message is issued by the Console Server in the target system in response to the receipt of a Console Command and Poll message from the Console Requester in the command system. The Console Response and Acknowledge message consists of: CODE CONTROL RESPONSE FLAGS DATA Where: CODE (1) : B = Protocol Messages Page 87 The number 19. CONTROL FLAGS (1) : BM = The control flags indicate the state of the console carrier message streams. They insure that messages are not lost. bit function 0 Message Number - indicates the current message number. This is a one bit sequence number of the current command message being acknowledged. 1 Command Data Lost Flag - indicates if the console command data was lost and must be sent again. This may take on the value of zero, meaning acceptance of the command data, or one, meaning that the command data was lost. 2 Response Data Lost Flag - indicates if remote console response data was lost due to data overrun. This may take on the value of zero, meaning no detection of lost data, or one, meaning there was lost data. RESPONSE DATA (*) : = This is a (possibly null) sequence of bytes to be provided as input to the receiving system's higher level user of the Console Requester. APPENDIX A PREDEFINED VALUES This appendix contains the predefined values for various maintenance operation parameters. These values are referenced in the interfaces and in the message definitions. Each parameter has a description to be used in the interface calls and an actual value to be used in protocol messages. New values are defined on an as needed basis. Communication Devices Value Name Device 0 DP DP11-DA (OBSOLETE) 1 UNA DEUNA multiaccess communication link 2 DU DU11-DA synchronous line interface 3 CNA 4 DL DL11-C, -E or -WA asynchronous line interface 5 QNA 6 DQ DQ11-DA (OBSOLETE) 7 CI Computer Interconnect interface 8 DA DA11-B or -AL UNIBUS link 9 PCL PCL11-B multiple CPU link 10 DUP DUP11-DA synchronous line interface 12 DMC DMC11-DA/AR, -FA/AR, -MA/AL or -MD/AL interprocessor link 14 DN DN11-BA or -AA automatic calling unit 16 DLV DLV11-E, -F, -J, MXV11-A or - B asynchronous line interface 18 DMP DMP11 multipoint interprocessor link 20 DTE DTE20 PDP-11 to KL10 interface 22 DV DV11-AA/BA synchronous line multiplexer 24 DZ DZ11-A, -B, -C, or -D asynchronous line multiplexer 28 KDP KMC11/DUP11-DA synchronous line multiplexer 30 KDZ KMC11/DZ11-A, -B, -C, or -D asynchronous line multiplexer 32 KL KL8-J (OBSOLETE) 34 DMV DMV11 interprocessor link 36 DPV DPV11 synchronous line interface 38 DMF DMF-32 synchronous line unit 40 DMR DMR11-AA, -AB, -AC, or -AE interprocessor link Predefined Values Page A-2 42 KMY KMS11-PX synchronous line interface with X.25 level 2 microcode 44 KMX KMS11-BD/BE synchronous line interface with X.25 level 2 microcode Data Links The data link type values are: Value Meaning 1 Ethernet 2 DDCMP 3 LAPB (frame level of X.25) System Processors System processor type values are: Value Meaning 1 PDP-11 (UNIBUS) 2 Communication Server 3 Professional APPENDIX B DATA LINK SPECIFIC INFORMATION This appendix contains information necessary to relate specific data link types to the maintenance operations. DDCMP The Digital Data Communication Message Protocol (DDCMP) Data Link is a point-to-point channel and allows exclusive maintenance operation in its maintenance mode. It does not require message padding. LAPB The LAPB Data Link is the frame level of X.25. It is a point-to-point channel and allows exclusive maintenance operation for loopback only. It does not require message padding. Ethernet The Ethernet Data Link is the Digital Equipment Corporation implementation of the inter-company Ethernet Data Link. It allows concurrent maintenance operation and is a multiaccess channel. As such it has specific protocol types and multicast addresses that go with it. It requires message padding. Refer to the the Ethernet Product Architecture Specification and the DNA Ethernet Data Link Architectural Specification for specific functions and requirements. For example, the Product Architecture Specification requires that the Loop Server and the Console Server cannot be off while the data link is on. Data Link Specific Information Page B-2 The protocol types are: Value Protocol 90-00 Loopback 60-01 Dump/Load 60-02 Remote Console The multicast addresses are: Address Group CF-00-00-00-00-00 Loopback assistance AB-00-00-01-00-00 Dump/Load assistance AB-00-00-02-00-00 Remote Console Ethernet counters can be read through the Remote Console. The counters are defined in the DNA Ethernet Data Link specification. The counters are a fixed format block with each value as indicated below. Byte Length Counter Value 2 Seconds since last zeroed 4 Bytes received 4 Bytes sent 4 Frames received 4 Frames sent 4 Multicast bytes received 4 Multicast frames received 4 Frames sent, initially deferred 4 Frames sent, single collision 4 Frames sent, multiple collisions 2 Send failure 2 Send failure reason bitmap 2 Receive failure 2 Receive failure reason bitmap 2 Unrecognized frame destination 2 Data overrun 2 System buffer unavailable 2 User buffer unavailable The bit meanings for the Send failure reason bitmap are: Bit Reason 0 Excessive collisions 1 Carrier check failed 2 Short circuit 3 Open circuit 4 Frame too long 5 Remote failure to defer Data Link Specific Information Page B-3 The bit meanings for the data errors inbound reason bitmap are: Bit Reason 0 Block check error 1 Framing error 2 Frame too long APPENDIX C IMPLEMENTATION SPECIFIC DUMP/LOAD CHARACTERISTICS This appendix documents characteristics of PDP-11 dump/load programs existing as of the date of this specification. Secondary Loader The secondary loader is sent as a single Memory Load with Transfer Address message as normally required. In addition to this requirement, it must be loaded and started at location 6. Current secondary loaders are between 400 and 600 bytes in length, depending upon the device type used. They use the stack address set up by the primary loader. For current loaders this will be between 17400(octal) and 17776(octal). The secondary loader assigns its buffer space below the stack. The secondary loader accepts Memory Load with and without Transfer Address messages. It is, therefore, capable of doing multi-block loads into absolute addresses without memory management. It requests a tertiary loader to be loaded. The DMP-11 and DMV-11 do not set up the stack pointer or R1 as described. For those devices, R1 contains the device unit number. Tertiary Loader The tertiary loader is loaded by the secondary in a multi-block load starting at location 10000(octal). It will run with memory management on if it exists on the system. The tertiary loader moves itself to the top of physical memory and assigns its stack and buffer space just below itself. It is, therefore, capable of multi-block loads from location 0 up to its buffer address, usually the last 1-2K words of physical memory. It requests the operating system to be loaded. The current tertiary loaders do not specify any specific operating system. The choice of system to send is established by prior agreement or by command at the host system. APPENDIX D REVISION HISTORY This appendix provides a list of the major changes that have been made to this specification. D.1 Changes from Version 1.1 to Version 2.0 1. Removed all references to MOP being used directly to non-adjacent systems over DECnet links. The NICE protocol performs MOP-like functions within DECnet, using actual MOP protocol only over a physical link. 2. Decoupled MOP from DDCMP maintenance mode. The protocol specifies the requirements of a link control procedure to be used with MOP. DDCMP maintenance mode is one such procedure. 3. Deleted the following messages not needed in MOP. These are now handled by NICE. Code 20, Examine data by name; code 22, Clear data by name; and code 26, Examined data by name. 4. Clarified the description of the fields in all MOP messages. Clarified and expanded the operational details of MOP and added a state table for operation. 5. Added detailed description of the requirements of the data link control procedure to be used by MOP and a detailed description of the interface, set of commands and responses, to that procedure. 6. Added VAX and DECSYSTEM 10/20 information in message formats where necessary. 7. Changed message 8, Request MOP secondary mode program, to Request Program. It is now used to request all program loads in MOP, not just the secondary program. The STADDR field is removed and replaced by a MOP version number field. Added DTE20 to DEVTYPE field. PGMTYPE field is changed and SOFTID is added. Revision History Page D-2 8. Changed message 10, Request memory load, to remove NODE and SOFTID, function now part of message 8 described above. Added an ERROR field to return any errors on previous load. 9. Changed message 12, Secondary mode running, to MOP mode running. Removed STADDR and replaced with MOP version number. Added a FEATURES field to describe the MOP features a node supports. 10. Added a new message, code 20, Parameter load with transfer address. This message is used to load a parameter block before transferring control to a just loaded program. 11. Added a detailed description of primary mode and the operation of loading the secondary program. D.2 Changes from Version 2.0 to Version 2.1.0 1. Added Looped Data Message as response to a Loopback Test Message. 2. Added host node number parameter to Parameter Load with Transfer Address Message. 3. Added notification from DDCMP that a start was received while in maintenance mode. D.3 Changes from Version 2.1.0 to Version 3.0.0 1. Expanded capabilities to cover data links which support multiple concurrent protocols and multiaccess channels (e.g. Ethernet). Changed references to "DDCMP" to "data link" to cover the more general scope. 2. Generally expanded the documentation. Added user and network management interface sections. 3. Divided functionality into three distinct classes (protocol types): Loop Test, Dump/Load, and Remote Console. 4. Added Dump Complete and Assistance messages to the Dump/Load protocol. 5. Changed Enter MOP Mode message to Boot message. Added Processor, Control Device ID, and Software ID fields. Revision History Page D-3 6. Added Request ID, System ID, Request Counters, Counters, Reserve Console, Release Console, Console Command and Poll, and Console Respond and Acknowledge messages to the Remote Console protocol. 7. Added Reply and Forward Data messages to the Loop Test protocol. These are for multiaccess channels. The V2.1 Loop messages are still available for point-to-point channels. 8. Replaced Load/Dump state tables with procedural descriptions. APPENDIX E ETHERNET LOOP TESTING Introduction The Ethernet Loop Testing Protocol provides minimum testing capability of communication between stations on an Ethernet. It is the only Client Layer protocol specified in the Ethernet specification. Using these procedures, the Network Managment System is given a minimum set of functions which can be used to determine network configuration, station addresses, and stations on the Ethernet with the ability to communicate. Some support of loop testing functions is required on all Ethernet stations, as specified in the section on Conformance Requirements. Goals The goals of the Ethernet Loop Testing Protocol are: 1. Provide for all forms of multi-station loop test that are necessary to diagnose a station's ability to communicate. 2. Allow each station to assume the responsibility to diagnose its own ability to communicate. 3. Allow a network management node to diagnose some other station's ability to communicate. 4. Minimize processing and memory requirements, particularly in stations other than the executing station. Loop Testing Functions A station using the Loop Test Protocol can ascertain the following: Ethernet Loop Testing Page E-2 specific some 3. The ability of a specific third party station to communicate with a specific remote station. 4. With the help of a third party station, the ability to hear or be heard by a specific station. Functional Model The Ethernet Loop Testing Protocol is composed of two modules, the Loop Requester and the Loop Server. Although these two modules are Client Layer entities, some services not included by the Data Link Layer are also required. A minimum Client Layer communication service, which lies between the Data Link Layer and the two modules above, is needed to provide simple success/fail transmit and receive services, as well as protocol type demultiplexing. Thus, the abstract Ethernet interface assumed in this description is of a slightly higher level than the Data Link to Client Layer interface. +--------------+ | User Modules | +--------------+ | | | +---------+ V | +-----------+--------+ | | Loop | Loop |<--+ | Requester | Server | +-----------+--------+ | | +---------+ | V +---------------+ | Communication | Client | Service | Layer +---------------+ . . . . . . . . . . . . | . . . . . . . . . . . . . . V +------------+ Data | Ethernet | Link | Data Link | Layer +------------+ The active end of the loop testing communication link is the Loop Requester module. It contains features which establish and control the loop communications. Ethernet Loop Testing Page E-3 Every Ethernet station must implement the Loop Server module. This module contains procedures which respond to Loop Requester inquiries and performs general communications service for remote Loop Requester modules for system tests and diagnostics. The relationship between the various modules are shown in the figure. Vertical arrows indicate flow of control at data interfaces. The horizontal arrow indicates control at a network management interface. Conformance Requirements In order to guarantee the availability of these functions and to provide for communication checking by a network management station, all Ethernet stations must implement the Loop Server. The Loop Server receives datagrams addressed to Ethernet physical addresses, the broadcast address, and, optionally, the loopback assistance multicast address. The Loop Server is not required to receive datagrams addressed to any other multicast address. Systems may implement the Loop Requester as desired. The allowed range of functions is between none at all to the full capability specified below. However, those stations that do not provide the full interface capability, proportionately limit their capacity for self-diagnosis and become more dependent on some centralized test facility. Interfaces This section describes the Loop Test functions using Pascal as a notational technique. These Pascal descriptions are to be understood as abstract, functional representations. Actual implementations may vary, for example in synchronization techniques, as long as they provide the same functions. The functional descriptions use the following common declarations: const addressSize = 48; {48 bit address = 6 octets} dataSize = 12000; {12000 bit data field = 1500 octets} receiptSize = 16; {16 bit receipt = 2 octets} type Bit = 0..1; array array record BufferMaximum: 0..dataSize; {Buffer maximum contents} BufferLength: 0..dataSize; {Buffer actual contents} array end Ethernet Loop Testing Page E-4 array Data Interface This section describes the data communication functions available to the user. These functions are the interface to the Loop Requester. There is no data interface to the Loop Server. The Loop Requester module provides three functions and one procedure as an interface for user module loop testing services. Functions: LoopDirect LoopAssisted LoopPoll Procedure: LoopAbort LoopDirect The LoopDirect function is used to determine if direct communication with a remote station is possible. function remoteAddress: AddressValue; transmitBuffer: BufferValue; var var type With the following definitions: remoteAddress - the identification of the station with which communication is to be checked. The address can be a multicast address, in which case success is defined as a response from any station in the multicast group. If no address is specified, the loopback assistant group multicast address is used. transmitBuffer - a buffer containing the data to be looped. receiptNumber - the request identification used in LoopPoll or LoopAbort to identify this request. receiveBuffer - an optional buffer to contain the looped back data. If no buffer is supplied (i.e. BufferMaximum = 0), the looped back data is not returned to the caller. LoopDirectStatus - the status of the request. One of: accepted - the loop will be attempted. Ethernet Loop Testing Page E-5 wrongState - the data link is in a state where a loop cannot be done. LoopAssisted The LoopAssisted function is used by a station to determine if some station in the local network can communicate with the specified remote station. This may be used if attempts at direct communication have failed. Loop testing assistance is obtained by a call to the function: function remoteAddress: AddressValue; assistantAddress: AddressValue; assistanceLevel: (transmit,receive,full); transmitBuffer: BufferValue; var var type (accepted,wrongState,invalidRemote,invalidAssistant); With the following definitions: remoteAddress - the identification of the final destination station of the test. The address cannot be a multicast address. assistantAddress - the identification of the third party station to assist in the test. To avoid undesirable levels of multicast traffic, the address cannot be a multicast address. assistanceLevel - the amount of assistance to be provided, one of: transmit - the assistant station is only to relay the request, the reply is to be returned from the station possessing the remoteAddress. receive - the assistant station is only to relay the reply, the request is to be sent to the station with the remoteAddress. full - the assistant station is to relay both request and reply. transmitBuffer - a buffer containing the data to loop. receiptNumber - the request identification used in the LoopPoll or LoopAbort function to identify this request. receiveBuffer - an optional buffer to contain the looped back data. If no buffer is supplied (i.e. BufferMaximum = 0), the looped back data is not returned to the caller. Ethernet Loop Testing Page E-6 LoopAssistedStatus - the status of the request. One of: accepted - the loop will be attempted. wrongState - the data link is not in a state where a loop can be done. invalidRemote - the destination-address was a multicast address. invalidAssistant - the assistant-address was a multicast address. LoopPoll The LoopPoll function is used to poll for completion of a LoopDirect or LoopAssisted. function receiptNumber: ReceiptValue; var type (notComplete,success,compareError,transmitFailed, communicationError); With the following definitions: receiptNumber - the request identification assigned to this request by the LoopDirect or LoopAssisted function. remoteAddress - the identification of the remote station that satisfied the request. For LoopAssisted with transmit assistance, this is the remote station address. For LoopAssisted with receive or full assistance, it is the assistant station address. LoopPollStatus - the status of the operation. One of: notComplete - the loop is not yet done. success - the data came back correctly. compareError - the data came back, but it did not match what was sent. transmitFailed - the local transmitter could not send the initial message. communicationError - no response was received. Either the initial message or the response did not arrive. Ethernet Loop Testing Page E-7 LoopAbort The LoopAbort procedure is used to abort a LoopDirect or LoopAssisted when, for example, the user decides that the reply has taken too long. procedure With the following definition: receiptNumber - the request identification assigned to this request by the LoopDirect or LoopAssisted function. Network Management Interface This section describes the Network Management control and observation functions. These functions interface to the Loop Server. There are no Network Management functions for the Loop Requester. EnableServer The EnableServer procedure is used to allow Loop Server operation. procedure DisableServer The DisableServer procedure is used to stop Loop Server operation. procedure EnableAssistance The EnableAssistance procedure is used to allow the Loop Server to listen to the loopback assistance multicast address. procedure DisableAssistance The DisableAssistance procedure is used to stop the Loop Server from listening to the loopback assistance multicast address. procedure Ethernet Loop Testing Page E-8 ReadStatus The ReadStatus procedure is used to read the status of the Loop server. procedure var var With the following definitions: serverState - the state of the Loop Server. assistanceState - the state of the loop assistance feature, i.e. determines if station is listening for loopback assistance multicast address. Loop Test Examples The following examples address the application of the Loop Test functions. They are intended as examples of how a higher level process can use the facilities. They are intended neither as a specification for how they must be used nor as an exhaustive test script. In the examples, no account is taken of the fact that the Loop Test functions make only one attempt to transmit a message. To increase the reliability of the tests, each interface function that fails due to a communication error should be retried enough times to lessen the probability that an intermittent error occurred. Local Control Test Example In this case, a station finds itself unable to communicate with some other station that it has reason to believe should be available. The following test script can be used by the station to check out the problem itself. First, LoopDirect is invoked with remoteAddress set at the correct address of the specific remote station. If this test succeeds, the communication is possible and the problem may have been either intermittent, the remote station is down, or there is a problem with message length or data pattern. Different message lengths and/or data patterns could then be tried. If LoopDirect results in a return indicating failure, next invoke LoopAssisted, using some other node as assistantAddress (if no potential assistant is known, use LoopDirect with no remoteAddress to find a member of the loopback assistance multicast group). If LoopAssisted fails, then the assistant cannot communicate with the remote node, either. If a LoopDirect was successfully used to find an Ethernet Loop Testing Page E-9 assistant, the remote station is probably down. If no communication with the multicast assistant group is possible, then the last resort is a LoopDirect to the general broadcast address. If this fails then either no one else is turned on or the local station is broken. If it succeeds, it is again most likely that the remote station is down. If some loopback assistant station can communicate with the remote node but the local station cannot, the local station can then test for the direction in which communication does not work. The LoopAssisted function, using the assistant node that responded previously as the assistant, can be used to detect either transmit or receive problems. By repeating the above test with different remote stations, it can be determined whether the local station or the remote station is at fault, thus isolating the problem to a particular transmitter or receiver. When a station finds itself unable to communicate, it can report this in whatever high level way is available. An operator or control center can then respond by attempting to isolate and repair the problem. Remote Control Test Example When a control center receives a report that a station cannot communicate properly, it can use the Loop Testing functions to investigate the problem. It can first diagnose its own ability to communicate with the station. If this communication appears to work, the control center can similarly check its ability to communicate with the remote station that the reporting station could not reach. If the control center can communicate with both stations, it can then use LoopAssisted, full assistance, with one of the nodes as assistant and the other as remote to see if they can communicate. Similarly it can use transmit and receive assistance to determine which direction is a problem. Similar checks using other stations can be used to isolate the problem to a particular transmitter or receiver. Operation This section describes the operation of the Loop Test Server and Requester. Loop Test operation does not depend on particular stations being able to receive multicast messages. Those stations willing to volunteer as loop testing assistants respond to multicast address CF-00-00-00-00-00, and are known as the loopback assistance multicast group. Ethernet Loop Testing Page E-10 In the interests of simplicity and efficiency, loopback operation and message formats are designed to meet the following requirements: 1. All fields begin on 16-bit boundaries. 2. Progressive operations on the same message (e.g. looping it back) do not change the message size. The general form of operation is that different loopback message types are encapsulated within one another. The first field, called the skip count, in all messages indicates how many octets to skip after the skip count to find the message type. When a message is processed, the processing system updates the skip count so that the next system will process the next encapsulated message. Note that in order to meet the 16-bit boundary requirement, the skip count is always an even number. The Loop Test protocol uses protocol type 90-00. The operational descriptions assume the following Loop Test protocol messages. 1. Reply - a message identifiable as a response to some request. 2. Forward Data - A message whose data portion is forwarded to another station. Loop Server The Loop Server always keeps a receive pending while the data link is turned on. Whenever a receive completes, it is processed and another receive posted. For purposes of not missing messages, it may be necessary to keep more than one receive posted, although this is not required. In order to help bound the time a test can take, the Loop Server must respond to the data link within one second of the time it receives a valid message. The received message is processed according to function code: 1. Forward Data message. The skip count is increased by the length of the function code and forward address. If the forward address is a multicast address, the message is ignored. Otherwise, the message is transmitted to the forward address. Ethernet Loop Testing Page E-11 2. Unrecognized function code. The message is ignored. In order to provide maximum problem diagnosis capabilities, Loop Servers must always attempt to receive Ethernet maximum sized messages. Loop Requester The Loop Requester uses receipt numbers to identify requests both back to the user and in protocol messages. When the system is initialized, the next available receipt number is set to a random value. It is then incremented each time one is used. LoopDirect Function A receipt number is assigned and the state of the operation is set to "not complete". The data, provided via transmitBuffer, is transmitted to the destination station, identified by remoteAddress, as a Reply message encapsulated in a Forward Data message with the local station as the forwarding address. If the transmit is not accepted, the error code is returned and the receipt number marked complete. If the transmit succeeded, a receive is posted. Note that in some implementations it may be necessary to post the receive first to avoid a race between the posting of the receive and the receipt of the message. The receive is satisfied by the first Reply message received with the correct receipt number. Additional replies (as in the case of a LoopDirect to the loopback assistance multicast group) are automatically ignored since there is no longer an outstanding request with the receipt number. When the transmit and receive are both complete, if they were successful the received data is compared to the transmitted data, exclusive of loop protocol overhead. If they do not match or the receive or transmit failed, the appropriate error is recorded; otherwise, success and the responding station address are recorded. LoopAssisted Function If the request is for receive assistance, and the assistant address is a multicast address, an invalid assistant address error is returned; otherwise, a receipt number is taken and the state of the operation is set to "not complete". The data is put into the form of a Reply message and encapsulated in a Forward Data message with the local station address as the forward address. The rest of the operation depends on the assistance level requested: Ethernet Loop Testing Page E-12 1. Transmit assistance. The message so far is encapsulated in a Forward Data message with the remote station as the forward address. The resulting message is then sent to the assistant address. 2. Receive assistance. The message so far is encapsulated in a Forward Data message with the assistant address as the forward address. The resulting message is then sent to the remote station. 3. Full assistance. The message so far is encapsulated in a Forward Data message, with the assistant address as the forward address. This, in turn, is encapsulated in a Forward Data message with the remote station address as the forward address. The resulting message is then sent to the assistant address. Receive processing is the same as was described for LoopDirect. LoopPoll Function The LoopPoll function returns the state of the operation. If the state is successful completion, the responding station address is also returned. If a receiveBuffer was provided on the initial request, the received message is returned, truncated if it will not fit. LoopAbort Function The LoopAbort procedure simply marks the receiptNumber as aborted if it is not already complete. Protocol Messages This section defines the format of the Loop Test protocol messages. The descriptive and transmission conventions are the same as for the body of the Ethernet specification. The Loop Test protocol contains the following messages: Function Code Function 1 Reply 2 Forward Data Ethernet Loop Testing Page E-13 Reply Message This message is recognized as a looped reply. The message format is: |<--- 1 octet --->| +-----------------+ | skip | 2 octets | count | +-----------------+ | | . octets to skip . . according to . skip count octets . skip count . +-----------------+ | function | 2 octets | 1 | +-----------------+ | receipt | 2 octets | number | +-----------------+ | | . . . data . remainder . . | | +-----------------+ Forward Data Message This message is used to get a message forwarded to some other station. Its format is: Ethernet Loop Testing Page E-14 |<--- 1 octet --->| +-----------------+ | skip | 2 octets | count | +-----------------+ | | . octets to skip . . according to . skip count octets . skip count . | | +-----------------+ | function | 2 octets | 2 | +-----------------+ | | | | | forward | 6 octets | address | | | | | +-----------------+ | | . . . data . remainder . . | | +-----------------+