Google
 

Trailing-Edge - PDP-10 Archives - bb-m836d-bm - tools/rmtcon/rmtcon.rno
There are 3 other files named rmtcon.rno in the archive. Click here to see a list.
.style headers 6,0,0 !causes all headers to be taken as is, no capitalizing
.set paragraph 0,1,2 !causes no indenting on first line in paragraph
.display number RL !number title and toc with lower case roman numerals
.ebb
.autoparagraph
.left margin 0
.right margin 72
.page size 59,83
.control characters
.set date
.set time
.flag substitute
.date		     !causes date to go under page number
.title
.blank 2
.center;Date: $$date##$$time
.center;Charge Number:V20-05113
.blank 1
.center;Revision "0.2" of
.center;Diagnostic Engineering Functional Specification for
.center;NI Services Program
.blank 1
.center;RMTCON
.page size 59,72
.autoparagraph
.title Overview of the Diagnostic Product
.no fill
Revisions:
.b1
Rev 0.1      26-Sep-83#By#John R. Kirchoff
Rev 0.2	     17-Oct-84#By#Gary Papazian
.fill
.page
.subtitle Table of Contents
.autosubtitle !causes header level 1's to be used as subtitles
.center;Table of Contents
.right;Page
.right;----
.!the next cmd inserts the table of contents produced by TOC.EXE
.require "RMTCON.RNT" !name of file for runoff to process
.display number D !number pages with decimal numbers
.number page 1
.fill.just.page.rm72
.autoparagraph

.send toc.blank 1
.lm0
.hl1 OVERVIEW OF DIAGNOSTIC PRODUCT
.lm4
.hl2 Scope of this document

This document describes the functional definition, design details, testing requirements and schedule for the "NI Services Program [DFNIC] of the TOPS-20 implementation of the TOPS-20/PLUTO.  This program implements the console carrier requestor portion (CCR) of the NI based system.  This document will be updated whenever changes are necessitated in these areas.

.hl2 General program description

The NI Services Program is a user mode only Program that will run under the TOPS-20 Operating System (Release 6.1 or newer).  In simple terms the NI Services Program is basically a terminal interface between TOPS-20(host) and a remote program which resides in a PLUTO(node) on the NI. This Program will have the ability to cause a Diagnostic or a Utility program in the remote node to be loaded and executed. It will also be able to communicate with the remote program while it is running and may take status or terminate its operation.

Command and Response Packets are passed between the NI Services Program and the PLUTO Console Carrier Server Task using the Console Carrier Protocol and the NI Remote Console Interface provided by the LLMOP% JSYS.

.hl2 Users and Uses

Field Service will use this Program to run remote diagnostic and utility programs on NI nodes.

.hl2 Pre-requisite software
.lm4
.list "o"
.le;TOPS-20 Operating System with the LLMOP% JSYS implemented.
.end list

.page

.send toc.blank 1
.lm0
.hl1 PRODUCT GOALS/NON-GOALS
.lm4
.send toc.blank 1
.hl2 Performance goals

To be able to execute, with a high degree of predictability, the commands received by the user on a terminal and relay messages effectively from the remote program.

.hl3 Program size

The NI Services Program should not be more than 10k, including buffer storage.

.hl3 Program run time

Run time in the traditional sense does not apply. This program is used as a terminal interface between TOPS-20 and a remote NI node.

.hl3 Exec mode capability

The NI Services Program will not run in Exec Mode.

.hl3 User mode capability

The user will need Wheel, Operator or Maintenance priviledges to run this Program.

.hl3 Fault Detection

The NI Services Program will not have any of its own Fault Detection. Any error detected by the remote program will be displayed for the User to see. A JSYS failure will be displayed on the users terminal like all other TOPS-20 programs.

.hl3 Fault isolation

The NI Services Program has no built in isolation capability. Any Functional Fault Detected will be passed back to the user by the remote program for analysis and reporting.

.hl3 General user interface philosophy

The NI Services Program will use TOPS-20 style Parsing and Recognition.

.hl3 Program documentation

Excerpts from this Functional Specification will be incorporated in the final Program documentation. The Program Documentation will be in conformance to the Diagnostic Q.A. Manual.

.send toc.blank 1
.hl2 Compatibility goals

The NI Services Program will support the manditory functionality as defined in the "A PLUTO IMPLEMTATION OF A CONSOLE CARRIER SERVER", 3-Mar-82 by Paul Weiss.

.hl3 CPU family

The NI Services Program is a user Program and is Monitor dependent rather than Hardware dependent. It will run on any KL10 Model B 36 bit CPU provided the Monitor is a TOPS-20 Monitor that supports the NI.

.hl3 Standard diagnostic support software

The NI Services Program will not use any of the Standard Diagnostic Support Software.  It will be a self contained program with an ".EXE" extension.

.hl3 Operating systems (TOPS-10)

There is no planned TOPS-10 support for the NI Services Program. If in the
future it is decided to have the NI Services Program run under TOPS-10, it will be done as a separate project. The TOPS-10 effort will be minimized by organizing the Software in a modular fashion.

.hl3 Operating systems (TOPS-20)

The NI Services Program will run under TOPS-20 release 6.1 and newer.

.hl3 Spear

The NI Services Program will be upward compatible with versions of SPEAR after TOPS-20 release 6.1 and newer.

.send toc.blank 1
.hl2 Failsoft goals
.hl3 CPU/Memory failures

The NI Services Program will be aborted by the Operating System.

.hl3 Power fail/restart

The Ni Services Program will have to be restarted by the user when the System is reloaded.

.send toc.blank 1
.hl2 Restrictions

The NI Services Program will only work under a TOPS-20 Operating System and communication will only be with a PLUTO node located on the NI.

.hl3 User mode privileges

The LLMOP% JSYS requires Wheel, Operator or Maintenence priviledges. This means that the directory the user is logged on to must have the above priviledges.

.hl3 User mode priority interrupts

The NI Services Program will not use any Hardware Interrupts. The Software Interrupt
System will be used.

.send toc.blank 1
.hl2 Non-Goals

.lm4
.list "o"
.le;The Ni Services Program will not do error retries.
.le;The NI Services Program will provide no exec mode support.
.le;The NI Services Program will provide no TOPS-10 support as part of this Project.
.end list

.page

.send toc.blank 1
.lm0
.hl1 REQUIREMENTS
.lm4

.hl2 Run time requirements

.list "o"
.le;A TOPS-20 Timesharing Monitor needs to be running.
.le;Adequate user priviledges.
.le;An NI (ETHERNET) Network
.le;A PLUTO, that has Console Carrier Server support.
.end list

.hl2 Development environment requirements

The hardware requirements needed to test the NI Services Program are:

.ls "o"
.le;A KL10 system that has a KLNI and a PLUTO is required.
.le;One Pluto system with a UNA.
.le;Two host systems residing on the NI.
.els

The NI Services Program must be tested with the PLUTO console server in each of the three possible states described below under Reservation States.

The NI Services Program must be tested with the PLUTO at micro-odt level and with the PLUTO based diagnostics package to test the normal processing of commands.

.hl2 Evaluation system

Engineering, Manufacturing and CSSE are expected to make their own arrangements as to the availability of hardware for their Diagnostic evaluation.

.page

.send toc.blank 1
.lm0
.hl1 PROGRAM INTERFACES
.lm4
.hl2 Diagnostic software interfaces

Not Applicable

.hl2 Operating system interfaces (TOPS-10)

Not Supported

.hl2 Operating system interfaces (TOPS-20)

The programming interface will be with the Monitor. Packets of information
will be sent and recieved using Monitor Calls that will be supported in TOPS-20 Release 6.1 and newer.

.page

.send toc.blank 1
.lm0
.hl1 COMMANDS
.lm4

The commands available to the user of the NI Services Program are:

.lit

	HELP

	ENABLE/DISABLE
|		Debug
		Spear-Reporting
		Output-Logging (to) <file-spec>
|		Trace


	IDENTIFY (node) <node-address>

|	DISPLAY-ADDRESS <of>
|		All
|		Local-node
|		Remote-nodes-on-network

|	READ-COUNTERS <node>

|	REDEFINE

|	CONNECT (port) <number>

|	CONNECT (node) <node-address>


	SHOW
|		All
|		Debug
|		Logging
|		Spear-reporting
|		Trace


	QUIT
|	EXIT

	Control-C
	Control-Y
|	Control-D
|	Control-B
.el

The HELP command will list information about the other commands and their options

The ENABLE command is used to enable or "turn-on" certain program features.

The DISABLE command is used to disable or "turn-off" certain program features.
.bb

The IDENTIFY command will cause the program to perform a REQUEST ID to the
address specified as part of the command and will print the SYS-ID information
obtained from that address.

The DISPLAY-ADDRESS command displays the address of the local node and/or all
the remote nodes on the network.

The READ-COUNTERS command will read the counters of the specified node.

The REDEFINE command will enable the user to change the exit character to exit
from the remote mode.

The CONNECT command actually connects the user's terminal to the PLUTO console
terminal to transfer characters back and forth between the two.
A "control-D" typed by the user will disconnect the user's terminal from this
mode and return the user's terminal to command mode.  A "control-B" typed on
the user's terminal will cause a BREAK to be sent to the the PLUTO.
.eb

 The SHOW command is used to display the current state of various options and control flags in use by the program.
.bb

The QUIT and EXIT commands will return the user to TOPS20 monitor level.  It will Deselect a selected NODE properly before returning to the monitor and close the logging file if it was in use.

A CONTROL-D typed while in the Remote Terminal mode will cause a disconnect
from the remote mode and put the user back to the command level.

Two CONTROL-C's typed while the program is in command or remote mode will
always put the user back to TOPS20 monitor level.
.eb

A CONTROL-Y typed while the program is in any mode will cause an immediate return to TOPS20 monitor level.  The monitor CONTINUE command will then resume operation from the interrupted point.

.page

.send toc.blank 1
.lm0
.hl1 FUNCTIONAL DESCRIPTION
.lm4

The PLUTO hardware does  not  include  a  physical  console  terminal.  Instead,  a  facility  has  been designed whereby a terminal on a host node can be connected logically to the console interface on the  PLUTO and hence act as its console.

The standard PLUTO Server software will not use  the  console  at  all,  but there  are occasions where this facility will be useful.  For example, diagnostics will use this facility extensively to communicate with the user  running the diagnostic - this enables diagnostics that currently exist to be used without  being  rewritten.   Also,  the  11/24  PLUTO processor  includes  micro-ODT, and so the remote console facility may be used to control or debug a failing node, much in the same way  that a standard 11/24 may be controlled via its own console terminal.

.hl2 Relationship To Other Components

.lit

  Terminal
     |
     |
     V
  +-----+  LLMOP%  +---------+   NI    +-------+  ASYNC  +-------+
  | NIS |<-------->| TOPS-20 |<------->| PLUTO |<------->| PLUTO |
  +-----+          +---------+  (MOP)  |  UNA  | Console | 11/24 |
     |                                 |  CCS  |         +-------+
     |            +----------+         +-------+
     +----------->| Volatile |
                  | Data     |     NIS = NI Services Program
                  | Base     |     CCS = Console Carrier Server
                  +----------+

.el

.page

.hl2 NI Services Program

The NI Services Program will communicate with the PLUTO console carrier server (CCS) which resides on a target node to provide remote access to normal PLUTO console services.  The NI Services Program will provide the user interface to communicate with the remote console.  This program communicates via the LLMOP% interface with the TOPS-20 monitor which in turn communicates with the PLUTO console carrier server on a target node.  It is a requirement that the user be a privileged user in order to invoke the NI Services Program and communicate with the PLUTO console carrier server.

There are two pieces of software that  implement  the  remote  console facility.  The NI Services Program on a TOPS20 host implements the Console Carrier protocol and transfers characters transmitted across the NI to and from a  physical terminal on the host.  The PLUTO UNA code that implements this facility is  known  as  the  Console Carrier  Server.

The PLUTO remote console is a resource, and  as  such  is  subject  to contention between multiple requesting hosts.  There is a mechanism to resolve conflicts in using the remote console, viz.  'reservation'  of the console.  The requestor has to 'reserve' the console before it may be used to transfer characters, and normally the requestor  'releases' the remote console when it is no longer required.

There is a timeout associated with reservation of the remote  console; the  requestor  must  communicate with the server often enough so that the reservation timer does not complete and  hence  cause  the  remote console  to  be  released  from  the  requestor.   The  value  of  the reservation timer is of the order of minutes;  its exact value will be determined  later.

Having reserved the PLUTO's remote console facility and confirmed that the  reservation was successful, the NI Services Program may now initiate communication to and from the PLUTO remote console.  Normally this  would  involve  communications  with  a  real  terminal,  taking characters typed by the user on the real terminal and passing them  to the  remote  console and taking characters from the remote console and displaying them on the users real terminal.

There is a requirement to provide an escape convention,  so  that  the terminal user may effect the following features:

.ls
.le;Exit from the REMOTE TERMINAL portion of the NI Services Program.
.le;Emulate an input break condition, as though the user had  hit the  break key on a local 11/24 console.  This will force the PLUTO processor into its micro-ODT, making available all  the features  that  micro-ODT  permits,  ie.   examining  memory, depositing memory, resetting the machine etc.
.le;Pass characters through that would otherwise  be  interpreted by the hosts terminal driver, for example _^C.
.els

As previously described, the requestor  program  should  ensure  that there  is  communications  with  the  server often enough to avoid the reservation timer in  the  server  expiring  and  forcing  the  remote console  back  in the unreserved state.  The Console Carrier protocol includes the ability to send 'null' messages so that communication can still occur  between a functioning requestor and the server without passing any data.

When the terminal user has  finished  with  the  remote  console,  the requestor should relinquish control.  The remote console facility is now available to other requestors.

.hl2 PLUTO Console Carrier Server

The PLUTO console carrier server is being supplied by the PLUTO server base.


.hl2 Console Carrier Protocol

The Console Carrier (CC) protocol is, as its name implies, a means  of transporting  ("carrying")  the  information  flow  between a computer console and that console's usually human user, in a situation in which the  user's  terminal is attached to a system other than the system of interest.  The information is typically streams of  ASCII  characters, though  that  is  not  a  requirement  of  the protocol.  The physical console serving as a paradigm for the model is not an  "old-fashioned" console  with a switch register, boot, continue, examine, address, and deposit switches, but rather an ASCII console.  Such a  console  is  a distinguished  terminal.   It  can  be  used  as a normal terminal I/O device until a particular sequence  of  characters  is  input  by  the human,   after  which  point  it  has  all  the  capabilities  of  the old-fashioned console.

The objects of interest in the protocol  are  a  requestor  module,  a server  module  (the objects which speak the protocol) and a requestor user process and server user process.  Typically the latter  two  will be  a  human  using  the remote console, and the target system's ASCII console, respectively.  The  requestor  and  server  protocol  modules occupy  levels  III through VI in the ISO model:  they make direct use of a data link layer (DDCMP  or  NI  Data  Link),  under  which  is  a physical  link  layer  (RS232-C  or  Ethernet Physical Link).  The end users make direct use of the CC Requestor and Server.

The Console Carrier protocol is a simple half-duplex  polled  protocol designed  to  provide  some  degree  of  end-to-end  (or user-to-user) communication without the overhead of  DECnet  logical  links.   These sections  will  discuss  the  operation  of  the  protocol in terms of message interchanges, the services the protocol affords, and what  the costs  are  for  supplying  those  services  in  such an "inexpensive" manner.  The description will be informal;  the protocol  is  formally defined in the DNA Low-level Maintenance Operations Spec.

.hl3  Message Flow Within The CC Protocol

The protocol is comprised of six different types of messages:  Request System  ID,  System  ID,  Reserve  Console,  Release  Console, Console Command and Poll,  and  Console  Response  and  Acknowledgement.   The procedure  which  a  Console Requestor must follow to reserve a remote console is:

.ls
.le;Ask the remote system for a System ID  message,  and  receive that message.
.le;Note that the remote system has a remote  console,  and  that the console is not reserved.  These two pieces of information are included in the system ID message.
.le;Assuming that the remote system has  an  unreserved  console, send that remote system a Reserve Console message.
.le;Again ask the remote system for a System ID message by  means of  a Request System ID message.  If the requestor system has been  successful  in  reserving  the  remote   console,   the requestor's  address  will appear as the console owner in the System ID message.
.els

If the remote system does not have a remote  console, it  may be possible to "put a console on the system". This is not part of the CC protocol, but is rather  a function   of   a   particular  implementation.   For instance, it will be seen later in  this  paper  that the  CC server for a Pluto implementation runs on the CPU aboard the Pluto's UNA, not on the  Pluto's  CPU. This  CC server can be down-line loaded into the UNA, at  which  time  the  remote  system  will  "have"  a console.

After reserving the remote console, the requestor must  maintain  that reservation  by  sending  Console  Commands and Polls at some interval less than the console's reservation  timer.   (The  magnitude  of  the timer is contained, again, within the System ID message.)

After the point at which the console  is  successfully  reserved,  the communication  consists  of  an  arbitrarily  long  series  of Console Commands   and   Polls,   answered   by    Console    Responses    and Acknowledgements.   Any  messages may have null data;  the protocol is concerned only with the correct state changes.  This dialog is  driven by  the  Requestor,  which  is  responsible  for  issuing commands and polling  for  responses  from   the   Server.    The   Server   cannot independently  return  a response.  Therefore, the Requestor must know when and how often it must poll a  response  in  order  to  prevent  a buffer  overrun  at  the Server.  The association of Requestor-defined command data to Server-returned response data  is  made  in  the  user layer above the CC protocol.  The communications path thus established between Requestor User and Server User will remain  intact  until  the console  is explicitly given up by the Requestor by means of a Release Console message, or until the interval between  Console  Commands  and Polls exceeds the Console Server-defined reservation timer.  The protocol state is reflected unchanged by the Console Server.   The burden   of  recognizing  an  unsynchronized  protocol  rests  on  the requestor.  To resynchronize the protocol, the requestor must release, then re-reserve the console.

.hl3  Characteristics And Uses Of The Protocol

A user process within  a  DECnet  network  (or  other  modern  layered protocol network) has available certain services which allow that user to  believe  that  there  exists  a  direct,  exclusive,  error   free communication  path  between  him/herself  and some physically distant analogous user process.  Of course, neither of  the  "users"  need  be human,  and  the  physical  distance  may  vary  by  several orders of magnitude, but in all cases, a model of two users "conversing" over an I/O  channel  (telephone  line,  "pipe")  is  a useful one.  Such user processes have the following expectations of an end-to-end protocol:

.ls
.le;That the pipe will hide the  imperfections  of  the  physical medium;  that is, they expect the path to be error-free.
.le;That everything entering at one end will come out  the  other in  the same order;  that is, they expect guaranteed delivery and sequentiality.
.le;That no other user's traffic will be interjected  into  their data  stream,  and  that  the  data  that  they input will be delivered only to the partner process.
.le;The  initiating  process  expects  that,  if   an   attempted connection succeeds, that connection will be made only to the object  with  which  it   is   specifically   interested   in communicating.
.le;Both processes expect a degree of flow control sufficient  to protect  themselves  and  the  network from congestion and/or overrun.
.els

The CC protocol addresses all of these problems except  the  first  by the  expedient  of  ignoring  them:  it is entirely the concern of the user processes to see that they get done.  The first,  the  error-free path, is assumed to be supplied by the data link layer protocol.

Delivery is not guaranteed:  if a requestor doesn't poll the server as fast  as  the  server generates responses, response data will be lost.  If the requestor generates commands faster  than  the  server  or  the server user process is able to process them, commands will be lost, or the association of response to command will become skewed.

Access to the PLUTO Console Carrier Server is controlled by  requiring  that the  value  of  the  "verification" field in a Reserve Console message match the verification field which is stored  in  the  PLUTO UNA.   How  the verification  field  value  in  the PLUTO UNA gets set is yet to be defined.  Access to the CC requestor module is neither specified nor  controlled by   the   protocol.    (However,  CC  requestors  will  typically  be implemented on larger, more controlled systems.)

Because the protocol assumes no  layers  between  itself  and  a  user layer, and because it demands no particular proof of identity from its users, the server user process is that process  which  happens  to  be interested  in  being  the  server user.  Control of the access to the console by a requestor user is within the protocol:  a requestor sends the console server a request to reserve the console, and then asks the console to send a  system  ID.   If  the  requestor  has  successfully reserved  the  console, the requestor's own address will appear in the ID message as the console user.  A requestor may explicitly release  a reserved  console.  In addition, a reservation timer, the magnitude of which is indicated in the system ID message, determines how  long  the requestor  may  remain idle (not sending commands or polling for data) before its ownership will be rescinded.  (The magnitude of this  timer is  not  yet  defined;   it is thought to be of the order of minutes.) This  value  will  be  hard-coded  into  the  Console  Carrier  Server microcode.

Flow control is very rudimentary:  only one message may be outstanding at  any  one  time;   to return response data requires a command/poll.  Lost response data is reported by the CC server.  The  protocol  state is  kept  as  a  one-bit  sequence number.  The first command from the requestor has a sequence number of one.  The  protocol  state  of  the requestor  may  be  thought  of  as  the message number of the current command/poll that it is  currently  attempting  to  get  across.   The protocol state of the server may be thoght of as the message number of the last correctly received command/poll.  A change in  state  implies an ACK, and is accompanied by (possibly null) command data or response data.  Command/polls with no state changes and no data are used by the Console  Requestor  to  NAK Console Responses.  The Console Server has the ability to indicate that it has dropped (or lost, or scrambled)  a Console Command, and the ability to piggyback Console Response data on that  NAK.   Such  a  response  might   be   better   called   a   WAK (wait/acknowledgement),  with  the  semantic  meaning:  "I've received your command, but no action will be taken on  it.   Please  retransmit the command, and, incidently, here is some response data."

All of this should be taken to mean that this  protocol  assumes  that the  requestor  user  process has the intelligence of a human, that in fact the requestor user process is a human.  Although  the  preceeding traits  seem  to describe a terrible protocol, they are, in fact, very much the same traits  exhibited  by  a  real  ASCII  console  terminal connected  to  a computer system in which one may be interested.  That terminal may be attached by some process of no interest, it may be too slow  to  output  the  information  from  the process without dropping characters, it  may  be  typing  out  the  uncoordinated  interspersed outputs  of  several  processes,  it  may  be  a  terminal on a "dead" machine, etc.  In such a case, the human user would either  make  some sense  of  the  scrambled  mess presented to him/her, or would put the terminal into console mode and reboot the system,  perhaps  using  the console  emulator  to  try  to  figure  the system's state first.  (Of course, it will frequently be the case that the terminal  will  afford the user exactly the desired capabilities.)

.hl2 Remote Console Reservation

The user must specify the target node with which the user wishes to communicate.  The required input to the NI Services Program will be a node id (ie. either node name or node address).  The other parameters are optional.  If not specified in the command line, they must be specified in the Ni Services data base.  If specified in the command line, they override the parameters set in the NI Services data base.  The syntax for the command line input is:

.lit

|	RMTCON> CONNECT port-id

|	RMTCON> CONNECT node-id

.el

If the connection is established with the specified node, the following message will be displayed on the user's terminal:


.lit
|	To Disconnect & return to command mode, type a single control-D
.el

.bb
Typing one or several carrage returns will then result in the following prompt
to be displayed on the user's terminal:
.eb

.lit
|	Local>
.el

The user can now begin communications as a remote terminal.

In order for the NI Services Program to communicate with a remote node, the SERVICE CIRCUIT, HARDWARE ADDRESS, and SERVICE PASSWORD must be specified in either the command line or the volatile data base.  The names of the files containing the special secondary loader and the micro-code will be hardwired into the program image.

.hl3 Reservation States

The PLUTO console carrier server may be in one of three states when the user wishes to reserve the console:

.ls
.le;The PLUTO console carrier server is loaded and unreserved.
.le;The PLUTO console carrier server is loaded and reserved.
.le;The PLUTO console carrier server is not loaded.
.els

If the PLUTO console carrier server is loaded and unreserved, the NI Services Program will reserve it.  At this point, the user will enter commands as if he were physically located at a console.  The commands will be transmitted by the requestor to the server.  The appropriate response will be transmitted by the server to the requestor.  The requestor will display this information to the user.  If the PLUTO console carrier server is loaded and reserved, an error message will be displayed to the user on the issuing terminal.

If the PLUTO console carrier server is not loaded, the requestor will load the server.  It may be necessary for the requestor to identify the target node via the 48-bit hardware address if the target node is not known to the network.  Once the server is loaded, the requestor will attempt to reserve the console and proceed as above.

.hl3 Reservation Details

The PLUTO UNA code that  implements  the  Console  Carrier  protocol may or may not be resident in the PLUTO UNA.  Thus the requestor must check whether the Console Carrier code is present in the PLUTO UNA and if  necessary  load the appropriate server code into the PLUTO UNA via the NI.

The  target  PLUTO  may  be responding to one of two 48bit NI addresses, depending on the state of the PLUTO UNA.  Thus the requestor should attempt to communicate  with  both the  PLUTO 48bit hardware UNA address and the PLUTO 48bit Phase IV UNA address and use whichever one that responds in subsequent messages.  

In its initial state, the PLUTO UNA will respond to its 48bit hardware UNA address.  When the PLUTO Server software initializes the UNA for a phase IV node, it changes the UNA address to be a Phase IV 48bit address.  The Phase IV 48bit address is formed by appending the 16bit Phase IV node number to a fixed 32bit value.

The following sections describe the  different  situations  which  may occur  when  the  requestor  tries  to  connect  to the remote console facility.  The requestor sends the  initial  request,  to  both  48bit addresses if necessary, as follows:

.lit

	REQUEST ID :
		CODE = 15
		RECEIPT NUMBER = requestors identification

.el

 We will now see the  possible  responses  to  this  request,  and  the actions that may be taken by the requestor in each case.

.hl3  Console Carrier exists - but console in use

In this case, the Console Carrier code has been loaded  into  the  PLUTO UNA previously,  but at the moment, another host has reserved the console, so that it is unavailable to us.

The format of the reply is:

.lit

	SYSTEM ID :
		CODE = 7
		RECEIPT NUMBER = matches value sent in REQUEST ID
		OTHER INFO :
			MAINTENANCE VERSION = 3.0.0	
			FUNCTIONS = at least console carrier
			CONSOLE USER = non-zero 48bit Phase IV address
					which does not match our address
			RESERVATION TIMER =	(value to be determined)
			CONSOLE COMMAND SIZE =	(value to be determined)
			CONSOLE RESPONSE SIZE =	(value to be determined)
			HARDWARE ADDRESS = 48bit hardware UNA address
			DEVICE = 1		(ie. UNA)

.el

In this case, console carrier is known to be present as  the  'console carrier' bit is set in the FUNCTIONS field - other bits will be set in this field depending on the current state of the PLUTO UNA.  The console  is reserved  by  some user as CONSOLE USER is non zero.  However the host is not the current user of the remote console feature as the value  of this field does not match the hosts 48bit Phase IV address.

In this case, the host is unable to reserve the  console.   There  are two  options  at  this  point:   either wait a while and try again, or return an error message to the user  who  is  requesting  the  console service for the PLUTO.

.hl3  Console Carrier exists - Console not reserved

In this case, the Console Carrier code has been previously loaded into the  PLUTO UNA, but at the moment there is no requestor who has reserved the console.

The reply looks like:

.lit

	SYSTEM ID :
		CODE = 7
		RECEIPT NUMBER = matches value sent in REQUEST ID
		OTHER INFO :
			MAINTENANCE VERSION = 3.0.0	
			FUNCTIONS = at least console carrier
			CONSOLE USER = 0	(ie. not reserved)
			RESERVATION TIMER =	(value to be determined)
			CONSOLE COMMAND SIZE =	(value to be determined)
			CONSOLE RESPONSE SIZE =	(value to be determined)
			HARDWARE ADDRESS = 48bit hardware UNA address
			DEVICE = 1		(ie. UNA)

.el

Here we see that the Console Carrier code is running, as  the  console carrier  bit is set in the FUNCTIONS byte.  However, CONSOLE USER is 0 meaning that there is no current host that has reserved the console.

We may now attempt to reserve the console, as follows:

.lit

	RESERVE CONSOLE :
		CODE = 13

.el

This will attempt to reserve the remote console for our exclusive use. However  it  is  possible  that  another user is trying to reserve the console, and managed to do so before we were able to.  There is also a possibility  that  the  Console  Carrier in the PLUTO UNA has been disabled before we were able to reserve the console.  Thus we need  to check   whether   we   did   indeed  manage  to  reserve  the  console successfully.

We now issue another REQUEST ID message, and depending on  the  reply, we  will  find  that  we  own the console, or that some other host has reserved the console before us, or that Console Carrier is  no  longer operational in the PLUTO, and will therefore have to be reloaded.  

.hl3  Console Carrier exists - we own the console

Assuming that we have tried to reserve the console, as in the previous case,  then  we  would  normally  expect  this reply when we issue the second REQUEST ID.  In this case,  we  have  managed  to  successfully reserve  the  PLUTO console carrier server and may proceed to use the remote console feature.

It is also possible that due to some error, the  console  believes  we own  it,  but we were not aware that we own it.  This case is an error as there can only be one user of the Console Carrier request code  for a given PLUTO at any time.  In this case, the requestor should issue a warning message, then  release  the  console  via  a  RELEASE  CONSOLE message  and  then  attempt to reserve the console again via a RESERVE CONSOLE message.

The format of the reply is:

.lit

	SYSTEM ID :
		CODE = 7
		RECEIPT NUMBER = matches value sent in REQUEST ID
		OTHER INFO :
			MAINTENANCE VERSION = 3.0.0	
			FUNCTIONS = at least console carrier
			CONSOLE USER = non-zero 48bit Phase IV address
					which matches our address
			RESERVATION TIMER =	(value to be determined)
			CONSOLE COMMAND SIZE =	(value to be determined)
			CONSOLE RESPONSE SIZE =	(value to be determined)
			HARDWARE ADDRESS = 48bit hardware UNA address
			DEVICE = 1		(ie. UNA)

.el

The console carrier code is present, as determined by the bit  set  in the FUNCTIONS field, and we are designated as the console requestor as the CONSOLE USER is set to be our 48bit Phase IV address.  We may  now use  the  console  carrier  server  and  communicate  between the host terminal and the DL on the PLUTO.

.hl3  Console Carrier code does not exist

Either there has never been  any console carrier code operating in the PLUTO, or else it had previously been loaded but has since been disabled.

The reply in this case looks like:

.lit

	SYSTEM ID :
		CODE = 7
		RECEIPT NUMBER = matches value sent in REQUEST ID
		OTHER INFO :
			MAINTENANCE VERSION = 3.0.0
			FUNCTIONS = does not include console carrier
			HARDWARE ADDRESS = 48bit UNA hardware address
			DEVICE = 1		(ie. UNA)


.el

In this case, the FUNCTIONS field does not include the console carrier bit, so there is no running PLUTO Console Carrier server on the PLUTO's UNA.  Therefore we must load the console carrier code into the UNA.  This is accomplished by sending a BOOT message to the PLUTO indicating that we wish to load the communications processor, ie.  the UNA,  rather  than the PLUTO itself.

The message format is:

.lit

	BOOT :
		CODE = 6
		VERIFICATION = 8 bytes of password
		PROCESSOR = 1		(ie. communications processor)
		CONTROL :
			BOOT SERVER = 1		(ie. requesting system)
			BOOT DEVICE = 0		(ie. system default)
		DEVICE ID = 0		(ie. irrelevant)
		SOFTWARE ID = -1	(ie. system image)

.el

As in the case of loading a PLUTO from a host, the password field  may be  set up in the PLUTO UNA as 8 octets of zero, or it may be non-zero.  The requestor should attempt this message twice if  necessary,  once  with the  normal  password, and once with the VERIFICATION field consisting of 8 octets of zeros.  Only one of these requests  will  be  responded to.   Note  that  the  SOFTWARE  ID is always -1;  "diagnostic" is not supported when trying to boot the communications processor  (ie.   the UNA).

The reply to the BOOT message will be a REQUEST PROGRAM,  which  is  a request for the host to load the appropriate secondary loader into the PLUTO UNA.  The format of the request is as follows:

.lit

	REQUEST PROGRAM :
		CODE = 8
		DEVICE TYPE = 1		(ie. UNA)
		FORMAT VERSION = 1
		PROGRAM TYPE = 0	(ie. secondary loader)
		SOFTWARE ID = -1	(ie. system image)
		OTHER INFO :
			MAINTENANCE VERSION = 3.0.0
			FUNCTIONS = dependant on current UNA state
			...	    the rest of this section depends on
				    the current UNA state

.el

The secondary loader that the host responds with is not  the  same  as would  be sent for a load of the complete node.  This secondary loader is a loader which will load an image into the PLUTO UNA WCS rather than  the PLUTO memory.  The secondary loader is contained in a file PLUTOWL.SYS on the PLUTO directory.

The host sends the secondary loader in a single message as follows:

.lit
	
	MEMORY LOAD WITH TRANSFER ADDRESS :
		CODE = 0
		LOAD NUMBER = 0
		LOAD ADDRESS = 		(value to be determined)
		IMAGE DATA = data from PLUTOWL.SYS
		TRANSFER ADDRESS = 	(value to be determined)

.el

The PLUTO WCS secondary loader now runs and requests  the PLUTO  WCS  code  to  be loaded,  ie.   the  console  carrier  server  code.  The message is as follows:

.lit

	REQUEST PROGRAM :
		CODE = 8
		DEVICE TYPE = 1		(ie. UNA)
		FORMAT VERSION = 1
		PROGRAM TYPE = 2	(ie. system)
		SOFTWARE ID = -1	(ie. loading standard software)
		OTHER INFO :
			MAINTENANCE VERSION = 3.0.0
			FUNCTIONS = dependant on current UNA state
			...	    the rest of this section depends on
				    the current state of the UNA

.el

The host will now load down the PLUTO console carrier server code  into  the PLUTO UNA  WCS.  This is a multiblock load.  The PLUTO console carrier server code is in the file PLUTOCC.SYS on the PLUTO directory.

The host sends the following message:

.lit

	MEMORY LOAD :
		CODE = 2
		LOAD NUMBER = starts at zero
		LOAD ADDRESS = starting address to load this segment
		IMAGE DATA = data to be loaded into the UNA's WCS

.el

The exact method for determining LOAD ADDRESS and IMAGE DATA from  the file  PLUTOCC.SYS  will be determined later.  The PLUTO UNA secondary loader will reply with a message in the following form:

.lit

	REQUEST MEMORY LOAD :
		CODE = 10
		LOAD NUMBER = number of next segment to load
		ERROR = 0, if the last segment received correctly
			1, if the last segment received was in error

.el 

The sequence of MEMORY LOAD and REQUEST MEMORY  LOAD  is  repeated  as often as necessary to complete the load of the PLUTO console carrier server. The load is terminated with a message of the form:

.lit

	PARAMETER LOAD WITH TRANSFER ADDRESS :
		CODE = 20
		LOAD NUMBER = matches the last REQUEST MEMORY LOAD value
		PARAMETERS :
			0		(ie. no parameters)
		TRANSFER ADDRESS = starting address of Console Carrier server

.el

The actual value for TRANSFER ADDRESS will be determined later.

At this stage the PLUTO console carrier server is loaded and running in  the PLUTO UNA  WCS.   The  host  should  now  issue a RESERVE CONSOLE request to attempt to get exclusive access to the remote console  facility.   The format of the message is as follows:

.lit

	RESERVE CONSOLE :
		CODE = 13

.el 

The possible responses to the RESERVE CONSOLE message are explained in a previous section.

.hl2 Remote Console Operation

Once the remote console is reserved, a timer routine will be executed once per second.  The timer routine will transmit a console command and poll message to the server with any data which has been typed in by the user since the last transmit.  If any response data is received from the server, this data will be displayed on the user's terminal exactly as it was received from the server.  The reservation timer for the server must be specified in units of seconds.  Since the requestor is polling at one second intervals, there is no problem with satisfying the requirement that the server must be polled within the time specified by its reservation timer.

.page

.send toc.blank 1
.lm0
.hl1 ERROR REPORTING PHILOSOPHY
.lm4
.list "o"
.le;Report back to the user on functional errors.
.le;Hardware errors will be detected and logged by the Operating System.
.end list

.hl2 Reporting to SPEAR

The following information will be logged into the System Error Log for SPEAR use.
.lm4
.list "o"
.le;The current time when the remote console is reserved.
.le;The current time when the remote console is released.
.le;Port number/Node number.
.end list

.page

.send toc.blank 1
.lm0
.hl1 OPEN ISSUES

There must be some special character which will be used to specify a 'BREAK' command in order to get the attention of micro-odt.  [Control-B]

There must also be some special character to exit console carrier mode.  [Control-X]

These special characters should be agreed upon by all host implementations (VMS and TOPS).  At this point, there has not been any agreement on the details in these areas.

The manner in which circuits over the UNA are modelled in network management has not been defined as yet.  For DDCMP circuits, the owner is changed to the appropriate module (ex. LOOPER) and the state and sub-state of the circuit is set according to the operation (ex. on-looping).  There is currently no definition of the model of UNA circuits which specifies that this information will be kept or how this information will be passed to network management if it will be collected.

.send toc.blank 1
.lm0
.hl1 SCHEDULE

.lit

   Milestone		Target Date
   ---------		-----------

1. Functional Spec	6 May 83
   Complete

2. Design/Code		1 July 83
   Complete

3. Begin Debug		5 July 83

4. Complete Debug	15 July 83

5. Documentation	29 July 83
   Complete

6. Evaluation		5 Aug 83
   Complete

7. Completed		12 Aug 83

.el

.page

.send toc.blank 1
.lm0
.hl1 BIBLIOGRAPHY
.lm4
.list "o"

.le;Diagnostic Engineering Project Plan For Support of the Ethernet Port (KLNI) on KL10.
.BR
Frank Gatulis / January 13,1983

.le;NI Node Product Architecture Specification
.BR
	/ March 24,1982

.le;Digital Network Architecture - Low Level Maintenance Operations Architectural Specification
.BR
Bob Stewart, Ken Chapman / April 20,1982

.le;A PLUTO Implementation of a Console Carrier Server
.BR
Paul Weiss / March 3,1982
.end list

.page

.send toc.blank 1
.lm0
.hl1 GLOSSARY
.lm8
.list "o"
.le;CCR####Console Carrier Requestor, (the NI Services Program)
.le;CCS####Console Carrier Server
.le;FCS####First Customer Ship
.le;KLNI###KL10 NI Ethernet Adapter
.le;N/A####Not Applicable
.le;NI#####Network Interconnect (ETHERNET)
.le;PLUTO##Communications Controller
.le;RCS####Remote Console Service
.le;SCS####Systems Communications Services
.le;SPEAR##Standard Package for Error Analysis and Reporting
.le;TBD####To Be Determined
.le;UUT####Unit Under Test
.end list
.lm0

.send toc.blank 1
.lm0
.hl1 REVISION HISTORY
.lm8

Revision 0.1
.br
May 3, 1983
.BR
John R. Kirchoff
.BR
The first mailing of this document.

.page

.send toc.blank 1
.lm0
.hl1 ALGORITHMS

.hl2 NI Services Program algorithm

.lit

	MODULE NIS
	    Get node to connect to
	    Check for required parameters in data base
	    IF user is privileged THEN
		Open circuit
		IF NI circuit THEN
		    Set characteristics
		ENDIF
		CALL Reserve_console
		IF success then
		    Clear exit_flag
		    WHILE exit_flag not set DO
			CALL process_command
		    ENDWHILE
		    Call release_console
		ENDIF
		Close circuit
	    ELSE
		Display error messge
	    ENDIF
	EXIT

.el

.hl2 Normal Command Processing algorithm

.lit

	ROUTINE process_command
	    WHILE exit not set DO
		Complement message number
		IF timer expired or character received THEN
		    IF character received = exit character THEN
			Set exit
		    ELSE
			Transmit console command and poll message
			Display response if any
		    ENDIF
		ELSE
		    Wait
		ENDIF
.el

.page

.hl2 Reserve Remote Console algorithm

.lit

	ROUTINE reserve_console
	    Clear error
	    CALL transmit(request_id)[receive system id message]
	    IF CCS not loaded THEN
		CALL load_server
	    ELSEIF CCS reserved by other node THEN
		Display error message
		Set error
	    ELSEIF CCS reserved by local node THEN
		CALL release_console
	    ENDIF
	    IF no error THEN
		Retry = 0
		Clear fatal_error
		WHILE retry < 5 and not fatal_error and not success DO
		    IF no error THEN
			CALL transmit(reserve_console)
			CALL transmit(request_id)
			IF reservation not successful THEN
			    IF not loaded THEN
				CALL load_server
			    ELSE
				Set fatal_error
				Display error message
			    ENDIF
			ELSE
			    Get reservation timer from system id message
			    Message_number = 0
			    Set success
			ENDIF
	 	   ENDIF
		ENDWHILE
	    ENDIF
	RETURN

.el

.hl2 Release Remote Console algorithm

.lit

	ROUTINE release_console
	    CALL transmit(release_console)
	RETURN
.el

.page

.hl2 Load Server Code algorithm

.lit

	ROUTINE load
	    Transmit boot message - no service password
	    IF no reply THEN
		Transmit boot message - include service password
		IF no reply THEN Set fatal error
	    ENDIF
	    WHILE no fatal error DO
		Set secondary comm loader flag
		WHILE no error and more to load DO
		    Open image and check for proper format
		    IF improper format THEN
			Set file error
		    ELSE
			Get start address, length, and transfer address
			IF loading secondary comm loader THEN
			    Read entire image
			    Transmit memory load with transfer address
			ELSE
		 	    Call multi-block load
			    Set retry counter to 0
			    WHILE no error and request memory load
					   and req segment = load number DO
				Transmit memory load with transfer address
				IF no error and request memory load
					    and req segment = load number
					    and retry counter < 5 THEN
				    Increment retry counter
				ELSE
				    Increment load segment number
				ENDIF
			    ENDWHILE
		 	ENDIF
		    ENDIF
		    IF no error THEN
			Close file being loaded
			IF loading server image THEN
			    IF request memory and segment = load number THEN
				Indicate no more to load
			    ELSE
				Set line protocol error
			    ENDIF
			ELSE
			    IF request program received THEN
				Set file to load from Program Request
			    ELSE
				Set line protocol error
			    ENDIF
			ENDIF
		    ENDIF
		ENDWHILE
	    ENDWHILE
	RETURN
.el

.page

.hl2 Multi-block Load algorithm

.lit

	 ROUTINE multi-block_load
	    Set Load Segment number to 0
	    Set Requested Segment number to 0
	    WHILE no error and more to load DO
		Read a segment of memory from file
		Set retry count to 0
		WHILE no error and Requested Segment = Load Segment DO
		    Transmit Memory Load Message
		    IF no error THEN
			IF Request Memory Load received THEN
			    Set Requested Segment number from message
			    IF Requested Segment = Load Segment THEN
				IF Retry count less than 5 THEN
				    Increment retry count
				ELSE
				    Set Line Communication error
				ENDIF
			    ELSE
				IF Req Segment .ne. Load Segment+1 THEN
				    Set Line Protocol error
				ENDIF
			    ENDIF
			ELSE
			    Set Line Protocol error
			ENDIF
		    ENDIF
		ENDWHILE
	    Increment Load Segment number
	    ENDWHILE
	RETURN
.el