DECnet Digital Network Architecture Phase IV Maintenance pera at ions Functional Specification Order No.
DECnet Digital Network Architecture Phase IV Maintenance Operations Functional Specification Order No. AA-X436A-TK December 1983 This document describes the structure, functions, interfaces, and protocols needed for the low level maintenance of a DECnet network. SUPERSESSION/UPDATE INFORMATION: This is a new manual VERSION: 3.0.0 To order additional copies of this document, contact your local Digital Equipment Corporation Sales Office. .
First Prin' ing. December 1983 The information in this document is subject to change without notice and should not be construed as a commitment by Digital Equipment Corporation. Digital Equipment Corporation assumes no responsibility for any errors that may appear in this document. The software described in this document is furnished under a license and may only be used or copied in accordance with the terms of such license.
Page 3 Table of Contents CONTENTS ....... . .. .. .. .. ... ........ ...... ............. . . . . . . . . . . . . . 67 .. .. .. .. .. .. .. .. .. .. .. .. .. 8 . . . . . . . . . . . . . 88 .............9 MODELS . . . . . . . . . . . . . . . . . . . . . . . 9 Relationship to DIGITAL Network Architecture . . . 9 SimplifiedNetworkModel . . . . . . . . . . . . 12 Low Level Maintenance Operation Model . . . . 12 INTERFACES . . . . . . . . . . . . . . . . . . . . 13 Data Link Interface . . . . . . . . . . . .
Page 5 Table of Contents APPENDIX E ETHERNET LOOP TESTING . . .. .. .. .. .. .. .. .. .. ... ...... .. . . . .. .. .. .. .. .. .. ........ ....... ......... ........ ....... ...... ..... .... . . . . . . . . ...... . .......... ........ ....... ... . . .. .. .... . . . . . .. .. .. .. .... E.1 Introduction E.I.1 Goals E.1.2 Loop Testing Functions E 1 3 Functional Model E.I.4 Conformance Requirements E.2 Interfaces E.2.1 Data Interface E.2.1.1 LoopDirect E.2.1.2 LoopAssisted E.2.1.3 LoopPoll E.2.1.
Page 6 Introduction 1 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 hiqh 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 l i n ~services.
Page 7 Introduction DNA Routing Layer Functional Specification, Version - 2.0.0, Order NO. AA-X435A-TK DNA Session Control Functional Specification, Version 1.0.0, Order NO. AA-K182A-TK The Ethernet - A- Local Area Network - -Data Link Layer and Physical Layer Specifications, Version Xerox), Order No. AA-K759B-TK 2.0, (Digital, Intel, and - The DECnet DIGITAL Network Architecture (Phase I V ) General Description (Order No.
Page 8 ~ntroduction System load/dump copies the contents of processor memory to or from remote system. a Throughout this document, the term boot is used to mean the process of causing a system to initialize itself. Initialization may include loading system memory. A boot command is a cause. The term load is used to mean the Drocess of transferring a system image into processor memory from some source. This is one potential effect of a boot command.
Page 9 Introduction . . . . 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 UD-line dump, overall speed of operation is an important goal. Extensible to accommodate newly modification of current functions. developed Operates independently of the underlying mechanism (e.g. DDCMP, Ethernet, etc.). No complex algorithms or data bases. the smallest systems.
Page 10 Mode 1s 1 I----> 1 User Modules ............................ I I 1 Network Application Modules - - 1 ................................ I I v v I I I 1 ---- > I I Session Control Modules ....................................... I I 1 ------ ' I I v I I I ' I I I I I 1 I NOTE Horizontal arrows show direct access for control and observation of parameters, counters, etc.
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 excnanged between equivalent modules in different nodes.
Mode 1s 2.2 Page 1 2 Simplified Network Model The following diagram shows a simplified relationship of maintenance operations to the rest of the network architecture. ------ User Layer I User I ........... I . the . . . . . . . . . . . . . . . I ------------- Network Management Layer 1 Maintenance 1 I Operations I ------------- ......... 1 ------1 i 2.2.1 ------- DDCMP i . 1 . I I I I 1 I 1 ---------i Ethernet I ..............
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.
Page 14 Interfaces . . maintenance operations. From the perspective of maintenance operations, there link configurations: ~oint-to-pointand multiaccess. Point-to-point data links are those where there is the each end of a loqical channel. T r a n s i t s and between these two nodes. Multipoint is treated as the sense that each logical channel (tributary) is independently.
Interfaces Page 15 Function: is needed. Checks the channel to see if maintenance service 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 traffic. channel wants to run maintenance Unrecognized channel - there is no channel with the identification.
Interfaces Page 16 Success - a port was opened. No resources - the data resources to open a port. link does not have Unrecognized channel - there is no channel with the identification. sufficient specified Channel in wrong state - the channel is not in a state where a port c a n b e opened. Port-id - a port identification to be used in the other data interface functions. 3.1.3 link Close Function: Closes an open port and releases all its resources.
Interfaces Page 17 This Destination-address - the address of the frame destination. can be either a physical address or a multicast address. ~pplicableonly 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 o f the buffer. Outputs: Return-code - the status of the request.
Interfaces Page 18 Transmit successful - a transmitter. frame successfully left the local Transmit failed - the local transmitter could not transmit the frame. Unrecognized port - there is no open port with identification. the Channel in wrong state - the channel is not in a it can send a frame. Input-buffer - the function. 3.1.6 buffer that was supplied in specified state the where Transmit Receive Funct ion: Queues a buffer to receive a frame.
Interfaces Page 19 Function: Check for the completion of a receive gives received frames to the user arrived. request. The data link in the order in which they 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 port. thi: Receive successful - a frame was the buffer.
Page 20 Interfaces 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 identification. the Unrecognized buffer - the specified buffer is not the specified port. 3.
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 . Loop-abort -- abort a loop. -- check for completion of 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.
Page 22 Interfaces 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 completion with the Force-load-poli function.
Interfaces Page 23 No resources - the Dump/Load Server does not resources to queue the request. have sufficient Unrecognized channel - there is no channel with the identification. specified Channel in wrong state - the channel is not in a state where a load can be done. ~eceipt-number- a receipt number to identify this request in Force-load-poll function. the Function: Checks for completion of a pending Force-load function is a call to the Dump/Load Server. function.
Page 24 Interfaces Unrecognized target - the Dump/Load Data Base was needed did not contain an entry for the specified target. but 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 Function: Requests a down-line load of the local system.
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 identification. specified Channel in wrong state - the channel is not in a state where a load can be done. Funct ion: Checks for completion of the pending Load-self function is a call to the Dump/Load Requester. Inputs: function. This None.
Page 26 Interfaces 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 completion with the Force-dump-poll function. checks for Inputs: Channel-id - the unique identification of the channel over which the dump is to be performed.
Interfaces Page 27 No resources - the Dump/Load Server does not resources to queue the request. Unrecognized destination - there is no specified identification. have destination Unrecognized channel - there is no channel with the identification. sufficient with the specified 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 Force-dump-poll function.
Interfaces Unrecognized channel - there is no channel with the identification. Page 28 specified Unrecognized target - the Dump/Load Data Base was needed, did not contain an entry for the specified target. but Channel in wrong state - the channel is not in a state where a dump operation can be done. Funct ion: Requests an up-line dump of the local system. This is the communications channel equivalent of a system dumping itself to local mass storage.
Interfaces Page 29 implementation-specific basis. Parameter-value - the value of the oarameter. 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 identification. specified Channel in wrong state - the channel is not in a state where a dump can be done.
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, systems other than the requesting system. particularly in The realization of these goals is differerii: for multiaccess channels and point-to-point channels, since multiaccess channels have a broader communication ability.
Interfaces Page 31 Input-buffer - a buffer containing the data to be looped. Output-buffer - a buffer to contain the looped back data. If present, the looped back data is not returned to the user. not 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 identification. Channel in wrong state - the channel is in loop cannot be done.
Page 32 Interfaces Output-buffer - a buffer to contain the looped back data. If present, the looped back data is not returned to the user. not 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 identification. Channel in wrong state - the channel is in loop cannot be done. a state Receipt-number - the request identification used in the or Loop-abort function to identify this request.
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. Function: Used to abort a Loop-direct or Loop-assisted, for example user decides that the reply has taken too long. if the Inputs: Receipt-number - the request identification assigned request by the Loop-direct or Loop-assisted function. Outputs: to this none. Remote Console Functions 3.2.
Page 34 Interfaces 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 check for remote requests. to Outputs: Return-code - the status of the request. One of: No requests - no remote requests have been received.
Interfaces Page 35 Verification-code - for a boot request, the verification code sent by the requesting system. 4 or Source-address - the identification of the system that request. Applicable only on multiaccess channels. 8 byte sent the 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.
Page 36 Interfaces Channel-id - the unique identification of the channel on which send the boot command. Destination-address - the identification of the system. Applicable only to multiaccess channels. to destination 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. I f it is 4 bytes, no additional parameters can be sent. If additional parameters are to be sent, the code must be 8 bytes long.
Interfaces 3.2.3.4 Page 37 Read-identity Funct ion: Reads the identity of the specified system. Inputs: Channel-id - the unique identification of the channel on which read the identity. Destination-address - the identification of the system. Applicable only to multiaccess channels. to destination Outputs: Receipt-number - the receipt number used in the Console-abort Read-identity-poll functions to identify this request. or Function: Polls for completion of a Read-identity function.
Page 38 Interfaces 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 remote console reserved. Not returned if not received. has the Reservation-timer - the maximum number of seconds that are allowed with no remote console requests before the reservation expires. Not returned if not received.
Interfaces Page 39 Parameter-value - the value of the parameter. 3.2.3.6 Read-counters Function: Reads the data link counters from the specified system. Inputs: Channel-id - the unique identification of the channel on which read the counters. Destination-address - the identification of the system. Applicable only to multiaccess channels. to destination outputs: Receipt-number - the receipt number used in the Console-abort Read-counters-poll functions to identify this request. 3.2.3.
Interfaces Page 40 Counters - a block of counter information particular data link (see Appendix B). as defined for the Function: This Reserves the,remote system console for use by this system. 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. I f the remote console reservation timer expiresl this system's console reservation is lost without notification.
Interfaces Page 41 Channel in wrong state - the channel is not in a the reservation can be made. state Port-id - a port identification to be used in the other Console Interface functions that require a reservation. where Remote Function: This Releases this system's access to the remote system console. provides an optimization over allowing the remote system's reservation timer to expire and deallocates the local port resources.
Interfaces Port-id - a port identification assigned console function. . by the Page 42 Reserve-remote- 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.
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 c o m a n d 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.
Page 44 Interfaces Response-data-lost-flag - a logical value that is true i f 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.
Interfaces Outputs: 3.3 Page 45 None. Network Management Interface This section defines the control and maintenance operations. observation functions for the 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 Base. Remove-dump/load-entry - - Remove an entry from Data Base.
Page 46 Interfaces Dump/Load assistance - controls whether the will respond to dump or load requests assistance multicast group. Durnp/Load Server to the dump/load 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 system is allowed to reserve the local console.
Page 47 Interfaces Unrecognized channel - there is no channel with the identification. Channel in wrong state - the channel is not in a the read can be done. specified state where 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 reservations.
Page 48 Interfaces Function: Removes an entry from the Dump/Load Data Base. Channel-id - the unique identification identifies the data base entry. of the channel that Destination-address - the identification of the target system that identifies the data base entry. NOTE Either the channel-id must be included in system.
Page 49 Interfaces Parameter-type - the particular parameter to set. One of: Load-file Secondary-loader Tertiary-loader Dump- f i le Secondary-dumper Dump-address Dump-count Parameter-value - the new value parameter-type. of the parameter specified by outputs: Return-code - the status of the request. One of: Success - parameter set. Unrecognized target - the DurnplLoad Data Base does not contain an entry for the specified target, Function: Reads the list of Dunp/Load Data Base entries.
Page 50 Interfaces Channel-id - the unique identification identifies the data base entry. of the channel that 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 destinationaddress is used as the data base search key to find other values in the DumpILoad Data Base.
Interfaces Page 51 Software-id System-processor Data-link-type Other-info (in the form of an other-info ~arameter-type) Parameter-value - the new value parameter-type. of the parameter specified by outputs: ~eturn-code- the status of the request. One of: Success - parameter set. Unrecognized channel - there is no channel with the identification. Channel in wrong state - the channel is not in a the parameter can be stored. 3.3.
Interfaces examples of multicast Loop Testl see Appendix E Specificationf Version 2.0. 3.4.1 A Page 52 or the Ethernet System Boot Monitor In this example, a system can be booted by remote commandl 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.
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 systemI i.e.
Operat ion 4 Page 54 OPERATION This section describes the operation that supoorts 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.
Page 55 Operat ion The Must-transact algorithm is: Set no intervention, no error, and no message received. WHILE no intervention AND no error AND no messaqe 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 ENDWH I LE The Transact algorithm is: Set retry counter to 0, no error, and no message received.
Page 56 Operat ion NOTE See Appendix C for implementation information. 4.2.1 specific Dump/Load 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.
Operat ion 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.
Page 58 Operat ion 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 ENDWHI LE IF no error: Complete file as necessary. ENDIF Transmit, dump complete. Close output file. 4.2.1.3 Load Operation Load operation requires the following messages: . Request program.
Operat ion . 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 multisegment load. NOTE See ~ p p e n d i xC for special conventions existing PDP-11 down-line load programs. related to 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.
Operat ion 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. END I F END1 F ENDIF ENDWH I LE 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 .
Operat ion 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.
Page 62 Operat ion 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.
Operat ion Page 63 Note that in the case of an unintelligent loopback mechanism, such a simple turn-around connector, the function code will not change. 4.3.2 as 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.
Page 64 Operat ion 1 <==== I I I I I I I 1 Enabled I = = = = > ! Reserved 1 I I I I I 1 <++++ 1 I -----------------I I 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.
Operat ion . . . . In response to a Boot information visible to Request-poll function. Page 65 message, make the request and boot the local higher level through the 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).
Page 66 Operat ion 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.
Page 67 Operat ion In the cases of the Read-identity, Read-counters, and Send-consolecommand 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.
Page 6 8 Operation SET no error. WHILE system-id DO = source-address AND no error transmit, Release Console message. receipt-number : = Next-receipt-number (channel-id). Transact, Request ID message. ENDWH I LE 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.
Protocol Messages 5 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.
Page 70 Protocol Messages A Nu1 l ASCII Interpretation depends on data representation Notes: . . . . All numeric values are shown in decimal noted. unless otherwise Fields are transmitted in the order shown, left to right. All fields are transmitted low-order or least bit first unless otherwise specified. Bits in a field are numbered from 0 to n where low-order or least-significant bit. significant 0 is the The messages specified here are a directly compatible extension of MOP version 2.1.
Protocol Messages IMAGE DATA ( * I Page 71 : = 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. 5.1.
Page 72 Protocol Messages 5.1.3 Request Memory Dump The Request Memory Dump message consists of: CODE MEMORY ADDRESS COUNT Where: CODE (1) : B = The number 4. MEMORY ADDRESS ( 4 ) : B = The starting physical memory address for the dump. COUNT ( 2 ) : B = The number o f 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.
Protocol Messages Page 73 FORMAT VERSION (1) : B = The protocol format version. 1. For all current versions, the number B = PROGRAM TYPE (1) : 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 0 1 2 Meaning Secondary loader Tertiary loader System This field and all the following can be omitted, in which case the default for this field is 0.
Page 74 Protocol Messages 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 values are: Value 0 1 5.1.6 for the previously received segment.
Page 75 Protocol Messages 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). 5.1.7 Memory Dump Data The Memory Dump Data message consists of: CODE MEMORY ADDRESS IMAGE DATA Where: CODE (1) : B = The number 14. MEMORY ADDRESS (4) : B = As described for the Request Memory Dump message.
Page 76 Protocol Messages Where: END MARK (1) : B = The number 0. 'And a parameter entry consists of: PARAMETER TYPE PARAMETER LENGTH PARAMETER VALUE Where: PARAMETER TYPE (1) : B = A type code for the parameter information. The values are: Value Parameter 1 2 3 4 5 TARGET SYSTEM NAME TARGET SYSTEM ADDRESS HOST SYSTEM NAME HOST SYSTEM ADDRESS HOST SYSTEM TIME PARAMETER LENGTH (1) : B = The number of bytes in the PARAMETER VALUE field.
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.
Page 78 Protocol Messages Dump Complete 5.1.9 The Dump Complete messaqe was not part of MOP 2.1. It consists of: CODE Where: CODE (1) : B = The number 1. 5.1.10 Assistance Volunteer The Assistance Volunteer message was not part of MOP version 2.1. consists of: It CODE Where: CODE (1) : B = The number 3. Loop Test 5.2 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.
Protocol Messages RECEIPT ( 2 ) : B Page 7 9 = The receipt number for the loop request. DATA (*) : B = The data to be looped back. Looped Data Message 5.2.2 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 5.3 Unless otherwise stated, the Remote Console messages are additions MOP version 2.1. 5.3.
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. BM = CONTROL (1) : Instructions to the system as operation.
Page 81 Protocol Messages Request ID 5.3.2 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. RECEIPT NUMBER ( 2 ) : A 5.3.3 B Value is 0. = receipt number to identify the request. System ID The System ID message consists of: CODE RESERVED RECE I PT NUMBER OTHER INFO Where: CODE (1) : B = The number 7. RESERVED (1) : = A one byte field reserved to DEC for future use.
Page 82 Protocol Messages INFO TYPE (2) : B = Is the type of information.
Page 83 Protocol Messages 4 5 6 7 Boot Console carrier Data link counters 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.
Page 84 Protocol Messages 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 (1-16) : = Information specific t o t h e particular SOFTWARE ID. Not present i f 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.
Protocol Messages 5.3.5 Page 85 Counters The Counters message consists of: CODE RECEIPT NUMBER COUNTER BLOCK Where: CODE (1) : B = The number 11. RECEIPT NUMBER ( 2 ) : A B = receipt number to identify the request. COUNTER BLOCK (*) : = block of counters as defined for the particular data Appendix B). A 5.3.6 link (see Reserve Console The Reserve Console message consists of: CODE VERIFICATION Where: CODE (1) : B = The number 13.
Page 86 Protocol Messages Console Command and Poll 5.3.8 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 FLAGS COMMAND DATA Where: CODE (1) : B = The number 17. CONTROL FLAGS (1) : BM = The control flags indicate the state of the console message streams. They insure that messages are not lost.
Protocol Messages Page 87 The number 19. CONTROL FLAGS (1) : BM = The control flags indicate the state of the console message streams. They insure that messages are not lost. bit carrier 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.
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. A.
predefined Values 42 KMY 44 KMX A.2 KMS11-PX synchronous line interface with X.25 level 2 microcode KMS11-BD/BE synchronous line interface with X.25 level 2 microcode Data Links The data link type values are: Value 1 2 3 A.3 ~eaning Ethernet DDCMP LAPB (frame level of X.
APPENDIX B DATA LINK SPECIFIC INFORMATION This appendix contains information necessary to relate link types to the maintenance operations. B. 1 specific data 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. B. 2 LAPB The LAPB Data Link is the frame level of X.25.
Data Link Specific Information Page B-2 The protocol types are: Value Protocol 90-00 60-01 60-02 Loopbac k Dump/Load Remote Console The multicast addresses are: Address Group CF-00-00-00-00-00 AB-00-00-01-00-00 AB-00-00-02-00-00 Loopback assistance Dump/Load assistance 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.
Data Link Specific Information P a g e B-3 The bit meanings for the data errors inbound reason bitmap are: Bit 0 1 2 Reason Block check error Framing error Frame too long
APPENDIX C IMPLEMENTATION SPECIFIC DUMPILOAD CHARACTERISTICS This appendix documents characteristics of PDP-11 existing as of the date of this specification. C.1 dump/load programs Secondary Loader The secondary loader is sent as a single Memory Load with Transfer Address message as normally required. In addition to this Current requirementI it must be loaded and started at location 6. secondary loaders are between 400 and 600 bytes in lengthI depending upon the device type used.
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 Removed all references to MOP being used directly to non-adjacent systems over DECnet links. The NICE protocol performs MOP-like functions within DECnetI using actual MOP protocol only over a physical link. Decoupled MOP from DDCMP maintenance mode. The protocol specifies the requirements of a link control procedure to be used with MOP.
Revision History D.2 D.3 Page D-2 8. Changed message 10, Request memory load, to remove NODE a3d 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.
Revision History Page D-3 6. Added Request IDl siitern IDl Request Countersr Countersr Reserve Consoler Release Consolel Console Command and Polll 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 LoadIDump state tables with procedural descriptions.
APPENDIX E ETHERNET LOOP TESTING Introduction E.1 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 Manaqment 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.
Ethernet Loop Testing Page E-2 1. The ability to communicate with a specific remote station. 2. The ability to communicate with some remote station. 3. The ability of a specific third party station 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. E.I.3 to communicate Functional Model The Ethernet Loop Testing Protocol is composed of two modules, the Loop Requester and the Loop Server.
Ethernet Loop ~ e s t i n g 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. E.l.
Ethernet Loop Testing Receiptvalue E.2.1 = Page E-4 array [l..receiptSize] of Bit; 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 t h e ~ o o pServer. The Loop Requester module provides three functions and as an interface for user module loop testing services. one procedure Functions: LoopDirect LoopAssisted LoopPoll Procedure: LoopAbor t E.2.1.
Ethernet Loop Testing Page E-5 wrongstate - the data link is in a state where a be done. E.2.1.2 loop cannot 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.
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 be done. invalidRemote address. - the - invalidAssistant address. E.2.1.3 destination-address the assistant-address was a was can multicast a multicast LoopPoll The LoopPoll function is used to poll for completion of or LoopAssisted.
Page E-7 Ethernet Loop Testing '2.2.1.4 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 LoopAbort (receipt~umber: ~eceiptvalue); With the following definition: receiptNumber - the request identification assigned request by the LoopDirect or LoopAssisted function. E.2.2 to this Network Management Interface This section describes the Network Management control and observation functions.
Ethernet Loop Testing E.2.2.5 Page E-8 ReadStatus The ReadStatus procedure is used server. to read the status of the Loop procedure ReadStatus ( war serverstate: (on,off); var assistancestate: (on,off)); With the following definit-ions: 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. E.
Page E-9 Ethernet Loop Testing 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. I f it succeeds, it is again most likely that the remote station is down.
Ethernet Loop Testing Page E-10 In the interests of simplicity and efficiency, loopback operation 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.9. back) do not change the message size. looping and it The general form of operation is that different loopback message types are encapsulated within one another.
Ethernet Loop Testing 2. Page E-11 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. E.4.2 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. E.4.2.
Ethernet Loop Testing Page E-12 Transmit assistance. The message so far is encapsulated in a Forward with the remote station as the forward address. message is then sent to the assistant address. Data message The resulting 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. Full assistance.
Page E-13 Ethernet Loop Testing E.5.1 Reply Message This message is recognized as a looped reply. 1 <--- 1 octet - - - > I I I + - - - - - - - - -- - - - - - - - - + I I I I The message format is: skip count . octets to skip . . according to . . skip count + 2 octets skip count octets +----------------- I I function 1 1 1 receipt number +----------------- +----------------- I data E.5.2 1 I + I I + I .
Ethernet Loop Testing Page E-14 1 <--- 1 octet --->I I I skip count +-------------_-_- I 2 octets I + I ..I octets to skip . according to . . skipcount skip count octets I I data .
DECnet Digital Network ArcnlIeciure rnasc 1 " Maintenance Operations Functional Specification AA-X436A-TK READER'S COMMENTS NOTE: This form is for document comments only. DIGITAL will use comments submitted on this form at the company's discretion. If you require a written reply and are eligible to receive one under Software Performance Report (SPR) service, submit your comments on an SPR form. Did you find this manual understandable, usable, and well-organized? Please make suggestions for improvement.
Necessary BUSINESS REPLY MAIL FIRST CLASS PERMIT N 0 . 3 3 MAYNARD MASS.
