Trailing-Edge
-
PDP-10 Archives
-
QT020_T20_4.1_6.1_SWSKIT_851021
-
swskit-documentation/lat-info.memos
There are no other files named lat-info.memos in the archive.
MEMOS IN THIS FILE INCLUDE:
o Software design specification for LAT terminal host
o Software product specification for LAT host software
o DNA-approved LAT architecture specification
o LAT service class 2 architecture specification
--------------------------
LAT20-HOST-DESIGN.MEM
Date: 7 February 1984
%%% {{ 13:12:51 }} %%%
Preliminary
Component Software Product
DESIGN SPECIFICATION
for the
LAT Terminal Host for TOPS-20
...........................
Written By: P. J. Weisbach
........................................
Issued By: P. J. Weisbach
........................................
Reviewed By: (Development Review Team)
........................................
LAT Terminal Host for TOPS-20
Component Software Product
DESIGN SPECIFICATION
Contents
---------------
1.0 INTRODUCTION . . . . . . . . . . . . . . . . . . . . 3
2.0 PROJECT CONVENTIONS . . . . . . . . . . . . . . . . 4
2.1 IMPLEMENTATION LANGUAGE . . . . . . . . . . . . . 4
2.2 LABELS AND SYMBOLS . . . . . . . . . . . . . . . . 4
2.3 SUBPROGRAM INTERFACES AND CALLING SEQUENCES . . . 4
2.4 DATA FORMATS AND REPRESENTATIONS . . . . . . . . . 4
2.5 DEFAULT CONDITION HANDLING PHILOSOPHY . . . . . . 4
2.6 ERROR AND EXCEPTION REPORTING . . . . . . . . . . 4
2.7 TREATMENT OF UNUSUAL CONDITIONS . . . . . . . . . 4
3.0 DESIGN OVERVIEW . . . . . . . . . . . . . . . . . . 5
3.1 Host Multicast Messages . . . . . . . . . . . . . 5
3.2 LAT Virtual Circuits . . . . . . . . . . . . . . . 5
3.3 LAT Slot Sessions . . . . . . . . . . . . . . . . 6
4.0 TABLES, QUEUES, AND BUFFERS . . . . . . . . . . . . 8
4.1 Literals . . . . . . . . . . . . . . . . . . . . . 8
4.2 TDB Addition For LAT . . . . . . . . . . . . . . . 8
4.3 HOST NODE Data Base . . . . . . . . . . . . . . . 9
4.4 Virtual Circuit Message Header . . . . . . . . . 10
4.5 Circuit Data Base . . . . . . . . . . . . . . . 11
4.6 Slot Data Base . . . . . . . . . . . . . . . . . 13
4.7 CIRCUIT BLOCK AGE QUEUE . . . . . . . . . . . . 14
5.0 OVERVIEW OF MAJOR MODULES . . . . . . . . . . . . 15
5.1 Initialization . . . . . . . . . . . . . . . . . 15
5.2 Multicast Transmitter . . . . . . . . . . . . . 15
5.3 Virtual Circuit Message Receiver . . . . . . . . 16
5.3.1 Assigning A Circuit Block . . . . . . . . . . 16
5.3.2 Message Processing . . . . . . . . . . . . . . 16
5.4 Slot Demultiplexor . . . . . . . . . . . . . . . 17
5.5 LAT Device Dependent Routines . . . . . . . . . 18
LAT Terminal Host for TOPS-20
5.6 Slot Multiplexor . . . . . . . . . . . . . . . . 18
5.7 Virtual Circuit Message Transmitter . . . . . . 20
6.0 KEY ALGORITHMS . . . . . . . . . . . . . . . . . . 21
6.1 Assigning A CIRCUIT BLOCK For Incoming Messages 21
6.2 Message Validity Check . . . . . . . . . . . . . 23
6.3 Message Receiver . . . . . . . . . . . . . . . 25
6.4 Slot Demultiplexor . . . . . . . . . . . . . . . 28
6.5 SLOT MULTIPLEXER . . . . . . . . . . . . . . . . 30
7.0 MAINTENANCE AND DIAGNOSTIC TOOLS AND PROCEDURES . 32
8.0 SYSTEM TEST DESCRIPTION . . . . . . . . . . . . . 33
APPENDIX A MESSAGE FORMATS
A.1 MULTICAST DATAGRAM . . . . . . . . . . . . . . . . 35
A.2 START MESSAGE . . . . . . . . . . . . . . . . . . 39
A.3 STOP MESSAGE . . . . . . . . . . . . . . . . . . . 42
A.4 RUN MESSAGE . . . . . . . . . . . . . . . . . . . 44
APPENDIX B SLOT FORMATS
B.1 START SLOT . . . . . . . . . . . . . . . . . . . . 46
B.2 DATA_A SLOT . . . . . . . . . . . . . . . . . . . 48
B.3 DATA_B SLOT . . . . . . . . . . . . . . . . . . . 49
B.4 ATTENTION SLOT . . . . . . . . . . . . . . . . . . 51
B.5 REJECT SLOT . . . . . . . . . . . . . . . . . . . 52
B.6 STOP SLOT . . . . . . . . . . . . . . . . . . . . 53
APPENDIX Z OUTSTANDING ISSUES
LAT Terminal Host for TOPS-20 Page 1
PREFACE
---------
This is a Component Software Product Design Specification, and is the
definitive description, in specific terms, of the internal
characteristics of the LAT Terminal Host for TOPS-20. This
Specification is the commitment of how the product is to be built, as
agreed by the Engineering Project Team.
No changes are to be made to the design or implementation of the
product as described here, unless approved and documented as an
amendment to this Specification.
Associated Documents:
1. The System Specification, which describes the total system of
which this Software Product is a component.
2. The Component Software Product Specification, which describes
the goals, capabilities, and external characteristics of the
product.
3. The Product Requirements, to which the Component Software
Product Specification is Software Engineering's response.
4. The Component Software Product Development Plan, which
describes the development project to design, build, test,
evaluate, and deliver this product.
5. Local Area Transport Architecture Specification, December
1983.
Change History:
DATE CHANGE NUMBER DESCRIPTION / SUMMARY OF CHANGES
dd-mmm-yy [n] {Description of this change}
LAT Terminal Host for TOPS-20 Page 2
GLOSSARY
LAT Terminal Host for TOPS-20 Page 3
1.0 INTRODUCTION
Local Area Transport (LAT) is a protocol which runs on an Ethernet
directly over the NI Data Link. It does not require or use DECnet.
Although it may be used for various network services, LAT has been
optimally designed for interactive terminal operation between a LAT
server and a LAT host, both on the same NI.
The interactive terminal service of LAT permits terminal users at a
LAT Server to conduct terminal sessions with LAT hosts connected to
the NI. This product is an implementation of the LAT host on TOPS-20.
The major components of this product are the LCP program, the LATOPR%
JSYS, and the LATSRV monitor module. The LCP program provides a
command interface so that a system manager can control the operation
of LAT at his node. The LATOP% JSYS provides LCP's interface to the
LAT databases which are maintained by LATSRV. LATSRV controls the LAT
protocol and interfaces to TTYSRV and NISRV.
2.0 PROJECT CONVENTIONS
2.1 IMPLEMENTATION LANGUAGE
All components of this product will be coded using MACRO-20.
2.2 LABELS AND SYMBOLS
Global names will always be prefixed with the letters LA followed by
up to 4 letters providing some meaningful identification to the label.
2.3 SUBPROGRAM INTERFACES AND CALLING SEQUENCES
Routine interfaces will follow the conventions provided in the TOPS20
Coding Standards and Conventions document.
2.4 DATA FORMATS AND REPRESENTATIONS
The BEGSTR macro will be used to define all database parameters.
2.5 DEFAULT CONDITION HANDLING PHILOSOPHY
LAT-20 is designed so that all parameters not provided by the user
default to a value which assures reasonable operation. The only
required parameter without which operation as a LAT host is impossible
is the LAT node name. All other parameters default to a value which
LAT Terminal Host for TOPS-20 Page 4
permits terminal users to access the host as soon as the system has
successfully completed system initialization.
2.6 ERROR AND EXCEPTION REPORTING
Errors encountered in processing an LCP command are reported
immediately with an appropriate error message. Errors encountered
while executing a LATOP% JSYS function cause an illegal instruction
trap. Details of error codes in both cases can be found in the
Component Software Product Specification.
2.7 TREATMENT OF UNUSUAL CONDITIONS
The receipt of illegal protocol messages causes the LAT virtual
circuit to be terminated and a BUGINF to be issued.
LAT Terminal Host for TOPS-20 Page 5
3.0 DESIGN OVERVIEW
This section describes the operation of the LAT protocol between LAT
server and host. The formats of messages and slots to which reference
is made can be found in Appendix A and Appendix B.
3.1 Host Multicast Messages
A host which supports the LAT host services advertises this to all LAT
terminal servers by periodically broadcasting an Ethernet multicast
datagram. The multicast message format is shown in Section A.1. Each
service offered by a host has a name which is transmitted in a service
name block of the multicast message.
Each LAT server maintains a list of services of those hosts from which
it has recently received a multicast datagram and deletes services
from the list of hosts which have not been heard from for some time.
Terminal users at the server may display the list of available
services and request the server to make a connection to a host
offering a specific service.
3.2 LAT Virtual Circuits
The logical association between a LAT terminal server and a LAT host
is called a virtual circuit. One circuit exists for a given
server/host pair. All terminal users at a server connected to the
same host will utilize the same virtual circuit.
When a user instructs the server to connect to a particular service,
the server determines the identity of the host offering the service.
It can happen that several hosts have announced the same service. The
server selects that host which provided the highest service rating for
that service and establishes a virtual circuit to that host if none
already exists. It does so by transmitting a START message (see Sec.
A.2) containing various server parameters to the host. The host may
accept or reject the connection based on the content of the start
message. The host accepts the connection by returning a START message
or rejects the connection with a STOP message. Following the START
message exchange, a virtual circuit exists between the server and the
host. All further information transfer is done in RUN messages (Sec.
A.4).
Characters and control data associated with a particular terminal are
parcelled into units call slots. The logical association between a
terminal at a server and the host is called a SLOT SESSION. Slots for
all terminals at a server which are conducting a terminal session at a
common host are multiplexed onto the same virutal circuit in the data
field of the RUN messages. RUN messages may contain zero or more
slots. A single terminal may have more than one slot in a single RUN
message.
LAT Terminal Host for TOPS-20 Page 6
All further interaction between host and server is timer based. The
server maintains a continuously running circuit timer whose period is
the order of 80 ms. Each time this timer expires, the server collects
all control and character data into a RUN message and transmits it to
the host. This message acknowledges all previously received RUN
messages from the host. If there is no data to be sent to the host
when the circuit timer expires, the server does not send the RUN
message.
Each time the host receives a RUN message from the server, it is
required to respond within a time short relative to the server's
circuit timer. Failure to do so will degrade the response time as
perceived by the terminal user. The host removes the terminal data
from the message and pass it to the host terminal driver. It then
builds and transmits a RUN message of its own which contains any
terminal character or control data destined for the server. The
host's RUN message acknowledges the message just received from the
server.
It can happen that the host and server exchange RUN messages in the
manner just described but that at the next expiration of the server's
circuit timer there is no terminal input data. In this case the
server does not transmit a RUN message and terminal output would
cease. To prevent this, the host is permitted to send one
"unsolicited" message. After sending the unsolicited message, the
host has two outstanding messages which have not be acknowledged by
the server. In order to force the server to acknowledge these, the
host sets a flag in the message called the REPLY REQUESTED FLAG (RRF).
When the server sees this flag set, it will send a RUN message at the
next tick of the circuit timer, whether there is terminal input data
or not. This acknowledges all the host's outstanding messages.
When the host transmits an unsolicited message, it starts its circuit
timer. If the timer expires before all messages have been acknoledged
by the server, it resets the timer and retransmits the unacknoledged
messages. This is repeated up to a maximum number of times after
which the host declares the server as no longer accessible. The
host's circuit timer has a period of the order of 1 second.
The server maintains a retransmit timer (approximate period is 1
second). It is started when the server send a RUN message to the
host. If it expires before the message is acknowledged, the server
retransmits the message. This repeats up to a maximum number of times
after which the server declares the host as inaccessible.
The server also maintains a polling timer called the keep-alive timer.
During periods of long inactivity of both the host and server, this
timer is used by the server to determine that the virtual circuit is
still intact. After the expiration of this timer, the server sends a
RUN message (which may have no slot data) at the next expiration of
the circuit timer.
LAT Terminal Host for TOPS-20 Page 7
3.3 LAT Slot Sessions
The logical association between a terminal at the LAT server and the
host is called a SLOT SESSION. A slot session exists for each
terminal user/host pair. All slot sessions associated with a given
host/server pair are multiplexed onto the same virtual circuit as
slots in the data field of RUN messages.
When a terminal user requests to be connected to a service, the server
establishes a virtual circuit, if necessary, as described above. It
then transmits a START SLOT to the host. The host may accept or
reject the slot session based on the content of the START slot. If
accepted, the host returns a START slot and the slot session is
established. If rejected, the host returns a REJECT slot.
Terminal input and output data is transferred between host and server
in DATA_A slots. DATA_B slots are used to transmit control
information. Terminal flow control is accomplished using a credit
scheme. The receiving station (host or server) controls transmission
from other stations by extending permissions or credits only when
there is sufficient receive buffer capacity available. These credits
are maintained on a per-terminal and bi-directional basis and are
transferred in slot headers. The initial credit quota is given in the
START slot when the slot session is established. Credit updates are
passed in the headers of DATA_A and DATA_B slots. For each terminal
session, a transmitting station keeps track of the number of credits
available by incrementing a credit count when recieving credits from
the receiving station and decrementing the count each time a DATA_A or
DATA_B slot is sent. Transmits are not permitted when the count goes
to zero.
LAT Terminal Host for TOPS-20 Page 8
4.0 TABLES, QUEUES, AND BUFFERS
4.1 Literals
LAFRSI ;FRAME_SIZE
MXSLSI ;MAX_SLOT_SIZE
MXSLTS ;MAX_SLOTS
MXSSRV ;NHOST_MAX_SERVERS
LALPV ;Low protocol version
LAHPV ;High protocol version
LACPV ;Current protocol version
LACPE ;Current protocol ECO
4.2 Terminal Data Block (TDB) Addition For LAT
The TDB is the TOPS-20 dynamic terminal database. One word is added
to the TDB to support LAT-20:
TTLATW==35 ; Pointer to LAT (slot) data base.
TTDDLN==36 ; New length of dynamic data.
LAT Terminal Host for TOPS-20 Page 9
4.3 HOST NODE Data Base
There is one host node database for each host node supported by the
local system. If the local node is acting as a Gateway for other
nodes in a CI cluster, there is 1 host node database for each CI node.
If the local node is not performing a Gateway function, there is only
one host node database. LAT-20 supports a single host node per system
only.
BEGSTR HN
WORD NAM,2 ;HOST_NAME - counted ASCII string representing the host
; node name.
WORD ID,^D13 ;HOST_IDENTIFICATION - counted ASCII string representing
; the identity of the host.
HWORD RLI ;HOST_RETRANSMIT_LIMIT - maximum number of times the host
; retransmit a message before declaring circuit down.
HWORD TIM ;HOST_CIRCUIT_TIMER - initial value in seconds for circuit
; timers.
HWORD MTI ;HOST_MULTICAST_TIMER_INITIAL_VALUE initial value
; for HOST_MULTICAST_TIMER in seconds.
HWORD MTR ;HOST_MULTICAST_TIMER - running value of the host
; multicast timer in long scheduler cycles.
HWORD NUM ;HOST_NUMBER
HWORD CFL ;HOST_CHANGE_FLAGS - copy of the multicast message change
; flags.
HWORD MXI ;HOST_MAX_CIRCUITS - the maximum of allocated circuit
; blocks permissible at any one time.
HWORD CIR ;HOST_CURRENT_CIRCUITS - number of circuit blocks currently
; allocated.
HWORD MCO ;HOST_MAX_CONNECTS - maximum number of simultaneously
; slots permissible at this host.
HWORD CON ;HOST_CURRENT_CONNECTS - current number of active slots.
HWORD PRG ;HOST_PROGRESS_TIMER
HWORD LAS ;LAT_ACCESS_STATE
WORD COU,3 ;HOST_ALL_SERVERS_COUNTS - the ALL_SERVERS counter set.
WORD HST ;HOST_CIRCUIT_STATE_TABLE - a pointer to the state table
; for processing LAT host events.
HWORD AHD ;HOST_NEWEST_ACTIVE_CB_INDEX - queue head for active CBs.
HWORD ATL ;HOST_OLDEST_ACTIVE_CB_INDEX - queue tail for active CBs.
HWORD HHD ;HOST_NEWEST_INACTIVE_CB_INDEX - inactive CB queue head.
HWORD HTL ;HOST_OLDEST_INCATIVE_CB_INDEX - inactive CB queue tail.
HWORD NXI ;HOST_NEXT_ASSIGNABLE_CID - next index into CB_ADR_VECTOR
; to assign when a new circuit is established.
WORD NIQ,2 ;HOST_NI_MSG_QUEUE - Queue header where Ethernet messages
; are queued at NI interrupt level.
WORD SCQ,2 ;HOST_SCHED_MSG_QUEUE - Queue header where Ethernet
; messages are queued at scheduler level.
WORD MCC ;Byte count for the multicast message.
WORD MCM,^D375 ;Copy of the multicast message.
ENDSTR
LAT Terminal Host for TOPS-20 Page 10
The hosts HOST_ACCESS_CODES are described by the following structure
BEGSTR AC ;ACCESS CODES
WORD LEN ;Access code string length in bytes
WORD COD,^D32;Storage for 256 bit bit-mask
ENDSTR
The format of the Service Block is shown below. There is one service
block each service provided by the host. A host must provided at
least one service if it is to function as a LAT host. If no services
have been defined by the LCP interface at the time LAT operations are
started, a default service is defined with the same name as the host
node name.
BEGSTR GB ;SERVICE BLOCK
WORD RAT ;Service Rating.
HWORD NC ;Count of bytes in service name.
HWORD LC ;Count of bytes in service location.
WORD NAM,4 ;Storage for up to 16 bytes of service name.
WORD HID,^D16 ;Storage for up to 64 bytes of service id.
ENDSTR
4.4 Virtual Circuit Message Header
The LAT virtual circuit message header is copied by the message
receiver into a buffer described by the following format:
BEGSTR MH
WORD TYP ;MSG$_TYPE - Message type of received message.
WORD SLO ;MSG$_NSLOTS - Number of slots in message.
WORD RID ;MSG$_SOURCE_CB_INDEX - Remote's circuit handle.
WORD LID ;MSG$_DESTINATION_CB_INDEX - Local circuit handle.
WORD RSS ;MSG$_RECEIVED_SEND_SEQ - Sequence number of received message.
WORD RAK ;MSG$_RECEIVED_LAST_ACKD - Last message ack'd by remote.
ENDSTR
LAT Terminal Host for TOPS-20 Page 11
4.5 Circuit Data Base
There is one circuit block for each virtual circuit to a server which
existed since the last system startup, up to a maximum of
HOST_MAX_CIRCUITS. After the maximum is reached, the oldest inactive
one is reused for new circuits. Reincarnations of a circuit to a
given server tend to use the same circuit block if it is still
existent.
BEGSTR CB ;CIRCUIT BLOCK
FIELD FLG,3 ;CB$_FLAGS - virtual circuit flags.
BIT RRF ;CB$_REPLY_REQUESTED_FLAG - set when an unsolicited
; message has been sent to the server which requires
; a reply.
BIT MRS ;CB$_MUST_REPLY_SOON - set to 1 when a message is
; received from the server to indicate that a reply
; is required.
BIT MRN ;CB$_MUST_REPLY_NOW - set to 1 in unbalanced mode to
; indicate that response to server cannot be delayed
; any longer.
HWORD SDC ;CB$_SLOT_DATA_COUNT - count of the number of slot
; blocks for this circuit which have data waiting
; to be tranmitted on this circuit.
WORD DNI,2 ;CB$_REMOTE_NI_ADDRESS - NI address of the remote
; server.
HWORD RID ;CB$_REMOTE_CB_INDEX - handle assigned by the remote
; node to identify the circuit.
WORD LID ;CB$_LOCAL_CB_INDEX - index into the list of circuit
; block address for this circuit block.
HWORD TSQ ;CB$_NEXT_SEND_SEQUENCE - sequence number of the next
; message to be transmitted over this circuit.
HWORD RSQ ;CB$_NEXT_RECV_SEQUENCE - expected sequence number of
; next message received over this circuit.
HWORD STA ;CB$_STATE - virtual circuit state
HWORD LRA ;CB$_LAST_ACK_FROM_REMOTE - sequence number of last
; message ack'd by remote node.
HWORD TIM ;CB$_CIRCUIT_TIMER - current value of circuit timer.
HWORD RTC ;CB$_RETRANSMIT_COUNT - number of times the current
; message has been retransmitted.
HWORD XMQ ;CB$_TRANSMIT_BUFFER - transmit buffer stored
; here while it is being message is built.
HWORD QUA ;CB$_CIRCUIT_QUALITY
WORD AKQ ;CB$_UNACK_QUEUE - queue header for unacknowledge
; transmit buffers
WORD FSQ ;CB$_SB_QUEUE - queue of slot blocks which are active
; on this virtual circuit.
WORD SM,^D12 ;CB$_START_MESSAGE_COPY - copy of the start message
; received from the remote when circuit was set up.
WORD COB,3 ;CB$_COUNTERS - counter block
WORD AGE ;Circuit block age queue header.
ENDSTR
LAT Terminal Host for TOPS-20 Page 12
The format of the CB$_START_MESSAGE_COPY field:
BEGSTR SM
HWORD FSI ;Frame size
HWORD MSS ;Maximum simultaneous slots for circuit
HWORD KAL ;Server keep-alive timer
HWORD CTI ;Circuit timer for remote
HWORD FN ;Facility Number
HWORD PTC ;Product type code
HWORD SNC ;Server name count
WORD SNM,4 ;Server name
WORD SLO,4 ;Server location
ENDSTR
The format of the CB$_COUNTERS field:
BEGSTR CC
HWORD MX ;Messages sent
HWORD MR ;Message received
HWORD IMR ;Illegal messages sent
HWORD REX ;Number of messages retransmitted
HWORD ISR ;Illegal slots received
HWORD OSQ ;Out-of-sequence messages received
ENDSTR
LAT Terminal Host for TOPS-20 Page 13
4.6 Slot Data Base
There is one slot block for each active slot session. Slot blocks are
created when a slot session is started and releases when the slot
session is terminated.
BEGSTR SB
FIELD FLG,3 ;SB$_FLAGS
BIT SDP ;SB$_SLOT_DATA_PRESENT - set whenever there is slot data
; to be sent the next time the slot multiplexer runs.
BIT FOU ;SB$_FLUSH_OUTPUT - set when TTYSRV wants to flush output
; for this slot in the server.
BIT ERC ;SB$_EXTEND_REMOTE_CREDITS - set when additional credits
; need to be extended to the remote session partner.
BIT FCC ;SB$_FLOW_CONTROL_CHANGE - set when TTYSRV wants to
; the characteristics of XON/XOFF processing in the
; server.
HWORD STA ;SB$_STATE - slot state.
HWORD TSI ;SB$_TRANSMIT_SLOT_ID - id of the next slot to transmit.
HWORD RID ;SB$_REMOTE_ID - id used by the remote session partner to
; to identify this slot.
HWORD LID ;SB$_LOCAL_ID - id used by the local host to identify
; this slot.
HWORD CRE ;SB$_ADDITIONAL_REMOTE_CREDITS - number of credits to
; extend to the session partner.
HWORD XCR ;SB$_TRANSMIT_CREDITS - number of still unused transmit
; credits which the remote session partner has extended
HWORD RCR ;SB$_RECEIVE_CREDITS - number of credits which has been
; extended to session partner which are still unused.
HWORD REA ;SB$_STOP_REASON_CODE - reason code for STOP or REJECT
; slots.
WORD TDB ;SB$_TDB_ADDRESS - address of the TDB for this slot.
WORD CBA ;SB$_CB_ADDRESS - CB address for this slot's underlying
; virtual circuit.
ENDSTR
LAT Terminal Host for TOPS-20 Page 14
5.0 OVERVIEW OF MAJOR MODULES
5.1 Initialization
LATINI is called at system initialization from MEXEC after DECnet-36,
if present, has been initialized. The following actions are take if
the default LAT_ACCESS_STATE is ON:
1. Format the default multicast message,
2. Open an NI portal and queue NHOST_MAX_SERVERS receive buffers
to NIDLL,
3. Start the multicast timer.
If the default LAT_ACCESS_STATE is OFF, only the first of these steps
is performed.
5.2 Multicast Transmitter
The Multicast Transmitter LATMCA transmits a LAT host multicast
message every HOST_MULTICAST_TIMER scheduler long cycles to the
Ethernet for all LAT servers to see. It first checks
HOST_CHANGE_FLAGS to determine if any if the dynamic parameters which
are transmitted in the message have changed since the last
transmission. These flags are set non-zero any time the LATOP% JSYS
changes any of the relevant dynamic parameters or if a service rating
has change dynamically.
If HOST_CHANGE_FLAGS is zero, nothing has changed and the copy of the
previous message is simply transmitted again. Otherwise a new copy of
the message is formatted and sent.
LAT Terminal Host for TOPS-20 Page 15
5.3 Virtual Circuit Message Receiver
The message receiver LAINTR is the DLL receive callback routine. It
receives LAT virtual circuit messages at NI interrupt level and queues
them to HOST_NI_MSG_QUEUE. All further processing is done at
scheduler level. LARSCH is called at the next short scheduler cycle.
It moves all messages from HOST_NI_MSG_QUEUE to HOST_SCHED_MSG_QUEUE
and completes the processing as described below.
Messages which are received with errors (UNSTA is returned non-zero
from the NIDLL) are discarded. The receive buffer is immediately
returned to the NIDLL through the routine REQUEUE_TO_NIDLL, which
performs the NU.RCV function.
If the UNDAD callback argument indicates that the received message was
transmitted to a multicast address, RECEIVE_MULTICAST is called. This
routine is dummy in a host-only implementation.
5.3.1 Assigning A Circuit Block
For each incoming message surviving the initial checks described
above, LARSCH attempts to assign a circuit block (CB) as described in
Section 6.1. Circuit blocks are not released after a server
disconnects from the host unless HOST_CURRENT_CIRCUITS is greater than
HOST_MAX_CIRCUITS (the latter may have been reduced by LCP).
Therefore since a CB may already exist for a server from a previous
connect, LARSCH first searches the CBs already allocated.
If no CB already exists and HOST_CURRENT_CIRCUITS is less than
HOST_MAX_CIRCUITS, a new CB is allocated. If however the number of
CBs is already at the maximum, the oldest CB in the HALTED state is
used.
If no circuit block is found which can be associated with a message, a
STOP MESSAGE is transmitted to the remote Ethernet address and
REQUEUE_TO_NIDLL is called to return the receive buffer to NIDLL.
For those messages which have an associated circuit block, an event is
generated as described in Section 6.2. LARSCH fetches the state table
address from the host node block (HOST_CIRCUIT_STATE_TABLE) and uses
this table to dispatch to the proper routine to complete processing of
the message.
5.3.2 Message Processing
Illegal messages are messages which in some way violate the LAT
virtual circuit protocol. If an illegal message is received, the
underlying virtual circuit is immediately terminated. An jobs
associated with the circuit are detached. The actions performed for
legal messages is described in Sec. 6.3.
LAT Terminal Host for TOPS-20 Page 16
5.4 Slot Demultiplexor
The Slot Demultiplexor LSDMUX is called during the scheduler short
cycle by LARSCH to process the slots in RUN messages which have been
queued by the message receiver. LSDMUX first obtains a transmit
buffer for the response message and queues it to
CB$_TRANSMIT_BUFFER_Q. It then loops through all slots in the
received RUN message, processing as described in Sec. 6.4.
If the attempt to obtain a transmit buffer fails, the received RUN
message is requeued to the head of the HOST_SCHED_MSG_QUEUE and the
slot demultiplexer and message receiver are exited for this cycle.
Slots which do not conform to the correct format are illegal and, when
received, cause the virtual circuit to be terminated. If there are
insufficient resources to support an additional slot session, a reject
slot is formatted in the buffer just obtained.
When a START slot is received, if all resource can be obtained, a job
is created by entering a ^C into the terminal's input stream. Data
slots contain terminal input data and flow control information. The
input characters are entered into the terminals input buffer. Each
time a data slot is received, SB$_RECEIVE_CREDITS is decremented by
one. This is the count of the number of transmit slots the remote
session partner still has available. When this goes to zero the
server can no longer send data. In this case the slot demultiplexer
will set flags to tell the multiplexer to attempt to extend these
credits if there is sufficient room in the terminal input buffers.
LAT Terminal Host for TOPS-20 Page 17
5.5 LAT Device Dependent Routines
Many functions in TTYSRV call device dependent routines for the
various terminal types defined in the monitor. For example, whenever
there is output for a terminal line, TTYSRV enters the characters into
the terminal's output buffers and calls the device dependent routine
to start the output to the specific terminal type. The LAT device
dependent routines which are called to send control or data characters
to the LAT server terminal call a routine LTTREQ to inform the slot
multiplexor that the terminal has slot data available.
LTTREQ obtains the slot block address from TTLATW of the TDB. From
the slot block, it determines the circuit block address. LTTREQ
always sets SB$_SLOT_DATA_PRESENT and increments CB$_SLOT_DATA_COUNT
so that the slot multiplexor can determine which circuits and slots
need to be processed. Some functions set an additional bit as
described below.
LTSTRO is the device dependent routine to start output on a LAT host
terminal line. Whenever there are output characters for a terminal
line, TTYSRV puts the characters into the terminal's output buffer and
calls LTSTRO to start output. LTSTRO calls LTTREQ as described above.
No additional bits are set.
LTCOBF is the device dependent routine to flush output for a terminal
line. LTCOBF calls LTTREQ which additionally sets SB$_FLUSH_OUTPUT .
When the slot multiplexor sees this bit, it creates an ATTENTION slot
to cause the LAT server to flush all output buffers for the terminal.
LTEXF is the device dependent routine to enable and disable XON and
XOFF recognition in the server. LTEXF calls LTTREQ which additionally
sets SB$_FLOW_CONTROL_CHANGE. When the slot multiplexor sees this
bit, it creates an DATA_B slot to cause the LAT server to enable or
disable processing of XON and XOFF.
LAT Terminal Host for TOPS-20 Page 18
5.6 Slot Multiplexor
The Slot Multiplexor LAMUX is called by LADMUX after all received
slots for all received RUN messages have been processed. It examines
all slots for all circuits in the RUNNING state which have control or
character data to send to the server. Section 6.5 defines the
procedure in detail.
For all virtual circuits in the RUNNING state, CB$_SLOT_DATA_COUNT is
used to determine if there are any slots which need attention. All
slots using a particular virtual circuit are linked to the circuit
block through the queue CB$_SB_QUEUE. Any slot which needs data sent
to the server has its SB$_SLOT_DATA_PRESENT flag set.
The CB$_MUST_REPLY_SOON is used to indicate that the host must reply
to a server RUN message before the server's circuit timer expires.
The flag is set by the Message Receiver when a RUN message is received
from the server. It is cleared when a RUN message is transmitted.
The host responds to the server's RUN message only if there is some
slot data waiting for the circuit. If there is none, it will wait one
short scheduler cycle. This will tend to reduce the number of RUN
messages containing no slots.
If the host has responded to the latest server RUN message, the
circuit is in balanced mode. For each scheduler cycle in which a
circuit is found to be balanced (CB$_MUST_REPLY_SOON = false), a
counter CB$_COUNT_SINCE_BALANCED is incremented. If after this
reaches a maximum as defined by MAX_BALANCE_COUNT there is slot data
waiting, the host will transmit an unsolicited RUN message.
LAT Terminal Host for TOPS-20 Page 19
5.7 Virtual Circuit Message Transmitter
The message transmitter is composed of three routines which are called
to transmit each of the three virtual circuit messages. After a
message is transmitted, it is queued to CB$UNACK_QUEUE until is has
been acknowledged by the server.
The routine to transmit a START message, LAXSTR, is called from the
message receiver when responding to an incoming START message. The
message is build from the host node data base.
LAXSTP, which builds and sends STOP messages, obtains the stop reason
code from the host node data base. It is called when the
LAT_ACCESS_STATE makes a transition to OFF.
LAXRUN sends the RUN messages built by the slot multiplexer.
LAT Terminal Host for TOPS-20 Page 20
6.0 KEY ALGORITHMS
6.1 Assigning A CIRCUIT BLOCK For Incoming Messages
This section describes the method to determine the circuit block
associated with an incoming virtual circuit message. The procedure is
executed by the message receiver LARSCH at scheduler level. The
result is one of:
success - the circuit block address CB is returned,
no-resources - there are no more available circuit blocks to
support an additional circuit,
non-existent-circuit - there is no existing circuit block associated
with the message and a new one has not been
created.
local INDEX;
case MSG$_TYPE of
[START]:
begin
INDEX = HOST_OLDEST_INACTIVE_CB;
while INDEX <> 0
do
begin
CB = CB_ADDRESS_VECTOR [INDEX];
if (MSG$_SOURCE_NI_ADDRESS = CB$_REMOTE_NI_ADDRESS) &
(MSG$_M-bit eql CB$_M-bit)
then
begin
REQUEUE_AS_NEWEST_ACTIVE_CB ();
return CB
end;
INDEX = CB$_NEXT_NEWER_CB_INDEX;
end
INDEX = HOST_OLDEST_ACTIVE_CB;
while INDEX <> 0
do
begin
CB = CB_ADDRESS_VECTOR [INDEX];
if (MSG$_SOURCE_NI_ADDRESS = CB$_REMOTE_NI_ADDRESS) &
(MSG$_M-bit eql CB$_M-bit)
then
return CB;
INDEX = CB$_NEXT_NEWER_CB_INDEX;
LAT Terminal Host for TOPS-20 Page 21
if HOST_CURRENT_CIRCUITS < HOST_MAX_CIRCUITS
then
begin
if (CB = ALLOCATE_NEW_CB ()) = fail then return no-resources
end
else
begin
INDEX = HOST_OLDEST_INACTIVE_CB_INDEX;
if INDEX = 0 then return no-resources;
CB = CB_ADDRESS_VECTOR [INDEX];
end;
REQUEUE_AS_NEWEST_ACTIVE_CB ();
CB$_REMOTE_NI_ADDRESS = MSG$_SOURCE_NI_ADDRESS
CB$_HOST_NODE_NAME = MSG$_HOST_NODE_NAME
CB$_M-bit = MSG$_M-bit
CB$_STATE = HALTED
if CB$_LOCAL_CB_INDEX <>0 then CB$_ADDRESS_VECTOR [CB$_LOCAL_CB_INDEX] = 0;
CB$_LOCAL_CB_INDEX = HOST_NEXT_ASSIGNABLE_CIX;
CB_ADDRESS_VECTOR [CB$_LOCAL_CB_INDEX] = CB;
until CB_ADDRESS_VECTOR [HOST_NEXT_ASSIGNABLE_CIX] = 0
do
begin
increment HOST_NEXT_ASSIGNABLE_CIX;
if HOST_NEXT_ASSIGNABLE_CIX > CB_ADDRESS_VECTOR_LENGTH
then HOST_NEXT_ASSIGNABLE_CIX = 1;
end
return CB;
end;
[otherwise]:
begin
CB = CB_ADDRESS_VECTOR [MSG$_DESTINATION_CB_INDEX]
if CB$_REMOTE_NI_ADDRESS = CB$_REMOTE_NI_ADDRESS then return CB
INDEX = 1
while INDEX <= HOST_MAX_CIRCUITS
do
begin
CB = CB_ADDRESS_VECTOR [INDEX];
if (MSG$_SOURCE_NI_ADDRESS = CB$_REMOTE_NI_ADDRESS) &
(MSG$_M-bit eql CB$_M-bit)
then return CB
INDEX = INDEX + 1
end
return EVENT = non-existent-circuit
end
LAT Terminal Host for TOPS-20 Page 22
6.2 Message Validity Check
This procedure determines the event to generate when a virtual circuit
message is received. It is executed by the message receiver. The
event generated is one of the following:
o START_MESSAGE_RCVD - a valid START message has been received.
o STOP_MESSAGE_RCVD - a valid STOP message has been received.
o RUN_MESSAGE_RCVD - a valid RUN message has been received.
o INV_START_MESSAGE_RCVD - an invalid START message has been
received.
o INV_STOP_MESSAGE_RCVD - an invalid STOP message has been
received.
o INV_RUN_MESSAGE_RCVD - an invalid RUN message has been
received.
o illegal-message - an illegal message has been received.
case MSG$_TYPE of
[START]:
begin
if (MSG$_DESTINATION_CB_INDEX = 0) |
(MSG$_M-bit = 1 & MSG$_SOURCE_CB_INDEX = 0) |
(MSG$_M-bit = 0 & MSG$_SOURCE_CB_INDEX >< 0
then return EVENT = illegal-message
if MSG$_DESTINATION_CB_INDEX = CB$_REMOTE_CIRCUIT_INDEX
then return EVENT = START_MESSAGE_RCVD
else return event = INVALID_START_MESSAGE_RCVD
end
[STOP]:
begin
if MSG$_DESTINATION_CB_INDEX = 0 then return EVENT = illegal-message
if MSG$_DESTINATION_CB_INDEX = CB$_REMOTE_CIRCUIT_INDEX
then return EVENT = STOP_MESSAGE_RCVD
else return EVENT = INV_STOP_MESSAGE_RCVD
end
[RUN]:
begin
if MSG$_DESTINATION_CB_INDEX = 0 |
MSG$_SOURCE_CB_INDEX = 0
then return EVENT = illegal-message
if MSG$_SOURCE_CB_INDEX <> CB$_REMOTE_CB_INDEX |
MSG$_DESTINATION_CB_INDEX <> CB$_REMOTE_CIRCUIT_INDEX
then return EVENT = INV_RUN_MESSAGE_RCVD
else return EVENT = RUN_MESSAGE_RCVD
end
[otherwise]:
return EVENT = illegal-message
LAT Terminal Host for TOPS-20 Page 23
6.3 Message Receiver
! Illegal messages are protocol violations. Terminate the virtual
! circuit regardless of the circuit state.
if EVENT = illegal-message
then
begin
until CB$_SB_QUEUE = empty
do
begin
DETACH_JOB ();
RELEASE_SLOT ();
end;
SEND_STOP_MESSAGE ();
CB$_STATE = HALTED;
REQUEUE_AS_OLDEST_CB ();
REQUEUE_BUFFER_TO_DLL ();
return;
end;
case CB$_STATE of
begin
[HALTED]:
case EVENT of
begin
[START_MESSAGE_RCVD]:
begin
!
! This is a normal attempt of a server to connect to the local host.
! Check to see if willing to accept a new virtual circuit. Host must
! support the server's protocol version and LAT must be turned ON.
!
if MSG$_CURRENT_PROTOCOL_VERSION < HOST_LOWEST_PROTOCOL_VERSION |
MSG$_CURRENT_PROTOCOL_VERSION > HOST_HIGHEST_PROTOCOL_VERSION |
HOST_LAT_SERVICE_STATE <> 'ON'
then SEND_STOP_MESSAGE ();
else
begin
INITIALIZE_HOST_CIRCUIT ();
SEND_START ();
CB$_STATE = STARTING;
end
REQUEUE_BUFFER_TO_DLL ();
end;
LAT Terminal Host for TOPS-20 Page 24
[INV_RUN_MESSAGE_RCVD,
INV_START_MESSAGE_RCVD,
RUN_MESSAGE_RCVD]:
!
! Host probably crashed and the server has not noticed yet.
! Tell the server to terminate the circuit.
!
begin
SEND_STOP ();
REQUEUE_BUFFER_TO_DLL ();
end;
[STOP_MESSAGE_RCVD,
INV_STOP_MESSAGE_RCVD]:
REQUEUE_BUFFER_TO_DLL ();
end;
[STARTING]:
case EVENT of
begin
[START_MESSAGE_RCVD,
INV_START_MESSAGE_RCVD]:
SEND_START_MESSAGE ();
[STOP_MESSAGE_RCVD]:
begin
CB$_STATE = HALTED;
REQUEUE_AS_OLDEST_CB ();
end;
[RUN_MESSAGE_RCVD]:
begin
CB$_LAST_ACK_FROM_REMOTE = MSG$_ACK_SEQUENCE_NUMBER;
if CB$_NEXT_RECV_SEQUENCE = MSG$_XMIT_SEQUENCE
then increment CB$_NEXT_RECV_SEQUENCE
else MSG$_N_SLOTS = 0; ! Out of sequence. Ignore slot data.
CB$_MUST_RESPOND_SOON = true;
CB$_STATE = RUNNING;
DEMULTIPLEX_SLOTS ();
REQUEUE_BUFFER_TO_DLL ();
end;
LAT Terminal Host for TOPS-20 Page 25
[RUNNING]:
case EVENT of
begin
[START_MESSAGE_RCVD,
INV_START_MESSAGE_RCVD]:
begin
until CB$_SB_QUEUE = empty
do
begin
DETACH_JOB ();
RELEASE_SLOT ();
end;
INITIALIZE_HOST_CIRCUIT ();
SEND_START ();
CB$_STATE = STARTING;
end;
[STOP_MESSAGE_RCVD]:
begin
until CB$_SB_QUEUE = empty
do
begin
DETACH_JOB ();
RELEASE_SLOT ();
end;
CB$_STATE = HALTED
REQUEUE_AS_OLDEST_CB ();
end;
[RUN_MESSAGE_RCVD]:
begin
CB$_LAST_ACK_FROM_REMOTE = MSG$_ACK_SEQUENCE_NUMBER;
if CB$_NEXT_RECV_SEQUENCE = MSG$_XMIT_SEQUENCE
then increment CB$_NEXT_RECV_SEQUENCE
else MSG$_N_SLOTS = 0; ! Out of sequence. Ignore slot data.
CB$_MUST_RESPOND_SOON = true;
DEMULTIPLEX_SLOTS ();
REQUEUE_BUFFER_TO_DLL ();
end;
end;
LAT Terminal Host for TOPS-20 Page 26
6.4 Slot Demultiplexor
local MESSAGE_SLOT_COUNT;
MESSAGE_SLOT_COUNT = MSG$_N_SLOTS;
while MESSAGE_SLOT_COUNT <>0
do
begin
case SLT$_SLOT_TYPE of
begin
[START]:
if SLT$_SOURCE_SLOT_ID = 0 |
SLT$_DESTINATION_SLOT_ID <> 0 |
SLT$_SERVICE_CLASS <> 1
then exitloop error = illegal-slot;
if (SB = GET_FREE_SLOT_BLOCK ()) = success &
GET_TERMINAL_DATA_BLOCK () = success
then
begin
INITIALIZE_SLOT_BLOCK ();
START_JOB ();
SB$_SLOT_DATA_PRESENT = true;
SB$_TRANSMIT_SLOT_ID = START_SLOT;
SB$_STATE = RUNNING;
CB$_SLOT_DATA_COUNT = CB$_SLOT_DATA_COUNT + 1;
end
else
begin
BUILD_REJECT_SLOT ();
CB$_SLOT_DATA_COUNT = CB$_SLOT_DATA_COUNT + 1;
end;
[DATA_A,DATA_B]:
begin
if SLT$_DESTINATION_SLOT_ID = 0 then exitloop error = illegal-slot;
SB = SLOT_ADDRESS_VECTOR [SLT$_DESTINATION_SLOT_ID];
if SB$_REMOTE_SLOT_ID = SLT$_SOURCE_SLOT_ID & SB$_STATE = RUNNING
then
begin
SB$_TRANSMIT_CREDITS = SB$_TRANSMIT_CREDITS + SLT$_CREDITS
SB$_RECEIVE_CREDITS = SB$_RECEIVE_CREDITS - 1;
if SB$_RECEIVE_CREDITS < 0 then exitloop error = illegal-slot;
if SB$_RECEIVE_CREDITS = 0
then
begin
SB$_EXTEND_REMOTE_CREDITS = true;
SB$_SLOT_DATA_PRESENT = true;
CB$_SLOT_DATA_COUNT = CB$_SLOT_DATA_COUNT + 1;
end;
SB$_TRANSMIT_SLOT_ID = 0;
if SLT$_SLOT_TYPE = DATA_A &
SLT$_DATA_COUNT <> 0 then MOVE_TO_TTY_INPUT_BUFFER ();
end;
LAT Terminal Host for TOPS-20 Page 27
[ATTENTION]: ignore;
[REJECT]:
exitloop error = illegal-slot;
[STOP]:
begin
if SLT$_SOURCE_SLOT_ID <> 0 then exitloop error =illegal-slot;
SB = SLOT_ADDRESS_VECTOR [SLT$_DESTINATION_SLOT_ID];
DETACH_JOB ();
SLT$_STATE = HALTED;
RELEASE_SLOT ();
end;
[otherwise]:
exitloop error = illegal-slot;
end;
SLOT_ADDRESS = SLOT_ADDRESS + SLT$_DATA_BYTE_COUNT + 4;
MESSAGE_SLOT_COUNT = MESSAGE_SLOT_COUNT - SLT$_DATA_BYTE_COUNT;
end;
LAT Terminal Host for TOPS-20 Page 28
6.5 SLOT MULTIPLEXER
looping over all circuits
if CB$_STATE <> HALTED
then
begin
case CB$_MUST_REPLY_SOON of
begin
[true]:
begin
if CB$_SLOT_DATA_COUNT <> 0
then
until CB$_SB_QUEUE = end
do
if SB$_SLOT_DATA_PRESENT
then
begin
BUILD_MESSAGE_SLOT ();
CB$_SLOT_DATA_COUNT = CB$_SLOT_DATA_COUNT - 1;
SB$_SLOT_DATA_PRESENT = false;
end
else
if CB$_MUST_REPLY_NOW = false
then
begin
CB$_MUST_REPLY_NOW = true;
return;
end;
CB$_MUST_REPLY_SOON = false;
CB$_MUST_REPLY_NOW = false;
end
[false]:
begin
if CB$_COUNT_SINCE_BALANCED < MAX_BALANCE_COUNT
then
begin
increment CB$_COUNT_SINCE_BALANCED;
return;
end;
if CB$_SLOT_DATA_COUNT <> 0
then
until CB$_SB_QUEUE = end
do
begin
BUILD_MESSAGE_SLOT ();
CB$_SLOT_DATA_COUNT = CB$_SLOT_DATA_COUNT - 1;
SB$_SLOT_DATA_PRESENT = false;
end
else return;
CB$_REPLY_REQUESTED_FLAG = true;
START_CIRCUIT_TIMER ();
end
TRANSMIT_RUN_MESSAGE ();
end;
LAT Terminal Host for TOPS-20 Page 29
LAT Terminal Host for TOPS-20 Page 30
7.0 MAINTENANCE AND DIAGNOSTIC TOOLS AND PROCEDURES
LAT Terminal Host for TOPS-20 Page 31
8.0 SYSTEM TEST DESCRIPTION
The LAT-20 host will be tested against the LAT-11 and Poseidon
terminal servers. Test functions will be added to the LATOP% JSYS to
permit simulation of LAT server terminals to test the performance of
the LAT host under varying degrees of load.
APPENDIX A
MESSAGE FORMATS
MESSAGE FORMATS Page A-2
A.1 MULTICAST DATAGRAM
+-----------------------+-----------------------+
| SERVER_CIRCUIT_TIMER | MESSAGE_TYPE |
+-----------------------+-----------------------+
| LOW_PROTOCOL_VERSION | HIGH_PROTOCOL_VERSION |
+-----------------------+-----------------------+
| CURRENT_PROTOCOL_ECO | CURRENT_PROTOCOL_VERS |
+-----------------------+-----------------------+
| CHANGE_FLAGS | MESSAGE_INCARNATION |
+-----------------------+-----------------------+
| FRAME_SIZE |
+-----------------------+-----------------------+
| HOST_STATUS |HOST_MULTICAST_TIMER |
+-----------------------+-----------------------+
| | ACCESS_CODE_LENGTH |
~ +-----------------------+
~ HOST_ACCESS_CODES ~
+-----------------------+-----------------------+
| | HOST_NAME_LENGTH |
| +-----------------------+
| HOST_NAME_STRING |
+-----------------------+-----------------------+
| |HOST_IDENTIFICATION_LEN|
| +-----------------------+
| HOST_IDENTIFICATION_STRING |
+-----------------------+-----------------------+
| |NAME_BLOCK_COUNT |
| +-----------------------+
| Service Name Blocks |
+-----------------------+-----------------------+
| |HOST_SERVICE_LENGTH |
| +-----------------------+
| HOST_SERVICE_CLASS list |
+-----------------------+-----------------------+
Service Name Block format is:
+-----------------------+
|HOST_SERVICE_RATING |
+-----------------------+-----------------------+
| | HOST_SERVICE_COUNT |
| +-----------------------+
~ HOST_SERVICE_NAME ~
| |
+-----------------------+-----------------------+
| | SERVICE_ID_LENGTH |
| +-----------------------+
~ HOST_SERVICE_ID_STRING ~
| |
+-----------------------+-----------------------+
MESSAGE FORMATS Page A-3
This multicast datagram is transmitted at periodic intervals by the
LAT host on the Ethernet multicast address AB-00-03-00-00-00-00
(hexidecimal).
o MESSAGE_TYPE - 50 octal.
o SERVER_CIRCUIT_TIMER - the value of the server's circuit
timer preferred by the host. The server is not obligated to
comply with this value. Zero implies that the host does not
have a preferred value. The LAT-20 host always sets this
field 0.
o HIGH_PROTOCOL_VERSION - Highest LAT protocol version
supported by the host. The host will reject any incoming
virtual circuit connects which specify a protocol version
higher than this in the START MESSAGE.
o LOW_PROTOCOL_VERSION - Lowest LAT protocol version supported
by the host. The host will reject any incoming virtual
circuit connects which specify a protocol version lower than
this in the START MESSAGE.
o CURRENT_PROTOCOL_VERS - Current LAT protocol version running
at the host.
o CURRENT_PROTOCOL_ECO - ECO level of the LAT protocol version
running at host.
o MESSAGE_INCARNATION - a modulo-256 number which indicates
that the datagram contents have changed. The first time the
datagram is transmitted after system startup, this is a
randomly generated number. Each time it is transmitted and
any entry has changed since the last time transmitted, this
field is incremented by one.
o CHANGE_FLAGS - a bit mask indicating which field(s) in the
message have changed since the last transmission. If a field
changes, the bit toggles and remains unchanged in all
successively transmitted datagrams until the field changes
again. The bit definitions are:
0 - HOST_ACCESS_CODES changed.
1 - HOST_IDENTIFICATION_STRING changed.
2 - a HOST_SERVICE_RATING changed.
3 - a HOST_SERVICE_NAME changed.
4 - a HOST_SERVICE_IDENTIFICATION_STRING changed.
5 - a HOST_SERVICE_CLASS changed.
6 - reserved
7 - something changed.
o FRAME_SIZE - the data link frame size supported by the host.
The host never transmits any messages larger than this and
guarantees that it will receive all messages up to this
length. LAT-20 guarantees that if can always receive the
MESSAGE FORMATS Page A-4
maximum Ethernet message size.
o HOST_MULTICAST_TIMER - the maximum time interval between the
transmission of the multicast datagrams.
o HOST_STATUS - a bit mask indicating the status of the host.
Bit zero is set to 1 if the host is not accepting any new
sessions. Otherwise it is zero. The remaining bits are not
defined.
o ACCESS_CODE_LENGTH - Length in bytes of the following field.
A length count of zero indicates that the host has only
access code 0 enabled.
o HOST_ACCESS_CODES - an up to 32 byte (8-bits/byte) bit mask
defining the access codes defined for the LAT host. Bit 0
(the most significant) corresponds to access code 1.
o HOST_NAME_LENGTH - length in bytes of the following field.
o HOST_HAME_STRING - ASCII string representing the unique name
of this host.
o HOST_IDENTIFICATION_LEN - count in bytes of the following
field. The range of this count is 0 to 64 bytes.
o HOST_IDENTIFICATION - the freely formatted ASCII string used
to identify the host. This can usually be displayed by
terminal users at the server.
o NAME_BLOCK_COUNT - the number of service name blocks which
follow.
o HOST_SERVICE_RATING - is the rating assigned to a particular
service name defined in this service name block.
o SERVICE_NAME_LENGTH - length in bytes of the following field.
o HOST_SERVICE_NAME - name of the service defined by this
service block.
o SERVICE_ID_LENGTH - length in bytes of the following field.
o HOST_SERVICE_ID_STRING - - the freely formatted ASCII string
used to identify the service. This can usually be displayed
by terminal users at the server.
o HOST_SERVICE_LENGTH - count in bytes of the following field.
There presentyl only one class available so this field must
be 1.
o HOST_SERVICE_CLASS - a string of bytes, each representing a
service class being offered by the host. There is presently
only one class available: Service Class 1, the Interactive
Terminal Service Class.
MESSAGE FORMATS Page A-5
A.2 START MESSAGE
15 8 7 0
+-----------------------+-----------------------+
| N_SLOTS | MESSAGE_TYPE |M|R|
+-----------------------+-----------------------+
| DST_DIR_ID |
+-----------------------+-----------------------+
| SRC_CIR_ID |
+-----------------------+-----------------------+
| ACK_SEQUENCE_NUMBER | XMIT_SEQUENCE_NUMBER |
+-----------------------+-----------------------+
| FRAME_SIZE
+-----------------------+-----------------------+
| CURRENT_PROTOCOL_ECO | CURRENT_PROTOCOL_VERS |
+-----------------------+-----------------------+
| ADDITIONAL_DL_BUFFERS | MAX_SLOTS |
+-----------------------+-----------------------+
|SERVER_KEEP-ALIVE_TIMER| SERVER_CIRCUIT_TIMER |
+-----------------------+-----------------------+
| FACILITY_NUMBER |
+-----------------------+-----------------------+
| PRODUCT_TYPE_CODE |
+-----------------------+-----------------------+
| |HOST_NAME_LENGTH |
~ +-----------------------+
~ HOST_NODE_NAME_STRING ~
| |
+-----------------------+-----------------------+
| |SYSTEM_NAME_LENGTH |
~ +-----------------------+
~ SYSTEM_NAME ~
| |
+-----------------------+-----------------------+
| | LOCATION_LENGTH |
| +-----------------------+
~ LOCATION_TEXT ~
| |
+-----------------------+-----------------------+
| PARAMETER_LENGTH | PARAMETER_CODE |
+-----------------------+-----------------------+
| PARAMETER_DATA |
+-----------------------+-----------------------+
MESSAGE FORMATS Page A-6
o R - Reply Requested Flag. Must be zero for the START
message.
o M - Master Bit. This bit is always set to 1 in all messages
transmitted by the server and cleared in all messages
transmitted by the host.
o MESSAGE_TYPE - 1
o N_SLOTS - Must be zero for START messages.
o DST_CIR_ID - the destinations's virtual circuit identifier.
o SRC_CIR_ID - the source's virtual circuit identifier.
o XMIT_SEQUENCE_NUMBER - Transmit sequence number for this
message. Must be zero for START messages.
o ACK_SEQUENCE_NUMBER - Sequence number of the last message
received from the virtual circuit partner. Must be zero for
the START message.
o FRAME_SIZE - size in bytes of the receive buffers queued to
the data link by the transmitter of this message. This
informs the virtual circuit partner of the maximum size
message which may be sent to the transmitter of this message.
o CURRENT_PROTOCOL_VERS - Current LAT protocol version being
used by the transmitter of this message.
o CURRENT_PROTOCOL_ECO - ECO level of the LAT protocol version
being used by the transmitter of this message.
o MAX_SLOTS - the maximum number of terminal (slot) sessions
which may be open at any one time on this virtual circuit.
This number is suggested by the terminal server. The value
returned in the host's START message, if lower, must be
honored by the server.
o ADDITIONAL_DL_BUFFERS - the number of receive buffers queued
to the data link by the transmitter of this message. The
receiver may queue this many additional transmit buffers.
LAT-20 Host always sets this to zero and ignores it in
messages from the server.
o SERVER_CIRCUIT_TIMER - the virtual circuit timer when the
transmitter of this message is the server. This field is
zero in START messages transmitted by the host.
o SERVER_KEEP-ALIVE_TIMER - the server keep-alive timer when
the transmitter of this message is the server. This field is
zero in START messages transmitted by the host.
MESSAGE FORMATS Page A-7
o FACILITY_NUMBER - the number associated with the server or
host transmitting this message. This number is intended to
uniquely identify servers and hosts on the local area
network. It assigned through the local LCP command
interface.
o PRODUCT_TYPE_CODE - a code identifying the product type of
the transmitter of this message. For LAT-20 Host this is 6.
o HOST_NAME_LENGTH - length in bytes of the following field.
o HOST_NODE_NAME_STRING - the HOST_NAME string.
o SYSTEM_NAME_LENGTH - length in bytes of the following field.
o SYSTEM_NAME - an string of up to 16 characters used to
identify the transmitter of this message by name. When
transmitted by the server, this is SERVER_NAME. When
transmitted by the host, this is HOST_NAME.
o LOCATION_LENGTH - length in bytes of the following field.
o LOCATION_TEXT - a string of up to 16 characters used to
identity the location of the transmitter of this message.
When transmitted by the server, this is SERVER_LOCATION.
When transmitted by the host, this is HOST_LOCATION.
o PARAMETER_CODE, PARAMETER_LENGTH, PARAMETER_DATA - there are
currently no parameters define.
MESSAGE FORMATS Page A-8
A.3 STOP MESSAGE
15 8 7 0
+-----------------------+-----------------------+
| N_SLOTS | MESSAGE_TYPE |M|R|
+-----------------------+-----------------------+
| DST_DIR_ID |
+-----------------------+-----------------------+
| SRC_CIR_ID |
+-----------------------+-----------------------+
| ACK_SEQUENCE_NUMBER | XMIT_SEQUENCE_NUMBER |
+-----------------------+-----------------------+
| DISCONNECT_REASON_CODE
+-----------------------+-----------------------+
| REASON_TEXT_COUNT
+-----------------------+-----------------------+
| |
~ REASON_TEXT ~
| |
+-----------------------+-----------------------+
o R - Reply Requested Flag. Must be zero for the STOP message.
o M - Master Bit. This bit is always set to 1 in all messages
transmitted by the server and cleared in all messages
transmitted by the host.
o MESSAGE_TYPE - 2
o N_SLOTS - Must be zero for STOP messages.
o DST_CIR_ID - the destinations's virtual circuit identifier.
o SRC_CIR_ID - the source's virtual circuit identifier. Must
be zero for STOP messages.
o XMIT_SEQUENCE_NUMBER - Transmit sequence number for this
message. Must be zero for STOP messages.
o ACK_SEQUENCE_NUMBER - Sequence number of the last message
received from the virtual circuit partner. Must be zero for
STOP messages.
o DISCONNECT_REASON_CODE - a code specifying the reason for the
virtual circuit disconnect. This code may be one of:
1. no slot sessions in progress on the virtual circuit.
2. illegal message or slot format received.
3. local user halted the virtual circuit.
4. the progress timer expired in the host.
MESSAGE FORMATS Page A-9
5. Time limit expired.
6. message retransmit limit exceeded.
7. insufficient resources.
8. server circuit timer out of range.
o REASON_TEXT_COUNT - count in bytes of the following field.
o REASON_TEXT - ASCII string describing the disconnect reason.
MESSAGE FORMATS Page A-10
A.4 RUN MESSAGE
15 8 7 0
+-----------------------+-----------------------+
| N_SLOTS | MESSAGE_TYPE |M|R|
+-----------------------+-----------------------+
| DSTDIR_ID |
+-----------------------+-----------------------+
| SRC_CIR_ID |
+-----------------------+-----------------------+
| ACK_SEQUENCE_NUMBER | XMIT_SEQUENCE_NUMBER |
+-----------------------+-----------------------+
| |
~ SLOT_DATA ~
| |
+-----------------------+-----------------------+
o R - Reply Requested Flag. This flag is always 0 in RUN
messages transmitted by the server. The host sets this flag
when it has used its last transmit buffer indicating to the
server that it must acknowledge at the next circuit timer
timeout.
o M - Master Bit. This bit is always set to 1 in all messages
transmitted by the server and cleared in all messages
transmitted by the host.
o MESSAGE_TYPE - 0
o N_SLOTS - the number of slots in the SLOT_DATA field.
o DST_CIR_ID - the destinations's virtual circuit identifier.
o SRC_CIR_ID - the source's virtual circuit identifier.
o XMIT_SEQUENCE_NUMBER - Transmit sequence number for this
message.
o ACK_SEQUENCE_NUMBER - Sequence number of the last message
received by the virtual circuit partner.
o SLOT_DATA - slot blocks.
APPENDIX B
SLOT FORMATS
SLOT FORMATS Page B-2
B.1 START SLOT
7 0
+-------------------------------+
| DST_SLOT_ID |
+-------------------------------+
| SRC_SLOT_ID |
+-------------------------------+
| DATA_BYTE_COUNT |
+---------------+---------------+
| SLOT_TYPE | CREDITS |
+===============+===============+
| SERVICE_CLASS | <-- start of DATA field
+-------------------------------+
| MINIMUM_ATTENTION_SLOT_SIZE |
+-------------------------------+
| MINIMUM_DATA_SLOT_SIZ |
+---------------+---------------+
| |DST_SLT_NAM_LEN|
~ +---------------+
| DST_SLOT_NAME ~
+---------------+---------------+
| |SRC_SLT_NAM_LEN|
~ +---------------+
| SRC_SLOT_NAME ~
+-------------------------------+
| PARM_CODE |
+-------------------------------+
| PARM_LEN |
+-------------------------------+
~ PARM_DATA ~
+-------------------------------+
| PARM_CODE, PARM_LEN, and |
~ PARM_DATA repeated until ~
| PARM_CODE is equal to zero. |
+-------------------------------+
o DST_SLOT_ID - destination's handle for accessing the slot.
o SRC_SLOT_ID - the source's handle for accessing the slot.
o SLOT_BYTE_COUNT - an unsigned integer count of the length of
the slot data field.
o CREDITS (4 bits) - a 4-bit integer equal to the number of
transmit credits being extended to the receiver of the
message.
o SLOT_TYPE (4 bits) - the value 9.
o SERVICE_CLASS - Service Class is always 1.
SLOT FORMATS Page B-3
o MINIMUM_ATTENTION_SLOT_SIZE (1 byte) - The minimum slot size
queued to receive Attention slot data (not including the slot
header). The system receiving this message must limit
transmitted ATTENTION slots to this size. A value of zero
indicates Attention slots are not supported.
o MINIMUM_DATA_SLOT_SIZE (1 byte) - The minimum slot size
queued to receive Data_a and Data_b slots (not including the
slot header). The system receiving this message must limit
transmitted Data_a and Data_b slots to this size.
o DST_SLOT_NAME_LEN (1 byte unsigned) - The byte count of the
next field.
o DST_SLOT_NAME - The name of the host slot block.
o SRC_SLOT_NAME_LEN (1 byte unsigned) - The byte count of the
next field.
o SRC_SLOT_NAME - The name of the server slot block.
o PARM_CODE (1 byte) - A parameter code. The value zero
indicates the end of the list (which means the following
fields are unpredictable). A non-zero value in this field
indicates the next two fields are valid. Parameter codes 0
through 127 are reserved for use by Digital Equipment
Corporation, while parameter codes 128 through 255 are
reserved for users.
o PARM_LEN (1 unsigned byte) - the length of the following
field in bytes.
o PARM_DATA (PARM_LEN bytes) - the format of this field is
defined by the associated PARM_CODE. The following
parameters are defined for service class 1 - Interactive
terminals:
o Parameter code 0 is reserved.
o Parameter code 1, parameter length = 2 - Flag word.
- Bit 0 - Remote (modem) line if set to 1.
- Bit 1 - Secure line if set to 1. Server will pass
the <break> condition to the host
- Bits 2-15 are unpredictable.
o Parameter codes 2 through 127 are unpredictable.
SLOT FORMATS Page B-4
B.2 DATA_A SLOT
7 0
+-------------------------------+
| DST_SLOT_ID |
+-------------------------------+
| SRC_SLOT_ID |
+-------------------------------+
| DATA_BYTE_COUNT |
+---------------+---------------+
| SLOT_TYPE | CREDITS |
+===============+===============+
~ SLOT_DATA ~
+-------------------------------+
o DST_SLOT_ID - destination's handle for accessing the slot.
o SRC_SLOT_ID - the source's handle for accessing the slot.
o DATA_BYTE_COUNT - an unsigned integer count of the length of
the slot data field.
o CREDITS (4 bits) - a 4-bit integer equal to the number of
transmit credits being extended to the receiver of the
message.
o SLOT_TYPE (4 bits) - the value 0.
o SLOT_DATA - terminal character data
SLOT FORMATS Page B-5
B.3 DATA_B SLOT
7 0
+-------------------------------+
| DST_SLOT_ID |
+-------------------------------+
| SRC_SLOT_ID |
+-------------------------------+
| DATA_BYTE_COUNT |
+---------------+---------------+
| SLOT_TYPE | CREDITS |
+===============+===============+
| CONTROL_FLAGS |
+-------------------------------+
| STOP_OUTPUT_CHANNEL_CHAR |
+-------------------------------+
| START_OUTPUT_CHANNEL_CHAR |
+-------------------------------+
| STOP_INPUT_CHANNEL_CHAR |
+-------------------------------+
| START_INPUT_CHANNEL_CHAR |
+-------------------------------+
o DST_SLOT_ID - destination's handle for accessing the slot.
o SRC_SLOT_ID - the source's handle for accessing the slot.
o DATA_BYTE_COUNT - an unsigned integer count of the length of
the slot data field.
o CREDITS (4 bits) - a 4-bit integer equal to the number of
transmit credits being extended to the receiver of the
message.
o SLOT_TYPE (4 bits) - the value 9.
SLOT FORMATS Page B-6
o CONTROL_FLAGS (8 bits) :
o (bit 0) - Enable recognition of input flow control
characters. If set, this bit changes the meaning of
STOP_OUTPUT_CHANNEL_CHAR and START_OUTPUT_CHANNEL_CHAR in
the terminal input stream. Upon detecting one of these
characters, the terminal server should disable/enable
terminal output stream as indicated, and discard the
character.
o (bit 1) - Disable recognition of input flow control
characters. If set, all characters in the terminal input
stream are passed directly through to the host without
interpretation.
o (bit 2) - Enable recognition of output flow control
characters. If set, this bit changes the meaning of
STOP_INPUT_CHANNEL_CHAR and START_INPUT_CHANNEL_CHAR in
the terminal output stream. If the terminal server is
about to overflow the terminal input stream buffering, it
should insert the STOP_INPUT_CHANNEL_CHAR into the
terminal output stream. When sufficient input buffering
is again available, the START_INPUT_CHANNEL_CHAR must be
inserted into the terminal output stream.
o (bit 3) - Disable recognition of output flow control
characters. If set, all terminal output characters are
passed directly to the output stream. No characters are
generated by the terminal server.
o (bit 4) - Break condition detected (terminal server to
host only).
o (bit 5 through bit 7) - Unpredictable.
o STOP_OUTPUT_CHANNEL_CHAR - The value assigned to stop the
terminal output stream if input flow control characters are
enabled. The value assigned is normally control-S.
o START_OUTPUT_CHANNEL_CHAR - The value assigned to start the
output channel if input flow control characters are enabled.
The value assigned is normally control-Q.
o STOP_INPUT_CHANNEL_CHAR - The value assigned to stop the
terminal input channel if output flow control characters are
enabled. The value ssigned is normally control-S or
control-G.
o START_INPUT_CHANNEL_CHAR - The value assigned to start the
terminal input channel if output flow control characters are
enabled. The value assigned is normally control-Q or null.
SLOT FORMATS Page B-7
B.4 ATTENTION SLOT
7 0
+-------------------------------+
| DST_SLOT_ID |
+-------------------------------+
| SRC_SLOT_ID |
+-------------------------------+
| DATA_BYTE_COUNT |
+---------------+---------------+
| SLOT_TYPE | MBZ |
+===============+===============+
| CONTROL_FLAGS |
+-------------------------------+
o DST_SLOT_ID - destination's handle for accessing the slot.
o SRC_SLOT_ID - the source's handle for accessing the slot.
o DATA_BYTE_COUNT - an unsigned integer count of the length of
the slot data field.
o CREDITS (4 bits) - a 4-bit integer equal to the number of
transmit credits being extended to the receiver of the
message.
o SLOT_TYPE (4 bits) - the value 9.
o CONTROL_FLAGS (8 bits) :
o (bit 0 through bit 4) - Unpredictable.
o (bit 5) - Abort. Causes buffered output data pipe to be
flushed of all characters.
o (bit 6 and bit 7) - Unpredictable.
SLOT FORMATS Page B-8
B.5 REJECT SLOT
7 0
+-------------------------------+
| DST_SLOT_ID |
+-------------------------------+
| SRC_SLOT_ID |
+-------------------------------+
| DATA_BYTE_COUNT |
+---------------+---------------+
| SLOT_TYPE | REASON |
+===============+===============+
o DST_SLOT_ID - destination's handle for accessing the slot.
o SRC_SLOT_ID - the source's handle for accessing the slot.
o DATA_BYTE_COUNT - an unsigned integer count of the length of
the slot data field. Must be zero since there is no data for
this slot type.
o REASON - an unsigned 4-bit integer, one of the following
reasons apply:
1. user requested disconnect
2. system shutdown in progress
3. invalid slot received
4. invalid service class
5. insufficient resources to satisfy request
o SLOT_TYPE - the value 12. (1100)
SLOT FORMATS Page B-9
B.6 STOP SLOT
7 0
+-------------------------------+
| DST_-SLOT_ID |
+-------------------------------+
| SRC_SLOT_ID |
+-------------------------------+
| DATA_BYTE_COUNT |
+---------------+---------------+
| SLOT_TYPE | REASON |
+===============+===============+
o DST_SLOT_ID - destination's handle for accessing the slot.
o SRC_SLOT_ID - the source's handle for accessing the slot.
o DATA_BYTE_COUNT - an unsigned integer count of the length of
the slot data field. Must be zero since there is no data for
this slot type.
o REASON - an unsigned 4-bit integer, one of the following
reasons apply:
1. user requested disconnect
2. system shutdown in progress
3. invalid slot received
4. invalid service class
5. insufficient resources to satisfy request
o SLOT_TYPE - the value 13. (1101)
APPENDIX Z
OUTSTANDING ISSUES
ISSUE DATE ISSUE PERSON
NUMBER ASSIGNED DESCRIPTION RESPONSIBLE
[n] dd mmm yy {Description of issue (n)} Name of DRI
[End of e-design]
LAT1020SPEC.MEM
Date: 23 October 1984
%%% {{ 10:04:37 }} %%%
Preliminary
Component Software Product
SPECIFICATION
for the
for
TOPS-10 and TOPS-20
.........
Written By: P. J. Weisbach and Carl J. Appellof
Issued By: P. J. Weisbach and Carl J. Appellof
Reviewed By: (Phase Review Product Team)
- 1 -
LAT Terminal HOST
Component Software Product
SPECIFICATION
Contents
---------------
1.0 PRODUCT SUMMARY . . . . . . . . . . . . . . . . . . 3
2.0 ENVIRONMENT . . . . . . . . . . . . . . . . . . . . 4
2.1 Users . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Hardware . . . . . . . . . . . . . . . . . . . . . 4
2.3 Software . . . . . . . . . . . . . . . . . . . . . 4
2.4 Services . . . . . . . . . . . . . . . . . . . . . 4
3.0 SOFTWARE CAPABILITIES . . . . . . . . . . . . . . . 5
3.1 LAT Operation Overview . . . . . . . . . . . . . . 5
3.2 TOPS-10/20 LAT Component Description . . . . . . . 6
3.3 Flow Control . . . . . . . . . . . . . . . . . . . 7
3.4 XON/XOFF Processing . . . . . . . . . . . . . . . 7
3.5 LAT Server Control Character Processing . . . . . 8
3.6 LAT Character Echo . . . . . . . . . . . . . . . . 8
3.7 HOST GROUP CODES . . . . . . . . . . . . . . . . . 8
3.8 HOST SERVICE NAMES . . . . . . . . . . . . . . . . 9
3.9 LAT System Parameters . . . . . . . . . . . . . 10
3.9.1 Permanent LAT Parameters . . . . . . . . . . . 10
3.9.2 Static Parameters . . . . . . . . . . . . . . 11
3.9.3 Dynamic Parameters . . . . . . . . . . . . . . 11
3.9.4 LAT COUNTERS . . . . . . . . . . . . . . . . . 13
3.10 THE SYSTEM MANAGER INTERFACE . . . . . . . . . . 14
3.10.1 Summary Of LCP Commands . . . . . . . . . . . 14
3.10.2 START/STOP Commands . . . . . . . . . . . . . 15
3.10.3 SET/CLEAR Commands . . . . . . . . . . . . . . 15
3.10.4 SHOW CHARACTERISTICS . . . . . . . . . . . . . 15
3.10.5 SHOW CONNECTS . . . . . . . . . . . . . . . . 16
3.10.6 SHOW SERVER . . . . . . . . . . . . . . . . . 17
3.10.7 SHOW COUNTERS . . . . . . . . . . . . . . . . 18
3.10.8 ZERO COUNTERS . . . . . . . . . . . . . . . . 18
3.11 The LATOP% JSYS And LATOP. UUO . . . . . . . . . 19
3.12 MODIFICATIONS TO TOPS-20 SYSTEM MODULES . . . . 26
3.12.1 LAT Initialization At System Startup . . . . . 26
3.12.2 Addition Of Terminal Type LAT . . . . . . . . 26
3.12.3 Modifications To TTYSRV . . . . . . . . . . . 27
3.12.3.1 Device Dependent TDCALLs . . . . . . . . . . 27
- 2 -
LAT Terminal HOST
3.12.3.1.1 Start Output For A LAT HOST Line . . . . . 27
3.12.3.1.2 Clear Output Buffer For A LAT HOST Line . 27
3.12.3.1.3 Enable/Disable XON/XOFF Recognition For A
LAT HOST Line . . . . . . . . . . . . . . 27
3.12.3.2 LAT Scheduler Routine LATSCH . . . . . . . . 27
3.12.4 SETSPD . . . . . . . . . . . . . . . . . . . . 28
3.12.5 Major External References . . . . . . . . . . 28
3.12.5.1 TTYSRV . . . . . . . . . . . . . . . . . . . 28
3.12.5.2 NIDLL . . . . . . . . . . . . . . . . . . . 28
3.13 MODIFICATIONS TO TOPS-10 SYSTEM MODULES . . . . 30
3.13.1 LAT Initialization At System Startup . . . . . 30
3.13.2 Addition Of Terminal Type LAT . . . . . . . . 30
3.13.3 SCNSER Dispatch Table LATDSP Entries For LATSRV 31
3.13.4 LAT Scheduler Routine LATSCH . . . . . . . . . 31
3.13.5 Major External References . . . . . . . . . . 31
3.13.5.1 SCNSER . . . . . . . . . . . . . . . . . . . 31
4.0 PUBLICATIONS . . . . . . . . . . . . . . . . . . . 33
5.0 PACKAGING . . . . . . . . . . . . . . . . . . . . 33
6.0 INSTALLABILITY . . . . . . . . . . . . . . . . . . 34
7.0 EASE OF USE . . . . . . . . . . . . . . . . . . . 34
8.0 PERFORMANCE . . . . . . . . . . . . . . . . . . . 35
8.1 TOPS-10/20 Performance . . . . . . . . . . . . . 35
8.2 NI Performance . . . . . . . . . . . . . . . . . 35
9.0 RELIABILITY . . . . . . . . . . . . . . . . . . . 36
10.0 MAINTAINABILITY . . . . . . . . . . . . . . . . . 37
11.0 MAINTENANCE SERVICE . . . . . . . . . . . . . . . 37
12.0 COMPATIBILITY . . . . . . . . . . . . . . . . . . 37
13.0 EVOLVABILITY . . . . . . . . . . . . . . . . . . . 37
13.1 Extendability . . . . . . . . . . . . . . . . . 37
13.2 Commonality Between TOPS-10 And TOPS-20 . . . . 37
14.0 COSTS . . . . . . . . . . . . . . . . . . . . . . 38
15.0 TIMELINESS . . . . . . . . . . . . . . . . . . . . 38
16.0 CONSTRAINTS & TRADE-OFFS . . . . . . . . . . . . . 38
APPENDIX A LAT PARAMETER VALUES
A.1 PERMANENT AND STATIC PARAMETER VALUES . . . . . . 39
- 3 -
LAT Terminal HOST
A.2 DYNAMIC PARAMETERS . . . . . . . . . . . . . . . . 40
APPENDIX B SHOW BLOCK FORMATS
B.1 FORMAT FOR THE .LASCH FUNCTION . . . . . . . . . . 42
B.2 FORMAT FOR THE .LASTC FUNCTION . . . . . . . . . . 44
B.3 FORMAT FOR THE .LASAS FUNCTION . . . . . . . . . . 45
B.4 COUNTER BLOCK FORMAT . . . . . . . . . . . . . . . 46
- 4 -
LAT Terminal HOST Page 1
PREFACE
---------
This is a Component Software Product Specification, and is the
definitive description, in measurable terms, of the goals, capabilities,
and external characteristics of LAT-10/20 Terminal Host. This
Specification is the commitment of what is to be built, as agreed by the
Product Team.
No changes are to be made to the product as described here, unless
approved and documented as an amendment to this Specification.
REFERENCES
----------
Local Area Transport Architecture, Bruce Mann, Rev. 1.3, Feb. 4, 1984.
NISRV Functional Specification, Stu Grossman, March 16, 1984.
Change History:
Rev Date Author Description
1 6/25/84 Weisbach Include changes since original version
2 7/2/84 Appellof Include TOPS-10 specifications
3 9/12/84 Weisbach
4 10/22/84 Weisbach In .LASAS and .LASCO, change to a
.LAQUA of zero instead of [0,,-1] to mean ALL
SERVERS.
5 10/22/84 Weisbach For the .LASCO function, remove any
reference to a host counter set since there is
no such thing.
6 10/22/84 Weisbach For setting/clearing group codes, .LAVAL is the
address of the bit map, not a byte pointer.
7 10/23/84 Weisbach Let SET/CLEAR GROUPS take a range as
well as single values.
8 10/23/84 Weisbach Change SHOW SERVER/NAME:name to
SHOW SERVER name
9 10/23/84 Weisbach Remove the location field from the
- 1 -
LAT Terminal HOST Page 2
connect block returned for the .LASTC
LATOP% function. Also remove the number of
connects returned since it can be computed.
Remove the server location from the SHOW
display.
- 2 -
LAT Terminal HOST Page 3
PRODUCT SUMMARY
1.0 PRODUCT SUMMARY
Local Area Transport (LAT) is a protocol which runs on an Ethernet link
directly over the NI Data Link (NIDLL). It is totally independent of
DECnet. Although it may be used for various network services, LAT has
been optimally designed for interactive terminal operation between a LAT
server and a LAT host, both on the same NI.
The interactive terminal service of LAT permits terminal users at a LAT
Server to conduct terminal sessions with LAT hosts connected to the NI.
Figure 1 shows a possible NI configuration with LAT terminal servers and
hosts.
TOPS-10/20 SYSTEM A
+-------+ +-------+
| LAT | | LAT |
| HOST | | HOST |
| | | |
+---0---+ +---0---+
| |
| |
| |
NI ===================0==================0============0=======
|
|
|
+---0---+
TTY -------| LAT |
TTY -------|SERVER |
TTY -------| |
+-------+
SYSTEM B
Figure 1. TOPS-10/20 as a LAT host on the Ethernet.
As shown in the figure, TOPS-10/20 and SYSTEM A have implemented the LAT
host. The terminal users at SYSTEM B may use either TOPS-10/20 or
SYSTEM A as host. SYSTEM A might be a VMS or RSX-11 system. SYSTEM B
might be any Ethernet-based terminal concentrator such as:
o the POSEIDON 8-line terminal server,
o the PLATO 16- or 32- line terminal server, or
o the LAT-11 64-line terminal server
- 3 -
LAT Terminal HOST Page 4
ENVIRONMENT
2.0 ENVIRONMENT
2.1 Users
TOPS-10/20 can serve as a host system to any terminal server which
supports the LAT interactive terminal service. Any user of an
asynchronous command terminal connected to a LAT terminal server can
host to a TOPS-10/20 system on the same NI. Available servers include
the POSEIDON, PLATO, and LAT-11 terminal servers.
2.2 Hardware
Any DECSYSTEM-10/20 supporting Ethernet hardware is capable of
supporting LAT.
2.3 Software
TOPS-20 release 6.1 or later is required to support LAT. TOPS-10
Version 7.03 or later is required to support LAT.
2.4 Services
No special services are required.
- 4 -
LAT Terminal HOST Page 5
SOFTWARE CAPABILITIES
3.0 SOFTWARE CAPABILITIES
3.1 LAT Operation Overview
Each host which supports the LAT interactive terminal service advertises
this fact to all LAT terminal servers by periodically broadcasting an
Ethernet multicast datagram. Each server maintains a list of hosts from
which it has recently received a multicast datagram and deletes those
from the list that have not been heard from for some time. A terminal
user at the server may display this list at any time to determine which
hosts are accessible.
The logical path between a LAT host and server is called a LAT virtual
circuit. There is one virtual circuit for each server/host pair which
has at least one active terminal session. All terminal data destined
for a given host is multiplexed onto the same virtual circuit.
LAT virtual circuits may be created only by the LAT server. Typically
the terminal user picks a host from the displayed list of available
hosts and requests a connection. The server creates a virtual circuit
to that host if none exists. Otherwise already existing circuits are
used . The host of course has the option to accept or reject a virtual
circuit connection. LAT virtual circuits may be terminated by either
the LAT server or host.
Virtual circuit messages are transmitted between host and server at
periodic intervals determined by a "circuit timer" maintained in the LAT
server. When the timer expires, the server assembles any terminal input
received during the past interval into a single virtual circuit message
and transmits it to the host. The timer's period is settable in the
server but has a recommended value of 80ms.
The data associated with a particular terminal are grouped in the
message in units called "slots". A virtual circuit message may contain
slots from many terminals and may contain more than one slot from a
single terminal.
Having received a server message, the host assembles as much terminal
output data as possible into a single message and transmits it to the
server. If no output is waiting for any terminal, a message is sent
with no slots. The host's response message acknowledges the previously
received message from the server. This message will be acknowledged by
the server message transmitted at the next tick of the circuit timer.
To reduce NI utilization and load on the host, the server only transmits
a message when there is something to send. It could happen that when
the server has no data to transmit, there is more terminal output data
waiting at the host. Because the last host message remains
unacknowledged, output flow from the host would stop. For this reason
the host is permitted to transmit one "unsolicited" message to the
server. The host sets a flag in the message which forces the server to
respond at the next tick of the circuit timer. This "forced" response
- 5 -
LAT Terminal HOST Page 6
SOFTWARE CAPABILITIES
acknowledges all the host's previously transmitted messages and returns
all transmit buffers so that they may be used again.
The server also maintains a polling timer called the keep-alive timer.
During periods of long inactivity of both the host and server, this
timer is used by the server to determine that the virtual circuit
connection to the host is still intact.
The host maintains a circuit timer with an interval of 1-2 seconds. The
function of the host's circuit timer differs from that of the server's
circuit timer: it is used solely as a retransmit timer. When the host
uses its last transmit buffer to send a message, it starts its circuit
timer. Because the server's circuit timer is short relative to the
host's, the server should have acknowledged all outstanding host
messages well before the host's timer expires. If this is not the case,
the host retransmits all unacknowledged messages. This continues until
either the server responds with an acknowledgement or the retransmit
limit is reached. If the retransmit limit is reached, the host assumes
the connection to the server is no longer useable and detaches all LAT
jobs.
3.2 TOPS-10/20 LAT Component Description
The TOPS-10/20 LAT components consist of:
o The Virtual Circuit Receiver
o the Slot Demultiplexor
o the Slot Multiplexor
o the Virtual Circuit Transmitter
o LAT Control Program (LCP)
o the LATOP% JSYS or LATOP. UUO
The Virtual Circuit Receiver (VC Receiver) receives datagrams from the
NIDLL at NI interrupt level and queues them for processing during a
short scheduler cycle by the Slot Demultiplexor.
The Slot Demultiplexor is called by the scheduler every SCHED_CYCLE_CNT
short scheduler cycles. It processes all datagrams queued by the VC
Receiver during the last SCHED_CYCLE_CNT short scheduler cycles. The
demultiplexor takes the incoming slot data and enters it into the
terminal input buffers.
The Slot Demultiplexor calls the Slot Multiplexor which fetches
characters from terminal output buffers and places them in slots of a
virtual circuit message. When either all terminal data has been entered
into slots or the virtual circuit message is full, the Slot Multiplexor
calls the VC Transmitter to send the message. The VC transmitter uses
the NIDLL interface in the monitor to send the message over the
Ethernet.
- 6 -
LAT Terminal HOST Page 7
SOFTWARE CAPABILITIES
The LAT Control Program is a utility which allows a system manager to
monitor and control the LAT functions at the local TOPS-10/20 system.
The LATOP% JSYS or LATOP. UUO provides the interface to the monitor for
LCP program.
3.3 Flow Control
Terminal flow control between the LAT host and server is accomplished
using a credit scheme. A receiving station (host or server) controls
transmission from other stations by extending permissions or credits
only when there is sufficient receive buffer capacity available. These
credits are maintained on a per-terminal and bi-directional basis and
are transferred in slot headers. For each terminal session, a
transmitting station keeps track of the number of credits available by
incrementing a credit count when receiving credits from the receiving
station and decrementing the count each time a slot data is sent.
Transmits are not permitted when the count goes to zero.
The TOPS-10/20 host extends credit to a server such that the TOPS-10/20
terminal input buffers do not overflow. The host therefore does not
need to send a ^S to the terminal to stop input.
3.4 XON/XOFF Processing
The LAT protocol allows a LAT host to control XON/XOFF functions at the
LAT server:
(a) Enable/disable the server's recognition of XON/XOFF characters
in the terminal's input stream,
(b) Enable/disable the server's capability to enter XON/XOFF
characters in the terminal's output stream when the server's
input buffer is about to overflow.
(c) Set the value of the characters to be interpreted as XON/XOFF
characters from the terminal input stream by the server.
(d) Set the value of the output stream XON/XOFF characters entered
into the terminal output stream by the server.
The TOPS-20 LAT host processes XON/XOFF (more specifically, ^S/^Q)
according to the TT%PGM bit of the terminal JFN mode word and page
PAUSE/UNPAUSE characters according to the TTRXF bit of TTFLG1. Any
change at the host to the TT%PGM bit causes the host to inform the
server to enable/disable the XON/XOFF processing at the server
appropriately. The server is not informed of any changes to TTRXF
because the host rather than the server always handles TOPS-20 style
pause/unpause characters. RESTRICTION: LAT servers do not pass ^S/^Q
characters to the host when XON/XOFF is enabled. Therefore these
characters cannot be used as pause/unpause characters.
- 7 -
LAT Terminal HOST Page 8
SOFTWARE CAPABILITIES
The TOPS-10 LAT host processes XON/XOFF according to the LPLXNF bit of
the LDBPAG word of the terminal's LDB and the page counter field pointed
to by LDPPCT if the user has SET TTY STOP or SSTOP. Change of the
LPLXNF bit at the host causes the host to inform the server to
enable/disable the XON/XOFF processing at the server appropriately.
RESTRICTION: LAT servers do not pass ^S/^Q characters to the host when
XON/XOFF is enabled. Therefore these characters cannot be used as
pause/unpause characters when TTY STOP or SSTOP is set. This makes it
impossible to use the TTY STOP or SSTOP feature on TOPS-10 with a LAT
terminal. This restriction may be lifted if there are further changes
to the LAT-11 specifications.
3.5 LAT Server Control Character Processing
Except when XON/XOFF recognition is enabled, the LAT server does not
process any control characters. Specifically, all editing, ^O, ^T, ^C,
etc. processing is done by the host.
3.6 LAT Character Echo
Echoing of characters in a LAT implementation is always done by the
host.
3.7 HOST GROUP CODES
The connectivity between a terminal server user and host may be
restricted through the use of group codes. A host or terminal user may
enable any of the 256 group codes in the range 0-255. Hosts convey
their list of enabled group codes to servers in the periodically
transmitted multicast messages. A LAT server will permit terminal users
to access only those hosts with which it has at least one enabled group
code in common.
Hosts which do not wish to restrict terminal access always enable group
code 0. Since servers have group code 0 enabled by default, group code
0 permits the most unrestrictive terminal-host connectivity. Group
codes are enabled, disabled, or displayed using the LCP command
interface.
- 8 -
LAT Terminal HOST Page 9
SOFTWARE CAPABILITIES
3.8 HOST SERVICE NAMES
Hosts provide a unique host name and one or more names for services
provided by the host. The server maintains a list of host and service
names and permits the terminal user to display those service names
provided by those hosts for which he has an enabled group code in
common. The server does not display the host name. Terminal users
specify connections to a service rather than to a host. Service names
need not be unique among the hosts on an Ethernet. Several hosts may
agree to present the same service name to the terminal servers. For
each service name, a host provides a service rating. If a terminal user
specifies service name being used by more than one host, the server will
attempt a connect to the host which provides the highest rating for that
service. If that connect fails, it will attempt to connect to the host
provided the next highest host rating.
For example, hosts GIDNEY and CLOYD, in addition to providing a
timesharing service as service names GIDNEY and CLOYD, each multicast
themselves as having the service name CFS. GIDNEY assigns a host rating
to name CFS of 5 whereas CLOYD assigns 3. A LAT terminal user, when
displaying the list of available LAT services, will see GIDNEY, CLOYD,
and CFS. If he connects to CFS, the server will first attempt to access
GIDNEY. If that fails, it will try CLOYD. The system manager could
regularly adjust the host ratings to distribute the load more evenly
between GIDNEY and CLOYD.
- 9 -
LAT Terminal HOST Page 10
SOFTWARE CAPABILITIES
3.9 LAT System Parameters
This section describes the parameters necessary for the operation of the
TOPS-10/20 LAT host . Parameters are divided into three types:
permanent parameters which can only be changed by a monitor rebuild,
static parameters which can be changed on TOPS-20 by editing CONFIG.CMD
followed by a system reload, and dynamic parameters which can be changed
by the LCP command interface. On TOPS-10 systems, STATIC parameters are
equivalent to PERMANENT parameters, and can only be changed by
rebuilding the monitor. On TOPS-10, all such parameters will have
defaults which can be changed by redefining the appropriate decimal
symbols at MONGEN time.
The parameter names are symbolic names and were chosen so that they
could be more easily remembered in reading this document. The actual
names which will appear in the code will be defined in the LAT Design
Specification.
The default values for all parameters can be found in Appendix A.
3.9.1 Permanent LAT Parameters
o FRAME_SIZE - The host or server guarantees that it can receive
NI datagrams of at least this size. Usually three ( 2 transmit
and 1 receive) buffers of this size are used for each LAT
circuit.
o MAX_HOST_SERVICES - This is the maximum number of LAT host
services which can be offered by this host.
o MAX_SLOTS - This is the maximum number of slots which may be
entered into a virtual circuit datagram for a given circuit.
It is agreed upon by the server and host when the virtual
circuit between them is established.
o MAX_SLOT_SIZE - This is the maximum number of bytes of data
(not including the slot header) which the server may send to
the host in any slot. This value is transmitted to the session
partner during setup of a terminal session. The session
partner will not send a slot which causes this limit to be
exceeded.
o MAX_SERVER_CACHE - This is the maximum number of servers whose
characteristics are kept in memory to be examined using the
SHOW SERVERS LCP command.
- 10 -
LAT Terminal HOST Page 11
SOFTWARE CAPABILITIES
3.9.2 Static Parameters
o DEFAULT_LAT_ACCESS_STATE - This is the initial value of the
dynamic parameter LAT_ACCESS_STATE at system startup (see
following section).
o HOST_NAME - This is the TOPS-10/20 system's node name which
must be unique within the local area network. If the system
supports DECnet, it is the DECnet node name. A node name is a
string of up to 6 characters composed from A-Z, a-z, 0-9.
There must be at least one alphabetic character. Lowercase
characters are converted to uppercase.
o HOST_NUMBER - This is a number assigned to the host in the
range 0 - 65535 intended to uniquely identify a host in the
local area. It is passed to the server when the virtual
circuit between them is established.
3.9.3 Dynamic Parameters
o HOST_CIRCUIT_TIMER - The expiration of this timer causes the
host to retransmit any unacknowledged messages to the server.
It is started when the host sends an "unsolicited" message and
is stopped when the host receives any message from the server
which acknowledges all outstanding messages.
o HOST_GROUP_CODES - This is a 32 byte (8-bits/byte) parameter
which is a bit mask defining the group codes defined for the
LAT host. Each bit represents a group code in the range from
0-255. The host has any number of codes defined. A LAT server
will not connect to the host unless both server and host have
at least one group code defined in common.
o HOST_IDENTIFICATION - This is a freely formatted ASCII string
of up to 64 characters which is transmitted to the servers in
the multicast message. It may be displayed by the terminal
users and is intended to supply the user with information about
the host's identification. The string may contain any
printable characters.
o HOST_MULTICAST_TIMER - This timer determines the interval at
which a host will transmit the multicast message to all servers
announcing the availability of the LAT terminal service.
o HOST_RETRANSMIT_LIMIT - This is the maximum number of times
that the LAT host will retransmit a message at the expiration
of HOST_CIRCUIT_TIMER. All jobs associated with the virtual
- 11 -
LAT Terminal HOST Page 12
SOFTWARE CAPABILITIES
circuit become detached when this limit is exceeded.
o HOST_SERVICE_NAME - Service names are names of services
provided by a host or group of host to terminal users at a LAT
server. Users select a service name rather that a host name
when requesting the server to initiate a terminal session. A
service name need not be unique amount all hosts. When the
save service is provided by multiple hosts, the server will
connect the user to the host with the currently highest rating.
A service name is a string of up to 16 characters composed from
A-Z, a-z, 0-9, $ (dollar), - (dash), or _ (underscore).
o HOST_SERVICE_NAME_RATING - This is rating which is assigned to
a particular service name. It may be a fixed number in the
range 0-255 or it may be DYNAMIC. If DYNAMIC, the system
15-minute load average maintained by the TOPS-20 monitor
subtracted from 255 is used.
o LAT_ACCESS_STATE
This parameter determines the accessibility to the LAT Terminal
Service to and from the local node. Values for the state are:
ON - full access permitted.
OFF - no access permitted. Any session in progress when
this state is entered is immediately terminated. All new
connects from any server are rejected.
o MAX_CIRCUITS - This is the maximum number of LAT virtual
circuits which can exist simultaneously at a node.
o MAX_CONNECTS - This is the maximum number of terminal sessions
to the local host which may simultaneously be active.
o SCHED_CYCLE_CNT - This is the frequency in number of scheduler
cycles at which a check is made for LAT activity. This
parameter can be modified only using DDT.
- 12 -
LAT Terminal HOST Page 13
SOFTWARE CAPABILITIES
3.9.4 LAT COUNTERS
The following counters are kept for all virtual circuits.
o Virtual Circuit Messages Received
o Virtual Circuit Messages Transmitted
o Illegal Virtual Circuit Messages Received
o Out of Sequence Virtual Circuit Messages Received
o Virtual Circuit Messages Retransmitted.
o Illegal Slots Received on a Virtual Circuit
These counters are kept separately for the following cases:
o Summed over all servers which have at any time connected to the
host,
o Individually for each server which has at any time connected to
the host.
- 13 -
LAT Terminal HOST Page 14
SOFTWARE CAPABILITIES
3.10 THE SYSTEM MANAGER INTERFACE
This section describes the LAT Control Program (LCP) interface which
enables a system manager to control and monitor LAT activity at a TOPS
node. To use the LCP interface, the system manager or other authorized
user runs the OPR program and types "ENTER LCP":
$OPR
OPR>ENTER LCP
LCP>
The user may now type any of the LCP commands summarized below.
3.10.1 Summary Of LCP Commands
START
STOP
SET CIRCUIT-TIMER seconds
SET GROUPS (0,1-5,....255)
SET SERVICE "service-name"{/RATING:{nn|DYNAMIC}|
/IDENTITICATION:identification-string|
nothing}
SET IDENTIFICATION "identification-string"
SET NUMBER number
SET MAXIMUM-CIRCUITS number
SET MAXIMUM-CONNECTS number
SET MULTICAST-TIMER seconds
SET RETRANSMIT-LIMIT number
CLEAR GROUPS (0,1-5,....255)
CLEAR SERVICE service-name
CLEAR IDENTIFICATION
SHOW CHARACTERISTICS
SHOW CONNECTS
SHOW COUNTERS{/ALL|
/SERVER:server-name|
nothing}
SHOW SERVER{/ALL|
server-name|
nothing}
ZERO COUNTERS{/ALL|
/SERVER:server-name|
nothing}
- 14 -
LAT Terminal HOST Page 15
SOFTWARE CAPABILITIES
3.10.2 START/STOP Commands
These commands start and stop LAT access to the local host. The issue
of the START command notifies all servers that the host is no accessible
via LAT. When a STOP command is issued, servers will no longer connect
to the host and all LAT terminal sessions existing at the time of the
STOP will be terminated.
3.10.3 SET/CLEAR Commands
The set and clear commands operate on the dynamic parameters described
earlier. The relationship between the commands and to the dynamic
parameters is straightforward. For example,
SET IDENTIFICATION identification-string
sets the parameter HOST_IDENTIFICATION
3.10.4 SHOW CHARACTERISTICS
This command displays the dynamic parameters and many of the permanent
parameters. The display format is:
LAT-Access: ON
Host Name: GIDNEY
Host Id: Large Systems Software Engineering
Host Number: 2579
LAT Protocol Version 5.0(0)
Maximum allocated circuits: 40
Currently allocated circuits: 30
Maximum active circuits: 20
Currently active circuits: 5
Maximum sessions: 128
Current sessions: 23
Retransmit Limit: 100
Circuit Timer: 2 s.
Multicast Timer: 30 s.
Maximum Service Names: 10
Maximum Frame Size: 1518
Maximum Slots: 64
Group Codes: (0,3,10,48)
Service Name(Rating) Service Identification
RONCO(200) RONCO's Timesharing Service
MR-TOPS20-CLUSTER(D) Any TOPS-20 System in MRO1-2
- 15 -
LAT Terminal HOST Page 16
SOFTWARE CAPABILITIES
3.10.5 SHOW CONNECTS
This command displays all currently active LAT terminal connections .
The information displayed includes:
o User Directory
o Terminal Identification
o Server Name
Example of the SHOW CONNECTS display:
Job Line Program Server Name User
5 212 EMACS GEIGE-AT-P10 IPERLMANN
27 31 EXEC KLAVIER ABRENDEL
- 16 -
LAT Terminal HOST Page 17
SOFTWARE CAPABILITIES
3.10.6 SHOW SERVER
This command displays the servers which have connected to the local LAT
host. The host attempts to keep server information in memory for all
servers which have connected since the last monitor load. This could
however require a very large data base so that only information for some
predefined number (see permanent parameters) is kept. When this number
is exceeded, the oldest inactive entry is deleted from the data base,
making room for a new entry.
The user has the option of specifying a switch for single line summary
of all the servers in the data base or a detailed display for a single
server.
The summary display includes:
o The Server Number
o Server Name
o Server Type
o Server's Ethernet Address
o Status
LCP>SHOW SERVER/ALL
Number Name Ethernet Address Type Status
65222 WORKSTATIONS AA-00-03-00-01-0E POSEIDON Connected
216 LABPRODUCTS AA-00-04-00-01-7C PLATO Disconnected
$
The more detailed display for a specific server additionally includes:
o Ethernet address
o Data Link buffer size
o Keep-alive timer
o LAT circuit timer
Example:
LCP>SHOW SERVER/NAME:LABPRODUCTS
Server Name(Number): LABPRODUCTS(216)
Server Location: MRO2
Server Type: PLATO
Protocol Version: 5.1(0)
Ethernet Address: A0-12-00-00-34-6E
Status: Disconnected
Max Slots: 32
Data Link Size: 1518
Circuit Timer (ms): 80
Keep-alive Timer (s): 10
- 17 -
LAT Terminal HOST Page 18
SOFTWARE CAPABILITIES
3.10.7 SHOW COUNTERS
This command allows the system manager to display counters kept by the
LAT modules. These counters are available on a "per-circuit-partner"
basis. There is a SERVER counter set for each LAT server which accessed
the local node's LAT host . The counts are kept in the server data
bases described above for the SHOW SERVERS command and therefore are
available even after the remote LAT server has disconnected from the
local node.
There is also an ALL SERVERS counter set. The ALL SERVERS set is
counted each time any SERVER set is counted. It is possible that the
sum of all SERVER counter sets is not equal to the ALL SERVERS counters
because any set can be zeroed independently or the data base may be been
flushed because data base overflow.
All counts are relative to the local LAT node. The desired set of
counts is selected by providing the appropriate command keyword.
SHOW COUNTERS/SERVER:server-name - causes the counters to be
displayed relevant to a particular server with name
server-name.
SHOW COUNTERS/ALL - causes the counters to be displayed summed
over all servers.
3.10.8 ZERO COUNTERS
Sets of LAT counters may selectively be zeroed with this command by
selecting the appropriate keyword:
ZERO COUNTERS/SERVER:server-name - zero the counters relevant
to a particular server with name server-name. Note that this
will not change the counts of the ALL SERVERS counter set.
ZERO COUNTERS/ALL - zero the counter set for ALL SERVERS. This
does not effect the counts of the individual servers.
- 18 -
LAT Terminal HOST Page 19
SOFTWARE CAPABILITIES
3.11 The LATOP% JSYS And LATOP. UUO
The LATOP% JSYS is a new JSYS to perform LAT functions for TOPS-20. The
LATOP. UUO is the corresponding monitor call for TOPS-10. There are
only two differences between the TOPS-10 and TOPS-20 implementation:
1) TOPS-20 will accept the address of an argument block in AC1, while
TOPS-10 can use any AC.
2) The TOPS-10 success return will be +2, while TOPS-20 always returns
+1 and generates an illegal instruction trap on a failure. On either
system, the error code will be returned in the AC on a failure return.
The LATOP% JSYS / LATOP. UUO functions are:
Code Symbol Explanation
0 .LASET Set local node LAT parameters. This function is used to
set the dynamic parameters for the host in the local node.
WHEEL or OPERATOR privileges are required on TOPS-20.
[1,2] or JACCT on TOPS-10.
Word Contents
0 .LAACT Length of the argument block, including this
word.
1 .LAFCN .LASET
2 .LAPRM Parameter number for parameter being set. The
following table gives the relationship of
parameter number to dynamic parameter.
1 MAX_CIRCUITS
2 MAX_CONNECTS
3 HOST_NUMBER
4 LAT_TERMINAL_ACCESS_STATE
5 HOST_RETRANSMIT_LIMIT
6 HOST_CIRCUIT_TIMER
7 HOST_MULTICAST_TIMER
10 HOST_ACCESS_CODES
11 HOST_NAME
12 HOST_IDENTIFICATION
13 HOST_SERVICE_NAME and
HOST_SERVICE_NAME_RATING and
HOST_SERVICE_DESCRIPTION
3 .LAVAL A function dependent parameter value. For
parameters 1-7 this is the new parameter value.
For parameter 10 this is the address of a 256
bit mask representing the access codes to be
set. For all others, this is an ASCIZ string
pointer to the string which represents the
parameter. The bit mask is arranged 32 bits per
- 19 -
LAT Terminal HOST Page 20
SOFTWARE CAPABILITIES
word, left adjusted. This argument word is
ignored for all other parameters.
- 20 -
LAT Terminal HOST Page 21
SOFTWARE CAPABILITIES
4 .LAQUA For parameter 13 only, a set of flags in the
left half and the service rating in the right
half. The meaning of the flag bits is:
Symbol Bit
LA%RAT 0 Set the rating as specified in the
right half of this argument word. If
all ones, the rating is set to
DYNAMIC.
LA%DSC 1 Set the service description as
specified in the next argument word.
If any of these bits is set, the value for the
corresponding service parameter is always set.
If a particular bit is not set, the action taken
depends on whether or not the service name
previously existed: if previously existent, the
parameter value is not changed. Otherwise the
default for the parameter is set.
4 .LADSC An ASCIZ string pointer to the service
description string to be set. If LA%DSC is set
and this parameter is zero, the current service
description will be cleared.
1 .LACLR Clear local node's LAT parameters. This function is used
to clear the dynamic parameters for the host in the local
node. WHEEL or OPERATOR privileges are required on
TOPS-20, [1,2] or JACCT on TOPS-10.
Word Contents
0 .LAACT Length of the argument block, including this
word.
1 .LAFCN .LACLR
2 .LAPRM Parameter number for parameter being cleared.
Parameter numbers are the same as those defined
for the .LASET function. Parameters 4 and 11
cannot be cleared. To change them, the .LASET
function must be used.
3 .LAVAL Address of a 256 bit mask indicating which
access codes are to be cleared (parameter 10) or
an ASCIZ pointer to the service name to be
cleared (parameter 13). The bit mask is
arranged 32 bits per word, left adjusted. This
argument word is ignored for all other
parameters.
- 21 -
LAT Terminal HOST Page 22
SOFTWARE CAPABILITIES
2 .LASCH Show the local node's LAT parameters. This function is
used to show the dynamic, static, and permanent parameters
for the host in the local node.
Word Contents
0 .LAACT Length of the argument block, including this
word.
1 .LAFCN .LASCH
2 .LABCT Count of the show buffer provided by the user
into which the data is to be placed in the right
half. Returned with the buffer count actually
used in the left half.
3 .LABFA3 Address of the show buffer. The format of the
buffer returned to the user is given in Appendix
B.
3 .LASTC Show connects. This function is used to show all currently
active LAT terminal connections at the local node.
Word Contents
0 .LAACT Length of the argument block, including this
word.
1 .LAFCN .LASTC
2 .LABCT Count of the show buffer provided by the user
into which the data is to be placed in the right
half. Returned with the buffer count actually
used in the left half.
3 .LABFA Address of the show buffer. The format of the
buffer returned to the user is given in Appendix
B.
- 22 -
LAT Terminal HOST Page 23
SOFTWARE CAPABILITIES
4 .LASAS Show Adjacent Servers. This function is used to return
information about one or more LAT servers which have access
the local LAT host. Information for as many servers as
possible is kept in memory but if the data base overflows,
the oldest entry is deleted to make room for the latest.
Word Contents
0 .LAACT Length of the argument block, including this
word.
1 .LAFCN .LASAS
2 .LABCT Count of the show buffer provided by the user
into which the data is to be placed in the right
half. Returned with the count actually needed
in the left half.
3 .LABFA Address of the show buffer.
4 .LAQUA ASCIZ pointer to server name if information
about a specific server is requested. Zero if a
summary of all servers is requested.
- 23 -
LAT Terminal HOST Page 24
SOFTWARE CAPABILITIES
5 .LASCO Show Counters.
Word Contents
0 .LAACT Length of the argument block, including this
word.
1 .LAFCN .LASCO
2 .LABCT Count of the show buffer provided by the user
into which the data is to be placed in the right
half. Returned with the buffer count actually
used in the left half.
3 .LABFA Address of the show buffer.
4 .LAQUA ASCIZ pointer to server name for a specific
server, zero for the ALL SERVERS counter set.
5 .LAZRO Zero Counters.
Word Contents
0 .LAACT Length of the argument block, including this
word.
1 .LAFCN .LAZRO
2 .LABCT unused
3 .LABFA unused
4 .LAQUA Server number for a specific server, zero for
the ALL SERVERS counter set.
LATOP% ERROR MNEMONICS:
ARGX02: Invalid function
ARGX04: Argument block too small
CAPX1: WHEEL or OPERATOR capability required.
LATX01: Buffer size too small for available data.
LATX02: LAT parameter value out of range.
LATX03: LAT is not operational.
LATX04: Invalid or unknown LAT server name.
LATX05: Invalid LAT parameter.
LATX06: Invalid LAT parameter value.
LATX07: Invalid or unknown LAT service name.
LATX08: Insufficient LAT Resources.
LATX09: LAT Host name already set.
LATOP. UUO ERROR MNEMONICS:
LAIPN%: Invalid parameter number
LAIVF%: Invalid function
LAABS%: Argument block too small
LAPRV%: Not enough privileges
LAISP%: Invalid string pointer argument
LASTL%: String too long
LASVR%: Unknown LAT server name
LAIPV%: Invalid parameter value
- 24 -
LAT Terminal HOST Page 25
SOFTWARE CAPABILITIES
LASVC%: Unknown LAT service name
- 25 -
LAT Terminal HOST Page 26
SOFTWARE CAPABILITIES
3.12 MODIFICATIONS TO TOPS-20 SYSTEM MODULES
3.12.1 LAT Initialization At System Startup
The initialization routine is called from MEXEC at system startup to
perform the following functions:
o Set up data bases
o Open a LAT NI port,
o If at least one host service supported, set up the default
multicast message used to advertise the host services,
o Queue receive buffers to the NIDLL for incoming connects.
3.12.2 Addition Of Terminal Type LAT
A new terminal type for the LAT host is defined. This requires changes
to the following modules:
In TTYDEF.MAC:
o add flags .LHFLG, which when set to 1 indicate existence of LAT
host terminal support.
o add terminal type LT to the TDCALL macro definition,
In PROLOG.MAC:
o add a definition for TT.LTH for the host LAT terminal type,
o increment by one the number of terminal types NLTYPS,
In TTYSRV.MAC:
o an entry must be added to PARTBL and DDLTBL in TTYSRV for LAT
terminals,
In PARAMS.MAC
o Define NTTLAT, the number of LAT host terminals.
- 26 -
LAT Terminal HOST Page 27
SOFTWARE CAPABILITIES
3.12.3 Modifications To TTYSRV
3.12.3.1 Device Dependent TDCALLs
3.12.3.1.1 Start Output For A LAT HOST Line
This routine is called from STRTOU when there are characters in the
output buffer of a LAT terminal.
The call format is:
TDCALL D,<<LT,LTSTRO>>
T1/LAT Line Number
T2/Address of TTY dynamic data block
3.12.3.1.2 Clear Output Buffer For A LAT HOST Line
This routine is called in TTCBF2 to clear terminal output buffers in the
LAT server.
The call format is:
TDCALL D,<<LT,LTCOBF>>
T1/LAT Line Number
T2/Address of TTY dynamic data block
3.12.3.1.3 Enable/Disable XON/XOFF Recognition For A LAT HOST Line
This routine is called at several places to enable or disable
recognition of the XON/XOFF character in the terminal input stream by
the LAT server.
The call format is:
TDCALL D,<<LT,LTEXF>>
T1/LAT Line Number
T2/Address of TTY dynamic data block
3.12.3.2 LAT Scheduler Routine LATSCH
Every SCHED_CYCLE_CNT scheduler cycles, LATSCH is called to process any
LAT run messages queued by the VC Receiver and to transfer any terminal
data from terminal buffers to slots for transmission on the NI.
Calling format is:
- 27 -
LAT Terminal HOST Page 28
SOFTWARE CAPABILITIES
CALL LATSCH
with no arguments
returns +1 always
3.12.4 SETSPD
The SETSPD program must be modified to understand a CONFIG.CMD commands:
LAT NODE lat-host-name lat-host-number
LAT STATE default-lat-access-state
and execute the LATOP% JSYS to set HOST_NAME, HOST_NUMBER, and
DEFAULT_LAT_ACCESS_STATE parameters.
3.12.5 Major External References
3.12.5.1 TTYSRV
Below is the list of calls to major routines in TTYSRV from TOPS-20 LAT.
o Routine called by the LAT host to enter a slot character into a
terminal input buffer.
T1/ character
T2/ address of TTY dynamic data block
CALL TTCHID
returns +1 always
o Routine called by the LAT host to fetch a character from the
terminal output buffer to be put into a slot.
T2/ address of TTY dynamic data block
CALL TTSND
returns +1: no output character available
returns +2: T1/ output character
3.12.5.2 NIDLL
The following NIDLL interface calls are used:
o DLLOPN - open NI portal
This call supplies the NIDLL with a callback routine address
for
- 28 -
LAT Terminal HOST Page 29
SOFTWARE CAPABILITIES
o NI datagram transmit complete
o NI receive datagram available
o NI state change
o DLLEPT - enable protocol type
The LAT protocol ID as supplied in the interface call is:
UNPRO: 00460 (hexidecimal)
o DLLDPT - disable protocol type
o DLLCLO - close NI protal
o DLLDPA - Enable multicast ID
The LAT multicast ID as supplied in the interface call is:
UNSAD: 000AB (hexidecimal)
UNSAD + 1: 00003 (hexidecimal)
o DLLRVA - Disable multicast ID
o DLLSNM - Send NI Datagram
o DLLSRB - Specify Receive Buffer
- 29 -
LAT Terminal HOST Page 30
SOFTWARE CAPABILITIES
3.13 MODIFICATIONS TO TOPS-10 SYSTEM MODULES
3.13.1 LAT Initialization At System Startup
The initialization routine is called from SYSINI at system startup to
perform the following functions:
o Set up data bases
o Open a LAN NI port,
o If at least one host service supported, set up the default
multicast message used to advertise the host services,
o Queue receive buffers to the NIDLL for incoming connects.
3.13.2 Addition Of Terminal Type LAT
A new terminal type for the LAT host is defined. This requires changes
to the following modules:
In NETGEN dialog:
o Ask question "Number of LAT terminals"
o Generate symbol M.LATN = number of LAT terminals
In COMDEV:
o Define global symbol NTTLAH to be equal to M.LATN from MONGEN
dialog.
o Allocate bit table NFRSBQ to keep track of allocated LAT slots.
o At SC'N'TIC add call to LATSTO to start I/O on LAT terminals.
o At SC'N'SEC add call to LATSEC for once a second code in
LATSRV.
In SCNSER:
o Define new LDB offset LDBLAT which redefines LDBTTD to point to
a LAT data structure for a particular terminal.
o Define new code APCLAT to indicate the terminal is a LAT.
o Define new bit LDLLAT to indicate a LAT terminal.
o Define new bit LPLLXF and pointer LDPLXF to indicate whether
LAT terminal has enabled auto XON/XOF.
In UUOSYM:
o Add symbols for LATOP. UUO
- 30 -
LAT Terminal HOST Page 31
SOFTWARE CAPABILITIES
3.13.3 SCNSER Dispatch Table LATDSP Entries For LATSRV
o Entry (2) LATSEC once a second call from SC'N'SEC
This routine will only run on CPU0 to do once a second LAT
services.
The calling format is:
PUSHJ P,LATDSP+ISRCHK
return: +1 always
o Entry (7) LATREM called from SCNSER for remote terminal
functions. Currently, the only function supported is to clear
output buffers when a user types ^O.
U/ LDB address
T1/ ISRREM
T3/ CODE (currently, the only code supported is 3)
PUSHJ P,@LDBISR(U)
return: +1 always
3.13.4 LAT Scheduler Routine LATSCH
On every tick, SC'N'TIC calls LATSTO. On CPU0, every SCHED_CYCLE_CNT
ticks, LATSTO calls LATSCH to process any LAT run messages queued by the
VC receiver and to transfer any terminal data from terminal buffers to
slots for transmission on the NI.
Calling format is:
PUSHJ P,LATSCH
with no arguments
return: +1 always
3.13.5 Major External References
3.13.5.1 SCNSER
Below is a list of calls to major routines in SCNSER from TOPS-10 LAT.
o Routine called by the LAT host to enter a slot character into a
terminal input buffer.
T3/character
U/LDB address of TTY line
- 31 -
LAT Terminal HOST Page 32
SOFTWARE CAPABILITIES
PUSHJ P,RECPTY
return +1 always
o Routine called by LAT to fetch a character from the TTY output
chunks to be put in a slot.
U/LDB address
PUSHJ P,XMTCHR
returns +1: no output character available
returns +2: T3/ output character
o Routine to find next terminal line which needs something done.
T1/ address of SCNSER queue header for active LAT lines
PUSHJ P,TOTAKE
returns +1: No lines in queue.
returns +2: U/LDB address of line which needs something done.
3.13.5.2
NIDLL
The NIDLL interface is the same as described for TOPS-20.
- 32 -
LAT Terminal HOST Page 33
PUBLICATIONS
4.0 PUBLICATIONS
The following manuals must be updated:
4.1
TOPS-20 manuals
See TOPS-20 V6.1 Documentation Plan
4.2
TOPS-10 manuals:
o TOPS-10 Monitor Calls Manuals 1 and 2 - Add a description of
the new LATOP. UUO
o TOPS-10 Software Installation Guide - Add references to LAT
installation at appropriate places.
o TOPS-10 Operator's Guide and Operator's Command Language
Reference Manual - Add a description of the LCP Command
Interface.
5.0 PACKAGING
LAT support is to be bundled with the standard TOPS-20 monitor, starting
with Release 6.1, and the TOPS-10 monitor starting with Version 7.03.
There will be no visible changes in the packaging other than the
addition of a monitor module and the LCP files.
- 33 -
LAT Terminal HOST Page 34
INSTALLABILITY
6.0 INSTALLABILITY
Installation will be an integral part of the TOPS-10/20 monitor
installation procedure. The LAT host is designed to be operational
after system startup with minimal installation action. Minimally the
HOST_NAME must be defined. If the system has DECnet installed, the
DECnet node name is used. If DECnet is not installed, the LAT host name
must be supplied as described above.
Two steps will be required to make LAT operational on TOPS-10:
o The number of LAT terminals must be specified in the NETGEN
portion of the MONGEN dialog.
o The LAT_TERMINAL_ACCESS_STATE must be set ON in the SYSTEM.CMD
file using the LCP command interface.
7.0 EASE OF USE
Terminal users will need to obtain the documentation covering the
operation of a specific terminal server such as the POSEIDON. This
document is not provided by this product. Once connected to a TOPS-20
system, the user should perceive the system just as if he were connected
using a local terminal in the manner to which he is accustomed.
Operators and System Managers also do not need to know details of the
LAT protocol. In order to use the LAT terminal service features
optimally, they should understand how to use the LAT dynamic parameters
in a way best suited to the local area network. There topics will be
covered in the Operator's Guide and the System Manager's Guide.
- 34 -
LAT Terminal HOST Page 35
PERFORMANCE
8.0 PERFORMANCE
8.1 TOPS-10/20 Performance
The load on a TOPS-10/20 system of LAT terminals for a low number of LAT
virtual circuits should not be noticeably greater than that for the
corresponding number of FE terminals. As the number of circuits
increases, the load will most likely increase above that for FE
terminals. Performance measurements will be required to determine what
value to set for the maximum number of virtual circuits (MAX_CIRCUITS)
to support in order not to significantly degrade TOPS-10/20 performance.
8.2 NI Performance
The LAT Ethernet utilization is lowest when the ratio of the number of
terminals to the number of LAT virtual circuits is high. The following
example illustrates this. Suppose that a given local area network
supports 128 LAT interactive terminals and a single host. The worst
case Ethernet usage occurs when all terminals are outputting at 9600
baud. A single such terminal uses .11% of the total NI bandwidth. This
includes both Ethernet and LAT protocol overhead. If all 128 terminals
are on different servers, the NI utilization is 14.1%. If these
terminals are distributed evenly over 8 servers, the utilization drops
to 11.0%. If distributed over 2 servers, it drops to 6.2%. This more
significant drop is due more to the fact that the LAT buffer scheme
restricts total NI utilization for a single server to be 3.1%.
Under normal conditions, terminal activity is much lower than suggested
by the above example. The average NI utilization should therefore be
much lower than the above figures indicate.
- 35 -
LAT Terminal HOST Page 36
RELIABILITY
9.0 RELIABILITY
To improve the reliability, LAT will participate fully in the inhouse
LOAD TEST and the FIELD TEST for TOPS-20 Version 6.1 and TOPS-10 Version
7.03. Software errors of the following severity will be corrected
before SDC submission:
o Errors which cause TOPS-10/20 to crash.
o LAT protocol violations
o Errors which cause performance to degrade to such a point that
LAT terminal usage becomes infeasible. Infeasible means that
users prefer to use any other terminal type rather than LAT to
accomplish a task.
- 36 -
LAT Terminal HOST Page 37
MAINTAINABILITY
10.0 MAINTAINABILITY
TOPS-10/20 LAT will be well documented in the TOPS-10/20 LAT Design
Specification. All code will be well commented.
11.0 MAINTENANCE SERVICE
Because LAT will be bundled as part of TOPS-20 Version 6.1 and TOPS-10
Version 7.03, the maintenance service for TOPS-10/20 LAT will be
included as part of the standard maintenance service for TOPS-10/20
monitors.
12.0 COMPATIBILITY
The TOPS-10/20 LAT host will be compatible with the corporate LAT
terminal servers such as the Poseidon and Pluto.
13.0 EVOLVABILITY
13.1 Extendability
TOPS-10/20 LAT will be designed so that any future service classes such
as LAT line printer service class can be added without a redesign.
13.2 Commonality Between TOPS-10 And TOPS-20
The TOPS-10/20 LAT components will be designed to permit maximum
commonality of code. The following characteristics will contribute to
this:
o The NI interface for TOPS-10 and TOPS-20 will be identical,
o The LATOP% JSYS can be changed to the LATOP. UUO easily since
the arguments are all defined in an argument block, a format
which is compatible to TOPS-10,
o Effort will be made in the design to modularize the code such
that system dependent functions are contained in a small number
of modules.
The VC Receiver, Slot Demultiplexor, Slot Multiplexor, and VC
Transmitter will be directly transportable without change. The LCP
program should only require the mapping of JSYS calls to UUO calls.
- 37 -
LAT Terminal HOST Page 38
EVOLVABILITY
Attention to the TOPS-20/TOPS-10 Galaxy differences may be required in
the parsing of LCP commands.
The interface to TOPS-20 TTYSRV must be substituted with an interface to
TOPS-10 SCNSER.
MONGEN (rather than INITIA, the SETSPD counterpart on the -10) will be
used to set the LAT host name for the case that a TOPS-10 system does
not support DECnet-10.
14.0 COSTS
All costs are bundled into the costs for TOPS-20 Version 6.1 or TOPS-10
Version 7.03.
15.0 TIMELINESS
LAT host support will be available with TOPS-20 Release 6.1 and TOPS-10
Version 7.03.
16.0 CONSTRAINTS & TRADE-OFFS
- 38 -
APPENDIX A
LAT PARAMETER VALUES
A.1 PERMANENT AND STATIC PARAMETER VALUES
The following table shows the range of permissible values and the
recommended value for the permanent LAT parameters.
PERMISSIBLE RECOMMENDED
PARAMETER RANGE VALUE USED
-----------------------------------------------------------------
FRAME_SIZE 576-1518 1518
MAX_HOST_SERVICES 0-254 8
MAX_SERVER_CACHE 20
MAX_SLOTS 64
MAX_SLOT_SIZE 1-255 40
- 39 -
LAT PARAMETER VALUES Page A-2
DYNAMIC PARAMETERS
A.2 DYNAMIC PARAMETERS
The following table gives the parameter number for the dynamic
parameters necessary to perform the SET and CLEAR LATOP% functions. The
table also shows the system startup defaults.
PARAMETER PARAMETER DEFAULT
NUMBER VALUE VALUE
-------------------------------------------------------
1 MAX_CIRCUITS 10
2 MAX_CONNECTS 40
3 HOST_NUMBER DECnet Node Number
4 LAT_TERMINAL_ACCESS_STATE ON
5 HOST_RETRANSMIT_LIMIT 60
6 HOST_CIRCUIT_TIMER 1 second
7 HOST_MULTICAST_TIMER 30 seconds
10 HOST_GROUP_CODES Group 0 enabled
11 HOST_NAME DECnet Node Name
12 HOST_IDENTIFICATION MONNAM.TXT
13 HOST_SERVICE_NAME HOST_NAME
HOST_SERVICE_NAME_RATING 255
HOST_SERVICE_DESCRIPTION MONNAM.TXT
- 40 -
APPENDIX B
SHOW BLOCK FORMATS
- 41 -
SHOW BLOCK FORMATS Page B-2
FORMAT FOR THE .LASCH FUNCTION
B.1 FORMAT FOR THE .LASCH FUNCTION
The show buffer format for the LAT show characteristics function is
shown below.
35 18 0
+-----------------------+-----------------------+
| MAX_ALLOC_CIRCUITS | N_ALLOC_CIRCUITS |
+-----------------------+-----------------------+
| MAX_ACTIVE_CIRCUITS | N_ACTIVE_CIRCUITS |
+-----------------------+-----------------------+
| MAX_CONNECTS | N_CONNECTS |
+-----------------------+-----------------------+
| HOST_NUMBER |LAT_TERMINAL_ACCESS_STA|
+-----------------------+-----------------------+
| HOST_RETRANSMIT_LIMIT | HOST_CIRCUIT_TIMER |
+-----------------------+-----------------------+
| HOST_MULTICAST_TIMER | RESERVED |
+-----------------------+-----------------------+
| HI_PROTOCOL_VERSION | LO_PROTOCOL_VERSION |
+-----------------------+-----------------------+
| PROTOCOL_ECO | CUR_PROTOCOL_VERSION |
+-----------------------+-----------------------+
| MAX_SLOT_SIZE | MAX_SLOTS |
+-----------------------+-----------------------+
| FRAME_SIZE | MAX_SERVICES |
+-----------------------+-----------------------+
| HOST_GROUP_CODES (8 words) |
| |
+-----------------------+-----------------------+
| HOST_NAME count | HOST_IDENT count |
+-----------------------+-----------------------+
| HOST_NAME (2 words) |
| |
+-----------------------+-----------------------+
| HOST_IDENTIFICATION (13 words) |
| |
+-----------------------+-----------------------+
| Service Blocks (19 words/group name) |
| |
+-----------------------+-----------------------+
- 42 -
SHOW BLOCK FORMATS Page B-3
FORMAT FOR THE .LASCH FUNCTION
Service block format is:
+-----------------------+-----------------------+
| HOST_SERVICE_NAME_RATING |
+-----------------------+-----------------------+
| SERVICE_NAME count |SERVICE_DESCRIPTION cnt|
+-----------------------+-----------------------+
| SERVICE_NAME (4 words) |
| |
+-----------------------+-----------------------+
| SERVICE_DESCRIPTION (13 words) |
| |
| |
+-----------------------+-----------------------+
- 43 -
SHOW BLOCK FORMATS Page B-4
FORMAT FOR THE .LASTC FUNCTION
B.2 FORMAT FOR THE .LASTC FUNCTION
There is one connect block returned for each LAT connection.
The connect block format is:
+-----------------------+-----------------------+
| Terminal Designator |
+-----------------------+-----------------------+
| Server Name Count | Indeterminate |
+-----------------------+-----------------------+
| Server Name (4 words) |
| |
| |
+-----------------------+-----------------------+
- 44 -
SHOW BLOCK FORMATS Page B-5
FORMAT FOR THE .LASAS FUNCTION
B.3 FORMAT FOR THE .LASAS FUNCTION
A full format block is returned when the .LASAS request specifies a
server name in argument .LAQUA.
+-----------------------+-----------------------+
| Server Ethernet Address (2 words) |
| |
+-----------------------+-----------------------+
| FRAME_SIZE | SERVER_VERSION |
+-----------------------+-----------------------+
| MAX_SLOTS | indeterminate |
+-----------------------+-----------------------+
| CIRCUIT_TIMER | KEEP-ALIVE_TIMER |
+-----------------------+-----------------------+
| PRODUCT_TYPE | STATE |
+-----------------------+-----------------------+
| SERVER_NUMBER | SERVER_NAME count |
+-----------------------+-----------------------+
| SERVER_LOCATION count | unused |
+-----------------------+-----------------------+
| SERVER_NAME (4 words) |
| |
+-----------------------+-----------------------+
| SERVER LOCATION (4 words) |
| |
+-----------------------+-----------------------+
A short format block is returned when the .LASAS request specifies no
server name.
+-----------------------+-----------------------+
| SERVER_NUMBER | SERVER_NAME count |
+-----------------------+-----------------------+
| SERVER_NAME (4 words) |
| |
+-----------------------+-----------------------+
| ETHERNET_ADDRESS (2 words) |
| |
+-----------------------+-----------------------+
- 45 -
SHOW BLOCK FORMATS Page B-6
COUNTER BLOCK FORMAT
B.4 COUNTER BLOCK FORMAT
+------------------+------------------+
| Messages Received |
+------------------+------------------+
| Messages Sent |
+------------------+------------------+
| Messages Retransmitted |
+------------------+------------------+
| Receive Sequence Errors |
+------------------+------------------+
| Illegal Messages Received |
+------------------+------------------+
| Resource Failures |
+------------------+------------------+
[End of xxxx]
- 46 -
DNA-APPROVED-LATSPEC.MEM
Local Area Transport Architecture - internal use only
Title: Local Area Transport Architecture
File: DELPHI::WRKD$:[MANN.DOC]BEM061.MEM
Date: 21-Dec-82
Author: Bruce Eric Mann
Abstract:
A simple, efficient, transparent model for exchanging data between
terminals connected to terminal servers and host operating system processes
is described. The model is termed Local Area Transport (LAT). LAT is
carefully tailored to take advantage of the environment offered by Local
Area Networks, such as the Ethernet data link, but maintains much of the
simplicity of traditional methods of connecting terminals and hosts.
Rev Description Author Date
0.0 Started draft Mann 20-Dec-82
0.1 draft state table modifications Mann,Lauck,Duffy 24-Jan-83
0.2 Finished draft for implementor's review Mann,Lauck 02-Feb-83
0.3 Updated draft based on Feb 15 review Mann 03-Mar-83
1.0 Updated draft based on June 3 review Mann 08-Jun-83
1.1 Updated draft based on June 3 review Mann 25-Aug-83
( DRG first reviewed this version)
1.2 Update based on September DRG review Mann 19-Dec-83
Some new material added.
1.3 Update based on January DRG review Mann 04-Feb-84
Digital Equipment plans to make the LAT protocol public next year. Until
then this specification is for interal use only. This specification should
not be distributed to any person who is not a Digital employee.
Local Area Transport Architecture - internal use only
I have more precisely defined the meaning of Group Code 0 to reflect
the consensus of current developers. This issue was not discussed by the
DRG.
I defined legal names based on what legal VMS file names are and
included one extra character "-".
Local Area Transport Architecture - internal use only Page 5
SCOPE 03 May 84
1.0 SCOPE
This document presents a communication architecture for an Ethernet local
area network. The architecture is called Local Area Transport (LAT). LAT is
utilized as a low level communication service upon which other higher level
services are layered.
This document presents LAT structured as a communication service for
terminal servers and host operating systems. The reason for presenting a
specific model is to provide a clear example of how the architecture can be
implemented. In fact, the architecture is appropriate to applications other
than terminal to host communications.
This document assumes that the reader is familiar with the Ethernet,
communications concepts, and practical problems accompanying implementations
of distributed services.
This document describes a data transport service provided to the host and
the terminal server. The level of detail is sufficient to allow the
interoperability of hosts and servers. This document does not describe any
specific issues involved in building products that utilize LAT as a transport
service. Those issues are addressed in detail by service classes.
Service classes are documented in appendices. Service classes define
message formats and algorithms which extend the basic services provided by
the LAT architecture. These extensions address problems that are unique to
the service class or to the implementation of a product.
The first five sections present an overview of the architecture.
2.0 PURPOSE
The purpose of this document is to specifiy the LAT architecture in
sufficient detail to allow interoperable implementations to be built based on
this document.
The purpose of the LAT protocol is to bias every design decision in favor
of simplicity, while simultaneously preserving the goals of the LAT
architecture.
- 5 -
Local Area Transport Architecture - internal use only Page 6
INTRODUCTION 03 May 84
3.0 INTRODUCTION
Local area networks allow computing resources to be physically distributed
throughout a facility, which satisfies the needs of the facility, instead of
the needs of the computing resources.
A second property of local area networks is dramatically reduced cabling
costs. All of the distributed computing resources are connected to a common
coaxial cable.
An Ethernet can have as many as 1000 attachments on a single coaxial cable
over 1 mile in length. A potential problem in such installations is the
limited bandwidth available on the Ethernet (about 7 usable megabits/second).
For this reason, communication architectures operating in this shared
environment should allocate the available bandwidth efficiently, fairly and
predictably among the many systems. This is an explicit goal of the LAT
architecture.
It is not the goal of the LAT architecture to specify a transport
mechanism sufficient for the needs of a large number of applications.
Instead, the architecture makes simplifying assumptions appropriate to a
subset of possible applications. The most important assumptions are:
o communication is local to a single Ethernet. This eliminates the
need for any routing capability.
o the nature of the communication is inherently asymmetric. This
simplifies connection management and greatly simplifies the host
implementation.
o the bandwidth of the Ethernet is much greater than the bandwidth
needed by an application. This assumption results in a timer based
protocol.
These assumptions applied to the problem of connecting terminals to hosts
allow the following tradeoffs:
o Minimize the load on the host operating systems by transferring load
to the terminal server.
o Reduce terminal server complexity to allow very low cost hardware
implementations, or increase the complexity to achieve a value added
service in the terminal server.
o Allow a user terminal to attach to any host in the local area, or
restrict the users view to a subset of the available hosts.
o Increase the level of performance at the terminal servers and limit
the total number of terminal servers simultaneously using the
Ethernet, or decrease the level of performance at the terminal
servers allowing a greater number of terminal servers to utilize the
shared Ethernet.
- 6 -
Local Area Transport Architecture - internal use only Page 7
INTRODUCTION 03 May 84
LAT views the Ethernet as a local device, not as a network. This approach
allows the implementation of the architecture to be confined to low levels of
the host operating systems. It also minimizes the cost of installation and
support of the computing resources by requiring very little training on the
part of the network manager and users.
It is not a goal of this architecture to provide any level of security
beyond that provided by the Ethernet itself. Extensions to this architecture
in the areas of authentication and data link encryption have been
anticipated, but not realized.
- 7 -
Local Area Transport Architecture - internal use only Page 8
TERMINOLOGY, ASSUMPTIONS AND NOTATION 03 May 84
4.0 TERMINOLOGY, ASSUMPTIONS AND NOTATION
o local area (network) - the topology defined by the set of logically
equivalent processors directly attached to a shared interconnect.
o terminal server - a dedicated function system ( processor,
controller ) providing attachment points for terminals in the local
area via a responsive virtual circuit service spanning the shared
interconnect.
o host node (operating system) - a special case of an integrated set
of server systems which implement an operating system.
o host service (application services) - Named services offered by
applications. There can be many such application services
associated with each individual host node.
o port - the adapter between a processor and interconnect which
implements the Ethernet data link layer.
o datagram - an atomic unit of information exchanged by local area
networks. In the Ethernet implementation, datagrams are required to
have a constant format consisting of: destination port address,
source port address, protocol type, data and an error detection
code. Datagrams may get corrupted on the Ethernet, and are
therefore not always delivered to the destination address.
o virtual circuit - a logical stream of data, established between a
terminal server and a host node with the characteristic that data
delivery is bidirectional, sequential, timely, and error-free. On
Ethernet, a virtual circuit service is a value added service since
the Ethernet data link provides a datagram service.
o message - a datagram under virtual circuit error control.
o slot - a segment of a message used to commuicate data between a
terminal on a terminal server and a host service. Messages may have
zero or more slots.
o session (connection) - a transient association which allows a
terminal server to exchange data reliably with a single host service
utilizing an underlying shared virtual circuit.
o flow control - a set of rules applied to processes which prevents a
transmitting process from sending data to a receiving process that
is not prepared to buffer the transmitted data.
o broadcast - as applied to data links, broadcast capability refers to
the ability of any one port to address all other ports
simultaneously with a single datagram.
- 8 -
Local Area Transport Architecture - internal use only Page 9
TERMINOLOGY, ASSUMPTIONS AND NOTATION 03 May 84
o multicast - as applied to data links, multicast capability refers to
the ability of any one port to address a sub-set of all other ports
simultaneously with a single datagram.
o users - the consumers of the services provided by this architecture.
As applied in this document, the term "user" is an abstraction that
refers to the set of routines interfacing to the highest level of
the architecture. The services provided to users are connection
management and data transfer.
LAT assumes the Ethernet has very predictable attributes. LAT's
performance depends on "low probability" events occuring infrequently. LAT's
correctness depends on very "low probability events" not occurring at all.
If "low probability" means less than one event every hour, and "very low
probability" means less than one event every year, then LAT assumes the
Ethernet data link has the following attributes:
o a low probability of datagram duplication
o a low probability of datagrams being received in an order different
from that in which they were transmitted
o a low probability of datagrams being corrupted (and therefore not
delivered)
o a low probability of datagrams being delayed more than 10
milliseconds between source and destination ports
o a very low probability of datagrams being delayed more than 10
seconds between source and destination ports
o a very low probability of datagrams being delivered to the wrong
destination address
o a very low probability of datagrams being delivered which contain
undetected corrupted data
o a bandwidth greater than 1 megabit/second
o a broadcast/multicast capability (see above)
- 9 -
Local Area Transport Architecture - internal use only Page 10
TERMINOLOGY, ASSUMPTIONS AND NOTATION 03 May 84
All numeric values are specified in decimal.
Character string literals are quoted as in "DELPHI". Occasionally,
phrases and terms that are conceptually important to the architecture are
quoted, "balanced mode" for instance.
Capitalized names are architecturally defined, an example is
SERVER_CIRCUIT_TIMER. Lower case names are function names or events. For
example: transmit_unacknowqledged_queue is a function name and Send_data is
an event. Many of these names appear in the document index.
- 10 -
Local Area Transport Architecture - internal use only Page 11
OVERVIEW OF ARCHITECTURE 03 May 84
5.0 OVERVIEW OF ARCHITECTURE
The major components of the architecture are the terminal server, the host
node, the local area network and software modules in the terminal server and
host.
The principal functional capability provided by the architecture is the
logical connection of terminals to host nodes. A vertical view of the
topology would reveal:
+----------------------------------------------------------------+
| H O S T S E R V I C E S |
+--------+-----+--------+-----+--------+----------------+--------+
| Node 1 | | Node 2 | | Node 3 | . . . | Node n |
+--------+ +--------+ +--------+ +--------+
^ ^ ^ ^
| | | |
v v v v
Ether<--------------------------------------------------------------->net
^ ^
| |
v v
+-----------------+ +-----------------+
|Terminal Server 1| . . . |Terminal Server m|
| o o o o o o o o | | o o o o o o o o |
+-|-|-|-|-|-|-|-|-+ +-|-|-|-|-|-|-|-|-+
| | | | | | | | | | | | | | | |
to terminals to terminals
Each of the users of the terminals on "terminal server 1" could be
connected to a different host service simultaneously. Or they could all be
utilizing the same host service. The same holds true for all of the other
terminal servers.
It is possible for a single system to operate simultaneously as both a
host implementation and a terminal server implementation. If such a system
wishes to allow local terminal users to transparently connect to the local
host services, Ethernet messages transmitted by the local system must be
delivered to the local system.
- 11 -
Local Area Transport Architecture - internal use only Page 12
OVERVIEW OF ARCHITECTURE 03 May 84
The Ethernet itself is layered:
m u l t i p l e c o m m u n i c a t i o n a r c h i t e c t u r e s
| ^ | ^ | ^
v | v | v |
--- +---------------+ +----------------+ +----------------+
^ |protocol user 1| | protocol user 2| .. | protocol user n|
| +---------------+ +----------------+ +----------------+
Data \ | /
Link \ | /
Layer +------------------------------------------------------------+
| |the port delivers datagrams to the different protocol users |
v | based upon the protocol type field in received datagrams |
--- +------------------------------------------------------------+
^ ^
| |
| v
Physical -----------------------------------------------------
Layer <--- Ethernet datagrams --->
| -----------------------------------------------------
| ^ ^ ^
v | | |
--- v v v
o t h e r E t h e r n e t p o r t s
As shown above, the Ethernet data link layer (the port hardware and
driver) and the Ethernet physical layer (the cable) can simultaneously
support LAT and other communication architectures. This is accomplished by
assigning each communication architecture a unique protocol type in the
Ethernet datagrams. The Ethernet ports use the Ethernet protocol type field
of receive datagrams to distinguish between the LAT protocol and other
protocol users of the Ethernet.
- 12 -
Local Area Transport Architecture - internal use only Page 13
OVERVIEW OF ARCHITECTURE 03 May 84
Datagrams are transmitted and received over the Ethernet by an
implementaion of the LAT architecture. The LAT architecture could be viewed
as a layered architecture:
Terminals Application Processes
+------+-------+------+ +------+-------+------+
|user-1| . . . |user-n|<- Users Services ->|user-a| . . . |user-N|
->+------+-------+------+ +------+-------+------+
L | Terminal Server |<-Terminal Server and Host->| Host |
| Slot Layer |processes pass data & control| Slot Layer |
A +---------------------+ +---------------------+
| Terminal Server |<-Terminal Server and Host->| Host |
T |Virtual Circuit Layer|processors exchange messages |Virtual Circuit Layer|
->+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+
E | Terminal Server |<-Terminal Server and Host->| Host |
T | Data Link Layer |processors exchange datagrams| Data Link Layer |
H +-+-+-+-+-+-+-+-+-+-+-+ - - - - - - - - - - - - - - +-+-+-+-+-+-+-+-+-+-+-+
E | |
R | ETHERNET Physical Layer |
N | (Physically shared) |
E | |
T | |
->+-------------------------------------------------------------------------+
In practice, an implementation would collapse the Slot and Virtual Circuit
Layers into a single module.
Functionally, the virtual circuit layer establishes and maintains a shared
virtual circuit. The slot layer multiplexes one or more users connections
over the underlying shared virtual circuit.
- 13 -
Local Area Transport Architecture - internal use only Page 14
OVERVIEW OF ARCHITECTURE 03 May 84
5.1 Slot Layer - User Interface
The primary responsibility of the slot layer is user session
establishment, data transfer and multiplexing/demultiplexing over a common
underlying virtual circuit maintained by the virtual circuit layer. The
sessions are established between terminals and host services.
The LAT protocol is specified in a way that allows each service class the
freedom to define extensions to the basic connection management and data
transfer services. These extensions to the foundation service can address
problems unique to the type of service being provided.
In a terminal server application (see appendix a), each host service is
made known to the local area by advertising the service in a datagram
periodically multicast to all terminal servers from each host node. Both the
host node name (NODE_NAME) and the host service names (SERVICE_NAME) are
represented in each multicast datagram. Terminal servers receive these
multicast datagrams, build up a list of available host nodes and services and
present the user a selection of the hosts services. Normally, these services
would be presented at each terminal in a console mode local to the terminal
server as shown in the diagram:
+---------+ +---------+ +---------+ +---------+ +---------+
|Service-a| |Service-b| |Service-c| |Service-d| |Service-e|
|Service-c| |Service-c| | | |Service-c| |Service-c|
++-------++ ++-------++ ++-------++ ++-------++ ++-------++
|Node A| |Node B| |Node C| |Node D| |Node E|
+-------+ +-------+ +-------+ +-------+ +-------+
| | | | |
These host nodes ( A,B,C,D and E ) multicast datagrams
periodically onto the Ethernet which name services a,b,c,d and e.
| | | | |
v v v v v
Ether<----------------------------------------------------------------->net
| |
Terminal servers build up and present lists of available host services
to each user. The node names are not presented to users.
| |
v v
+--------------------+ +--------------------+
| Available services:| | Available services:|
| a,b,c,d,e | | a,b,c,d,e |
+--------------------+ +--------------------+
|oooooooo| |oooooooo|
|oooooooo| |oooooooo|
+--------+ +--------+
Terminal at Terminal at
terminal server a terminal server b
A user then simply selects the desired host service from the displayed
list of available host services. The slot layer translates the selected host
service name into the name of a host node which offers the service. After
- 14 -
Local Area Transport Architecture - internal use only Page 15
OVERVIEW OF ARCHITECTURE 03 May 84
successfully establishing a session with the desired host service, further
input typed by the user at the terminal is transferred just as though the
terminal were, in fact, local to the host. Thus the peculiarities (such as
meaning of control-O, control-T, control-Y ...) of a particular host service
remain unknown to the terminal server.
Note that more than one host node can offer the same host service ( host
service c ). This is useful when the host services being offered are
equivalent - as with interactive timesharing service offered by a VAXcluster.
For network management purposes, each terminal server can present a
different set of available host services based on group codes assigned to
host nodes and terminal servers. This capability is provided to allow
segmentation of the computing resources based on such criteria as
departmental ownership or physical location. See the section on "LOCAL AREA
DIRECTORY SERVICE" for more details.
5.2 Virtual Circuit Layer
The primary responsibility of the virtual circuit layer is to establish
and maintain virtual circuits between host nodes and terminal servers.
The virtual circuit allows messages to be reliably exchanged between the
terminal server and the host node. The format and the rules governing
message exchange is specified by the Local Area Transport architecture. The
virtual circuit layer is responsible for translating node names into 48-bit
Ethernet addresses. The data necessary to make this translation is normally
supplied to the virtual circuit layer by multicast datagrams.
Transmission of messages from the terminal server to the host node is
timer based. The host always responds to these messages from the terminal
server. Under certain conditions (see state diagram) the host node may send
an unsolicited message.
- 15 -
Local Area Transport Architecture - internal use only Page 16
OVERVIEW OF ARCHITECTURE 03 May 84
The architecture minimizes the overhead of the virtual circuit by:
o using simple, asymmetric connection management - Only one virtual
circuit is established between any pairing of a terminal server and
host node (multiple nodes may be implemented in a single processor
or multiprocessor). The virtual circuit service is always initiated
at the request of the terminal server.
o procrastinating so there is more to do when things have to be done -
Messages are not normally exchanged when data is available to be
transmitted. Instead, messages are exchanged periodically. The
rate of exchange can be set to a constant value or varied to suit
the needs of the application. A typical value for terminal servers
is about 80 milliseconds. As more users are connected over an
existing virtual circuit, the number of messages exchanged is held
constant, but the length of each message is likely to increase.
o piggybacking virtual circuit control information and multiple users
data in a single message - The virtual circuit simultaneously
supports more than one user, the messages are divided into an
Ethernet header (which allows the physical cable to be shared), a
LAT header (which allows the virtual circuit to be shared) and one
or more slots. Slots contain a header, which identifies a terminal
and a host process offering the host service.
An Ethernet message is limited in length to 1518 bytes:
+---------------+-------------+----------------+----------------+
|Ethernet header| LAT header | LAT slots ... | frame check |
+---------------+-------------+----------------+----------------+
|<-- 14 bytes ->|<- 8 bytes ->|<- up to 1492 ->|<-- 4 bytes -->|
A LAT slot is limited to 255 bytes of data:
+-----------------+-----------------------+
| LAT slot header | slot data |
+-----------------+-----------------------+
|<--- 4 bytes --->|<- 255 bytes maximum ->|
o assuming a low loss, highly responsive, high bandwidth, point to
point interconnect - Messages are not pipelined: instead, each end
of a virtual circuit takes turns transmitting messages. This limits
the load a single virtual circuit can present to the Ethernet and,
because messages can be exchanged quickly, does not reduce the
available bandwidth below useful levels for most applications.
- 16 -
Local Area Transport Architecture - internal use only Page 17
OVERVIEW OF ARCHITECTURE 03 May 84
5.3 Product Considerations
5.3.1 Host -
Hosts implement the passive (or slave) end of the virtual circuit because
this end of the virtual circuit is simpler (and therfore offers less load).
The entire architecture can be implemented in operating systems by presenting
the LAT user interface to the operating system terminal driver as though it
were one or more terminals. By encapsulating the architecture within this
existing framework, the maximum benefit can be gained with a minimum effort.
An example sequence of events follows:
1. A terminal server "hears from" a host node and adds the host node to
its menu of available systems and the host service names to its menu
of available services.
2. The terminal server user requests a connection to a specific host
service by choosing one of the host service names displayed at the
terminal server.
3. The terminal server connects to the host node.
4. The operating system terminal driver creates a "virtual" terminal.
5. The terminal server user "logs in".
Operating systems that implement the LAT architecture will benefit greatly
if the terminal driver is organized as a terminal "class driver" and "port
driver". The class driver embodies the control characteristics of the
operating system terminal interface, while one or more port drivers
specialize in passing stream data between the (local) terminal hardware
interface and a common class driver interface. As a specific example,
consider the VAX/VMS operating system:
+-----------------------------------+
Soft, OS specific, | VMS Terminal Class Driver | Class Driver
interface -----------> +-----------------------------------+
| DZ32 | DZ11 | DMF | LAT |
| Port | Port | Port | Port | Port Driver
Hard, DEC specific, | Driver | Driver | Driver | Driver |
interface -----------> +-----------------------------------+
| DZ32 | DZ11 | DMF | NI |
| Port | Port | Port | Port | Local Interface
Hard, industry |Hardware|Hardware|Hardware|Hardware|
standard interface --> +-----------------------------------+
| wires, fibers and other |
| assorted paraphernalia |
+-----------------------------------+
Within the host, the implementation of the Local Area Terminal architecture
is confined to the box labeled "LAT Port Driver". In an actual
implementation, the "LAT Port Driver" would consist of a LAT protocol driver
and an underlying, normally shared, NI Port Driver.
- 17 -
Local Area Transport Architecture - internal use only Page 18
OVERVIEW OF ARCHITECTURE 03 May 84
5.3.2 Terminal Server -
The simplest terminal server can be implemented by using a inexpensive
microcomputer. The LAT software modules, and the rest of the operating
system code can be implemented in read only memories. A user friendly
console interface, better than those found on large commercial terminal
switches, can be used to assist the person trying to utilize a host service.
A more complex terminal server could utilize LAT to communicate more
structured data than the character streams described in this document.
Examples might be workstations transferring files between the host and the
workstation, or a terminal server that supported multiple windows at the
terminal, each mapped to a different session.
- 18 -
Local Area Transport Architecture - internal use only Page 19
LOCAL AREA DIRECTORY SERVICE 03 May 84
6.0 LOCAL AREA DIRECTORY SERVICE
The directory service is based on the multicast mechanism built into the
Ethernet. The directory service is designed to minimize the need for
intervention by a network manager.
The directory service is very responsive to sudden changes in the local
area topology. All terminal servers discover that a particular host node is
accessible within milliseconds of the host node's announcing the service. If
a host node should crash, the terminal servers can notify the users within a
few seconds that the associated host services are not available.
The overhead associated with the maintenance of a directory service is
small compared with the overhead of the connection management and data
transport services.
The slot layer translates service names into node names. The virtual
circuit layer translates node names into Ethernet 48-bit addresses. These
translation are normally accomplished by utilizing data received by the
terminal server in multicast messages.
While the different classes of service share the underlying data transport
service, each class of service defines a different directory service
appropriate to the needs of that particular class of service. This
architecture is described in the context of terminal servers and hosts. A
directory service that partially fulfills the needs of the hosts and terminal
servers is described in detail in the appendix titled "SERVICE CLASS 1 -
INTERACTIVE TERMINALS".
6.1 Two Level Name Space
The scope of this two level name space is the local Ethernet or the
extended local Ethernet if bridges or repeaters are used to extend the
Ethernet local area network.
Names supplied by multicast messages are one of two different types:
o NODE_NAME - Node names correspond to "service access points" (SAPs)
or "sockets" in the host node virtual circuit layer. Each virtual
circuit between a host node and a Terminal Server connects two of
these virtual circuit layer service access points together. Since
the Terminal Server originates all virtual circuit connections, the
host node SAPs are named and the Terminal Server SAP are not named.
The virtual circuit (CIRCUIT_NAME) assumes the name of the host node
(NODE_NAME). A host node can have two different circuit blocks with
the same CIRCUIT_NAME as long as these two different circuit blocks
are associated with a different Terminal Server (a different
REM_ADDRESS value in each circuit block).
- 19 -
Local Area Transport Architecture - internal use only Page 20
LOCAL AREA DIRECTORY SERVICE 03 May 84
o SERVICE_NAME - Service names correspond to service access points in
the slot layer in the host. These names are supplied to terminal
server users for the purpose of providing a convenient means of
identifting services. These names are especially useful in
establishing slot sessions when more than one type of service is
offered by a host node.
The same service name might be specified by more than one host node if
equivalent services are offered by the two different nodes.
When a user selects a host service name, the terminal server transmits a
start slot which specifies a DST_SLOT_NAME identical to the SERVICE_NAME
selected by the user.
It is possible to have two different names associated with a session - one
provided by each end. Neither name is constrained to be the host
SERVICE_NAME used to establish the session. For example, a SLOT_NAME
supplied by a terminal server might be the terminal user username. A
SLOT_NAME supplied by a host might be the host service name or some other
name clarifying the service being utilized.
All multicast messages are required to specifiy a NODE_NAME. Systems that
wish to announce an available service send multicast messages periodically.
In order to support the following environment:
Host services: 1 2 3 4 1
\ / | \ /
\ / | \ /
\ / | \ /
Host nodes: NODEA NODEB NODEC
| / \ |
| / \ |
| / \ |
Host Ethernet ports: ETHERNET_PORT_A ETHERNET_PORT_B
| |
| |
Ethernet physical layer: <------------------------------------------------->
These multicast messages could be transmitted periodically:
Source +------------------+ +------------------+ +------------------+
address: | PORT_A | | PORT_A OR PORT_B | | PORT_B |
+------------------+ +------------------+ +------------------+
Node name: | NODEA | | NODEB | | NODEC |
+------------------+ +------------------+ +------------------+
Service | 1 - rating 233 | | 3 - rating 231 | | 4 - rating 34 |
Names: | 2 - rating 134 | | | | 1 - rating 250 |
+------------------+ +------------------+ +------------------+
- 20 -
Local Area Transport Architecture - internal use only Page 21
LOCAL AREA DIRECTORY SERVICE 03 May 84
Which would cause the following database to be constructed in a sever:
+--------------+--------------+--------------+----------------+
| NODE_NAME | NODE_ADDRESS | SERVICE_NAME | SERVICE_RATING |
+--------------+--------------+--------------+----------------+
| NODEA | PORT_A | | |
| | | 1 | 233 |
| | | 2 | 134 |
+--------------+--------------+--------------+----------------+
| NODEB | PORT_A | | |
| | or PORT_B | 3 | 231 |
+--------------+--------------+--------------+----------------+
| NODEC | PORT_B | | |
| | | 4 | 34 |
| | | 1 | 250 |
+--------------+--------------+--------------+----------------+
And results in the following display to a server user:
Service Name Status Description
------------ ------ -----------
1 Available Description of service 1
2 Available Description of service 2
3 Available Description of service 3
4 Available Description of service 4
Note that the node names are not displayed to the user. If the user
chooses service 1, the service rating is used to choose between the
equivalent services.
6.2 Service Class 1 Multicast Message
Service class 1 utilizes a single multicast message. This message enables
the virtual circuit layer to translate node names into 48-bit Ethernet
destination addresses and the slot layer to translate host service names into
node names. The format and useage of this Service Class 1 message is
described in the Service Class 1 appendix.
- 21 -
Local Area Transport Architecture - internal use only Page 22
ARCHITECTURAL MODEL 03 May 84
7.0 ARCHITECTURAL MODEL
This section presents state diagrams for the underlying virtual circuit
(Virtual Circuit layer) and for slot session establishment (Slot layer).
Further discussion of many of the variables found in this section can be
found in the "AXIOMS AND ALGORITHMS" section.
7.1 Slot Data
The term "slot data" means data supplied by any of the following
functions:
o volunteer_xmt_data_a
o volunteer_xmt_data_a
o volunteer_attention_data
o queue_rcv_slot_buffer (creates a credit to be transferred)
7.2 Asymmetry
The host and terminal server state diagrams differ significantly. For
this reason, they are presented separately. The state variables and mapping
of received messages into the state diagrams are so similar that this
material is presented once for the virtual circuit and once for the slot
sessions. Frequently explicit notes point out that an item is relevant only
to the host or to the terminal server.
7.3 Virtual Circuit Service
In order to establish a virtual circuit from a server to a host node, the
Ethernet address, the host node name, and desired service class of the target
host node must be known. The target host node name, Ethernet address and
service class are usually determined from a multicast datagram received by
the terminal server.
- 22 -
Local Area Transport Architecture - internal use only Page 23
ARCHITECTURAL MODEL 03 May 84
7.3.1 Virtual Circuit State -
The state of a virtual circuit is captured in a data structure called the
Circuit Block. A separate Circuit Block is maintained by the host and by the
terminal server. Changes to the Circuit Block are caused by events at the
Ethernet port, events at the user interface and timers (counters) within the
protocol state machine.
A general description of these variables follows. Algorithms for
receiving and transmitting messages can be found in the "AXIOMS AND
ALGORITHMS" section.
o CIRCUIT_NAME - the name of the virtual circuit
o REM_ADDRESS - the Ethernet address of the remote system.
o LOC_ADDRESS - the Ethernet address of the local system.
o MSG_TYP - Message type. The high order six bits of this field
distinguish between different message types. The low order bit (bit
0) of this field is the RRF (response requested flag) flag. Bit 1
of this field is the the Master flag. It is always set in messages
transmitted by the terminal server and always clear in messages
transmitted by the host node.
o RRF - The Response Requested Flag. This bit is always clear in
messages transmitted by the terminal server. This bit is
conditionally set when messages are transmitted by the host node.
o REM_CIR_ID - Remote circuit identification
o LOC_CIR_ID - Local circuit identification (index to circuit block
itself)
o NXMT - Next message number to transmit (modulo 256). This value is
used to guarantee message sequencing. Every new message transmitted
is numbered one higher than the previous message modulo 256
(254,255,0,1...).
o ACK - Highest message number received in sequence (modulo 256).
This value is used to tell the session partner which sequenced
message(s) have been received by the local system. It is
transmitted in every message header for the remote session partner's
use.
o DWF (terminal server only) - Data Waiting Flag. The flag is set by
the virtual circuit layer whenever the RRF flag is set in a message
received from the host node. DWF is also set by the slot layer
whenever slot data is supplied.
The DWF is cleared by the terminal server virtual circuit layer
- 23 -
Local Area Transport Architecture - internal use only Page 24
ARCHITECTURAL MODEL 03 May 84
every time a new message is transmitted to the host that contains
all of the available slot data supplied by the local users. Thus
the DWF is cleared when all slot block Data Ready Flags are clear.
o DWF (host only) - Data waiting flag. This flag is set by the slot
layer whenever any slot data is supplied. The DWF is cleared by the
host virtual circuit layer every time a new message is transmitted
to the terminal server that contains all of the slot data available
from local users. Thus the DWF is cleared when all slot block Data
Ready Flags are clear.
o LXMT - Lowest unacknowledged message number transmitted (modulo 256)
o HXMT - Highest unacknowledged message number transmitted (modulo
256)
o HOST_RETRANSMIT_TIMER (host only) - The host's retransmit timer is
an interval timer which is started when the host node sends an
"unsolicited" message to the terminal server. When this timer
expires all unacknowledged messages are retransmitted.
o SERVER_CIRCUIT_TIMER (terminal server only) - This timer is used to
initiate the transmission of new data but is not used to retransmit
unacknowledged data.
o SERVER_RETRANSMIT_TIMER (Terminal server only) - This timer is used
to retransmit unacknowledged messages. The terminal server
retransmit policy is explained in the AXIOMS and ALGORITHMS section
in the Message Trasmitter section.
o HOST_RETRANSMIT_COUNTER, SERVER_RETRANSMIT_COUNTER - Count of number
of times the current message number has been retransmitted. If this
value reaches LAT_MESSAGE_RETRANSMIT_LIMIT, one of two different
policies can be enforced:
1. the users of the circuit are notified that communications has
been lost. The state of the virtual circuit is set to Halted.
2. the users of the circuit are notified that communications has
been temporarily interrupted. The state of the virtual circuit
is not changed and messages continue to be retransmitted.
If the terminal server does not support multiple sessions, it is
recommended that policy #1 be enforced. If the host crashes, policy
#2 would "hang" all of the users until the host is rebooted and the
terminal server transits the of the virtual circuit state through
Halted; even users that attempt to disconnect would be "hung" in
the disconecting sub-state until a message was sucessfully
transmitted and acknowledged or until the virtual circuit state
reached Halted. If multiple sessions are supported, users can
escape to a new virtual terminal.
- 24 -
Local Area Transport Architecture - internal use only Page 25
ARCHITECTURAL MODEL 03 May 84
o VC_QUALITY - A rating of the virtual circuit quality. Circuit
quality is either acceptable or unacceptable.
o XMT_BUFFER_FREEQ - Linked list of available transmit buffers.
o UNACKED_XMTQ - Linked list of unacknowledged transmit messages.
Messages are numbered from LXMT to HXMT consecutively, unless the
queue is empty. (On the terminal server the length of this queue
does not normally exceed one message.)
o SECONDS_SINCE_LAST_ZEROED (optional) - Seconds since the following
counters were zeroed.
o MESSAGES_TRANSMITTED - Count of messages transmitted. The multicast
messages transmitted by the host should be included in this total.
o MESSAGES_RECEIVED - Count of messages received.
o MESSAGES_RETRANSMITTED - Count of messages retransmitted because the
message was not acknowledged.
o OUT_OF_SEQUENCE_MESSAGES_RECEIVED - Count of messages received which
were not in sequence.
o ILLEGAL_MESSAGES_RECEIVED - Count of illegal messages received (see
next section).
o ILLEGAL_SLOTS_RECEIVED - Count of illegal slots received (see next
section).
- 25 -
Local Area Transport Architecture - internal use only Page 26
ARCHITECTURAL MODEL 03 May 84
7.3.2 Architecturally Controlled Names And Variables -
7.3.2.1 Virtual Circuit State Variables -
There are four state variables maintained by each end of a virtual circuit
in the circuit block which are constrained by the architecture:
o LOC_CIR_ID - local circuit identification. This value is stored in
the circuit block when the circuit block is created. The value zero
is reserved and is not valid as a LOC_CIR_ID. Each valid Run
message received by the local system will have the DST_CIR_ID field
of the received message equal to the LOC_CIR_ID field in some
circuit block.
The LOC_CIR_ID value should be defined by the system to help locate
the circuit block. If a virtual circuit to a partner should fail,
and a new circuit to the same partner is to be formed, the values of
LOC_CIR_ID used to form the new circuit must be different than the
value used in the previous circuit. Normally this is accomplished
by using a sequence number.
o REM_CIR_ID - remote circuit identification. Initially the
REM_CIR_ID value is zero in the circuit block. The source of this
value is the SRC_CIR_ID field in received messages. This non-zero
value references the remote system circuit block.
o NXMT - next message number to transmit. This circuit block value is
a modulo-256 value that is used to assign the message header field
MSG_SEQ_NBR.
o ACK - the number of the most recent message received in sequence.
This circuit block value is also a modulo-256 value. It is copied
from the MSG_SEQ_NBR field of any message received in sequence
(including Start messages) to the circuit block ACK field. Every
time a message is transmitted, this value is copied into the message
MSG_ACK_NBR field.
7.3.2.2 Slot State Variables -
The LOC_SLOT_ID is a value assigned by the local implementation. Received
Run slot DST_SLOT_IDs will be identical to the value transmitted in the Start
slot SRC_SLOT_ID field used to establish the slot session. For this reason,
the value should be assigned as an index into an array of slot block
addresses. The value LOC_SLOT_ID is constrained to be non-zero.
- 26 -
Local Area Transport Architecture - internal use only Page 27
ARCHITECTURAL MODEL 03 May 84
REM_SLOT_ID is a value stored in the local slot block which is used to
validate received Run slots. Initially the REM_SLOT_ID is zero in the slot
block. The source of this value is the SRC_SLOT_ID field in received Start
slots. This non-zero value references the remote system slot block.
7.3.2.3 Message Counters -
The implementor of Digital products should read "Digital Ethernet Node
Product architecture" specification. This document specifies generic product
requirements for Digital Ethernet nodes.
The purpose of requiring counters is to identify hardware faults and
software implementation errors.
Required counters must be displayable on demand by a privileged user on a
terminal connected to the local system. The description of the displayed
counters must resemble the descriptions used in this section.
These counters should be zeroed as infrequently as possible. Ideally,
counters should be zeroed by command of a privileged user only. It may be
desirable for nonprivileged users to be able to display counters.
If a virtual circuit to a remote system is halted, the associated counters
must must not be zeroed (although they may be deleted). An implementation
should attempt to retain counters even after communications with a remote
system has terminated so long as this requirement causes only idle resource
consumption.
Values must be unsigned 32-bit integers. The values must "latch" the
highest possible value if they overflow.
An implemetations must collect and be capable of locally displaying the
following list of values:
o Those required in "Digital Ethernet Node Product architecture"
o Total number of Illegal messages received (and associated Ethernet
physical address if possible)
o Total number of Illegal slots received (and associated Ethernet
physical address if possible)
NOTE
Illegal message and slot counters are
maintained as a part of the virtual circuit
database listed above. If these counter
databases are retained for some time after the
virtual circuits are terminated, a valuable
piece of information is retained to diagnose
- 27 -
Local Area Transport Architecture - internal use only Page 28
ARCHITECTURAL MODEL 03 May 84
the source of the illegal data - the Ethernet
physical address the remote system ! A minimum
of one circuit block must be retained by an
implementation after active circuits are
terminated. This is to retain the circuit
block counters for some minimum amount of time
for error diagnosis.
Implemetations must collect and be capable of locally displaying the
following list of values for each currently active virtual circuit:
o (best effort) SECONDS_SINCE_LAST_ZEROED (optional)
o MESSAGES_TRANSMITTED
o MESSAGES_RECEIVED
o MESSAGES_RETRANSMITTED
o OUT_OF_SEQUENCE_RECEIVED
o ILLEGAL_MESSAGES_RECEIVED (causing the virtual circuit to be
aborted)
o ILLEGAL_SLOTS_RECEIVED (causing the virtual circuit to be aborted)
Remember that messages are Ethernet frames under virtual circuit control.
Multicast datagrams are not messages.
- 28 -
Local Area Transport Architecture - internal use only Page 29
ARCHITECTURAL MODEL 03 May 84
7.3.2.4 Error Handling - Illegal Slots And Messages -
Virtual circuits are immediately stopped when illegal messages or slots
are received.
Illegal messages and slots are those that do not conform to the defined
message formats or grossly violate the defined state transitions of a virtual
circuit or user slot sessions. These messages and slots should not occur,
but if they do:
o Minimally, a displayable counter must be incremented. Ideally, the
affected users and the system manager should be immediately notified
of this unusual event.
o As much of the message or slot as possible should be stored in order
to diagnose the failure. Optionally store the number of the error
(see below).
o The message should be discarded.
o The (underlying) virtual circuit should be Stopped.
The term "illegal" should be distinguished from the term "invalid".
Invalid messages and slots are normal events and are usually caused by
improper synchronization (resynchronization of virtual circuits and user
sessions).
Examples of illegal messages are:
1. A received message with either the DESTINATION_ADDRESS or the
SOURCE_ADDRESS equal to zero.
2. An unknown MSG_TYPE in a received message.
3. A non-zero SRC_CIR_ID in a received Stop message.
4. A zero SRC_CIR_ID in a Start or Run message.
5. A non-zero DST_CIR_ID in a Start message received by a host node.
6. A zero DST_CIR_ID in a Run or Stop message sent by the termial
server.
7. A zero DST_CIR_ID in a Start, Run or Stop message sent by the host.
8. Others - please get them added to this list.
Examples of illegal slots are:
1. An unknown SLOT_TYPE value is received.
2. An unknown SERVICE_CLASS is received in a Start slot.
3. A non-zero SRC_SLOT_ID in a received Stop slot.
4. A zero SRC_SLOT_ID in a Start slot.
5. A non-zero DST_SLOT_ID in a Start slot received by a host node.
6. A zero DST_SLOT_ID in any slot but a Start slot sent by the terminal
server.
7. An Attention slot specifyingg a non-zero value in the credit field
(documented as an MBZ field in the message format section).
- 29 -
Local Area Transport Architecture - internal use only Page 30
ARCHITECTURAL MODEL 03 May 84
8. a Start slot received in the Run state (without and intervening Stop
slot)
9. a Reject slot received in the Run state.
10. a Data_a or Data_b slot arrives which contains data (consumed a
remote credit), but no user buffer is available (no credit was
extended).
11. a Run slot with a zero SRC_SLOT_ID.
12. Others - please get them added to this list.
- 30 -
Local Area Transport Architecture - internal use only Page 31
ARCHITECTURAL MODEL 03 May 84
7.3.2.5 Defined Parameters And Recommended Or Required Default Values -
Some of the values defined in this section may be changed by the system
manager. The name of the variable should be similar to the name used below
in command interfaces.
The follow values are architecturally defined constants:
o Protocol Type - 60-04 (hexadecimal) or as a bit stream, first bit on
Ethernet at left (0000.0110.0010.0000)
o Multicast Address - AB-00-03-00-00-00-00 (hexadecimal) or as a bit
stream, first bit on Ethernet at left
(1101.0101.0000.0000.1100.0000.0000.0000.0000.0000.0000.0000)
The following values must be specified before an implementation is
operational. If an implementation allows the values are settable within the
ranges specified, the names used to refer to the parameters must be a
reasonable facsimile of the name used below. If the parameters are not
settable, the recommended default values should be used. The architecture
requires the values be within the ranges specified:
o PROTOCOL_VERSION - The value 5.
o SERVICE_NAME - must be specified by the host system manager before
the start of service can be announced.
o NODE_NAME - must be specified by the host system manager before the
start of service can be announced.
o SERVER_CIRCUIT_TIMER - In the range 1-100. This parameter specifies
10 millisecond intervals. (The value 8 is recommended - 80
milliseconds).
o SERVER_RETRANSMIT_TIMER - In the range 1 to 2 seconds.
o HOST_RETRANSMIT_TIMER - In the range 1 to 2 seconds.
o LAT_MESSAGE_RETRANSMIT_LIMIT - Four or more messages. Eight
messages recommended for the terminal server
(SERVER_RETRANSMIT_COUNTER limit), more than 60 messages recommended
for the host node (HOST_RETRANSMIT_COUNTER limit).
o HOST_MULTICAST_TIMER - In the range 10 to 180 seconds (30 seconds
recommended). This value is supplied via the start_service_class
function.
o LAT_MIN_RCV_DATAGRAM_SIZE - In the range 576 to 1518 ( 1518
recommended) for both the host node and terminal server.
o LAT_MIN_RCV_SLOT_SIZE - In the range 1 to 255 (127 recommended) for
both the host and terminal server.
o LAT_MIN_RCV_ATT_SLOT_SIZE - In the range 1 to 255 (31 recommended)
for both the host and terminal server.
o NBR_DL_BUFS - The number of data link buffers assigned minus one. A
value of zero is recommended.
o A Host implemenation should enable multicast group 0 by default
(unless specified differently interactively).
o A Server implemenation should enable multicast group 0 by default
(unless specified differently interactively).
- 31 -
Local Area Transport Architecture - internal use only Page 32
ARCHITECTURAL MODEL 03 May 84
o PRODUCT_TYPE_CODE -
1. PLUTO terminal server
2. POSEIDON terminal server
3. VAX/VMS host
4. RSX11-M host
5. RSX11-M+ host
6. TOPS-20 host
7. TOPS-10 host
8. TOPS-20 terminal server
9. LAT-11 terminal server
10. RSTS/E host
11. Berkley/UNIX host
The following value must be supplied before an implementation is
convenient to use:
o LAT_KEEP_ALIVE_TIMER - In the range 10 to 255. A value of 20
seconds is recommended.
The parameters that are optional are:
o PROTOCOL_ECO - The value 0 unless an ECO has been applied.
o FACILITY_NUMBER - A value supplied via the local command interface.
o SERVER_NAME - A name supplied via the local command interface.
o LOCATION_TEXT - Text supplied via the local command interface.
o Parameter data supplied by an implementation's software modules or
via the local command interface. See individual service classes for
a description of these parameters.
- 32 -
Local Area Transport Architecture - internal use only Page 33
ARCHITECTURAL MODEL 03 May 84
7.3.3 Message Types -
There is a common virtual circuit header format for LAT messages
documented in the section "MESSAGE FORMATS" (other message formats are
defined by the different service classes). This virtual circuit message
format is one of three different types:
1. start message - Start messages are used to establish new virtual
circuits.
2. run message - Run messages convey state and slot data between
systems.
3. stop message - Stop messages are used to end a virtual circuit
session.
A stop message is also used as a "no circuit" message to reply to a
received message which references a nonexistent or invalid virtual circuit
(see state diagrams "Send Stop"). An implementation should make a best
effort to send these "no circuit" messages. Occasionally, due to lack of
resources or Ethernet data link errors, these "no circuit" messages may fail
to get delivered. Failure to send these "no circuit" messages can result in
slow resynchronization after the host node or server crashes.
- 33 -
Local Area Transport Architecture - internal use only Page 34
ARCHITECTURAL MODEL 03 May 84
7.3.4 Virtual Circuit State Variables -
There are three virtual circuit states: Halted, Starting and Running.
Once the system to system virtual circuit has started successfully, the
circuit reaches the Running state.
These events determine state transitions:
1. VC_start (server only) - user requests virtual circuit startup. An
implementation would allocate a Circuit Block at this point if none
existed.
2. VC_halt - user requests that the virtual circuit be halted
immediately
3. Start_rcv - Start message received. An implementation would
allocate a Circuit Block at this point, if one did not exist from a
previous circuit, and initialize all state variables.
4. Inv_start_rcv - invalid Start received (see message mapping section)
5. Stop_rcv - Stop message received.
6. Inv_stop_rcv - invalid Stop received (see next section)
7. Run_rcv - Run message received with valid connection identification.
The message is in sequence if MSG_SEQ_NBR of received message equals
the value ACK+1 in the circuit block ( modulo 256 ).
8. Inv_run_rcv - invalid Run received (see next section)
9. Circuit_timer - the SERVER_CIRCUIT_TIMER expires.
10. Rexmit_timer - The SERVER_RETRANSMIT_TIMER or HOST_RETRANSMIT_TIMER
expires.
11. Resend_limit - The retransmit counter reached the limit
LAT_MESSAGE_RETRANSMIT_LIMIT.
12. Send_data (host only) - A user supplies slot data and the RRF flag
in the circuit block is clear. Note that this event is blocked if
the RRF is set.
- 34 -
Local Area Transport Architecture - internal use only Page 35
ARCHITECTURAL MODEL 03 May 84
7.3.5 Response Requested Flag And Balanced Mode -
When the most recent message received from the host node has the
RRF clear (no response requested), and this message acknowledges the
last message transmitted from the terminal server, the virtual
circuit is said to be "balanced". When in this state, the host node
has permission to send one "unsolicited" message and the terminal
server will not send messages if the DWF (data waiting flags) is
clear.
This state will persist until either the Send_data event occurs
in the host or the DWF is set in the terminal server (possibly due
to the keep alive timer).
"Balanced mode" prevents the LAT protocol from consuming
unecessary Ethernet bandwidth. Without balanced mode, LAT messages
would be exchanged at SERVER_CIRCUIT_TIMER millisecond intervals,
even though no useful data was being exchanged.
There is a sub-state that is not evident from a cursory
inspection of the state diagrams. This sub-state is entered when
the event Send_data occurs. Notice that this event causes the
HOST_RETRANSMIT_TIMER to be started and may cause the Circuit Block
RRF flag to be set. Also notice that this event cannot occur if the
RRF flag is already set. This sub-state retransmits all
unacknowledged messages whenever the HOST_RETRANSMIT_TIMER expires.
This sub-state is exited when the host node receives a message that
acknowledges all of the currently unacknowledged messages. At this
point and the HOST_RETRANSMIT_TIMER is stopped. The purpose of this
sub-state is to guarantee "unsolicited" message delivery.
- 35 -
Local Area Transport Architecture - internal use only Page 36
ARCHITECTURAL MODEL 03 May 84
7.3.6 Message Mapping Onto State Diagram -
Received messages must be validated.
The Ethernet data link layer verifies that the Ethernet
DESTINATION_ADDRESS field in the received message matches the address
assigned to the local system and that the PROTOCOL_TYPE field in the received
message is equal to the LAT protocol type.
The LAT virtual circuit layer maps Start messages onto circuit blocks
based on the value of the CIRCUIT_NAME field and the SOURCE_ADDRESS field of
the received Start message. A match to a circuit block is found if the
CIRCUIT_NAME field of the received Start message equals the CIRCUIT_NAME
field in the circuit block AND the SOURCE_ADDRESS field of the received Start
message equals the REM_ADDRESS field in the circuit block. If no match is
found, a new circuit block can be created and these two values used to
initialize the new circuit block.
Run messages and Stop messages are mapped onto a circuit block based
solely on the value of the DST_CIR_ID field of the received message. The
value DST_CIR_ID must match the value LOC_CIR_ID in the referenced circuit
block and the value SRC_CIR_ID must match the REM_CIR_ID value in the circuit
block. Run messages that do not map onto a circuit block in the Running
state are discarded and a Stop message is sent to the remote system.
Next, the message type is determined from the LAT header MESSAGE_TYPE
field. The received message is then mapped into the state diagram based on
the following rules:
o Start_rcv - The DST_CIR_ID of the received message must equal the
LOC_CIR_ID in the referenced circuit block. SRC_CIR_ID of message
must not be zero, and is copied to the REM_CIR_ID field of the
referenced circuit block.
o Inv_start_rcv - DST_CIR_ID of received message is non-zero and not
equal to LOC_CIR_ID in the referenced circuit block.
o Run_rcv - DST_CIR_ID of received message equals LOC_CIR_ID of
circuit block and SRC_CIR_ID of received message equals REM_CIR_ID
of circuit block. The message is in sequence if MSG_SEQ_NBR of
received message equals the value ACK+1 in the circuit block (
modulo 256 ).
o Inv_run_rcv - DST_CIR_ID of message not equal to LOC_CIR_ID in
circuit block or SRC_CIR_ID of message not equal to REM_CIR_ID of
circuit block.
o Stop_rcv - DST_CIR_ID of message equals LOC_CIR_ID of circuit block
and SRC_CIR_ID of message equals zero.
o Inv_stop_rcv - DST_CIR_ID of message not equal to LOC_CIR_ID in
circuit block.
In the case of the first Start_rcv event in the host node, no circuit
block will exist to reference. A circuit block should be allocated and the
state variables should be initialized as described below the host virtual
- 36 -
Local Area Transport Architecture - internal use only Page 37
ARCHITECTURAL MODEL 03 May 84
circuit state table. The DST_CIR_ID of the received message should be
considered a match to the LOC_CIR_ID of the circuit block in this case. If a
circuit block cannot be allocated, the implementation should attempt to send
a Stop message that indicates no resources.
Invalid messages are the result of improper synchronization between the
host node and terminal server. These events are normal; the message is
treated as described in the state diagrams.
- 37 -
Local Area Transport Architecture - internal use only Page 38
ARCHITECTURAL MODEL 03 May 84
7.3.6.1 Terminal Server Virtual Circuit State Table -
State Event(s) Action(s) Next State
+==========+===============+===================================+============+
| Halted | VC_start | Initialize, Send Start. | Starting |
+----------+---------------+-----------------------------------+------------+
| | Stop_rcv | No action. | Halted |
+----------+---------------+-----------------------------------+------------+
| | Inv_stop_rcv | No action. | Halted |
+----------+---------------+-----------------------------------+------------+
| | any other msg | Process Start, Send Stop. | Halted |
+----------+---------------+-----------------------------------+------------+
| | any other | No action. | Halted |
+==========+---------------+-----------------------------------+------------+
| Starting | Start_rcv | Process Start, send Run. | Running |
| | | (typically including Start slot) | |
+----------+---------------+-----------------------------------+------------+
| | Resend_limit | Notify users, send Stop. | Halted |
+----------+---------------+-----------------------------------+------------+
| | Rexmit_timer | Resend Start. | Starting |
+----------+---------------+-----------------------------------+------------+
| | Stop_rcv | Notify users. | Halted |
+----------+---------------+-----------------------------------+------------+
| | VC_halt | Send Stop | Halted |
+----------+---------------+-----------------------------------+------------+
| | Inv_stop_rcv | No action. | Starting |
+----------+---------------+-----------------------------------+------------+
| | any other msg | Process Start, send Start. | Starting |
+----------+---------------+-----------------------------------+------------+
Terminal Server Virtual Circuit State Table Notes
"process Start" means copy the SRC_CIR_ID field from the received Start
message to the REM_CIR_ID field in the circuit block.
The "Initialize" means the values in the Circuit Block are initialized as:
1. CIRCUIT_NAME<- <the name passed by the VC_start function>
2. REM_ADDRESS<- <value passed in the VC_start call>
3. LOC_ADDRESS<- <value assigned to the local system>
4. REM_CIR_ID<- 0 (later copied from received Start message)
5. LOC_CIR_ID<- <unique virtual circuit connection id>
6. NXMT<- 0 - Next message number to transmit
7. ACK <- 255 - message number most recently received in sequence
8. LXMT<- 0 - Lowest unacknowledged message number transmitted
9. HXMT<- 0 - Highest unacknowledged message number transmitted
10. SERVER_CIRCUIT_TIMER<- <reset to ~ 80 ms> (count-down to zero)
11. SERVER_RETRANSMIT_COUNTER<-0 (count-up to LAT_MESSAGE_REXMIT_LIMIT)
12. UNACKED_XMTQ<- <empty>
13. RRF and DWF are cleared
- 38 -
Local Area Transport Architecture - internal use only Page 39
ARCHITECTURAL MODEL 03 May 84
terminal server virtual circuit state table - continued
State Event(s) Action(s) Next State
+==========+---------------+-----------------------------------+------------+
| Running | Run_rcv | If msg is out of sequence: zero | Running |
| | | NBR_SLOTS in msg hdr. If RRF | |
| | | flag is set: set DWF. Process | |
| | | received ack; process message. | |
| +---------------+-----------------------------------+------------+
| | Rexmit_timer | If messages remain unacknowledged:| |
| | | resend all unacked messages. | |
| +---------------+-----------------------------------+------------+
| | Circuit_timer | If messages acked and DWF set: | |
| | | send message; clear DWF if all | Running |
| | | slot data has been sent. | |
| | | If messages acked and DWF clear: | |
| | | no action. | |
| +---------------+-----------------------------------+------------+
| | Resend_limit | Notify users (or optionally halt | Running |
| | | via VC_halt event). | (Halted) |
| +---------------+-----------------------------------+------------+
| | VC_halt | Send Stop | Halted |
| +---------------+-----------------------------------+------------+
| | Stop_rcv | Notify users | Halted |
| +---------------+-----------------------------------+------------+
| | any other | set DWF | Running |
+----------+---------------+-----------------------------------+------------+
Note that the server slot state table also specifies that DWF be set.
- 39 -
Local Area Transport Architecture - internal use only Page 40
ARCHITECTURAL MODEL 03 May 84
7.3.6.2 Host Virtual Circuit State Table -
State Event(s) Action(s) Next State
+========+================+====================================+============+
| Halted | Start_rcv or | Initialize; process Start; | Starting |
| | Inv_start_rcv | Send Start (or Stop). | (or Halted)|
| +----------------+------------------------------------+------------+
| | Stop_rcv or | | |
| | Inv_stop_rcv | No action. | Halted |
| +----------------+------------------------------------+------------+
| | any other msg, | | |
| | or no resources| Process Start; send Stop. | Halted |
+========+----------------+------------------------------------+------------+
|Starting| Run_rcv | If msg is out of sequence: zero | Running |
| | | NBR_SLOTS in msg header. Process | |
| | | rcvd ACK. Process rcvd message. | |
| +----------------+------------------------------------+------------+
| | VC_halt | Send Stop | Halted |
| +----------------+------------------------------------+------------+
| | Stop_rcv | No action. | Halted |
| +----------------+------------------------------------+------------+
| | Inv_stop_rcv | No action. | Starting |
| +----------------+------------------------------------+------------+
| | Start_rcv | Initialize; process Start; | |
| | | send Start. | Starting |
| +----------------+------------------------------------+------------+
| | any other msg | send Start | Starting |
+--------+----------------+------------------------------------+------------+
"process Start" means copy SRC_CIR_ID from the received Start message into
the circuit block field REM_CIR_ID; copy the SRC_ADDRESS from the message
into the REM_ADDRESS field in the circuit block and copy the CIRCUIT_NAME
from the received Start message into the circuit block CIRCUIT_NAME field.
"Initialize" means the values in the Circuit Block are initialized as:
1. NODE_NAME<- <copied from the receive Start message>
2. REM_ADDRESS<- <SOURCE_ADDRESS from the received Start message>
3. LOC_ADDRESS<- <value assigned to the local system>
4. REM_CIR_CID<- <copied from received Start message>
5. LOC_CIR_ID<- <unique connection id>
6. NXMT<- 0 - Next message number to transmit
7. ACK <- 0 - most recent message number received in sequence
8. LXMT<- 0 - Lowest unacknowledged message number transmitted
9. HXMT<- 0 - Highest unacknowledged message number transmitted
10. HOST_RETRANSMIT_TIMER<- <stopped>
11. HOST_RETRANSMIT_COUNTER<- 0 (counts up to LAT_MESSAGE_REXMIT_LIMIT)
12. UNACKED_XMTQ<- <empty>
13. RRF flag is cleared
14. DWF is cleared
- 40 -
Local Area Transport Architecture - internal use only Page 41
ARCHITECTURAL MODEL 03 May 84
host virtual circuit state table - continued
State Event(s) Action(s) Next State
+========+---------------+-------------------------------------+------------+
| Running| Run_msg_rcv | If msg is out of sequence: zero | Running |
| | | NBR_SLOTS in msg header. Process | |
| | | rcvd ACK; if all msgs are acked: | |
| | | stop timer. Process rcvd message;| |
| | | queue_transmit_message; | |
| | | transmit_unacknowledged_queue. | |
| +---------------+-------------------------------------+------------+
| | Send_data | Start timer; queue_transmit_message;| Running |
| | | transmit_unacknowledged_queue. | |
| +---------------+-------------------------------------+------------+
| | Rexmit_Timer | Resend unacked msgs; reset timer. | Running |
| +---------------+-------------------------------------+------------+
| | Resend_limit | Notify users (or optionally halt | Running |
| | | via VC_halt event). | (Halted) |
| +---------------+-------------------------------------+------------+
| | VC_halt | Send Stop. | Halted |
| +---------------+-------------------------------------+------------+
| | Stop_rcv | Notify users. | Halted |
| +---------------+-------------------------------------+------------+
| | Start_rcv | Initialize; process Start; | |
| | | send Start. | Starting |
| +---------------+-------------------------------------+------------+
| | any other | Transmit_unacknowledged_queue. | Running |
+--------+---------------+-------------------------------------+------------+
"Start rexmit_timer" starts a one to two second interval timer. This
timer is used to retransmit messages that do not get acknowledged by the
terminal server within the expected time limit. One second is arbitrarily
larger than the timer value used by the terminal server
(SERVER_CIRCUIT_TIMER). If this HOST_RETRANSMIT_TIMER expires, most likely
the terminal server has crashed or the Ethernet data link has failed.
- 41 -
Local Area Transport Architecture - internal use only Page 42
ARCHITECTURAL MODEL 03 May 84
7.4 User Connection Management And Data Flow
Variables in this section are described in sufficient detail to explain
the slot state transitions necessary to establish and maintain slot sessions.
7.4.1 Service Classes -
It is the responsibility of the slot layer to deliver start slots (connect
requests) to the appropriate service class in the host. Each service class
has the freedom to define the capabilities utilized by that service class
independently. For instance, the service class A might utilize attention
slots while the service class B might not.
After the start slot has been accepted by the service class, and a start
slot sent in response, all subsequent slots associated with that session are
delivered to the same service class.
Therefore the virtual circuit service can be shared by one or more service
classes, while each service class utilizes different slot types and slot
formats.
7.4.2 Host Session Management -
The host implementation may choose to always accept or reject a connection
(respond to a start slot received by the host service with a start or reject
slot) based soley on currently available resources. ( Lack of resources
might include such criteria as nonavailability of memory, too many users or
system shutdown in progress). This type of implementation is appropriate if
the connect request contains insufficient information for the host service to
make a decision to reject the connection. Interactive terminal login is an
example of such a host service. The account name and password must be
supplied within the context of the session before the host service can reject
the session.
Alternatively, a host implementation may offer the host service a chance
to reject or accept directly. This is the behavior modeled in the host slot
state table.
7.4.3 Multiplexing Over A Virtual Circuit -
To provide multiple users connection management and data transfer service
simultaneously, the underlying virtual circuit can be shared by all active
users. This sharing is accomplished by dividing each message into a header
and one or more slots. Whenever more than one user has volunteered data to
be transmitted, an individual user's ability to transmit data is restricted
by the following rules, which guarantee each user gets treated fairly:
- 42 -
Local Area Transport Architecture - internal use only Page 43
ARCHITECTURAL MODEL 03 May 84
o limiting the slot size - the maximum slot size is the slot header
size (4 bytes) plus the maximum data size (255 bytes), or 259 bytes.
Thus one 1518 byte message has enough room for at least five, and
usually more slots.
o slot flow control - Data_a and Data_b slots cannot be transmitted
unless a transmit slot credit (LOCAL_CREDITS) is owned by the user.
o limiting each user to one slot until all other users have been
considered
o not starting with same user each time - if not all of the slot data
fit into a message, the next scan for slot data should resume with
the users that did not get slot data into the message the previous
time.
As with frames on the Ethernet, slots are divided into a header and a data
section. Connection management is accomplished by defining the state
transitions of the slot headers as described in the following sections.
7.4.4 Slot Ordering Within Messages -
Slot ordering within a message is not arbitrary. If two or more slots in
a buffer are addressed to the same user, the slots are processed from the
beginning of the buffer to the end.
For instance, an "abort" slot received by a terminal server will abort any
output data in slots received before it within the message (and in previous
messages), but will not affect a slot in the buffer following it.
- 43 -
Local Area Transport Architecture - internal use only Page 44
ARCHITECTURAL MODEL 03 May 84
7.4.5 Slot State Variables -
The state transitions for slots are similar to those for the underlying
virtual circuit itself. Any of the slot transitions shown in the slot state
tables assume an underlying virtual circuit in the Running state. If the
virtual circuit should exit the Running state, the slot sessions immediately
transfer to the halted state.
The state of a slot session is captured by each end in a data structure
called the Slot Block. Changes to the Slot Block are caused by events at the
Ethernet port and events at the user interface.
The virtual circuit layer delivers to the slot layer messages that contain
one or more slots. Slot validation is the responsibility of the slot layer.
The slot block contains the following fields:
o REM_SLOT_NAME - the name of the remote slot block. Required to be
the name of the remote service selected.
o LOC_SLOT_NAME - the name of the local slot block
o REM_SLOT_ID - Remote slot connection identification
o LOC_SLOT_ID - Local slot connection identification
o REMOTE_CREDITS - credits being extended to the session partner.
This credit total is zeroed by the slot layer each time the slot
multiplexer copies the slot into a message buffer. This total is
incremented every time the user adds a receive buffer via the
queue_rcv_slot_buffer function.
o LOCAL_CREDITS - available credits to transmit slots. This field is
initialized to zero when the slot block is created. The slot layer
slot demultiplxer adds any credits extended in the received slot
CRED field to this slot block LOCAL_CREDITS field. The slot layer
slot multiplexer decrements this field whenever a Data_a or Data_b
slot is copied into a message buffer with a non-zero
SLOT_BYTE_COUNT. Data_a and Data_b slots do NOT consume credits if
the SLOT_BYTE_COUNT is zero (to prevent infinite looping!). Start,
Stop and Attention slots do not consume credits.
o SLOT_TYPE - slot type. One of Start, Data_a, Data_b, Attention,
Reject or Stop.
o DRF - Data Ready Flag. Set whenever slot data is available.
Cleared by the slot layer whenever all slot data is under virtual
circuit control. This flag is not essential to the architecture.
o SLOT_COUNT - byte count of next field (which could be zero)
o SLOT_DATA_BUFFER - This buffer is used to store Data_a received over
the session as the result of extending slot credits.
o ATTENTION_DATA_BUFFER - This buffer is used to deliver Attention
data to the user. A semaphore (not shown in the slot block) is used
to arbitrate ownership of the buffer. Since Attention data is not
flow controlled, Attention data is discarded if new data is
delivered and the buffer is not available.
- 44 -
Local Area Transport Architecture - internal use only Page 45
ARCHITECTURAL MODEL 03 May 84
These events determine state transitions:
1. Connect_req (terminal server only) - user requests connection.
2. Disconnect_req - user requests disconnection.
3. Reject_req (host only) - user rejects a requested connection.
4. Accept_req (host only) - user accepts a requested connection.
5. Start_rcv - start slot received.
6. Stop_rcv - stop slot received .
7. Reject_rcv - reject slot received.
8. Run_rcv - Data_a, Data_b or Attention slot received.
9. User_data - user supplies data via volunteer_data_a or
volunteer_data_b.
10. User_rcv - user supplies receive slot buffer via
queue_rcv_slot_buffer.
11. Stop_sent - Stop slot under virtual circuit control.
7.4.6 Terminal Server Slot Mapping Onto State Diagram -
Received slots are mapped onto the events based on the values received in
the received slot DST_SLOT_ID and SRC_SLOT_ID fields, and the current slot
block values of REM_SLOT_ID and LOC_SLOT_ID.
The key for the symbols in the table:
o L - DST_SLOT_ID from the received slot equals LOC_SLOT_ID in the
referenced slot block
o R - SRC_SLOT_ID from the received slot equals REM_SLOT_ID in the
referenced slot block
o I - DST_SLOT_ID from the received slot does not equal LOC_SLOT_ID in
the referenced slot block
o J - SRC_SLOT_ID from the received slot does not equal REM_SLOT_ID in
the referenced slot block
o D - Doesn't matter what SRC_SLOT_ID in the received slot is
o 0 - DST_SLOT_ID or SRC_SLOT_ID in received slot is zero
DST_SLOT_ID SRC_SLOT_ID State Type of slot or action to be taken
--------- --------- ----- ----------------------------------
L R Running Data_a, Data_b or Attention slot
L D Starting Start slot (D cannot be zero)
L 0 any Stop or Reject slot
L J Running send Stop to SRC_SLOT_ID
I D Starting ignore slot (session shutting down)
I D Running ignore slot (session shutting down)
Events shown in this list but not in the table below are either invalid or
are events that occur as a session shuts down. The list suggests an
appropriate action.
- 45 -
Local Area Transport Architecture - internal use only Page 46
ARCHITECTURAL MODEL 03 May 84
7.4.7 Terminal Server Slot State Table -
State Event Action Next State
+==========+===============+===================================+============+
| Halted | connect_req | Initialize, Send Start. | Starting |
| +---------------+-----------------------------------+------------+
| | any other | No action. | Halted |
+==========+---------------+-----------------------------------+------------+
| Starting | disconnect_req| No action. | Abort_start|
| +---------------+-----------------------------------+------------+
| | Reject_rcv | No action. | Halted |
| +---------------+-----------------------------------+------------+
| | Start_rcv | process SRC_SLOT_ID; | Running |
| | | update credits; process Start. | |
| +---------------+-----------------------------------+------------+
| | any other | No action. | Starting |
+==========+---------------+-----------------------------------+------------+
|Abort_strt| Reject_rcv | No action. | Halted |
| +---------------+-----------------------------------+------------+
| | Start_rcv | Send Stop | Halted |
| +---------------+-----------------------------------+------------+
| | any other | No action. | Abort_start|
+==========+---------------+-----------------------------------+------------+
| Running | disconnect_req| Send Stop (see note below). | Stopping |
| +---------------+-----------------------------------+------------+
| | Stop_rcv | Notify user. | Halted |
| +---------------+-----------------------------------+------------+
| | Reject_rcv | Illegal slot (Declare VC_halt) | Halted |
| +---------------+-----------------------------------+------------+
| | Start_rcv | Illegal slot (Declare VC_halt) | Halted |
| +---------------+-----------------------------------+------------+
| | Run_rcv | Update credits and process slot. | Running |
| +---------------+-----------------------------------+------------+
| | User_data or | | |
| | User_rcv | Set DWF and DRF. | Running |
| +---------------+-----------------------------------+------------+
| | any other | No action. | Running |
+==========+---------------+-----------------------------------+------------+
| Stopping | Stop_sent | No action. | Halted |
| +---------------+-----------------------------------+------------+
| | any other | No action. | Stopping |
+----------+---------------+-----------------------------------+------------+
A Start_rcv event need not be distinguished from a Run_rcv except in the
Starting state. In the Starting state the Start slot should be validated
based on Slot_type to be sure a Run slot is not being received.
"process SRC_SLOT_ID" means copy the SRC_SLOT_ID field from the received
slot into the REM_SLOT_ID field of the slot block.
- 46 -
Local Area Transport Architecture - internal use only Page 47
ARCHITECTURAL MODEL 03 May 84
"Update credits" means add the CREDIT field in the received slot into the
LOCAL_CREDITS field of the slot block.
The "Send stop" action in the table may involve queue delays until the
virtual circuit layer accepts the Stop slot. Until the Stop slot is accepted
under virtual circuit control, all other received messages should be ignored,
and the transition to the Halted state must be delayed. This prevents the
connect_req event from reusing a slot state table until a queued stop has
been accepted by the virtual circuit layer.
- 47 -
Local Area Transport Architecture - internal use only Page 48
ARCHITECTURAL MODEL 03 May 84
7.4.8 Host Slot Mapping Onto State Diagram -
Slots are mapped onto the events based on the values received in the slot
DST_SLOT_ID and SRC_SLOT_ID fields, and the current slot block state
variables LOC_SLOT_ID and REM_SLOT_ID. The key for the symbols in the table:
o L - DST_SLOT_ID from the received slot equals LOC_SLOT_ID in the
referenced slot block
o R - SRC_SLOT_ID from the received slot equals REM_SLOT_ID in the
referenced slot block
o I - DST_SLOT_ID from the received slot does not equal LOC_SLOT_ID in
the referenced slot block
o J - SRC_SLOT_ID from the received slot does not equal REM_SLOT_ID in
the referenced slot block
o D - Doesn't matter what SRC_SLOT_ID in the received slot is
o 0 - DST_SLOT_ID or SRC_SLOT_ID in received slot is zero
DST_SLOT_ID SRC_SLOT_ID Type of slot or action to be taken
--------- --------- -----------------------------------
L R Data_a, Data_b or Attention slot
L J Ignore (stop slot followed by reassignment of
LOC_SLOT_ID.)
L 0 Stop or Reject slot
0 D Start ( D cannot be zero ).
I D ignore slot (session shutting down)
The Start_rcv event <0 D> can occur in any state, but the event is always
mapped onto a new slot block in the halted state.
Events shown in this list but not in the table below are either invalid or
are events that occur as a session shuts down. The list suggests an
appropriate action.
- 48 -
Local Area Transport Architecture - internal use only Page 49
ARCHITECTURAL MODEL 03 May 84
7.4.9 Host Slot State Table -
State Event Action Next State
+==========+===============+===================================+============+
| Halted | start_rcv | Init; request session of user. | Starting |
| +---------------+-----------------------------------+------------+
| | Any other | No action. | Halted |
+==========+---------------+-----------------------------------+------------+
| Starting | reject_req | Send Reject. | Halted |
| +---------------+-----------------------------------+------------+
| | accept_req | Send Start. | Running |
| +---------------+-----------------------------------+------------+
| | Any other | No action. | Starting |
+==========+---------------+-----------------------------------+------------+
| Running | Disconnect_req| Send Stop. | Stopping |
| +---------------+-----------------------------------+------------+
| | Stop_rcv | No action. | Halted |
| +---------------+-----------------------------------+------------+
| | Reject_rcv | No action. | Halted |
| +---------------+-----------------------------------+------------+
| | Run_rcv | Process slot. | Running |
| +---------------+-----------------------------------+------------+
| | User_data or | | |
| | User_rcv | Set DWF and DRF. | Running |
| +---------------+-----------------------------------+------------+
| | Any other | No action. | Running |
+==========+---------------+-----------------------------------+------------+
| Stopping | Stop_sent | No action. | Halted |
| +---------------+-----------------------------------+------------+
| | Any other | No action. | Stopping |
+----------+---------------+-----------------------------------+------------+
A host implementation may choose to always accept a requested session. In
this case the Starting state in the table would not exist. The start_rcv
event would establish a session (assuming sufficient resources). A host
service (the terminal class driver) might then later reject the session via
the disconnect_req. This example would occur during a terminal server user
login failure.
- 49 -
Local Area Transport Architecture - internal use only Page 50
LAYER INTERFACES 03 May 84
8.0 LAYER INTERFACES
The interfaces presented in this section are not meant to be implemented.
The purpose is to present the control and data flowing through the LAT layers
between the users in a way that unambiguously describes what is required at
the interfaces, but allows implementations the freedom necessary to implement
the functions appropriately for each different system.
The model presented implies that each side of the interface both provides
service entry points and utilizes service entry points provided to it.
Synchronization across interfaces is the responsibility of the
implementation. Specifically, the implementation must assure that all user
and Ethernet data link interface events are processed serially and
atomically, in both directions. This requirement arises primarily from the
need to maintain predictable states in the shared Circuit and Slot blocks.
The polling model is used to show correspondence of functions and to
reduce the amount of text necessary to describe the interfaces. Only one
interface is described at each layer. In fact, implementations would offer
only a subset of the functions described, one subset corresponding to the
terminal server and another corresponding to the host.
In interface calls:
o input parameters are specified first
o input parameters are separated from output parameters by a semicolon
o parameters are separated by commas
o "S-","H-", and "SH-" indicate that a function is available at the
terminal server ("S-"), host ("H-") or both ("SH-").
Within the interface calls, the "reason" argument is defined separately for
each different service class ( see the appendices).
8.1 Data Types
There are two distinct types of data that can be transferred between
session partners: Data streams (Data_a and Data_b) and attention data. The
data streams are flow controlled and error controlled. The attention data is
error controlled, but is not flow controlled. Idempotent operations and data
not requiring delivery can be transfered in attention slots.
The purpose of having both Data_a and Data_b data streams is:
o status and control information (Data_b) can be transfered as a
separate data stream. An implementation does not have to embed the
status and control information in the data stream or operate a
separate virtual circuit.
o status and control (Data_b) transfers are phase locked relative to
Data_a transfers. If the Data_b slot indicates a change is to be
applied to the Data_a stream, the change is unambiguously applied to
- 50 -
Local Area Transport Architecture - internal use only Page 51
LAYER INTERFACES 03 May 84
the subsequent Data_a slots.
o the implementation is free to define the entire format of the Data_b
slots. This provides much greater flexibility since the Data_a
channel is normally unformatted.
The rules governing Attention data are different than those governing
Data_a and Data_b. Attention data can be transmitted even though the
LOCAL_CREDIT total in the slot block is zero. The purpose of Attention data
is:
o to allow a control slot to preempt any data waiting to be
transmitted at the local system
o to allow a control information to be transferred to the session
partner even though the normal Data_a and Data_b paths are blocked
due to lack of flow control credits
Each service class must define the maximum size of attention data slots.
The slot block must reserve a buffer of this size dedicated to the delivery
of Attention data. A semaphore is set by the slot layer when Attention data
is delivered into this buffer and cleared when the user has process the data.
If the semaphore is set when Attention data is delivered, the Attention data
is discarded by the slot layer.
- 51 -
Local Area Transport Architecture - internal use only Page 52
LAYER INTERFACES 03 May 84
8.2 User/Slot Layer Interface
This interface allows users to advertise service, establish user (slot)
sessions, and transmit and receive data. These three categories of service
are referred to as directory services, session control services and data
transfer services.
The slot layer itself formats slots for transmission and validates
received slots before passing the data to the user. The slot layer is also
responsible for flow control and periodic service advertisements.
8.2.1 Summary Of Functions -
The slot layer offers the following hierarchy of functions to the user
layer:
+------------------------------------------+-------------------+
| Function offered: | Type of function: |
+------------------------------------------+-------------------+
|H- start_service_class | directory service |
|S- poll_service_class | directory service |
|S- start_session (connect) | session service |
|H- new_session_poll | session service |
|H- accept_new_session | session service |
|H- reject_new_session | session service |
|SH- poll_session | session service |
|SH- queue_rcv_slot_buffer | data service |
|SH- poll_rcv_done | data service |
|SH- queue_attention_buffer | data service |
|SH- poll_attention_done | data service |
|SH- volunteer_xmt_data_a | data service |
|SH- volunteer_xmt_data_b | data service |
|SH- volunteer_attention_data | data service |
|SH- poll_xmt_done | data service |
|SH- end_session (disconnect) | session service |
|H- end_service_class | directory service |
+------------------------------------------+-------------------+
- 52 -
Local Area Transport Architecture - internal use only Page 53
LAYER INTERFACES 03 May 84
8.2.2 Description Of Functions -
The functions offered to the user by the slot layer are:
o H-start_service_class(class,timer;status),
H-end_service_class(class,reason;status),
S-poll_service_class(class;status) - these functions are used to
advertise availability and to determine availability of particular
service classes (such as interactive terminals) in the local area.
Conceptually, these functions bracket all of the other services
offered to the users by the slot layer. These are directory
services, and are not an integral part of an implementation. These
functions normally control the transmission and reception of
multicast addresses.
o class - service class (see appendicies)
o timer (optional) - specified in seconds, determines frequency of
multicast message transmission HOST_MULTICAST_TIMER (see DEFINED
PARAMETERS AND RECOMMENDED OR REQUIRED DEFAULT VALUES).
o status - one of: class enabled, class disabled.
o S-start_session(rem_srv_nm,loc_srv_nm,class,min_slot_size;-
S----------------------------------------------handle,status),
SH-end_session(handle,reason;status) - these functions are used to
establish a new session and to disestablish an existing session.
These functions bracket the remaining functions offered to a user by
the slot layer; data services cannot be invoked unless the user has
successfully established a session.
o address - Ethernet address of host
o rem_service_name - The name of the host service selected by the
user. This field may not be null.
o loc_service_name - The name of the local service (username) or
null.
o class - service class
o handle - used to reference the session locally
o slot_size - the minimum slot size queued by
queue_rcv_slot_buffer for Data_a, Data_b and Attention slots.
o status - one of: request_active, request_rejected (see service
class appendix), insufficient resources to complete request, no
such session.
o reason - the reason can be an integer value, a byte counted
ASCII string or both. This reason may be supplied to the users
if that is appropriate to the implementation. The reason is
conveyed to the remote half-session by the Stop message and/or a
multicast message.
- 53 -
Local Area Transport Architecture - internal use only Page 54
LAYER INTERFACES 03 May 84
o H-new_session_poll(;handle,status),
H-accept_new_session(hndl,rem_slt_nm,loc_slt_nm,min_slt_size,mode;-
H----------------------------------------------------------status),
H-reject_new_session(handle,reason;status) - these functions are
used to accept or reject a request to establish a session.
o handle - used to reference the session locally
o rem_slot_name - The slot_name received in the start slot or
null.
o loc_slot_name - The name of the local slot block (could be the
host service name or some other name) or null.
o slot_size - the minimum slot size queued by
queue_rcv_slot_buffer for Data_a, Data_b and Attention slots.
o status - one of: request active, request_rejected(see service
class appendix), insufficient resources to complete request, no
such session.
o reason - the reason can be an integer value, a byte counted
ASCII string or both.
o SH-poll_session(handle;status,quality) - this function is used to
determine the status of existing sessions.
o handle - used to reference the session locally
o status - Starting, Running or Halted (with reason code).
o quality - the quality of the virtual circuit, one of: VC_ok,
VC_suspect, transport disabled.
o SH-queue_rcv_slot_buffer(handle,buffer;status),
SH-poll_rcv_done(handle;buffer,status) - these functions allow slot
buffers to be queued and received slot data to be delivered. The
minimum length of this receive buffer is specified in the Start slot
MINIMUM_ATTENTION_SLOT_SIZE and MINIMUM_DATA_SLOT_SIZE fields.
Since slot credits are used for both Data_a and Data_b slots, these
slot receive buffers must be the same minimum size.
o handle - a reference to a local session
o buffer - the starting address and length of a buffer.
o status - one of: buffer queued, no slot data available, slot
data available (Start, Stop, Data_a, Data_b or Reject).
o SH-queue_attention_buffer(handle,buffer;status),
SH-poll_attention_done(handle;buffer,status) - these functions allow
the user to receive out of band data. Data delivered by this
function is not sequenced relative to the data delivered via
poll_rcv_done. If the data delivered by this function is not
received faster than it is delivered, new data may be discarded by
the slot layer.
- 54 -
Local Area Transport Architecture - internal use only Page 55
LAYER INTERFACES 03 May 84
o handle - a reference to a local session
o buffer - the starting address and length of a buffer.
o status - one of: buffer queued, no data available, data
available, data available and data missed.
o SH-volunteer_xmt_data_a(handle,buffer;status),
SH-volunteer_xmt_data_b(handle,buffer;status),
SH-volunteer_xmt_attention(handle,buffer;status),
SH-poll_xmt_done(handle;buffer,status) - these functions allow data
and attention slots to be transmitted to the session partner.
Attention data is not flow controlled. Attention data (out of band)
is not blocked by the normal data (in band).
o handle - a reference to a local session
o buffer - the starting address and length of a buffer.
o status - one of: buffer queued, data transmitted.
- 55 -
Local Area Transport Architecture - internal use only Page 56
LAYER INTERFACES 03 May 84
8.3 Slot/Virtual Circuit Layer Interface
This interface allows the slot layer to establish virtual circuits and to
transmit and receive messages and multicast datagrams.
The virtual circuit layer maintains virtual circuits to one or more remote
systems, transmits and receives messages, runs a timer, transmits and
receives multicast datagrams and notifies the slot layer about changes in
service.
8.3.1 Summary Of Functions -
In summary, the virtual circuit layer offers the following hierarchy of
functions to the slot layer:
+------------------------------------------+
| Function offered: |
+------------------------------------------+
|SH- queue_rcv_datagram |
|SH- poll_rcv_done |
|SH- queue_transmit_datagram |
|SH- poll_transmit_done |
|S- VC_start |
|H- accept_virtual_circuit |
|SH- poll_virtual_circuit |
|SH- poll_receive_message_done |
|SH- queue_transmit_message |
|SH- poll_transmit_message_acked |
|SH- transmit_unacknowledged_queue |
|SH- VC_stop |
+------------------------------------------+
- 56 -
Local Area Transport Architecture - internal use only Page 57
LAYER INTERFACES 03 May 84
8.3.2 Description Of Functions -
The specific functions offered to the slot layer by the virtual circuit
layer are:
o S-Virtual_Circuit_start(node_name,max_sessions;handle,status),
H-accept_virtual_circuit(handle;status),
SH-Virtual_Circuit_stop(handle;status) - these functions allow the
slot layer to establish and disestablish virtual circuits. The slot
layer must poll the virtual circuit layer to discover the state of
virtual circuits and the state of the underlying data link itself.
The host node must not dally in responding to a request to start a
virtual circuit. If the host node wishes not to have any new
circuits established, all service classes should be disabled and the
appropriate status should be indicated in the multicast message
transmitted by the host periodically. This multicast message should
be transmitted at least once before host services are discontinued.
o address - Ethernet address of destination system
o node_name - The name of the target node. Used as the virtual
circuit name CIRCUIT_NAME.
o max_sessions (optional) - the maximum number of session that
will ever be active simultaneously. If supplied by the terminal
server, a host implementation might avoid allocating
unnecessarily large data structures.
o handle - handle used to reference the virtual circuit locally (
a reference to the circuit block)
o status - one of: insufficient resources to complete request, no
such circuit.
o H-poll_virtual_circuit(;handle,status,quality),
SH-poll_virtual_circuit(handle;status,quality) - these functions
allow the existence of new sessions and the status of existing
sessions to be determined.
o handle - handle used to reference the virtual circuit locally
o status - one of: Starting, Running or Halted (with reason).
o quality - the virtual circuit quality, one of: VC_ok,
VC_suspect, Ethernet data link disabled.
o SH-queue_receive_datagram(buffer;status),
SH-poll_rcv_done(;handle,buffer,status) - this function gives the
virtual circuit layer datagram buffers which are in turn queued to
the Ethernet data link. These datagram buffer are filled by
multicast datagrams and by virtual circuit messages.
o buffer - address and length of a buffer.
- 57 -
Local Area Transport Architecture - internal use only Page 58
LAYER INTERFACES 03 May 84
o status - one of: buffer queued, no data available, multicast
datagram available.
o H-queue_transmit_datagram(buffer;status),
H-poll_transmit_done(;buffer,status) - these functions queue
datagrams to the Ethernet data link for transmission and poll for
the transmit completion. These functions are used to transmit the
multicast (or possibly other types) of datagrams.
o buffer - address and length of a buffer.
o status - one of: buffer queued, transmitter error.
o SH-queue_transmit_message(handle,buffer;status),
SH-poll_transmit_message_acked(handle;buffer;status) - these
functions allow the slot layer add messages to the virtual circuit
layer unacknowledged message queue and to receive them back after
they have been acknowledged.
o handle - handle used to reference the virtual circuit locally
o buffer - address and length of a message.
o status - one of: message queued for transmission or message
transmitted.
o SH-transmit_unacknowledged_queue(handle) - this function caused all
outstanding unacknowledged messages to be retransmitted.
o handle - handle used to reference the virtual circuit locally
o SH-poll_receive_message_done(handle;buffer,status) - this function
allows the slot layer poll the transport layer for any received
messages.
o handle - handle used to reference the virtual circuit locally
o buffer - address and length of a message.
o status - one of: no data available, message available.
- 58 -
Local Area Transport Architecture - internal use only Page 59
AXIOMS AND ALGORITHMS 03 May 84
9.0 AXIOMS AND ALGORITHMS
This section details a set of algorithms that would produce the correct
behavior at the user and Ethernet data link interfaces. While these
algorithms would produce the desired result, any number of equivalent
algorithms that produce an equivalent result at the same two interfaces would
serve equally well.
The whole architecture can be characterized as two (host and terminal
server) two-port black boxes. Compressing both the host and the terminal
server into single diagram, one might visualize the internal structure of the
LAT architecture as:
U S E R L A Y E R
v o l u n t e e r +--------+ r e c e i v e
slot data | SLOT | slot data
------------------------------------| BLOCK |----------------------------------
| |(shared)| ^
v +--------+ | E C
+-----------------+ +-----------------+ O L
timer | slot | pass credits | slot | N A
---------->| multiplexer |<----------------------| demultiplexer | N N Y
+--| (slots into msg)| pass control (in host)| (msg into slots)| E E
| +-----------------+ +-----------------+ C R
| | ^ ^ |queue D T
| transmit| | +-----------+ | |receive
v messagev | | CIRCUIT | | vbuffer
--------+----------+-+-------------| BLOCK |--------------+-+---------------
transmit| | ^ | (shared) | ^ |
unacked| | |return +-----------+ | |
queue| | |acknowledged deliver| | T
| v |message message| v R
| +-----------------+ +-----------------+ A L
| | message | remove acked message | message | N A
+->| transmitter |<----------------------| receiver | S Y
|(virtual circuit |<----------------------|(virtual circuit | P E
| maintenance) | transmit unacked queue| maintenance) | O R
+-----------------+ +-----------------+ R
transmit | transmit ^ receive ^ queue | T
datagram v complete | datagram | receive v
--------------------------------------------------------------------------------
ETHERNET DATA LINK LAYER
- 59 -
Local Area Transport Architecture - internal use only Page 60
AXIOMS AND ALGORITHMS 03 May 84
The following process abstractions are (somewhat arbitrarily) created
within the slot layer to help present a detailed model of the internal flow
of control and data within the layer:
o slot_demultiplexer - turns a message into one or more slots
o slot_multiplexer - turns one or more slots into messages
o session_starter - allocates a SLOT_BLOCK and initializes a
half-session
o session_ender - closes a half-session and deallocates the SLOT_BLOCK
o administrator - advertises service (in host) and builds lists (in
terminal server)
The following process abstractions are (again somewhat arbitrarily)
created within the virtual circuit layer to help present a detailed model of
the internal flow of control and data within the layer:
o circuit_starter (terminal server only) - starts new virtual circuits
o circuit_ender - stops an existing virtual circuit
o message_receiver - receives datagrams from the Ethernet data link,
validates the received datagrams (turning each into a message) and
passes the message on to the slot layer
o message_transmitter - receives messages from the slot layer,
maintains a queue of unacknowledged messages, and transmits
datagrams on the Ethernet data link
- 60 -
Local Area Transport Architecture - internal use only Page 61
AXIOMS AND ALGORITHMS 03 May 84
9.1 Virtual Circuit Layer
The algorithms described in this section correspond to the state table
actions, not the state table events.
9.1.1 Circuit Starter (terminal Server Only) -
When a request is received to start a new virtual circuit (via the
VC_start function), the terminal server:
o allocate a circuit block (see state diagram) and buffers. Allocate
NBR_DL_BUFS+1 receive message buffers and one transmit message
buffer where NBR_DL_BUFS is the value sent in the Start message.
o queue the receive message buffer(s) to the Ethernet data link via
the queue_rcv_datagram function
o store the transmit message buffer in the circuit block
o Translate the CIRCUIT_NAME into a 48-bit Ethernet address and load
this address into the REM_ADDRESS field of the Circuit Block.
o generate a Start message (using the transmit message buffer) and
queue it to the Message Transmitter via the queue_transmit_message
function
9.1.2 Circuit Ender -
When a request is received to stop an existing virtual circuit (via the
VC_stop function), the Circuit Ender generates a Stop message and queues it
to the Message Transmitter via the queue_transmit_message function and
indicates in the circuit block that the virtual circuit is in the Halted
state.
In the host, if service is being terminated, the Circuit Ender should also
send at least one multicast datagram to indicate that service has been ended.
9.1.3 Message Receiver -
The message receiver validates received messages. The Ethernet data link
verifies the:
o Ethernet destination address of the frame matches that of the local
system
o LAT protocol type (depending on implementation)
- 61 -
Local Area Transport Architecture - internal use only Page 62
AXIOMS AND ALGORITHMS 03 May 84
After these fields are checked, the message type is determined from the
LAT header MESSAGE_TYPE field. The received message is then mapped as one of
the message types (see STATE DIAGRAMS section). If any of the actions
described fails, the message is discarded without perturbing the existing
circuit state. In any case, the receive buffer is always queued back to the
Ethernet data link quickly with respect to SERVER_CIRCUIT_TIMER.
o Start message (host) -
o discard message if the SRC_CIR_ID field of message is zero.
o Match to an existing circuit block or, if no circuit block
exists, allocate a circuit block and buffers. If insufficient
resources exist to accomplish this, a best effort attempt is
made to send a Stop message. Normally one receive message
buffer is allocated. If the NBR_DL_BUFS field in the Start
message response will be non-zero, that many additional receive
buffers are allocated. Two transmit message buffers plus
(optionally) the value in the NBR_DL_BUFS in the received Start
message are allocated. (One transmit message buffer is consumed
by a message containing data with the RRF flag clear since it
will not be acknowledged; so a second buffer is required which,
if it is the last, will always have RRF set to force a terminal
server response).
o queue the receive message(s) to the Ethernet data link via the
queue_rcv_datagram function
o store the available transmit message buffers in the circuit
block
o copy the SRC_CIR_ID field from the received message to the
REM_CIR_ID field of the circuit block, copy the SRC_ADDRESS from
the received message into the Circuit Block and copy the
CIRCUIT_NAME from the Start message in to the Circuit Block.
o generate a Start message (normally) or generate a Stop message
(with a reason specified) and queue it to the Message
Transmitter via the queue_transmit_message function
o Start message (terminal server) -
o If the SRC_CIR_ID is non-zero, match to an existing circuit
block. If no circuit block is referenced (invalid message)
discard the message and send a Stop message addressed too
SRC_CIR_ID. If the SRC_CIR_ID is zero it is an illegal message.
If a valid Start message is received, SRC_CIR_ID of the received
message should be copied to the REM_CIR_ID field of the
referenced circuit block.
o if the NBR_DL_BUFS field in the received Start message is
non-zero, optionally allocate that many additional transmit
buffers and store them in the circuit block.
- 62 -
Local Area Transport Architecture - internal use only Page 63
AXIOMS AND ALGORITHMS 03 May 84
o Run_msg_rcv (Host and terminal server) -
o If the MSG_SEQ_NBR is not equal to ACK+1 (modulo 256) in the
circuit block, set the NBR_SLOTS in the message header to zero.
In the terminal server only, if the MSG_SEQ_NBR is not equal to
ACK+1, copy the SOURCE_ADDRESS of the received message into the
CIRCUIT_BLOCK REM_ADDRESS field - this will allow dynamic path
failover if a host node has access to two different Ethernet
ports.
o In terminal server, if RRF is set, set DWF.
o request the Message Transmitter to return all messages
acknowledged by the value MSG_ACK_NBR received in the message.
This algorithm must be done modulo 256.
o In the host node, stop the HOST_RETRANSMIT_TIMER if all messages
are acknowledged.
o If the MSG_SEQ_NBR is equal to ACK+1 (modulo 256) in the circuit
block then increment ACK in the circuit block.
o pass the message to Slot demultiplexer
o Stop_rcv (or Reject_rcv) -
o notify slot demultiplexer of circuit state transition
o indicate state of circuit block is Halted
o requeue the datagram buffer to the Ethernet data link
Any time the circuit goes into the Halted state, the circuit block
can be deallocated along with its associated resources.
A special use of the DST_CIR_ID field occurs whenever the host node and
terminal server are out of synchonization due to crashes, prolonged
communication link failures or nonsequential message delivery. In these
cases, the remote system might ignore the message (possibly a delayed Stop
message) in order to preserve the currently Running virtual circuit. In
order to close this half established (half-open session), the SRC_CIR_ID
field is copied from the Running message into the REM_CIR_ID field of the
circuit block and a Stop message is generated. This will cause the remote
system to reinitialize.
Any fields not defined by the LAT architecture (labeled UNPREDICTABLE in
the message formats) are ignored.
- 63 -
Local Area Transport Architecture - internal use only Page 64
AXIOMS AND ALGORITHMS 03 May 84
9.1.4 Message Transmitter -
The terminal server message transmitter normally maintains an
unacknowledged transmit queue of one entry, while the host node normally
maintains a queue of one or two entries. If extra data link buffers are
allocated, these queues can be longer.
The Message transmitter gets three types of requests:
o transmit unacknowledged transmit queue - this causes the Message
Transmitter to start transmitting the head of the queue, wait for
the transmit complete event, and transmit the next message until the
entire queue has been emptied. If this was in progress when the
request to retransmit the queue is made, the request is ignored.
Before a message is retransmitted, the MSG_ACK_NBR field in the
message header is copied from the circuit block field ACK.
The Retransmit limiter is a part of the message transmitter.
Every time the head of the unacknowledged transmit queue is
transmitted, the retransmit counter is incremented (either
HOST_RETRANSMIT_COUNTER or SERVER_RETANSMIT_COUNTER). Every time
the head of the unacknowledged transmit queue changes,
Retransmit_Counter is zeroed. If the retransmit counter reaches
LAT_MESSAGE_RETRANSMIT_LIMIT, the Resend_limit event occurs. This
event (Resend_limit) should cause users to be notified of the
unacceptable virtual circuit quality.
o queue/dequeue transmit message - this adds and deletes entries from
the unacknowledged transmit queue. As each new message is added to
the queue, via the queue_transmit_message function, the message the
header is created by:
o copying the REM_CIR_ID from the circuit block to the message
field DST_CIR_ID
o copying the LOC_CIR_ID from the circuit block to the message
field SRC_CIR_ID
o (host only) the RRF flag is:
o set if:
1. the Circuit Block DWF is set or
2. this is the last transmit message buffer
3. credit consuming slots were sent in last message
4. (optionally) if new data is expected via the volunteer
functions - this may cause better behaviour under load
by preventing unnecessary "unsolicited" messages from
being sent by the host. This state could be anticipated
if data were delivered but not echoed for instance.
- 64 -
Local Area Transport Architecture - internal use only Page 65
AXIOMS AND ALGORITHMS 03 May 84
o cleared if:
1. the Circuit Block DWF is clear and
2. this is not the last transmit message buffer
3. no credit consuming slots were sent in last message
o (host only) copying the RRF flag state into the message header
from the circuit block
o copying the NXMT circuit block field into the message header
MSG_SEQ_NBR and incrementing NXMT
o transmit datagram - this function transmits the buffer and returns
the transmit complete event, along with the buffer, to the
requestor.
Retransmission of the unacknowledged transmit queue (the first of the
three types of request described above) in the host node occurs at the rate
HOST_RETRANSMIT_TIMER seconds. This causes messages to be retransmitted
about every one or two seconds.
In the terminal server, this would be an unsatifactory arrangement due to
the rate at which retransmissions would occur (the value used by
SERVER_CIRCUIT_TIMER is typically 80 milliseconds). Because the most likely
reason a message is being retransmitted is that the host node has not had a
chance to process the received message, the terminal server retransmission of
messages must occur at dramatically reduced rates. One acceptable policy is
to retransmit at SERVER_RETRANSMIT_TIMER intervals after the original message
was sent.
NOTE
In an actual implementation, the host node may
be overloaded and unable to respond to received
buffers. The retransmit policy is based on the
assumption that the host node has not responded
because it has not processed the buffer. This
policy assures that the host node is not
swamped with duplicate buffers during heavy
host loading.
- 65 -
Local Area Transport Architecture - internal use only Page 66
AXIOMS AND ALGORITHMS 03 May 84
9.1.5 Circuit Timer Policy -
The circuit timers, in both the terminal server and the host node, should
be reset both when the message is queued for transmission and when the
transmit completes. This policy prevents multiple terminal servers from
synchronizing by utilizing the Ethernet backoff algorithm.
9.1.6 Buffering -
The LAT architecture assumes that any receive buffers assigned to the
Ethernet data link cannot be preempted by other architectures that might
share the data link. Failure to adhere to this policy may cause LAT to be
unable to deliver data in a timely fashion.
In the case of a host implementation, the initial processing of received
data link buffers should occur at high priority. Received messages that are
out of sequence or received start messages that cause the current total to
exceed the value LAT_MAX_SERVERS, must be rejected immediately and requeued
to the Ethernet data link to allow new data messages to be stored until they
can be processed. Failure to adhere to this policy can cause long delays
since host buffers can be filled by duplicates causing non-duplicates to not
be delivered. If the retransmission policy is to wait one second, this
failure mode will cause one second delays as perceived by the user.
9.2 Slot Layer
The algorithms described in this section correspond to the state table
actions, not the state table events.
9.2.1 Host System Management -
When the start of service is announced in the host (start_service_class
function), a transmit datagram must be allocated and reserved for the purpose
of transmitting the multicast datagram periodically. In addition,
LAT_MAX_SERVERS receive datagram buffers must be allocated and queued via the
queue_receive_datagram function. The value LAT_MAX_SERVERS is equal to the
number of terminal servers that the host node wishes to allow to startup
simultaneously.
These same resources must be recovered when the end of service is
announced.
o Start multicast transmit and start multicast timer for
retransmission.
- 66 -
Local Area Transport Architecture - internal use only Page 67
AXIOMS AND ALGORITHMS 03 May 84
o Stop the HOST_RETRANSMIT_TIMER (the timer could not be active since
no virtual circuits are active).
- 67 -
Local Area Transport Architecture - internal use only Page 68
AXIOMS AND ALGORITHMS 03 May 84
9.2.2 Terminal Server System Management -
When service is started in the terminal server:
o at least one buffer should be queued to the data link to receive
multicast addresses.
o start the server circuit timer in anticipation of virtual circuits
being activated (it should already be running).
Policies might reasonably be modified or extended by each different
service class.
- 68 -
Local Area Transport Architecture - internal use only Page 69
AXIOMS AND ALGORITHMS 03 May 84
9.2.3 Session Starter (terminal Server) -
This process allocates and initializes a slot block upon receiving a call
from the start_session function.
One important responsibility of the session starter of the terminal server
is translating the REM_SERVICE_NAME supplied in the start_session function
into a NODE_NAME to be passed in the VC_START function when a new virtual
circuit must be established.
9.2.4 Session Starter (host) -
A host service implementation can choose between two models. In one
model, received Start slots cause the user to receive a request to start a
new session. The user can then either accept or reject the session. The
user should not procrastinate in making this decision.
The second model does not give the host service this choice, but instead
accepts or rejects the session without notifying the service. Later the host
service may stop the session with a reason.
If a DST_SLOT_NAME is specified in the start slot, the host session can be
bound to a specific host service (host port such a specific controller or
unit) associated with the slot name or can be bound to a more abstract
service, such as electronic mail.
9.2.5 Slot Demultiplexer -
This process receives its input and control from the poll_rcv_done
function. Each such message received has been validated on the virtual
circuit by the message receiver.
Messages contain zero or more slots. A slot can be a Start, Data_a,
Data_B, Attention, Reject, or Stop slot.
Slots are validated by using the received slot's DST_SLOT_ID field to
reference a slot block. The referenced slot block's LOC_SLOT_ID field must
equal the received slot's DST_SLOT_ID field. Additionally, the received
slot's SRC_SLOT_ID field must equal the slot block's REM_SLOT_ID field. The
slot type field must be consistent with the state block receiving the slot.
(See the section on slot mapping onto state diagram.)
If the terminal server receives a start slot, the slot's SRC_SLOT_ID field
is copied into the referenced slot block's REM_SLOT_ID field.
In the host, the slot_demultiplexer creates and initializes a slot block
if a start slot is received and passes the slot block to the appropriate
class of service via the new_session_poll function. The slot block is a data
- 69 -
Local Area Transport Architecture - internal use only Page 70
AXIOMS AND ALGORITHMS 03 May 84
structure shared by all slot layer processes and is accessed by the user
processes. (see slot state variables section).
The host may use the DST_SLOT_NAME supplied in the Start slot to bind the
session to a particular service access point.
If any credits are received in a slot, the credit field value is added
into the LOCAL_CREDIT field of the referenced slot block to create a new
total.
Data_a and Data_b slots are delivered via the poll_rcv_done; Attention
slots are delivered via poll_attention_done; Start and Stop slots are
delivered via the poll_session function.
A Stop slot causes the slot block to be deallocated and the event is
delivered to the user via the poll_session function.
In the host, after the slot demultiplexer has finished processing the
received message, the message is requeued to the virtual circuit layer and
control is passed to the slot multiplexer.
9.2.6 Slot Multiplexer -
In the host, this process receives control soon after the slot
demultiplexer executes. This transfer of control can be immediate or can be
delayed in an effort to return more data in the reponse. This transfer of
control between the slot demultiplexer and the slot multiplexer in the host
does not have to preserve the "serial and atomic" requirement stated in the
layer interface introduction. This delay should never exceed about 1/2 the
SERVER_CIRCUIT_TIMER; the response generated must be received by the termial
server before SERVER_CIRCUIT_TIMER expires a second time.
In the terminal server, this transfer of control is timer based and cannot
be less than SERVER_CIRCUIT_TIMER milliseconds.
When reading the algorithms, keep in mind that "slot data" can be Data_a,
Data_b, Attenton data or REMOTE_CREDITS waiting to be transfered.
Before accepting any data from users, the process verifies that at least
one transmit message buffer is available in the circuit block. If none is
available, then execute the transmit_unacknowledged_transmit_queue function.
- 70 -
Local Area Transport Architecture - internal use only Page 71
AXIOMS AND ALGORITHMS 03 May 84
The following algorithm is executed by the terminal server whenever control
is received from the timer event and by the host whenever control is received
from the slot_demultiplexer. In the host, transfer of control is also
received from the volunteer functions if the circuit block RRF flag is clear
(the Send_data event):
o In the host, if the DWF is clear:
o dequeue a transmit message buffer from the circuit block
XMT_BUFFER_FREEQ (if it is empty, execute the
transmit_unacknowledged_queue function and exit)
o generate a new message header
o execute queue_transmit_message
o execute transmit_unacknowledged_queue
o In the terminal server, if the DWF is clear, exit.
o if the DWF is set:
1. dequeue a transmit message buffer from the circuit block
XMT_BUFFER_FREEQ (if it is empty, go to step 8 - EXIT)
2. generate a new message header
3. UNTIL the message buffer is filled or UNTIL all slots have DRF
clear or UNTIL all slots with DRF set have no LOCAL_CREDITS
left: Find the next slot block with DRF set in a round-robin
fashion and:
- if Attention data is volunteered, format attention slot in
message buffer, clear DRF if no slot data is left. Exit
back to UNTIL loop.
- if Data_a or Data_b is signaled, decrement LOCAL_CREDITS (if
none available, go to next step), format Data_a or Data_b
slot header in message buffer, copy REMOTE_CREDITS field
from slot block into slot header and zero and REMOTE_CREDITS
field, copy data into slot and clear DRF if no slot data is
left. Exit back to UNTIL loop.
- if REMOTE_CREDITS is non-zero (because LOCAL_CREDITS is zero
in previous step or because no Data_a or Data_b has been
volunteered), format Data_a slot header in message buffer,
copy REMOTE_CREDITS field from the slot block into slot
header and zero the slot block REMOTE_CREDITS field, and
clear DRF if no slot data is left. Exit back to UNTIL loop.
4. queue the buffer via queue_transmit_message
5. if all slot block DRF flags are clear, clear DWF.
6. In the host, if control was received via a volunteer function,
the HOST_RETRANSMIT_TIMER is started. ( Whenever this timer
expires, all unacknowledged messages are retransmitted. )
7. If more slot data is available, go to step 1.
8. Exit - execute the transmit_unacknowledged_queue function.
- 71 -
Local Area Transport Architecture - internal use only Page 72
AXIOMS AND ALGORITHMS 03 May 84
9.2.7 Session Ender -
The terminal server cannot stop a session while it is in the Starting
state. This is because the handle on the remote slot block is not known
until a response to the start slot is received. Thus the special state
Abort_start is entered upon receiving a disconnect_req. A slot block in this
state cannot be used to start a new session.
Otherwise, either the host service or the terminal server user can issue
an end_session (disconnect) function call.
9.2.8 Flow Control -
There are two levels of flow control: One in the slot layer and one in
the virtual circuit layer.
9.2.8.1 Slot Flow Control -
The session user that owns a flow control credit (credit is held on user's
behalf by the slot layer), is guaranteed that the session partner will be
able to receive (and buffer) at least one Data_a or Data_b slot. In an
implementation, slot data is copied from a receive message buffer in the
virtual circuit layer into slot buffers supplied by the users. This is the
model described in this document.
These flow control credits are consumed by Data_a and Data_b slots if, and
only if, the SLOT_BYTE_COUNT field is non-zero.
As a CPU performance optimization, this can be implemented in different
way. CPU usage can be traded for memory usage. The users can supply data
link sized slot buffers ( LAT_MIN_RCV_DATAGRAM_SIZE ), and the entire buffer
can be passed to the user without copying data. This method requires that an
occupancy count be maintained for each buffer since buffers can be occupied
by one or more slots destined for different users. In this way received slot
data does not have to be copied. However prodigious amounts of memory is
consumed. For instance, to extend two slot credits for each of 8 users,
2x8x1518 (24,288) bytes of buffering is used instead of 2x8x255 (4080) bytes
of buffering.
References are made to "slot" flow control throughout the document. The
sections SLOT MULTIPLEXER and SLOT DEMULTIPLEXER in the AXIOMS and ALGORITHMS
section define how slot flow control is applied to a running slot session.
- 72 -
Local Area Transport Architecture - internal use only Page 73
AXIOMS AND ALGORITHMS 03 May 84
9.2.8.2 Message Buffer Flow Control -
In the virtual circuit layer, when a new circuit is to be established, a
fixed number of datagram buffers is allocated before the Start message is
sent. These buffers are queued as receive buffers to the Ethernet data link
layer. The number of buffers queued as receive buffers minus one is then
transmitted in the Start message NBR_DL_BUFS field.
In the terminal server, the number of transmit buffers allocated should be
equal to the value NBR_DL_BUFS received in the Start message plus one.
In the host, the number of transmit buffers allocated should be equal to
the value NBR_DL_BUFS received in the Start message plus two. This extra
buffer is used to sent the one possible "unsolicited" message when the
virtual circuit is balanced (RRF clear).
In general, this document does not directly refer to flow control at the
virtual circuit level (references to the term "flow control" are normally
references to slot flow control). Instead, references are made to the
availability of data link buffers (XMT_BUFFER_FREEQ in the circuit block).
Availability of a data link message buffer corresponds to the availability of
a credit to transmit a message buffer since these buffers remain on the
unacknowledged transmit queue until they are acknowledged by the receiving
process. This acknowledgement guarantees that the remote system has emptied
and requeued the data link buffer to receive a new message. See the AXIOMS
and ALGORITHMS section titled MESSAGE TRANSMITTER and MESSAGE RECEIVER.
9.2.9 Protocol Versions And ECO Control -
Multicast messages for each service class specify LOW_PRTCL_VER,
HIGH_PRTCL_VER, CUR_PRTCL_VER, CUR_PRTCL_ECO.
The start message specifies PRTCL_VER and PRTCL_ECO.
The HIGH_PRTCL_VER specifies the highest (most recent) protocol version
that the system supports.
The LOW_PRTCL_VER specifies the lowest (oldest) protocol version that the
system supports.
The CUR_PRTCL_VER specifies the protocol version of the message. In the
case of the Start message, it also guarantees that all other messages will
also be of the same protocol version as the Start message.
The PRTCL_ECO specifies the Engineering Change Order level of the message.
Again, in the case of the Start message, it also guarantees that all Run and
Stop messages will also be of the same ECO level as the Start message. ECOs
are made to a protocol version only if the change will not adversly affect
the unchanged systems already in the field.
- 73 -
Local Area Transport Architecture - internal use only Page 74
AXIOMS AND ALGORITHMS 03 May 84
If a change will make systems incompatabile in the field, then a newer
protocol version number is allocated.
- 74 -
Local Area Transport Architecture - internal use only Page 75
AXIOMS AND ALGORITHMS 03 May 84
9.3 Other Processes
9.3.1 Keep-alive Process -
The keep-alive process is relevant to the terminal server only - the host
does not implement a keep-alive process. The purpose of the keep-alive
process is to notify the users of an idle virtual circuit that the circuit is
suspected to be inoperable. This is is accomplished by causing data to be
transmitted at least every LAT_KEEP_ALIVE_TIMER seconds. The keep-alive
process accomplishes this by simply guaranteeing that the data waiting flag
(DWF) is set at least every LAT_KEEP_ALIVE_TIMER seconds.
Setting DWF causes a sequenced message to be sent. If the message
repeatedly fails to be acknowledged, the LAT_MESSAGE_RETRANSMIT_LIMIT will be
reached, and the users notified of the unacceptable circuit quality.
9.3.2 Progress Process -
In theory, the virtual circuits described in this document cannot
"deadlock". However, cosmic radiation, UNIBUSes and other equally
defenseless culprits are often blamed for events that "cannot" happen.
As insurance against such unlikely events, a terminal server can implement
a progress process. After the LAT_MESSAGE_RETRANSMIT_LIMIT is reached, an
implementation may choose to continue sending messages every
LAT_KEEP_ALIVE_TIMER seconds. If the value of LAT_MESSAGE_RETRANSMIT_LIMIT
should reach a ridiculous value, such as 500 messages, or if more than an
hour of real time has elapsed, the circuit should be stopped by transmitting
a stop message with an appropriate reason.
A host implementation must run an additional timer when the RRF flag is
clear in the circuit block. If a message is not received within a reasonable
time (as little as 2 or 3 times the LAT_KEEP_ALIVE timer seconds or as long
as a few days), the host may wish to generate a Stop message to stop the
circuit. If host implementation lacked this timer, it would not discover
that a terminal server had crashed if the crash occurs while the host RRF
flag was clear. The hazard is that host resources are dedicated to the
virtual circuit until a user from the same terminal server again requests
service from the host.
- 75 -
Local Area Transport Architecture - internal use only Page 76
MESSAGE FORMATS 03 May 84
10.0 MESSAGE FORMATS
Bits are transmitted onto the Ethernet low order bit first. When fields
are concatenated, the right hand field is transmitted first. Numeric fields
more that 8-bits long are transmitted least significant byte first.
Fields are represented as bit streams, right to left. All fields are an
integer multiple of eight bits. The symbol "=" is used to indicate fields of
varying or indeterminate length.
A message transmitted from a master to a slave (from a terminal server to
a host node) always has the MASTER bit of the message type field set to 1. A
message transmitted from a slave to a master always has the MASTER bit of the
message type field set to 0. Notice that this makes it possible to implement
both ends of the asymmetric LAT architecture simultaneously in a single
system.
LAT messages must be padded to the Ethernet 64 byte minimum. The data
used to pad the frame to achieve this 64-byte minimum are unpredictable.
- 76 -
Local Area Transport Architecture - internal use only Page 77
MESSAGE FORMATS 03 May 84
10.1 Virtual Circuit Message Header
All messages have the same header format:
1
5 0
+-------------------------------+
| DESTINATION_ADDRESS | E
| | T H
| | H E
+-------------------------------+ E A
| SOURCE_ADDRESS | R D
| | N E
| | E R
+-------------------------------+ T
| PROTOCOL_TYPE |
+===============================+
| NBR_SLOTS | MSG_TYPE |M|R|
+---------------+---------------+
| DST_CIR_ID |
+-------------------------------+
| SRC_CIR_ID |
+-------------------------------+
| MSG_ACK_NBR | MSG_SEQ_NBR |
+-------------------------------+
o R (1 bit) - RRF flag. This flag is clear for all message types
except for Run messages transmitted from the host node to the
terminal server which require responses. This flag is never set in
any message transmitted by the terminal server.
o M (1 bit) - MASTER flag. This flag is set in all messages sent by
the terminal server to the host node. Messages sent by the host
node to the terminal server always clear this flag.
o MSG_TYPE (6 bits) - the message type field:
o Start message have this field set to 1.
o Run message have this field set to 0.
o Stop message have this field set to 2.
o NBR_SLOTS - number of slots in the message
o DST_CIR_ID - one of the virtual circuit identifications
o SRC_CIR_ID - one of the virtual circuit identifications
o MSG_SEQ_NBR - message sequence number (modulo 256)
o MSG_ACK_NBR - message acknowledgement number (modulo 256)
- 77 -
Local Area Transport Architecture - internal use only Page 78
MESSAGE FORMATS 03 May 84
10.1.1 Start Message Format -
Start message headers have MSG_TYPE fixed at 1, the NBR_SLOTS equal to
zero. Additionally, start messages transmitted by the terminal server must
specify the DST_CIR_ID as zero and the SRC_CIR_ID as non-zero. Start
messages transmitted by the host node must specify these same two fields as
non-zero.
1
5 0
+-------------------------------+
| LAT_MIN_RCV_DATAGRAM_SIZE |
+---------------+---------------+
| PRTCL_ECO | PRTCL_VER |
+---------------+---------------+
| NBR_DL_BUFS | MAX_SIM_SLOTS |
+---------------+---------------+
|KEEP_LIVE_TIMER| SRV_CIRCT_TMR |
+---------------+---------------+
| FACILITY_NUMBER |
+-------------------------------+
| PRODUCT_TYPE_CODE |
+---------------+---------------+
| | NODE_NAME_LEN |
| +---------------+
= NODE_NAME =
+---------------+---------------+
| | SYS_NAM_LEN |
| +---------------+
| SYS_NAME |
+---------------+---------------+
| | LOCATION_LEN |
| +---------------+
= LOCATION_TEXT =
+---------------+---------------+
| PARM_LEN | PARM_CODE |
+---------------+---------------+
= PARM_DATA =
+-------------------------------+
| PARM_CODE, PARM_LEN, and |
= PARM_DATA repeated until =
| PARM_CODE is equal to zero. |
+-------------------------------+
= UNPREDICTABLE =
+-------------------------------+
- 78 -
Local Area Transport Architecture - internal use only Page 79
MESSAGE FORMATS 03 May 84
o LAT_MIN_RCV_DATAGRAM_SIZE (2 bytes) - The minimum and maximum sizes
of frames are restricted by the Ethernet specification to be in the
range 46 through 1518 bytes. An implementation must specify the
minimum size receive buffer that it queues to the data link layer of
Ethernet. Legal values are restricted by the LAT architecture to be
in the range of 576 through 1518 bytes.
o PRTCL_VER (1 byte) - The protocol version of this message and of all
messages transmitted during this session.
o PRTCL_ECO (1 byte) - The protocol version ECO (Engineering Change
Order) of this message and of all messages transmitted during this
session. For any given protocol version, ECOs are backward
compatible. The PRTCL_ECO level is intended to be used to reflect
patches made in the field by automatic updates or by field software
specialists.
o MAX_SIM_SLOTS (1 byte) - maximum number of simultaneous sessions
that can be opened on this virtual circuit. Value is suggested by
the terminal server. Value supplied by the host must be used as the
maximum by the terminal server.
o NBR_DL_BUFS (1 byte) - number of extra data link buffers queued.
This corresponds to the number of additional messages (beyond the
normal one message) that can be generated by the slot multiplexer on
the system receiving this start message.
o SERVER_CIRCUIT_TIMER (1 byte unsigned) - Circuit timer in 10
millisecond intervals. Specified by terminal server. This field is
ignored when received from the host. A value of zero in this field
is illegal.
o KEEP_ALIVE_TIMER (1 byte unsigned) - Value specified in seconds by
terminal server. This field is ignored when received from the host
by the termial server. A value of zero indicates that no keep-alive
message will be sent.
o FACILITY_NUMBER (2 bytes) - Value specified by the server and host.
This value is not restricted. It is intended to allow terminal
servers and hosts to be uniquely numbered within a local area. A
privileged user should supply this value to the implementation.
o PRODUCT_TYPE_CODE (2 bytes unsigned) - The product type codes are
assigned by Digital Equipment Corporation.
o NODE_NAME_LEN (1 byte unsigned) - The byte count of the next field.
A value of zero in this field is illegal.
o NODE_NAME - The name of the virtual circuit.
- 79 -
Local Area Transport Architecture - internal use only Page 80
MESSAGE FORMATS 03 May 84
o SYSTEM_NAME_LEN (1 byte unsigned) - Byte count of SYSTEM_NAME field.
This field may be zero.
o SYSTEM_NAME (SYSTEM_NAME_LEN bytes) - The text within this field
describes the terminal server or host node that transmitted the
message.
o LOCATION_LEN (1 byte unsigned) - Byte count of LOCATION_TEXT field.
This field may be zero.
o LOCATION_TEXT (LOCATION_LEN bytes) - The text within this field
should describe the physical location of the system that transmits
this message.
o PARM_CODE (1 byte) - A parameter code. No parameter codes are
currently defined. The value zero indicates the end of the list
(which means the following fields are unpredictable). A non-zero
value in this field indicates the next two fields are valid.
Parameter codes 0 through 127 are reserved for use by Digital
Equipment Corporation, while parameter codes 128 through 255 are
reserved for users.
o PARM_LEN (1 unsigned byte) - the length of the following field in
bytes.
o PARM_DATA (PARM_LEN bytes) - the format of this field is defined by
the associated PARM_CODE.
- 80 -
Local Area Transport Architecture - internal use only Page 81
MESSAGE FORMATS 03 May 84
10.1.2 Run Message Format -
Run messages have MSG_TYPE set to 0. If the NBR_SLOTS (number of slots in
the message) is zero, then the message header is the entire message.
NBR_SLOTS is equal to the number of slots within the message. The DST_CIR_ID
and SRC_CIR_ID must always be non-zero in Run messages.
Each slot is aligned on word (16-bit) boundaries. The first slot is
contiguous to the message header. The second slot is contiguous to the first
if the slot's total length is even. If a slot's total length is odd, then
one byte of UNPREDICTABLE data is used as a pad byte between the slot to
force the following slot to a word boundary.
Run messages can contain Start, Data_a, Data_b, Attention, Reject and/or
Stop slots.
Note that the slot type assignment are done to assist an implementation in
detecting a Data_a slot. Specifically Data_a slots are assigned the value
zero while all other slots (and all future slot type assignments) are
assigned a four bit value with the left-most bit set. Thus Data_a slots are
easily recognized since the byte value is alway zero or positive and credits
are coveyed by Data_a slots as a byte value.
- 81 -
Local Area Transport Architecture - internal use only Page 82
MESSAGE FORMATS 03 May 84
10.1.2.1 Start Slot -
If a start slot is received (see slot state tables), the format of the
slot is:
7 0
+-------------------------------+
| DST_SLOT_ID |
+-------------------------------+
| SRC_SLOT_ID |
+-------------------------------+
| STATUS_BYTE_COUNT |
+---------------+---------------+
| SLOT_TYPE | CREDITS |
+===============+===============+
| SERVICE_CLASS | <-- start of STATUS field
+-------------------------------+
| MINIMUM_ATTENTION_SLOT_SIZE |
+-------------------------------+
| MINIMUM_DATA_SLOT_SIZ |
+---------------+---------------+
| |DST_SLT_NAM_LEN|
= +---------------+
| DST_SLOT_NAME =
+---------------+---------------+
| |SRC_SLT_NAM_LEN|
= +---------------+
| SRC_SLOT_NAME =
+-------------------------------+
= remainder of STATUS field =
+-------------------------------+
| UNPREDICTABLE | (only exists if
+-------------------------------+ STATUS_BYTE_COUNT is odd)
o DST_SLOT_ID - a reference to a slot block
o SRC_SLOT_ID - a reference to a slot block
o STATUS_BYTE_COUNT - an unsigned integer count of the length of the
STATUS field.
o CREDITS (4 bits) - a 4-bit integer equal to the number of credits
being transferred.
o SLOT_TYPE (4 bits) - the value 9 (1001).
o SERVICE_CLASS - see appendices
o MINIMUM_ATTENTION_SLOT_SIZE (1 byte) - The minimum slot size queued
to receive Attention slot data (not including the slot header). The
system receiving this message must limit transmitted Data_a slots to
this size. A value of zero indicates Attention slots are not
supported.
o MINIMUM_DATA_SLOT_SIZE (1 byte) - The minimum slot size queued to
receive Data_a and Data_b slots (not including the slot header).
The system receiving this message must limit transmitted Data_a and
Data_b slots to this size.
- 82 -
Local Area Transport Architecture - internal use only Page 83
MESSAGE FORMATS 03 May 84
o DST_SLOT_NAME_LEN (1 byte unsigned) - The byte count of the next
field.
o DST_SLOT_NAME - The name of the destination slot block. If received
by a host, often this field specifies a host service name.
o SRC_SLOT_NAME_LEN (1 byte unsigned) - The byte count of the next
field.
o SRC_SLOT_NAME - The name of the source slot block. If received by a
host, often this field specifies a username.
o STATUS - The remainder of the status field meanings are defined
separately for each service class.
- 83 -
Local Area Transport Architecture - internal use only Page 84
MESSAGE FORMATS 03 May 84
10.1.2.2 Data_a Slot -
7 0
+-------------------------------+
| DST_SLOT_ID |
+-------------------------------+
| SRC_SLOT_ID |
+-------------------------------+
| SLOT_BYTE_COUNT |
+---------------+---------------+
| SLOT_TYPE | CREDITS |
+===============+===============+
= SLOT_DATA =
+-------------------------------+
| UNPREDICTABLE | (only exists if
+-------------------------------+ SLOT_BYTE_COUNT is odd)
o DST_SLOT_ID - a reference to a slot block
o SRC_SLOT_ID - a reference to a slot block
o SLOT_BYTE_COUNT - an unsigned integer count of the length of the
SLOT_DATA field.
o CREDITS (4 bits) - a 4-bit positive integer equal to the number of
credits being transferred.
o SLOT_TYPE (4 bits) - the value 0.
o SLOT_DATA - SLOT_BYTE_COUNT bytes of slot data.
- 84 -
Local Area Transport Architecture - internal use only Page 85
MESSAGE FORMATS 03 May 84
10.1.2.3 Data_b Slot -
7 0
+-------------------------------+
| DST_SLOT_ID |
+-------------------------------+
| SRC_SLOT_ID |
+-------------------------------+
| SLOT_BYTE_COUNT |
+---------------+---------------+
| SLOT_TYPE | CREDITS |
+===============+===============+
= SLOT_DATA =
+-------------------------------+
| UNPREDICTABLE | (only exists if
+-------------------------------+ SLOT_BYTE_COUNT is odd)
o DST_SLOT_ID - a reference to a slot block
o SRC_SLOT_ID - a reference to a slot block
o SLOT_BYTE_COUNT - an unsigned integer count of the length of the
SLOT_DATA field.
o CREDITS (4 bits) - a 4-bit positive integer equal to the number of
credits being transferred.
o SLOT_TYPE (4 bits) - the value 10. (1010)
o SLOT_DATA - SLOT_BYTE_COUNT bytes of slot data.
- 85 -
Local Area Transport Architecture - internal use only Page 86
MESSAGE FORMATS 03 May 84
10.1.2.4 Attention Slot -
7 0
+-------------------------------+
| DST_SLOT_ID |
+-------------------------------+
| SRC_SLOT_ID |
+-------------------------------+
| SLOT_BYTE_COUNT |
+---------------+---------------+
| SLOT_TYPE | MBZ |
+===============+===============+
= SLOT_DATA =
+-------------------------------+
| UNPREDICTABLE | (only exists if
+-------------------------------+ SLOT_BYTE_COUNT is odd)
o DST_SLOT_ID - a reference to a slot block
o SRC_SLOT_ID - a reference to a slot block
o SLOT_BYTE_COUNT - an unsigned integer count of the length of the
SLOT_DATA field.
o MBZ (4 bits) - must be zero.
o SLOT_TYPE (4 bits) - the value 11. (1011)
o SLOT_DATA - SLOT_BYTE_COUNT bytes of slot data.
- 86 -
Local Area Transport Architecture - internal use only Page 87
MESSAGE FORMATS 03 May 84
10.1.2.5 Reject Slot -
7 0
+-------------------------------+
| DST_SLOT_ID |
+-------------------------------+
| SRC_SLOT_ID |
+-------------------------------+
| STATUS_BYTE_COUNT |
+---------------+---------------+
| SLOT_TYPE | REASON |
+===============+===============+
= STATUS =
+-------------------------------+
| UNPREDICTABLE | (only exists if
+-------------------------------+ STATUS_BYTE_COUNT is odd)
o DST_SLOT_ID - a reference to a slot block
o SRC_SLOT_ID - a reference to a slot block
o STATUS_BYTE_COUNT - an unsigned integer count of the length of the
STATUS field.
o REASON - an unsigned 4-bit integer, one of the following reasons
apply:
1. user requested disconnect
2. system shutdown in progress
3. invalid slot received
4. invalid service class
5. insufficient resources to satisfy request
6. (invent your own, please get reasons added to this document)
o SLOT_TYPE - the value 12. (1100)
o STATUS - STATUS_BYTE_COUNT bytes of status. The status field
meanings are defined separately for each service class.
This slot can only be transmitted from the host.
- 87 -
Local Area Transport Architecture - internal use only Page 88
MESSAGE FORMATS 03 May 84
10.1.2.6 Stop Slot -
7 0
+-------------------------------+
| DST_SLOT_ID |
+-------------------------------+
| SRC_SLOT_ID |
+-------------------------------+
| STATUS_BYTE_COUNT |
+---------------+---------------+
| SLOT_TYPE | REASON |
+===============+===============+
= STATUS =
+-------------------------------+
| UNPREDICTABLE | (only exists if
+-------------------------------+ STATUS_BYTE_COUNT is odd)
o DST_SLOT_ID - a reference to a slot block
o SRC_SLOT_ID - a reference to a slot block (must be zero)
o STATUS_BYTE_COUNT - an unsigned integer count of the length of the
STATUS field.
o REASON - an unsigned 4-bit integer, one of the following reasons
apply:
1. user requested disconnect
2. system shutdown in progress
3. invalid slot received
4. invalid service class
5. insufficient resources to satisfy request
6. (invent your own, please get reasons added to this document)
o SLOT_TYPE - the value 13. (1101)
o STATUS - STATUS_BYTE_COUNT bytes of status. The status field
meanings are defined separately for each service class.
- 88 -
Local Area Transport Architecture - internal use only Page 89
MESSAGE FORMATS 03 May 84
10.1.3 Stop Message Format -
Stop message headers have MSG_TYPE equal to 2. The SRC_CIR_ID field must
always be zeroed in Stop messages.
7 0
+-------------------------------+
| CIRCUIT_DISCONNECT_REASON |
+-------------------------------+
| REASON_BYTE_COUNT |
+-------------------------------+
| |
= REASON_TEXT =
| |
+-------------------------------+
o CIRCUIT_DISCONNECT_REASON (2 bytes unsigned) - A zero value means no
reason is given. The currently defined reasons are:
1. No slots connected on virtual circuit.
2. Illegal message or slot format received.
3. VC_halt from user.
4. No progress is being made.
5. Time limit expired.
6. LAT_MESSAGE_RETRANSMIT_LIMIT reached.
7. Insufficient resources to satisfy request.
8. SERVER_CIRCUIT_TIMER out of desired range.
9. (make up your own reasons, but please get them added to this
document).
o REASON_BYTE_COUNT (1 byte) - Byte count of REASON_TEXT field.
Normally specified as zero.
o REASON_TEXT (REASON_BYTE_COUNT bytes) - This field of ASCII
characters contains the reason the stop message was sent.
- 89 -
Local Area Transport Architecture - internal use only Page 90
REFERENCES 03 May 84
11.0 REFERENCES
o "The Ethernet - A Local Area Network - Data Link Layer and Physical
Layer Specifications", DEC-INTEL-XEROX, V2.0, September 30, 1980.
o DNA NI DATA LINK ARCHITECTURAL SPECIFICATION, Digital Equipment
Corporation, 1982.
o DNA ETHERNET NODE PRODUCT SPECIFICATION, Digital Equipment
Corporation, 1982
- 90 -
APPENDIX A
SERVICE CLASS 1 - INTERACTIVE TERMINALS
This service class allows data terminal equipment to be remoted from a
host over an intervening Ethernet. Except for the latency associated with
reading and writing to the device, the host and terminal server user should
find that the remoted terminal performs similarly to a locally connected
terminal.
A.1 LOCAL AREA DIRECTORY SERVICE
This service class provides a local area directory service to allow users
at a terminal server to address host services without the manual intervention
of a network manager.
The directory service is very responsive to sudden changes in the local
area topology. All terminal servers discover that a particular host node is
available within milliseconds of the host node announcing the service. If a
host node should crash, the terminal servers can notify the users within a
few seconds that the host node may have crashed.
The directory service is based on the multicast mechanism built into the
Ethernet.
- 91 -
SERVICE CLASS 1 - INTERACTIVE TERMINALS Page A-2
LOCAL AREA DIRECTORY SERVICE 03 May 84
A.1.1 Groups
Connectivity may be restricted by use of group codes. This restriction
allows segmentation of the computing resources based on such criteria as
departmental ownership or physical location.
Host nodes are assigned to one or more groups. Terminals (or terminal
servers) are also assigned to one or more groups. Whenever a terminal and a
host node belong to the same group, those two system can interact. For
example:
+------------------------------------------------------------------------+
| H O S T S E R V I C E S |
+------+------+-----+------+-----+------+-----+------+-----+------+------+
|Node a| |Node b| |Node c| |Node d| |Node e|
+------+ +------+ +------+ +------+ +------+
|groups| |groups| |groups| |groups| |groups|
| 1,2 | | 1,9 | | 2,4 | | 9 | | 5,4,3|
+------+ +------+ +------+ +------+ +------+
| | | | |
v v v v v
These host nodes multicast datagrams periodically onto the Ethernet
| | | | |
v v v v v
Ether<---------------------------------------------------------------------->net
| |
v v
Terminal servers build up and present lists of available
host nodes and host services at each terminal based on group codes
| |
v v
-------------------- -------------------
/ Available services: \ / Available services: \
| a,b,c,d,e | | b,d,e |
+----------------------+ +---------------------+
+--------+ +--------+
|oooooooo| |oooooooo|
+--------+ +--------+
Terminal at Terminal at
terminal server a terminal server b
(groups-2,5,9,14) (groups-5,9)
The HOST_GROUPS field in the multicast message is a bit mask of 256 bits.
If a bit is set, then the host node is a member of that group. The first bit
of the mask (bit 0) corresponds to group 0. A maximum of 256 groups can be
specified (0-255) and therefore this field's maximum length is 32 bytes.
The purpose of the host node group field is to allow the user at a server
to control the display, not to restrict connectivity between hosts and
terminal servers. Without this capability, a server user might be annoyed by
the length of the display of available host services.
- 92 -
SERVICE CLASS 1 - INTERACTIVE TERMINALS Page A-3
LOCAL AREA DIRECTORY SERVICE 03 May 84
Terminal servers (users) are assigned group numbers and discard all
multicast datagrams that do not specify one of the group numbers assigned to
the terminal server.
When group 0 is enabled in the terminal server, host nodes that are in
group 0 and multicast messages which do not specify any group codes (i.e.,
specify the HOST_GROUP_LENGTH field as zero) are displayed to the users.
A terminal server implementation should provide a privileged user with a
single command which enables all group codes.
A.1.2 Specification Of Names
The NODE_NAME and SERVICE_NAME specified in the host multicast message are
constrained to contain the following characters:
o "$" - dollar sign character, ascii code 36.
o "-" - hyphen or dash, ascii code 45.
o "." - period, ascii code 46.
o "0 through 9" - numerals, ascii codes 48 through 57.
o "A through Z" - upper case letters, ascii codes 65 through 90.
o "_" - underscore, ascii code 95.
o "a through z" - lower case letters, ascii codes 97 through 122.
o "part of the international character set" - ascii codes 192 through
253.
These names, and the host service name specified by the terminal server
user are upcased before they are compared. Upcasing means subracting the
value 32 from the lower case letters in the range 97 through 122 and
subtracting 32 from the international character set in the range 224 through
253.
If characters in the international character are specified in service
names, only those terminals that support the international character set will
be able to select those host services.
Some implementations may not support the international character set. In
local area networks which include these cases, the international character
set should not be specified in names.
Any other ascii characters specified by the host ot terminal server user
should be printable. Control characters must ot be specified in ascii
fields.
- 93 -
SERVICE CLASS 1 - INTERACTIVE TERMINALS Page A-4
LOCAL AREA DIRECTORY SERVICE 03 May 84
A.1.3 Host
A.1.3.1 Initialization -
A host system manager may specify:
o group codes (R)
o host node name (R)
o host service names and ratings (R)
o the guaranteed minimum Ethernet data link receive buffer size (R)
o the maximum slot size that can be received (R)
o the maximum slot size that can be transmitted (R)
o the physical location of the host node
o a facility number
o host characteristics and status as defined by the particular service
class to which the host belongs
It is recommended that the system manager be required to specify none of
these parameters in order to communicate with terminal servers that belong to
group 0. In order to accomplish this, LAT host implementations must supply
reasonable default values for those parameters labeled (R) (see DEFINED
PARAMETERS AND RECOMMENDED OR REQUIRED DEFAULT VALUES).
A host node that has no assigned NODE_NAME or o assigned SERVICE_NAME may
not announce start of service. Instead, an error should be returned to the
system manager.
A.1.3.2 Host Group Codes -
If a host node wishes to allow any terminal server to attempt to utilize
services available at the host node, then group zero should be assigned at
initialization. If a host node wish to allow it's services to be available
to only certain terminal server (users), then the coordination of a
facility-wide group codes must be coordinated by the facility manager.
A.1.3.3 Host Node Names -
One or more ASCII names are specified in the multicast message transmitted
periodically by each host node.
Although an ASCII names can be up to 127 characters in length, a name
should be convenient for a user to remember and type. Hosts should not
specify names that are hard (or impossible) for terminal server users to
specify. Terminal servers must support a minimum ASCII name length of 16
bytes.
- 94 -
SERVICE CLASS 1 - INTERACTIVE TERMINALS Page A-5
LOCAL AREA DIRECTORY SERVICE 03 May 84
A host node must specify at least one NODE_NAME in the multicast message.
A host can specify more than eight SERVICE_NAMES, a terminal server is
required to buffer a minimum of eight SERVICE_NAMES. A terminal server is
require to update all of the information in a multicast datagram, or none of
it.
A.1.3.4 Steady-state Operation -
The host node should periodically multicast the multicast datagram. This
interval is measured in seconds and is specified in the HOST_MULTICAST_TIMER
field.
Whenever any of the information in the multicast datagram changes, the
MSG_INCARNATION must be incremented (modulo 256) and the CHANGE_FLAGS field
should reflect which field was changed. The CHANGE_FLAGS field bits are
toggled each time the associated field is changed. The flag remains in the
new state until the field is changed a second time.
A.1.3.5 System Shutdown -
When a host node is "shutting down", the HOST_STATUS field in the
multicast datagram should reflect the fact the the host is not accepting new
sessions.
If service is terminated by the host system manager, at LEAST one addition
multicast message should be transmitted to reflect this change of state.
- 95 -
SERVICE CLASS 1 - INTERACTIVE TERMINALS Page A-6
LOCAL AREA DIRECTORY SERVICE 03 May 84
A.1.4 Terminal Server
A.1.4.1 Initialization -
Whenever a terminal server is initialized, and no parameters are supplied
interactively, the following default values must be supplied by
implementations:
o Group code 0 is enabled (all groups are displayed).
o ^S and ^Q are used as the output flow control characters
o ^S and ^Q are used as the input flow control characters
o These same flow control defaults are used when a slot session is
established. Of course the host might change these values. When
the terminal enters "local" mode, the original default flow control
values are restored. If a previously active session is resumed, the
flow control setting of the session must be restored.
An implementation might allow a privileged terminal server user to
specify:
o group codes (R)
o the guaranteed minimum Ethernet data link receive buffer size (R)
o the circuit timer value (R)
o the maximum slot size that can be received (R)
o the maximum slot size that can be transmitted (R)
o the physical location of the terminal server
o a facility number
o a nickname used to refer to the terminal server
o server characteristic and status as defined by the particular
service class to which the terminal server belongs
It is recommended that an implementation not require a privileged terminal
server user to specify any of these parameters in order to communicate with
host nodes that belong to group 0. In order to accomplish this, an
implementation must supply reasonable default values for those parameters
labeled (R) (see DEFINED PARAMETERS AND RECOMMENDED OR REQUIRED DEFAULT
VALUES).
An implementation of a terminal server might allow all group codes to be
enabled with a single command.
If a privileged user disables group code 0 in the Terminal Server, and no
multicast messages has yet been received that specifies one of the group
codes 1-256, then no host services will be displayed to the user.
- 96 -
SERVICE CLASS 1 - INTERACTIVE TERMINALS Page A-7
LOCAL AREA DIRECTORY SERVICE 03 May 84
A.1.4.2 Building The Circuit Name Database -
Each Terminal Server build a database from the information received in
multicast datagrams. A terminal service is require to process all of the
information in a multicast datagram, or none of it.
Terminal servers receive multicast datagrams periodically from each host
node. Each time a multicast datagram is received, the terminal servers scan
a list of enabled group codes, and if one of the group codes in the multicast
datagram matches one of those assigned to the terminal server (user), then
the information in the multicast message is added to the local server
database (see section on LOCAL AREA DIRECTORY SERVICE). If group code 0 is
enabled in the terminal server, then all multicast messages specifying the
HOST_GROUP_LENGTH field as zero and those that are in group zero are stored.
If the multicast message contains a NODE_NAME which is not already in the
list, a new node entry is created and the information in the multicast
datagram is parsed into the entry. If the NODE_NAME has associated
SERVICE_NAMES, these too are added to the database.
If the NODE_NAME is already entered, the datagram MSG_INCARNATION field is
compared with the MSG_INCARNATION field stored in the list entry to see if
the information in this multicast datagram is identical to the data receive
previously from the host node. If this field has changed, then the
information in the multicast datagram is reparsed into the list entry
corresponding to the NODE_NAME. The CHANGE_FLAGS field should be used to
reduce the CPU time necessary to parse the entry.
If the NODE_NAME is already entered in the list, but as the message is
parsed into an existing entry it is determined that the message was received
from a different Ethernet address, the TOTAL_DUPLICATE_NODE_NAME counter
should be incremented. The newly received multicast datagram should replace
the existing entry. This behaviour is possible if a host node has access to
more than one Ethernet port and the port that was being used failed. The
host node might then start transmitting the same multicast datagram from a
different port. Of course, the name could be mistakenly sharded by more than
one host system. For this reason, the TOTAL_DUPLICATE_NODE_NAME counter is
maintained. The facility manager can diagnose this second abberant condition
by monitoring the node name from a terminal server and observing the changing
Ethernet 48-bit address.
Servers maintain the list of all names in memory.
If a terminal server has insufficient memory to buffer all of the received
multicast data, NODE_NAME entries are purged from this database in the
following order:
1. Timed-out - these are nodes that are known to be unavailable because
the LAT_MESSAGE_RETRANSMIT_LIMIT was reached on an active virtual
circuit associated with the host node.
- 97 -
SERVICE CLASS 1 - INTERACTIVE TERMINALS Page A-8
LOCAL AREA DIRECTORY SERVICE 03 May 84
2. Unknown - these nodes have stopped transmitting multicast messages
for more than 5 times the HOST_MULTICAST_INTERVAL seconds, and are
therefore assumed to be in an unusual state (crashed).
3. Shutdown - these are host nodes that have indicated that they are no
longer accepting new virtual circuits.
4. Reachable (optional) - these are host nodes that are available, but
no virtual circuit is currently established to the node NODE_NAME.
If these names are purged from the server database, an unacceptable
CPU penalty may be exacted due to the high turnover rate of entries
in some implementations.
If after all of the above entries have been purged from the NODE_NAME
database, no entries are available, the multicast message is discarded.
Nodes associated with active virtual circuits are never purged from the node
data base.
A.1.4.2.1 Error Recovery -
If a connect to a SERVICE_NAME name fails, the list of SERVICE_NAMEs is
searched for an alternate NODE_NAME path to the SERVICE_NAME. If one is
found, a connection is attempted. This continues until a connection succeeds
or until all possible NODE_NAME paths to the selected SERVICE_NAME have
failed.
If 5 times the HOST_MULTICAST_TIMER seconds elapse in the terminal server,
and a terminal server has not received the multicast datagram corresponding
to a list entry, the entry status field is set to unknown.
- 98 -
SERVICE CLASS 1 - INTERACTIVE TERMINALS Page A-9
IMPLEMENTATION ISSUES 03 May 84
A.2 IMPLEMENTATION ISSUES
A number of very different host services can be presented using the
multicast message defined by service class 1.
A.2.1 Multiple Service Access Points
Define a service access point (SAP) as a preallocated host slot block in
the Halted state with an associated SERVICE_NAME. For example, consider this
host topology: eight physical RS232 ports and a single Ethernet port. The
problem is how to allow users to select a specific host SAP rather than any
random SAP in the host.
This can be accomplished by giving each different host SAP (group) a
different SERVICE_NAME in the multicast message transmitted by the host node.
This will cause the SERVICE_NAMES names to be presented to the users
seperately, but all sessions will be piggybacked over a single virtual
circuit to the host node.
A.2.2 Cluster Static Load Balancing
Clusters of machines might choose to present the same SERVICE_NAME in
their multiple multicast messages if they offer equivalent services. By
cooperating among themselves to establish a common SERVICE_NAME with
appropriate independent SERVICE_RATINGs, cluster members can arrange to share
the terminal user load. Digital Equipment VaxCluster present this type of
name space to LAT terminal servers.
A.2.3 Multiprocessors, Gateways, Virtual Machines
Multiprocessors may wish to present individual host system processors as
unique systems through a shared Ethernet port. More specifically, they may
require that messages arriving at the single Ethernet port contain slots all
destined for the same physical (virtual) processor.
This can be accomplished by assigning multiple NODE_NAMEs to a single
multiprocessor system which shares a single Ethernet port. This will cause a
terminal server to establish a new virtual circuit to each different
NODE_NAME.
Each NODE_NAME can still specify one or more SERVICE_NAMES. This would
allow piggybacking of sessions as usual. The same SERVICE_NAME can be
assigned to more than one NODE_NAME to achieve static load balancing.
- 99 -
SERVICE CLASS 1 - INTERACTIVE TERMINALS Page A-10
SERVICE CLASS 1 MESSAGE FORMAT EXTENSIONS 03 May 84
A.3 SERVICE CLASS 1 MESSAGE FORMAT EXTENSIONS
Each service class can define extensions to the messages in the main body
of the document. Service class 1 extends the Start slot and defines special
meanings to the Attention slot.
If the slot byte count is in conflict with a field byte count, the slot is
invalid. If the slot byte count truncates an extension to the slot, the slot
is valid and the extension is not supplied. If a byte counted field within a
slot status field is specified as zero length, the next byte following the
byte count is the first byte of the following field.
Bits are transmitted onto the Ethernet low order bit first. When fields
are concatenated, the right hand field is transmitted first. Numeric fields
more that 8-bits long are transmitted least significant byte first.
Fields are represented as bit streams, right to left. All fields are an
integer multiple of eight bits. The symbol "=" is used to indicate fields of
varying or indeterminate length.
- 100 -
SERVICE CLASS 1 - INTERACTIVE TERMINALS Page A-11
SERVICE CLASS 1 MESSAGE FORMAT EXTENSIONS 03 May 84
A.3.1 Start Slot Status Field
The Start slot sent to the host by the terminal concentrator is extended
by this service class. The Start slot sent by the host is not extended. All
of the fields in the Start slot extension are optional. The format of the
server-to-host Start slot is:
7 0
+-------------------------------+
| DST_SLOT_ID |
+-------------------------------+
| SRC_SLOT_ID |
+-------------------------------+
| STATUS_BYTE_COUNT |
+---------------+---------------+
| SLOT_TYPE | CREDITS |
+===============+===============+
| SERVICE_CLASS | <-- start of STATUS field
+-------------------------------+
| MINIMUM_ATTENTION_SLOT_SIZE |
+-------------------------------+
| MINIMUM_DATA_SLOT_SIZ |
+---------------+---------------+
| |DST_SLT_NAM_LEN|
= +---------------+
| DST_SLOT_NAME =
+---------------+---------------+
| |SRC_SLT_NAM_LEN|
= +---------------+
| SRC_SLOT_NAME =
+-------------------------------+
| PARM_CODE | <- start of extension
+-------------------------------+
| PARM_LEN |
+-------------------------------+
= PARM_DATA =
+-------------------------------+
| PARM_CODE, PARM_LEN, and |
= PARM_DATA repeated until =
| PARM_CODE is equal to zero. |
+-------------------------------+ <- end of extension
| UNPREDICTABLE | (only exists if
+-------------------------------+ STATUS_BYTE_COUNT is odd)
- 101 -
SERVICE CLASS 1 - INTERACTIVE TERMINALS Page A-12
SERVICE CLASS 1 MESSAGE FORMAT EXTENSIONS 03 May 84
o DST_SLOT_ID - a handle on the remote slot block
o SRC_SLOT_ID - a handle on the local slot
o ...
o PARM_CODE (1 byte) - A parameter code. The value zero indicates the
end of the list (which means the following fields are
unpredictable). A non-zero value in this field indicates the next
two fields are valid. Parameter codes 0 through 127 are reserved
for use by Digital Equipment Corporation, while parameter codes 128
through 255 are reserved for users.
o PARM_LEN (1 unsigned byte) - the length of the following field in
bytes.
o PARM_DATA (PARM_LEN bytes) - the format of this field is defined by
the associated PARM_CODE.
The following parameters are defined for service class 1 - Interactive
terminals:
o Parameter code 0 is reserved.
o Parameter code 1, parameter length = 2 - Flag word.
- Bit 0 - Remote (modem) line if set to 1.
- Bit 1 - Disable interactive login if set to 1.
- Bit 2 - Reserved.
- Bit 3 - Reserved.
- Bit 4 - Reserved.
- Bits 5 - 15 are unpredictable.
o Parameter code 2 is reserved.
o Parameter code 3 is reserved.
o Parameter code 4 - Host service port identification. This parameter
is used to designate a particular physical port. The contents of
this field is an ASCII string which is the name of the physical
port. The structure of the name is implementation dependent.
o Parameter code 5 - Server service port identification. This
parameter is used to designate a particular physical port. The
contents of this field is an ASCII string which is the name of the
physical port. The structure of the name is implementation
dependent.
o Parameter code 6 is reserved.
o Parameter code 7 is reserved.
o Parameter codes 8 through 127 are unpredictable.
- 102 -
SERVICE CLASS 1 - INTERACTIVE TERMINALS Page A-13
SERVICE CLASS 1 MESSAGE FORMAT EXTENSIONS 03 May 84
A.3.2 Data_b Slot Status Field
The Data_b slot is extended by this service class. The slot can be sent
by either the host or the terminal server.
If this slot is received by the host, the host may choose to ignore the
break flag and always ignores the flow control functions.
A host implementation is required to send the flow control state to the
server at appropriate times. Normally this state information would be
transmitted whenever the flow control values change.
If a terminal server receives a break flag, it should attempt to signal
the break condition on the terminal output line. A terminal server must
process received flow control data.
A terminal server should transmit the break flag if two consecutive
"short" break events are detected on the terminal input line.
Note that this slot is flow controlled.
The format of the Data_b slot is:
7 0
+-------------------------------+
| DST_SLOT_ID |
+-------------------------------+
| SRC_SLOT_ID |
+-------------------------------+
| SLOT_BYTE_COUNT |
+---------------+---------------+
| SLOT_TYPE | CREDITS |
+===============+===============+
| CONTROL_FLAGS |
+-------------------------------+
| STOP_OUTPUT_CHANNEL_CHAR |
+-------------------------------+
| START_OUTPUT_CHANNEL_CHAR |
+-------------------------------+
| STOP_INPUT_CHANNEL_CHAR |
+-------------------------------+
| START_INPUT_CHANNEL_CHAR |
+-------------------------------+
| UNPREDICTABLE | (only exists if
+-------------------------------+ SLOT_BYTE_COUNT is odd)
o DST_SLOT_ID - a handle on the remote slot block
o SRC_SLOT_ID - a handle on the local slot block
o SLOT_BYTE_COUNT - an unsigned integer count of the length of the
SLOT_DATA field.
- 103 -
SERVICE CLASS 1 - INTERACTIVE TERMINALS Page A-14
SERVICE CLASS 1 MESSAGE FORMAT EXTENSIONS 03 May 84
o CREDITS (4 bits) - a 4-bit positive integer equal to the number of
credits being extended.
o SLOT_TYPE (4 bits) - the value 11.
o CONTROL_FLAGS (8 bits) :
o (bit 0) - Enable recognition of input flow control characters.
If set, this bit changes the meaning of STOP_OUTPUT_CHANNEL_CHAR
and START_OUTPUT_CHANNEL_CHAR in the terminal input stream.
Upon detecting one of these characters, the terminal server
should disable/enable terminal output stream as indicated, and
discard the character.
o (bit 1) - Disable recognition of input flow control characters.
If set, all characters in the terminal input stream are passed
directly through to the host without interpretation.
o (bit 2) - Enable recognition of output flow control characters.
If set, this bit changes the meaning of STOP_INPUT_CHANNEL_CHAR
and START_INPUT_CHANNEL_CHAR in the terminal output stream. If
the terminal server is about to overflow the terminal input
stream buffering, it should insert the STOP_INPUT_CHANNEL_CHAR
into the terminal output stream. When sufficient input
buffering is again available, the START_INPUT_CHANNEL_CHAR must
be inserted into the terminal output stream.
o (bit 3) - Disable recognition of output flow control characters.
If set, all terminal output characters are passed directly to
the output stream. No characters are generated by the terminal
server.
o (bit 4) - Break condition detected (terminal server to host
only).
o (bit 5 through bit 7) - Unpredictable.
o STOP_OUTPUT_CHANNEL_CHAR - The value assigned to stop the terminal
output stream if input flow control characters are enabled. The
value assigned is normally control-S.
o START_OUTPUT_CHANNEL_CHAR - The value assigned to start the output
channel if input flow control characters are enabled. The value
assigned is normally control-Q.
o STOP_INPUT_CHANNEL_CHAR - The value assigned to stop the terminal
input channel if output flow control characters are enabled. The
value ssigned is normally control-S.
o START_INPUT_CHANNEL_CHAR - The value assigned to start the terminal
input channel if output flow control characters are enabled. The
value assigned is normally control-Q.
- 104 -
SERVICE CLASS 1 - INTERACTIVE TERMINALS Page A-15
SERVICE CLASS 1 MESSAGE FORMAT EXTENSIONS 03 May 84
A.3.3 Attention Slot Status Field
The Attention slot is extended by this service class to include 1 byte of
control flags, and within the byte a single "abort" flag. It's purpose is to
discard all buffered data remaining to be delivered to the user. The slot
can be sent by either the host or the terminals server.
Host implementation is optional for both transmission and reception of the
slot.
The terminal server must process this slot if it is received, but
transmission of this slot is optional.
Note that this slot is not flow controlled.
The format of the Attention slot is:
7 0
+-------------------------------+
| DST_SLOT_ID |
+-------------------------------+
| SRC_SLOT_ID |
+-------------------------------+
| SLOT_BYTE_COUNT |
+---------------+---------------+
| SLOT_TYPE | MBZ |
+===============+===============+
| CONTROL_FLAGS |
+-------------------------------+
| UNPREDICTABLE |
+-------------------------------+
o DST_SLOT_ID - a handle on the remote slot block
o SRC_SLOT_ID - a handle on the local slot block
o SLOT_BYTE_COUNT - an unsigned integer count of the length of the
SLOT_DATA field - the value 1.
o MBZ (4 bits) - must be zero
o SLOT_TYPE (4 bits) - the value 11.
o CONTROL_FLAGS (8 bits) :
o (bit 0 through bit 4) - Unpredictable.
o (bit 5) - Abort. Causes buffered output data pipe to be flushed
of all data. Credits are returned as if the data had been
normally delivered.
o (bit 6 and bit 7) - Unpredictable.
- 105 -
SERVICE CLASS 1 - INTERACTIVE TERMINALS Page A-16
MESSAGE FORMATS 03 May 84
A.4 MESSAGE FORMATS
This service class defines the following additional message.:
1
5 0
+-------------------------------+
| DESTINATION_ADDRESS | E
| | T H
| | H E
+-------------------------------+ E A
| SOURCE_ADDRESS | R D
| | N E
| | E R
+-------------------------------+ T
| PROTOCOL_TYPE |
+===============================+
| SRV_CIRCT_TMR | MSG_TYP |M|R|
+---------------+-----------+-+-+
| LOW_PRTCL_VER | HIGH_PRTCL_VER|
+---------------+---------------+
| CUR_PRTCL_ECO | CUR_PRTCL_VER |
+---------------+---------------+
| CHANGE_FLAGS |MSG_INCARNATION|
+---------------+---------------+
| DATA_LINK_RCV_FRAME_SIZE |
+---------------+---------------+
| NODE_STATUS |NODE_MULTI_TIMR|
+---------------+---------------+
| NODE_GROUPS |NODE_GROUP_LEN |
| +---------------+
= NODE_GROUP_LEN group numbers =
+---------------+---------------+
| | NODE_NAME_LEN |
| +---------------+
= NODE_NAME_LEN ascii characters=
+-------------------------------+
| | NODE_DESC_LEN |
| +---------------+
= NODE_DESC_LEN ascii characters=
+---------------+---------------+
| SRVC_RATING |SRVC_NAME_COUNT|
+---------------+---------------+
| | SRCV_NAME_LEN |
| +---------------+
= SRCV_NAME_LEN ascii characters=
+-------------------------------+
| | SRVC_DESC_LEN |
| +---------------+
= SRVC_DESC_LEN ascii characters=
+-------------------------------+
| if SRVC_NAME_COUNT is greater |
- 106 -
SERVICE CLASS 1 - INTERACTIVE TERMINALS Page A-17
MESSAGE FORMATS 03 May 84
= than one, then the previous =
| five field are repeated here |
+---------------+---------------+
|NODE_SER_CLASES| NODE_SER_LEN |
| +---------------+
= NODE_SER_LEN service classes =
+-------------------------------+
= UNPREDICTABLE =
+-------------------------------+
o R (1 bit) - Response requested flag. Must be zero.
o M (1 bit) - Master flag. Must be zero.
o MSG_TYP (6 bits) - fixed at 10.
o SERVER_CIRCUIT_TIMER (1 byte) - Desired value in 10 millisecond
intervals. The node suggests a value in this field. The value may
be ignored by the terminal server. A zero specifies no preferred
value.
o HIGH_PRTCL_VER (1 byte) - Highest protocol version supported by
node.
o LOW_PRTCL_VER (1 byte) - Lowest protocol version supported by node.
o CUR_PRTCL_VER (1 byte) - Protocol version of this message.
o CUR_PRTCL_ECO (1 byte) - ECO level of CUR_PRTCL_VER (this message).
ECO (Engineering Change Orders) are always backwards compatible for
any given protocol version. If an ECO makes a change incompatible
with the previous version, a new (higher) protocol version must be
allocated.
o MSG_INC (1 byte) - Message incarnation. This multicast datagram is
transmitted periodically by each node. Any time ANY field within
this message changes value relative to the previous message, the
MSG_INCARNATION must be incremented by one. When the node assigns
this value to the first multicast message, a random value should be
chosen.
o CHANGE_FLAGS (1 byte) - Each bit in this byte corresponds to a field
in the multicast message that can change:
o bit 0 - Node group codes changed
o bit 1 - Node descriptor changed.
o bit 2 - Service names (and/or number of names) changed
o bit 3 - Service ratings changed.
o bit 4 - Service descriptors changed.
- 107 -
SERVICE CLASS 1 - INTERACTIVE TERMINALS Page A-18
MESSAGE FORMATS 03 May 84
o bit 5 - Service classes changed.
o bit 6 - unpredictable
o bit 7 - Other parameters changed.
If a field changes, the bit value toggles (0 -> 1 or 1 -> 0) and
then remains at that value as multicast messages are transmitted
until the field changes again.
o DATA_LINK_RCV_FRAME_SIZE (2 bytes) - The minimum and maximum sizes
of frames are restricted by the Ethernet specification to be in the
range 46 through 1518 bytes. A node must specify the guaranteed
minimum size receive buffer that it queues to the data link layer of
Ethernet. Legal values are restricted by the LAT architecture to be
in the range of 576 through 1518 bytes. Terminal servers never
transmit a datagram to a node that is longer than
DATA_LINK_RCV_FRAME_SIZE bytes. The node never queues a receive
buffer smaller than this size.
o NODE_MULTICAST_TIMER (1 byte unsigned) - The minimum rate at which
the node will send multicast messages in seconds.
o NODE_STATUS (1 byte bit mask) - Node status flags byte.
o Bit 0 - Set to 1 if the node is not accepting new sessions.
o Bits 1 through 7 - unpredictable.
o NODE_GROUP_LEN (1 byte unsigned) - A byte count of the NODE_GROUP
field. A value of zero is legal and indicates that the node belongs
only to group zero.
o NODE_GROUPS (NODE_GROUP_LEN bytes) - This field is specified as a
bit-mask of 256 bits. A bit set to 1 indicates the node belongs to
that group. The first bit of the mask (bit 0) corresponds to group
0.
o NODE_NAME_LEN (1 byte signed) - A byte count of the NODE_NAME field.
A value of zero is illegal.
o NODE_NAME (NODE_NAME_LEN bytes) - These characters are constrained
as described in the section entitled "Specification of names".
o NODE_DESCRIPTOR_LEN - (1 byte unsigned) - A byte count of the
NODE_DESCRIPTOR field. A value of zero indicates that no node
description is available.
o NODE_DESCRIPTION (NODE_DESCRIPTION_LEN bytes) - An ASCII string of
characters that describes the node.
o SERVICE_NAME_COUNT (1 byte unsigned) - This field is equal to the
number of service names offered. The next five fields are repeated
SERVICE_NAME_COUNT times.
- 108 -
SERVICE CLASS 1 - INTERACTIVE TERMINALS Page A-19
MESSAGE FORMATS 03 May 84
o SERVICE_RATING (1 byte unsigned) - the rating of the associated
service name.
o SERVICE_NAME_LEN (1 byte signed) - A byte count of the SERVICE_NAME
field. A value of zero is illegal.
o SERVICE_NAME (SERVICE_NAME_LEN bytes) - These characters are
constrained as described in the section entitled "Specification of
names".
o SERVICE_DESCRIPTOR_LEN - (1 byte unsigned) - A byte count of the
SERVICE_DESCRIPTOR field. A value of zero indicates that no service
description is available.
o SERVICE_DESCRIPTION (SERVICE_DESCRIPTION_LEN bytes) - An ASCII
string of characters that will help the terminal server user
identify the service being offered. The node should not load
control characters into this field. Terminal servers must support a
minimum SERVICE_NAME length of 64 characters.
o NODE_SERVICE_LEN (1 byte unsigned) - A byte count of the
NODE_SER_CLASES field. A value of zero is illegal.
o NODE_SERVICE_CLASSES (NODE_SERVICE_LEN bytes) - A node might
simultaneously support multiple service classes. A service class is
coded as a byte value in the range 0 to 255. The value zero is
reserved. This field is specified to make the architecture
extensible. A node must specify the service classes it supports.
The service classes defined at present are:
o CLASS 1 - Interactive terminals
o CLASS 2 - Application terminals
- 109 -
APPENDIX B
SERVICE CLASS 2 - APPLICATION TERMINALS
B.1 INTRODUCTION
Service class 2 is not fully specified and has not been approved for
implementation. An outline appears here simpy to show how service classes
will be interrelated.
An Interactive terminal is a device under the control of a user, while an
Application terminal is a device under the control of a computer process. In
some cases an Application terminal may not even have a keyboard: line
printers, video monitors and display windows fall into this class of
Application Terminal.
Before a computer process can allocate an Application terminal and write
to it, the name of the Application terminal must be made available to the
computer process and the computer process must have the authority to use the
device.
B.2 RELATIONSHIP TO SERVICE CLASS 1
Service Class 2 supports every detail of Service Class 1. The only
difference between the two different service classes are the extensions to
Service Class 1 made by Service Class 2.
B.3 ARCHITECTURAL MODEL
B.3.1 Host Node As Initiator Of Connect
In order to:
o preserve the investment in the host implementation
o to allow the shared Application terminal to be arbitrated
o to allow the host system to initiate sessions to terminal server
ports
- 110 -
SERVICE CLASS 2 - APPLICATION TERMINALS Page B-2
ARCHITECTURAL MODEL 03 May 84
host application processes "solicit" sessions with Application terminals.
B.3.2 Authorization
In the model presented in this Service Class, the device itself decides
which computer processes are authorized to allocate and use the device. A
host computer process, no matter how privileged within the context of the
host operating system, cannot allocated and use a Service Class 2 device
unless the device has been set up to service the group to which the host
system belongs.
B.3.3 Advertising Application Terminals
Host system processes find out about Application devices by listening to
to the Application terminal multicast address. Each server system supporting
Application Terminals multicasts this message periodically. The message
lists the names of the names of the Application terminals connected to the
server system.
1
5 0
+-------------------------------+
| DESTINATION_ADDRESS | E
| | T H
| | H E
+-------------------------------+ E A
| SOURCE_ADDRESS | R D
| | N E
| | E R
+-------------------------------+ T
| PROTOCOL_TYPE |
+===============================+
| | MSG_TYP |M|D|
+---------------+-----------+-+-+
| | PRTCL_VER |
+---------------+---------------+
| Application_terminal_name_1 |
+-------------------------------+
| Application_terminal_name_2 |
+-------------------------------+
| ... |
+-------------------------------+
| Application_terminal_name_N |
+-------------------------------+
- 111 -
SERVICE CLASS 2 - APPLICATION TERMINALS Page B-3
ARCHITECTURAL MODEL 03 May 84
B.3.4 Soliciting Application Terminals
If a host system wishes to use an Application terminal, it must transmit
this message to the server system on which the Application terminal is
attached. This message is physically addressed.
1
5 0
+-------------------------------+
| DESTINATION_ADDRESS | E
| | T H
| | H E
+-------------------------------+ E A
| SOURCE_ADDRESS | R D
| | N E
| | E R
+-------------------------------+ T
| PROTOCOL_TYPE |
+===============================+
| | MSG_TYP |M|D|
+---------------+-----------+-+-+
| | PRTCL_VER |
+---------------+---------------+
| Application_terminal_name |
+-------------------------------+
B.3.5 Sharing
Since a device might be busy at the time service is requested by a host
process, the following physically addressed message is used to reply to the
host system requesting service:
1
5 0
+-------------------------------+
| DESTINATION_ADDRESS | E
| | T H
| | H E
+-------------------------------+ E A
| SOURCE_ADDRESS | R D
| | N E
| | E R
+-------------------------------+ T
| PROTOCOL_TYPE |
+===============================+
| | MSG_TYP |M|D|
+---------------+-----------+-+-+
| | PRTCL_VER |
+---------------+---------------+
| Status of Application_terminal|
- 112 -
SERVICE CLASS 2 - APPLICATION TERMINALS Page B-4
ARCHITECTURAL MODEL 03 May 84
+-------------------------------+
[End of Document]
- 113 -
LATSPEC-CLASS-2.MEM
Service Class 2 Architecture - internal use only
Digital Equipment Corporation 19 June 1984
Title: Service Class 2 (Application Terminals) Architecture
File: STAR::WORK6:[YWOSKUS.DOC]SC2.MEM
Date: 19 June 1984
Author: John A. Ywoskus
Abstract: Service Class 2 (Application Terminals) Architecture
Associated document: Local Area Transport Architecture Specification
(Copies may be obtained from BERGIL::LAUCK)
Rev Description Author Date
Service Class 2 Architecture - internal use only
Digital Equipment Corporation 19 June 1984
CONTENTS
1 ASSUMPTIONS . . . . . . . . . . . . . . . . . . . . 3
2 INTRODUCTION . . . . . . . . . . . . . . . . . . . . 3
3 RELATIONSHIP TO SERVICE CLASS 1 . . . . . . . . . . 3
3.1 Additions To Service Class 1 . . . . . . . . . . . 3
3.2 Architecturally Controlled Values . . . . . . . . 4
4 GOALS OF SERVICE CLASS 2 . . . . . . . . . . . . . . 5
5 ARCHITECTURAL MODEL . . . . . . . . . . . . . . . . 6
5.1 Host Service As Initiator Of Connect . . . . . . . 6
5.2 Advertising Application Terminals . . . . . . . . 6
5.2.1 Service Class 2 Multicast Message . . . . . . . 6
5.3 Connecting To Application Terminals . . . . . . 14
5.3.1 Solicit Message . . . . . . . . . . . . . . . 16
5.3.2 Acceptance Message . . . . . . . . . . . . . . 19
5.3.3 Start Slot . . . . . . . . . . . . . . . . . . 21
5.4 Authorization . . . . . . . . . . . . . . . . . 22
5.5 Application Terminal Sharing . . . . . . . . . . 23
5.5.1 Exclusive Use . . . . . . . . . . . . . . . . 23
5.5.2 Serial Use . . . . . . . . . . . . . . . . . . 23
5.5.3 Concurrent Use . . . . . . . . . . . . . . . . 24
5.6 Disconnecting From Application Terminals . . . . 24
5.7 Flow Control . . . . . . . . . . . . . . . . . . 25
5.8 Session Status Information . . . . . . . . . . . 25
5.9 Message Loss During The Solicitation Sequence . 25
5.10 Slot Size And Credit Extension . . . . . . . . . 25
5.10.1 Implications For High Speed Devices . . . . . 26
6 IMPLEMENTATION ISSUES . . . . . . . . . . . . . . 27
6.1 Host Implementation Issues . . . . . . . . . . . 27
6.1.1 User's View Of Application Terminals . . . . . 27
6.1.2 High Speed Input Devices . . . . . . . . . . . 27
6.2 Server Implementation Issues . . . . . . . . . . 28
6.2.1 Device And Server Naming . . . . . . . . . . . 28
7 SAMPLE INTERACTION . . . . . . . . . . . . . . . . 29
Service Class 2 Architecture - internal use only
ASSUMPTIONS 19 June 1984
1 ASSUMPTIONS
This document assumes that the user is familiar with the LAT
protocol, communications via the Ethernet, and the details of the
Service Class 1 (Interactive Terminals) architecture.
2 INTRODUCTION
An Application Terminal is a device that is interfaced to a server
but under the control of a host service. An Interactive Terminal is a
device under the control of the terminal user. In some cases an
Application Terminal may not have a keyboard or even be a 'terminal'
at all: line printers, video monitors, scanners, and display windows
fall into this class of Application Terminal.
Service Class 2 defines an extension of Service Class 1 that
provides support for Application Terminals. Therefore, Service Class
2 uses the same underlying Local Area Transport (LAT) protocol as
Service Class 1 to effect the communication of data targetted for an
Application Terminal from a host node. This document will detail
message and slot formats required by Service Class 2 to initiate the
data transfer from the host node to the Application Terminal using the
LAT protocol.
3 RELATIONSHIP TO SERVICE CLASS 1
Service Class 2 supports every detail of Service Class 1. The only
difference between the two different service classes are the
extensions to Service Class 1 made by Service Class 2. Both service
classes use the same underlying LAT protocol to effect data transfer
between host node and server. Both service classes can coexist across
the same Virtual Circuit.
The primary difference between the two classes is that Service
Class 2 provides a mechanism for host initiated connects to the
server, while Service Class 1 provides a mechanism for server
initiated connects to the host. Since the LAT protocol requires that
the server initiate the connections between the host node and server,
additional message types are required in Service Class 2 to allow the
host node to "solicit" the server to initiate connections.
3.1 Additions To Service Class 1
The following list summarizes the differences between the two service
classes:
- 3 -
Service Class 2 Architecture - internal use only
RELATIONSHIP TO SERVICE CLASS 1 19 June 1984
o Additional messages are required by Service Class 2 for a
host service to solicit connections to Application Terminals
on a server. These messages are the Solicit and Acceptance
Messages. These messages are required because the host
service is not allowed to initiate a connection to the device
directly with the LAT Architecture. Servers always initiate
the connections, and the Solicit Message is the method that
the host uses to inform the server that it desires a
connection.
o Various extensions are required in the slot formats by
Service Class 2.
. Three additional parameters are provided in the Start
Slot. These are the REQUEST_IDENTIFIER,
SESSION_IDENTIFIER, and DEVICE_IDENTIFIER parameters,
numbered 6, 7, and 8, respectively.
. 'Device time limit exceeded' error with a value of 6 is
provided in the REASON field of the Stop Slot.
3.2 Architecturally Controlled Values
Several fields are defined and their values are controlled by the
Service Class 2 Architecture. This section is an addition to the
'Defined Parameters and Recommended or Required Default Values'
section of the LAT Architecture Specification. It summarizes
dependencies between Messages and Service Classes.
o DEVICE_IDENTIFIER - this is a word that identifies the
Application Terminal on the server. This value must be
unique on the server. Together with SERVER_NAME the
Application Terminal is therefore uniquely identified in the
Local Area Network.
o SESSION_IDENTIFIER - this is a word that the server assigns
to identify the connection (or connection solicitation)
between the Application Terminal and the host service. This
value must be unique across all currently active Application
Terminal sessions on the server.
o REQUEST_IDENTIFIER - this is a word that the host node
assigns to identify the connection (or connection
solicitation) between the host service and the Application
Terminal. This value must be unique across all currently
active Application Terminal sessions to that server.
The previous three fields overlap in the Solicit and
Acceptance Messages as well as the Start Slot.
- 4 -
Service Class 2 Architecture - internal use only
RELATIONSHIP TO SERVICE CLASS 1 19 June 1984
o SERVER_NAME - this is an ASCII string that must uniquely
identify the server in the Local Area Network. Together with
DEVICE_IDENTIFIER the Application Terminal is uniquely
identified in the Local Area network.
o SERVER_MC_TIMR - this is a word which specifies in seconds
how often the server will announce availability of
Application Terminals. Its value must be in the range 60 to
3600 seconds.
o SERVICE_NAME - this is an array that describes the name of
the service soliciting the connection to the Application
Terminal. If Service Class 1 is also implemented it must be
the same as the service advertised in the Service Class 1
Multicast Message.
o NODE_NAME - this is an array that describes the name of the
node providing the service that is soliciting the connection
to the Application Terminal. If Service Class 1 is also
implemented it must be the same as the node name specified in
the Service Class 1 Multicast Message.
o DEV_GROUP_LEN - this is a byte that specifies the length of
the group code mask array. A value of zero indicates that
the Application Terminal is accessible from all groups (as
qualified by the server group codes).
o SRVC_GROUPS - this is an array that specifies the group
code(s) associated with the host service that is soliciting
the Application Terminal. If Service Class 1 is implemented
this must be a subset of the NODE_GROUPS field in the Service
Class 1 Multicast Message.
o DATA_LINK_RCV_FRAME_SIZE - a word the server uses to specify
the guaranteed minimum size receive buffer that it queues to
the data link layer of Ethernet. Legal values are restricted
by the LAT architecture to be in the range of 576 through
1518 bytes. This value must be the same as for the
LAT_MIN_RCV_DATAGRAM_SIZE field in the Start Message issued
by the server.
4 GOALS OF SERVICE CLASS 2
Service Class 2 provides a mechanism for arbitrating conflicting
requests for Application Terminal connections from host nodes and for
effecting the communication of data to the Application Terminal from
the host node using the underlying LAT protocol. Service Class 2
therefore does not address higher level issues such as file transfer
or forms management.
- 5 -
Service Class 2 Architecture - internal use only
ARCHITECTURAL MODEL 19 June 1984
5 ARCHITECTURAL MODEL
Before a host service can solicit use of an Application Terminal
and send data to it, the name of the Application Terminal must be made
available to the host service and the host service must have the
authority to use the device. The host service then attempts to
solicit a connection to the device.
5.1 Host Service As Initiator Of Connect
In order to:
o preserve the investment in the host node implementation
o allow the shared Application Terminal to be arbitrated
o allow the host service to initiate sessions to server ports
o multiplex all data over a single Virtual Circuit
host services "solicit" connections to Application Terminals.
If the Application Terminal is already connected by some other host
service, the host node may still attempt to solicit a connection to
the Application Terminal. The request may be placed in a queue of
requests to the device for servicing at a later time, provided that
the device characteristics permit such queueing. Note that a
mechanism exists in this Service Class to cancel a previously issued
solicitation should the host node later decide not to use the device.
5.2 Advertising Application Terminals
The host node LAT implementation finds out about Application
Terminals by listening for the Application Terminal multicast address.
Each server system supporting Application Terminals multicasts this
message periodically. The message lists the names of the Application
Terminals connected to the server system. The range of the multicast
interval is architecturally defined and may vary within this range
depending on the server implementation of this service class.
5.2.1 Service Class 2 Multicast Message -
The next diagram presents the format of the Service Class 2
multicast message. Detailed descriptions of each field in the message
follow.
- 6 -
Service Class 2 Architecture - internal use only
ARCHITECTURAL MODEL 19 June 1984
Service Class 2 Multicast Message Format
15 0
+-------------------------------+
| DESTINATION_ADDRESS | E
| | T H
| | H E
+-------------------------------+ E A
| SOURCE_ADDRESS | R D
| (address of Server) | N E
| | E R
+-------------------------------+ T
| PROTOCOL_TYPE |
+===============================+
| unused | MSG_TYP |M|R|
+---------------+-----------+-+-+
| LOW_PRTCL_VER | HIGH_PRTCL_VER|
+---------------+---------------+
| CUR_PRTCL_ECO | CUR_PRTCL_VER |
+---------------+---------------+
| CHANGE_FLAGS |MSG_INCARNATION|
+---------------+---------------+
| DATA_LINK_RCV_FRAME_SIZE |
+---------------+---------------+
| SERVER_MC_TIMR |
+-------------------------------+
| SERVER_STATUS |
+-------------------------------|
| SERVER_NUMBER |
+---------------+---------------+
| SERVER_GROUPS |SERVER_GRP_LEN |
| +---------------+
= SERVER_GRP_LEN bytes =
+---------------+---------------+
| SERVER_NAME |SERVER_NAME_LEN|
| +---------------+
= SERVER_NAME_LEN ascii chars =
+---------------+---------------+
|SERVER_LOCATION| SERVER_LOC_LEN|
| +---------------+
=SERVER_LOC_LEN ascii characters=
+---------------+---------------+
| SERVER_DEV_COUNT |
Start of ----->+===============+---------------+
device area +--|NEXT_DEV_OFFSET| DEV_COUNT |
| +---------------+===============+
Byte | | NEXT_DEV_OFFSET |
offset | +---------------+---------------|
to | | DEV_GROUP_LEN | DEV_STATUS |
next | +---------------+---------------+
device | | DEV_GROUPS |
area = = DEV_GROUP_LEN group numbers =
- 7 -
Service Class 2 Architecture - internal use only
ARCHITECTURAL MODEL 19 June 1984
| +---------------+---------------+
| | DEV_TYPE | DEV_CLASS |
| +---------------+---------------+
| | DEV_NAME | DEV_NAME_LEN |
| + +---------------+
= = DEV_NAME_LEN ascii characters =
| +-------------------------------+
| | DEV_LOCATION | DEV_LOC_LEN |
| + +---------------+
= = DEV_LOCATION_LEN ascii chars =
| |-------------------------------|
| | DEV_Q_LENGTH |
| +-------------------------------+
| | DEV_IDENTIFIER |
| +---------------+---------------+
| | DEV_CHARS | DEV_CHAR_LEN |
| | +---------------+
= = DEV_CHAR_LEN bytes =
| +-------------------------------+
| | DEV_TIMER |
| +-------------------------------+
| | DEV_INPUT_SPEED |
| +-------------------------------+
| | DEV_OUTPUT_SPEED |
| +-------------------------------+
+->| if more than one Application |
= Terminal exists, the previous =
| seventeen fields are repeated |
End of ----->+---------------+---------------+
device area |SRV_SER_CLASSES| SRV_SER_LEN |
| +---------------+
= SRV_SER_LEN service classes =
+-------------------------------+
= UNPREDICTABLE =
+-------------------------------+
Service Class 2 Multicast Message Format (cont.)
o R (1 bit) - Response Requested Flag. Must be zero.
o M (1 bit) - Master flag. Must be 1.
o MSG_TYP (6 bits) - fixed at 11.
o HIGH_PRTCL_VER (1 byte) - Highest protocol version supported
by server.
o LOW_PRTCL_VER (1 byte) - Lowest protocol version supported by
server.
- 8 -
Service Class 2 Architecture - internal use only
ARCHITECTURAL MODEL 19 June 1984
o CUR_PRTCL_VER (1 byte) - Protocol version of this message.
o CUR_PRTCL_ECO (1 byte) - ECO level of CUR_PRTCL_VER (this
message). ECO (Engineering Change Orders) are always
backwards compatible for any given protocol version. If an
ECO makes a change incompatible with the previous version, a
new (higher) protocol version must be allocated.
o MSG_INCARNATION (1 byte) - Message incarnation. This
multicast datagram is transmitted periodically by each
Application Terminal server. Any time ANY field within this
message changes value relative to the previous message, the
MSG_INCARNATION must be incremented by one. When the server
assigns this value to the first multicast message, a random
value should be chosen.
o CHANGE_FLAGS (1 byte) - Multicast message change flags. Each
bit in this byte corresponds to a field in the multicast
message that can change:
. Bit 0 - Server group codes changed.
. Bit 1 - Server name changed.
. Bit 2 - Server location text changed.
. Bit 3 - Server device configuration changed.
. Bit 4 - Server device status changed.
. Bit 5 - Must be zero.
. Bit 6 - Must be zero.
. Bit 7 - Other parameters changed.
If a field changes, the bit value toggles (0 -> 1 or 1 -> 0)
and then remains at that value as multicast messages are
transmitted until the field changes again.
o DATA_LINK_RCV_FRAME_SIZE (2 bytes) - The minimum and maximum
sizes of frames are restricted by the Ethernet specification
to be in the range 46 through 1518 bytes. The server must
specify the guaranteed minimum size receive buffer that it
queues to the data link layer of Ethernet. Legal values are
restricted by the LAT architecture to be in the range of 576
through 1518 bytes. Nodes never transmit a Service Class 2
datagram to a server that is longer than
DATA_LINK_RCV_FRAME_SIZE bytes. The server never queues a
receive buffer smaller than this size. This value must be
the same as for the LAT_MIN_RCV_DATAGRAM_SIZE field in the
Start Message issued by the server.
o SERVER_MC_TIMR (1 word unsigned) - The minimum rate at which
the server will send multicast messages in seconds. The
value must be in the range 60 to 3600 seconds.
- 9 -
Service Class 2 Architecture - internal use only
ARCHITECTURAL MODEL 19 June 1984
o SERVER_STATUS (1 word bit mask) - Server status flags word.
. Bit 0 - Set to 1 if the server is not accepting new
device connections.
. Bits 1 through 15 - Must be zero.
o SERVER_NUMBER (1 word unsigned) - Server number. This is a
value assigned to the server by the server manager. It must
be unique across the Local Area Network.
o SERVER_GRP_LEN (1 byte unsigned) - Server group code byte
length. A byte count of the SERVER_GROUPS field. A value of
zero is legal and indicates that the server belongs only to
group zero. Maximum value is 32 (-> 256 bits).
o SERVER_GROUPS (SERVER_GRP_LEN bytes) - Server group code
mask. This field is specified as a bit-mask of up to 256
bits. A bit set to 1 indicates the server belongs to that
group. The first bit of the mask (bit 0) corresponds to
group 0.
o SERVER_NAME_LEN - Server name length. A byte count of the
SERVER_NAME field. A value of zero indicates that no server
name is available.
o SERVER_NAME (SERVER_NAME_LEN bytes) - Server name. An ASCII
string of characters that contains the name of the server.
These characters are constrained as described in the section
of the LAT Architecture Specification entitled "Specification
of Names". This name must be unique to the Local Area
Network.
o SERVER_LOC_LEN - (1 byte unsigned) - Server location name
length. A byte count of the SERVER_LOCATION field. A value
of zero indicates that no server location is available.
o SERVER_LOCATION (SERVER_LOC_LEN bytes) - Server location. An
ASCII string of characters that describes the location of the
server. These characters are constrained as described in the
section of the LAT Architecture Specification entitled
"Specification of Names".
o SERVER_DEV_COUNT (1 word unsigned) - Count of the devices
connected to the server. This is a count of all physical
devices interfaced to the server.
o DEV_COUNT (1 byte unsigned) - Count of the devices in the
following list. These devices may be available for usage by
host services via the Solicit Message.
The next seventeen fields are repeated DEV_COUNT times:
- 10 -
Service Class 2 Architecture - internal use only
ARCHITECTURAL MODEL 19 June 1984
o NEXT_DEV_OFFSET (1 byte unsigned) - Offset to next device
area. This is the number of bytes (not including the 2 bytes
for this field) that the following DEV fields occupy for this
particular device. It is the offset to the next DEV_OFFSET
field or to the SRV_SER_LEN field if this is the last device
entry in this message.
o DEV_STATUS (1 byte signed) - Application Terminal status. A
byte containing the status of the corresponding device.
. Bit 0 - Device available.
. Bit 1 - Device connected by a host service.
. Bits 2 through 7 - Must be zero.
o DEV_GROUP_LEN (1 byte unsigned) - Application Terminal group
code length. A byte count of the DEV_GROUP field. A value
of zero is legal and indicates that the Application Terminal
belongs only to all groups. The maximum value is 32 (-> 256
bits).
o DEV_GROUPS (DEV_GROUP_LEN bytes) - Application Terminal group
codes. This field is specified as a bit-mask of 256 bits. A
bit set to 1 indicates the Application Terminal belongs to
that group. The first bit of the mask (bit 0) corresponds to
group 0. See section on 'Authorization'.
o DEV_CLASS (1 byte unsigned) - Device class. A byte
containing the class to which the device belongs. Possible
values are:
. Value 0 - Unknown class.
. Values 1 through 255. - <TBS>
o DEV_TYPE (1 byte unsigned) - Device type. A byte containing
the type of device within the specified class. Possible
values are:
. Value 0 - Unknown type.
. Values 1 through 255. - <TBS>
o DEV_NAME_LEN (1 byte unsigned) - Device name length. A byte
containing the length in bytes of the DEV_NAME field. A
value of zero indicates no device name is available.
o DEV_NAME (DEV_NAME_LEN bytes) - Device name. An array of
ASCII characters that forms the name of the device as known
at the server. These characters are constrained as described
in the section of the LAT Architecture Specification entitled
"Specification of Names". This name is not constrained to be
- 11 -
Service Class 2 Architecture - internal use only
ARCHITECTURAL MODEL 19 June 1984
unique in the Local Area Network. It simply provides
decriptive text about the device. The LAN-wide 'unique'
device name may be derived from the pair <SERVER_NAME,
DEVICE_IDENTIFIER>.
o DEV_LOC_LEN - (1 byte unsigned) - Device location name
length. A byte count of the DEV_LOCATION field. A value of
zero indicates that no device location is available.
o DEV_LOCATION (DEV_LOC_LEN bytes) - Device location. An ASCII
string of characters that describes the location of the
device. These characters are constrained as described in the
section of the LAT Architecture Specification entitled
"Specification of Names".
o DEV_Q_LENGTH (1 word unsigned) - Device queue length. If the
Application Terminal is neither 'shareable' or 'allocatable',
it allows serial use by potentially many host services.
Since only one service may use it at a time in this case,
other solicitations for the device are queued by the server
for later processing. This field is a word containing the
number of Solicit Messages queued to the device.
o DEV_IDENTIFIER (1 word unsigned) - Device identifier. A word
containing a numeric identifier assigned by the server to the
device. This value must be unique within the server. This
value corresponds to the DEVICE_IDENTIFIER supplied by the
host service in the Solicit Message. This field facilitates
identifying the the Application Terminal (compared to
DEV_NAME).
o DEV_CHAR_LEN (1 byte unsigned) - Device characteristics
length. A byte containing the length in bytes of the
DEV_CHARS field.
o DEV_CHARS (DEV_CHAR_LEN bytes) - Device characteristics.
This field is specified as a bit mask of 8 * DEV_CHAR_LEN
bits. A bit set to 1 indicates that the device possesses the
corresponding characteristics. The mapping between bit
setting and characteristic is a function of the DEV_TYPE and
DEV_CLASS fields. The bits are defined as follows:
. Bit 0 - Device is allocatable
. Bit 1 - Device is shareable (bits 0 and 1 mutually
exclusive)
. Bit 2 - Even parity is enabled on the device
. Bit 3 - Odd parity is enabled on the device (bits 2 and 3
mutually exclusive)
. Remaining bits: <TBS>
- 12 -
Service Class 2 Architecture - internal use only
ARCHITECTURAL MODEL 19 June 1984
o DEV_TIMER (1 word unsigned) - Device timer. A word
specifying in minutes the maximum time that a given
application is allowed to use the Application Terminal after
which the session will be aborted. This field is used by the
server system manager to control the length of time that any
given application will use the Application Terminal in order
to assure availability to other host services. A value of 0
indicates there is no limit.
o DEV_INPUT_SPEED (1 word unsigned) - The approximate input
data rate in bytes per second of the Application Terminal. A
value of zero indicates that the speed is unknown. This
field must be specified if DEV_TIMER is nonzero so that the
host service can determine approximately how long the I/O
will take to complete.
o DEV_OUTPUT_SPEED (1 word unsigned) - The approximate output
data rate in bytes per second of the Application Terminal. A
value of zero indicates that the speed is unknown. This
field must be specified if DEV_TIMER is nonzero so that the
host service can determine approximately how long the I/O
will take to complete.
The previous field marks the end of the device area
corresponding to a specific Application Terminal.
o SERVER_SERVICE_LEN (1 byte unsigned) - Server service class
length. A byte count of the SERVER_SERVICE_CLASSES field. A
value of zero is illegal.
o SERVER_SERVICE_CLASSES (SERVER_SERVICE_LEN bytes) - Server
service classes. A server might simultaneously support
multiple service classes. A service class is coded as a byte
value in the range 0 to 255. The value zero is reserved.
This field is specified to make the architecture extensible.
A server must specify the service classes it supports. The
service class defined at present for this multicast message
format is:
. CLASS 1 - Interactive Terminals
. CLASS 2 - Application Terminals
The device area of the Multicast Message provides in depth
information about the devices listed. The device area is optional
because the host services may have prior knowledge about the devices
present on a particular server which is obtained independent of the
Multicast Message and the information conveyed here would be
redundant. Note that only two pieces of information are required of
the host service to connect to the device: the server name (which
- 13 -
Service Class 2 Architecture - internal use only
ARCHITECTURAL MODEL 19 June 1984
maps into a 48-bit Ethernet address) and the DEVICE_IDENTIFIER, which
may be gotten from the server manager.
An architectural restriction is that only one Multicast Message may
be transmitted every SERVER_MC_TIMR interval. This implies a limit on
the number of devices that may be advertised in detail (in this device
list) due to the contraint of the Ethernet packet size.
5.3 Connecting To Application Terminals
If a host system wishes to use an Application Terminal, it must
establish a connection to that terminal. The host node learns about
the Application Terminal from the multicast message transmitted by the
server. As described above, this message contains information
regarding the characteristics and status of the Application Terminal.
In particular, this information includes whether or not the device is
available and a count of how many host services are waiting to use it
(see 'Application Terminal Sharing' below) if it is currently busy.
Once the decision is made by the host node to establish a
connection, the host node formats a Solicit Message that will be sent
to the server (the server's physical Ethernet address is 'remembered'
from the multicast message previously issued). Such a Solicit Message
(specified below) informs the server of the host node's desire to use
the Application Terminal. (As discussed later, this message has two
additional uses: a) to cancel a previous solicitation, and b) to
inquire about Application Terminal status and solicitation queue
position.)
Upon receipt of the Solicit Message, the server replies with a) an
Acceptance Message or b) a Start Message or c) a Run Message
containing a Start Slot.
The Acceptance Message is only sent if the solicitation is rejected
by the server or if the solicitation is accepted but the Application
Terminal is currently being used by some other host service and the
device characteristics allow queueing of requests.
The Acceptance Message indicates rejection if
o there is a resource problem at the server,
o the request has exceeded the local (server) queue limit,
o the host node is not authorized to use the Application
Terminal as determined from Group Code assignments (see
section entitled 'Authorization'),
- 14 -
Service Class 2 Architecture - internal use only
ARCHITECTURAL MODEL 19 June 1984
o the host service requested exclusive use of the device and
the device did not have the 'allocatable' characteristic (see
section entitled 'Application Terminal Sharing'),
o the host service requested shared use of the device and the
'shareable' characteristic was not set (see section entitled
'Application Terminal Sharing').
The Acceptance Message indicates acceptance of the solicitation if the
device is busy with another host service and the device possesses
neither the 'allocatable' not 'shareable' characteristics. In this
case a 'session' identifier is assigned by the server and the
solicitation request is placed in a queue associated with the
Application Terminal. This session identifier and the queue position
are passed back to the host node in the Acceptance Message.
If queuing is allowed and the Application Terminal is not busy, or
if the device is either 'allocatable' or 'shareable', no acceptance
message is returned on success. Instead the server attempts to
establish the connection between the host node and the Application
terminal. The underlying Virtual Circuit may not already exist
between the server and the host node. If it already exists, then the
device connection uses the existing Virtual Circuit and a Run Message
containing a Start Slot is sent by the server to the host node.
If it doesn't exist, the Virtual Circuit must somehow be
established. There is an inherent asymmetry in the Virtual Circuit
establishment process as defined by the LAT Architecture, namely that
the establishment must be initiated by the server. Consequently, the
server will initiate the creation of the Virtual Circuit by sending a
Start Message to the host node (see below). The format of this Start
Message is presented in the LAT Architecture Specification and is not
repeated here.
If the Virtual Circuit already exists, it was created for one of
two reasons: a) it was created previously by the same host node
attempting to use an Application Terminal on the same server; or b) it
was created by a Service Class 1 (Interactive Terminal) user
establishing a connection to that host node (if Service Class 1 is
also implemented).
- 15 -
Service Class 2 Architecture - internal use only
ARCHITECTURAL MODEL 19 June 1984
5.3.1 Solicit Message -
The next diagram presents the format of the Service Class 2 Solicit
Message. Detailed descriptions of each field in the message follow.
15 0
+-------------------------------+
| DESTINATION_ADDRESS | E
| (address of Server) | T H
| | H E
+-------------------------------+ E A
| SOURCE_ADDRESS | R D
| (address of Host Node) | N E
| | E R
+-------------------------------+ T
| PROTOCOL_TYPE |
+===============================+
| SOLICIT_TYPE | MSG_TYP |M|R|
+---------------+-----------+-+-+
| DEVICE_IDENTIFIER |
+-------------------------------+
| REQUEST_IDENTIFIER |
+-------------------------------+
| SESSION_IDENTIFIER |
+---------------+---------------|
| NODE_NAME | NODE_NAME_LEN |
| +---------------+
| NODE_NAME_LEN ascii characters|
+---------------+---------------+
| SERVICE_NAME |SERVICE_NAM_LEN|
| +---------------+
| SERVICE_NAM_LEN ascii chars |
+---------------+---------------+
| SRVC_GROUPS |SRVC_GROUP_LEN |
| +---------------+
| SRVC_GROUP_LEN bytes |
+-------------------------------+
Solicit Message Format
o R (1 bit) - Response Requested Flag. Must be one.
o M (1 bit) - Master flag. Must be zero.
o MSG_TYP (6 bits) - fixed at 12.
o SOLICIT_TYPE (1 byte unsigned) - Solicit Message type code.
The Solicit Message is issued by the host node for various
reasons which are summarized by the type codes below:
- 16 -
Service Class 2 Architecture - internal use only
ARCHITECTURAL MODEL 19 June 1984
. Value 0 - Solicit exclusive use of the device. No other
host service may queue a request to the device while the
device is 'allocated' in this way. The device must have
the 'allocatable' characteristic set by the server for
this solicitation to succeed. (Note that the DEV_TIMER
parameter in the Multicast Message controls the length of
time that the device can be allocated in this way.)
. Value 1 - Solicit use of the device. This value is
passed if the message is used to solicit use of the
device. The request may be queued if the device is busy.
(Note that the DEV_TIMER parameter in the Multicast
Message controls the length of time that the service can
use the device once the connection is established.)
. Value 2 - Solicit shared use of the device. Possibly
many other host services may use the device concurrently.
The device must have the 'shareable' characteristic set
by the server for this solicitation to succees. (Note
that the DEV_TIMER parameter in the Multicast Message
controls the length of time that the service can use the
device once the connection is established.)
. Value 3 - Discard previous solicitation. This value is
passed if the message is used to cancel a previous
solicitation (ie cancel a previous Solicit Message with
SOLICIT_TYPE set to 1).
. Value 4 - Send status. This value is passed if the
Solicit Message is being used to obtain Application
Terminal status and the queue position of previously
issued solicitation (ie inquire about a previous Solicit
message with SOLICIT_TYPE set to 0, 1, or 2).
o DEVICE_IDENTIFIER (1 word unsigned) - Device identifier. A
word containing the device identifier assigned to the
Application Terminal by the server as advertised previously
by the Service Class 2 Multicast Message.
o REQUEST_IDENTIFIER (1 word unsigned) - Request identifier. A
word containing a solicit request identifier that is assigned
by the host node soliciting the Application Terminal
connection. This value is used by the host node to correlate
Acceptance Messages arriving from the server with Solicit
Messages sent by the node.
o SESSION_IDENTIFIER (1 word unsigned) - Session identifier.
This field contains the identifier of a previously issued
Solicit Message (ie one in which SOLICIT_TYPE was set to 0, 1
or 2). This field only contains this value when SOLICIT_TYPE
is set to 3 or 4. It must be 0 if SOLICIT_TYPE is 0, 1, or
2.
- 17 -
Service Class 2 Architecture - internal use only
ARCHITECTURAL MODEL 19 June 1984
o NODE_NAME_LEN (1 byte unsigned) - Host node name length. A
byte containing the length of the NODE_NAME field in bytes.
A value of zero is illegal when SOLICIT_TYPE is set to 0, 1
or 2.
o NODE_NAME (NODE_NAME_LEN bytes) - Node name. An array of
ASCII characters describing the name of the host node issuing
the Solicit Message. This name must be the same as the node
name specified in the Service Class 1 multicast message.
These characters are constrained as described in the section
of the LAT Architecture Specification entitled "Specification
of Names".
o SERVICE_NAM_LEN (1 byte unsigned) - Host service name length.
A byte containing the length of the SERVICE_NAME field in
bytes. A value of zero is illegal when SOLICIT_TYPE is set
to 0, 1 or 2.
o SERVICE_NAME (SERVICE_NAM_LEN bytes) - Service name. An
array of ASCII characters describing the name of the host
service issuing the Solicit Message. The same as the service
name specified in the Service Class 1 multicast message, if
Service Class 1 is also implemented. These characters are
constrained as described in the section of the LAT
Architecture Specification entitled "Specification of Names".
o SRVC_GROUP_LEN (1 byte unsigned) - Service group code byte
length. A byte count of the SRVC_GROUPS field. A value of
zero is legal and indicates that the service belongs only to
group zero. Maximum value is 32 (-> 256 bits).
o SRVC_GROUPS (SRVC_GROUP_LEN bytes) - Service group code mask.
This field is specified as a bit-mask of up to 256 bits. A
bit set to 1 indicates the service belongs to that group.
The first bit of the mask (bit 0) corresponds to group 0.
This field must be a subset of the NODE_GROUPS field of the
Service Class 1 Multicast Message if Service Class 1 is also
implemented.
- 18 -
Service Class 2 Architecture - internal use only
ARCHITECTURAL MODEL 19 June 1984
5.3.2 Acceptance Message -
The next diagram presents the format of the Service Class 2
Acceptance Message. Detailed descriptions of each field in the
message follow.
15 0
+-------------------------------+
| DESTINATION_ADDRESS | E
| (address of Server) | T H
| | H E
+-------------------------------+ E A
| SOURCE_ADDRESS | R D
| (address of Host Node) | N E
| | E R
+-------------------------------+ T
| PROTOCOL_TYPE |
+===============================+
| STATUS | MSG_TYP |M|R|
+---------------+-----------+-+-+
| REQUEST_IDENTIFIER |
+-------------------------------+
| SESSION_IDENTIFIER |
+-------------------------------+
| Q_POSITION |
+-------------------------------+
Acceptance Message Format
o R (1 bit) - Response Requested Flag. Must be zero.
o M (1 bit) - Master flag. Must be one.
o MSG_TYP (6 bits) - fixed at 13.
o STATUS (1 byte signed) - Solicitation status. A byte
containing a solicitation acceptance/rejection mask and
reason code. The bits are defined as follows:
o Bits 0-6 - Rejection reason code. Defined reasons are:
. 1 -> Host not authorized to use Application Terminal
. 2 -> No such device in configuration
. 3 -> Device disabled
. 4 -> Insufficient resources to queue request
. 5 -> Request already queued to device
. 6 -> No such SESSION_IDENTIFIER
. 7 -> Device not allocatable
- 19 -
Service Class 2 Architecture - internal use only
ARCHITECTURAL MODEL 19 June 1984
. 8 -> Device already allocated
. 9 -> Device not shareable
o Bit 7 - Solicitation accepted (0) or rejected (1)
o REQUEST_IDENTIFIER (1 word unsigned) - Request identifier. A
word containing the identifier of the Solicit Message
assigned by the host node. The REQUEST_IDENTIFIER is
returned here in order to provide the host node with a means
of identifying the solicitation request that is being
responded to.
o SESSION_IDENTIFIER (1 word unsigned) - Session identifier. A
word containing the identifier of the Solicit Message as
assigned by the server.
o Q_POSITION (1 word unsigned) - Queue position. A word
containing the position in the server's request queue of the
Solicit Message.
- 20 -
Service Class 2 Architecture - internal use only
ARCHITECTURAL MODEL 19 June 1984
5.3.3 Start Slot -
The following Start Slot parameters are defined for Service Class
2. Note that certain codes are reserved to facilitate implementation
with Service Class 1.
. Parameter code 0 is reserved.
. Parameter code 1, parameter length = 2 - Flag word.
- Bit 0 - Reserved.
- Bit 1 - Reserved.
- Bit 2 - Reserved.
- Bit 3 - Reserved.
- Bit 4 - Reserved.
- Bits 5 - 15 must be zero.
. Parameter code 2 is reserved.
. Parameter code 3 is reserved.
. Parameter code 4 - Host service port identification. This
parameter is used to designate a particular physical port.
The contents of this field is an ASCII string which is the
name of the physical port. The structure of the name is
implementation dependent.
. Parameter code 5 - Server service port identification. This
parameter is used to designate a particular physical port.
The contents of this field is an ASCII string which is the
name of the physical port. The structure of the name must be
the same as the DEV_NAME field in the Service Class 2
Multicast Message.
. Parameter code 6 - Request Identifier. This is a two byte
field containing the identifier of the Solicit Message that
initiated the connect by the server. This value is assigned
by the soliciting host service.
. Parameter code 7 - Session Identifier. This is a two byte
field containing the identifier of the previously received
Solicit Message. This is assigned by the server and is the
same value as would be returned in the Acceptance Message if
the device was busy and non-shared, non-exclusive access was
requested.
. Parameter code 8 - Device Identifier. this is a two byte
field containing the identifier of the device as assigned by
the server and announced in the Service Class 2 Multicast
Message.
The Request Identifier and Device Identifier allow the host
node to validate the connection to the Application Terminal.
. Parameter codes 9 through 127 are reserved.
Note that no queue depth indicator is returned as in the Start Slot
since the establishment of the connection means that the device is
'online' to the host service.
- 21 -
Service Class 2 Architecture - internal use only
ARCHITECTURAL MODEL 19 June 1984
The host node may choose to reject the establishment of the
connection by the server. A typical reason may be that the host node
has insufficient resources to complete the connection. The host node
tells the server to discard the request by responding with a Reject
Slot when the server issues the Start Slot.
5.4 Authorization
Group codes control the access of host services to Application
Terminals. A host service, no matter how privileged within the
context of the host operating system, cannot use a Service Class 2
device unless the device group code(s) have been set up to match the
group to which the host service belongs. Authorization is defined as
a match between the group code(s) assigned to the host service and the
group code assigned to the Application Terminal.
Four group code assignments exist: a) the server group code(s), b)
the Application Terminal group code(s), c) the host node group
code(s), and d) the host service group code(s). An architectural
requirement is that the Application Terminal code(s) be a subset of
the server code(s), and that the host service code(s) be a subset of
the host node code(s). Note that no orthogonal set of group codes
exists for Service Class 2: both Service Classes share the same group
code space.
The following presents the set of rules that must be followed to
control device access with the group code mechanism:
o Host nodes ignore Service Class 2 Multicast Messages of
servers whose server group code assignments do not overlap
with the host node's. Thus device availability may be
restricted on a host-wide basis.
o Connection solicitations from services on the host node
contain a service group code mask. The server accepts the
solicitation only if the group code(s) specified overlap the
group code(s) assigned to the Application Terminal (and
therefore the server group code(s)). If the service has no
group code(s) associated with it then the host node's group
code(s) are specified in the Solicit Message. If the host
node's group code(s) are not defined, then the Solicit
Message's SRVC_GROUP_LEN field is set to 0, indicating that
the service is assigned to group 0 (default).
Note that SRVC_GROUPS must be a subset of the NODE_GROUPS
field of the Service Class 1 Multicast Message if this
service class is also implemented.
- 22 -
Service Class 2 Architecture - internal use only
ARCHITECTURAL MODEL 19 June 1984
5.5 Application Terminal Sharing
Sharing of Application Terminals is an issue which must be
addressed by this service class. The first task is to define the
concept of 'sharing' a remote device.
Three types of device sharing are possible:
o exclusive use of the device by one host service (no sharing),
o serial use of the device by many host services,
o concurrent (parallel) use of the device by many host
services.
5.5.1 Exclusive Use -
Service Class 2 defines a mechanism for 'allocating' Application
Terminals through the Solicit/Accept exchange. This concept of
allocation or exclusive use simply means that the server will not
allow queuing of requests to the device. The host sending the first
Solicit Message requesting exclusive use of the device will retain
exclusive access to the device until the connection to the device is
broken.
For this to work, the host node must send a Solicit Message
requesting exclusive use and the server must have the 'allocatable'
characteristic set for the device. Requests for non-exclusive use of
the device when this characteristic is set will result in an error
issued by the server. Likewise, requests for exclusive use when this
characteristic is not set will result in an error being issued by the
server.
Note that if the DEV_TIMER field in the multicast message is nozero
this use of the Application Terminal will still be subject to the
specified time constraint.
5.5.2 Serial Use -
An Application Terminal is available for use by potentially many
host services. For this reason some form of connection arbitration
and queueing is required to be performed by the server. This scheme
provides an element of fairness since Solicit Messages are queued to
the Application Terminal by the server on a first come, first served
basis.
- 23 -
Service Class 2 Architecture - internal use only
ARCHITECTURAL MODEL 19 June 1984
As Solicit Messages arrive from host nodes they are queued to the
Application Terminal. They are then dequeued on a first-come,
first-served basis. When dequeued the host service has exclusive use
of the device until either the host node disconnects from the device
(eg finishes using it) or the server disconnects from the host node
(eg the device timer expired).
As requests move up to the beginning of the queue when sessions
complete, the next Solicit Message that is dequeued causes the server
to attempt a connection to the host node that sent the Solicit
Message. The host node can either accept the Start Slot that is
transmitted by the server by also sending a Start Slot, or it can
respond with a Reject Slot, indicating that the host node decided not
to use the Application Terminal after sending the Solicit Message.
In the first case, data transmission occurs by means of Run
Messages after the Start Slots are exchanged. In the second case, the
host node rejects the Start Slot by sending a Reject Slot. A
rejection would occur if the host node found another Application
Terminal to service the request after the original Solicit Message was
sent. Note that a mechanism is provided to the host node to 'cancel'
a queued solicitation.
For this mechanism to work the host node must solicit
non-exclusive, non-shared use of the Application Terminal. Moreover,
the server must not have the 'allocatable' or 'shareable'
characteristics set for the device.
5.5.3 Concurrent Use -
Sometimes it may be necessary for serveral host services to use the
Application Terminal concurrently. An example of this would be
multiple window terminals.
The server indicates that multiple sessions to the same Application
Terminal are possible by assigning the 'shareable' characteristic to
the device. The host node solicits shared use with SOLICIT_TYPE set
to 2 in the Solicit Message.
5.6 Disconnecting From Application Terminals
Connection (ie 'Session') termination and Virtual Circuit
termination are managed exactly the same as for Service Class 1. A
host node disconnects from an Application Terminal by sending the
server a Stop Slot. The server implicitly disconnects the host node
from the Application Terminal by sending a Stop Slot upon completion
of the session.
- 24 -
Service Class 2 Architecture - internal use only
ARCHITECTURAL MODEL 19 June 1984
A Stop Slot may be sent by the server if the session exceeds the
DEV_TIMER limit set at the server for the device. The reason
indicated in the Stop Slot would be 'device time limit exceeded',
assigned value 6 in the REASON field of the Stop Slot.
5.7 Flow Control
Flow control is identical to what is described for Service Class 1.
5.8 Session Status Information
The host node may require the ability to inquire the status of
sessions queued to a given Application Terminal. The Solicit Message
with SOLICIT_TYPE set to 4 is issued by the host node to the server in
order to perform this inquiry.
The server responds with an Acceptance Message supplying
device/session information.
5.9 Message Loss During The Solicitation Sequence
Should a Solicit Message from the host node become lost in
transmission to the server, the host node can retransmit the Solicit
Message at a maximum rate of once a second. No problem can arise from
duplicate requests being received by the server on behalf of the same
session because each request is 'tagged' with the REQUEST_IDENTIFIER
assigned by the host node. The server allows at most one Solicit
Message from a given host with a given REQUEST_IDENTIFIER. The
additional requests will be rejected with a 'request already queued'
error in the Acceptance Message that is sent in response.
5.10 Slot Size And Credit Extension
The LAT protocol provides five parameters to control the rate of
data transfer between host node and server with the LAT protocol.
These are:
o server circuit timer
o number of data link buffers queued
o size of queued data link buffers
- 25 -
Service Class 2 Architecture - internal use only
ARCHITECTURAL MODEL 19 June 1984
o number of slot credits extended
o size of slots
The first three parameters are specified in the Start Messages
exchanged between the server and host node when the Virtual Circuit is
established. The server circuit timer is the time period that elapses
between server transmissions to the host node. This value is sent by
the server to the host node in the SRV_CIRCT_TMR of the Start Message.
Halving the timer implies doubling the data rate. The number of data
link buffers queued is specified in the NBR_DL_BUFS field of the Start
Message. This field tells the other end of the Virtual Circuit how
many additional buffers (other than the normal one packet) are queued
for receipt of Ethernet packets for that Virtual Circuit.
After Virtual Circuit establishment credits are then extended to
control the number of slots exchanged. The greater the number of
credits extended, the greater the data throughput. The tradeoff here
is that other sessions sharing the Virtual Circuit may be 'crowded
out' of messages if one session (ie connection) has too many credits
associated with it and the transfer rate is high. Increasing
NBR_DL_BUFS would solve this problem, at the cost of memory in both
the host node and server.
5.10.1 Implications For High Speed Devices -
Service Class 2 is a device independent architecture. The
parameters cited above are provided by the LAT Architecture so that
the implementor of Service Class 2 can 'tune' the implementation
according to the types of devices to be supported.
High speed printers, for example, would require that additional
credits be extended by the server to the host node over what would be
required for interactive terminals. The server circuit timer might
have to be adjusted downward to maintain the required throughput. If
many Service Class 2 devices exist on the same server than NBR_DL_BUFS
would have to be increased to accomodate them all if the number of
credits extended is high. This would also be true if Service Class 1
terminals are also using the same Virtual Circuit, to ensure that the
interactive users are not 'crowded out' by a high speed device on the
same server.
- 26 -
Service Class 2 Architecture - internal use only
IMPLEMENTATION ISSUES 19 June 1984
6 IMPLEMENTATION ISSUES
The next two sections present various considerations that will
impact the implementation of Service Class 2 at both the host node and
server.
6.1 Host Implementation Issues
Host node implementations of Service Class 2 should take note of
the following considerations:
o Host node user's view of Application Terminals
o High speed input devices
o <<<Others ?>>>
6.1.1 User's View Of Application Terminals -
The concept of a truly remote device that appears directly
connected to a host node should be made as transparent to the user as
possible. The host node implementation of Service Class 2 therefore
should ensure that the device names and access methods are identical
to those for locally connected devices.
Servers supporting Service Class 2 provide the server name and
optionally a DEVICE_IDENTIFIER for the Application Terminals
interfaced to the server. This DEVICE_IDENTIFIER may be determined by
other means (by asking the server manager, for example). When the
server name is paired with the DEVICE_IDENTIFIER a LAN-wide unique
name is derived. The DEV_NAME field provides descriptive text about
the device. (For example, 'Development Group LN01'.)
The host implementation should bind the unique <SERVER_NAME,
DEVICE_IDENTIFIER> pair to a local device name. Note that DEV_NAME
may map onto several of these unique name pairs.
6.1.2 High Speed Input Devices -
Host node implementations of Service Class 1 may historically be
tuned for high speed output and low speed input. An implementation of
Service Class 2 that is built upon a Service Class 1 implementation
may experience performance problems that are not the result of a flaw
in the Service Class 2 Architecture (input and output are presented
symmetrically in the model), but rather of an inherent implementation
- 27 -
Service Class 2 Architecture - internal use only
IMPLEMENTATION ISSUES 19 June 1984
bias toward output performance.
6.2 Server Implementation Issues
Server implementations of Service Class 2 should take note of the
following considerations:
o Device and Server Naming
o <<<Others?>>>
6.2.1 Device And Server Naming -
Server names and device names are required to be unique within the
Local Area Network to avoid confusion. While the SERVER_NAME field of
the Service Class 2 Multicast Message is architecturally constrained
to be unique in the Local Area Network, the DEV_NAME field is not.
This field simply provides text to describe the device.
Uniqueness of device names depends on uniqueness of server names
and the uniqueness of the DEVICE_IDENTIFIER within a server. A
LAN-wide unique device name may be derived from the <SERVER_NAME,
DEVICE_IDENTIFIER> pair. Note that DEV_NAME may map onto several of
these unique name pairs.
- 28 -
Service Class 2 Architecture - internal use only
SAMPLE INTERACTION 19 June 1984
7 SAMPLE INTERACTION
The following diagram presents the message flow for a host node
soliciting an Application Terminal on a server that has other sessions
already queued to the device:
Host Server
| Multicast Message |
|<-------------------------------|
= =
User issues | Solicit Message (solicit) |
'print' cmd |------------------------------->|
| Acceptance Message (accept) | Request is
|<-------------------------------| queued
= =
User issues | Solicit Message (status) |
'SHOW QUEUE' |------------------------------->|
| Acceptance Message (status) | Session status
|<-------------------------------| is returned
= =
| Start Message | Server
|<-------------------------------| starts VC
| Start Message |
|------------------------------->|
| Run Message (Start Slot) | Server
|<-------------------------------| starts connect
| Run Message (Start Slot) |
|------------------------------->|
| Run Message (Data) | Data flow starts
|------------------------------->|
= =
Session finishes| Run Message (Stop Slot) |
|------------------------------->|
VC is killed | Stop Message |
|------------------------------->|
Exchange between Host and Server
The above diagram shows an exchange between the host and the server
in which the host solicits the device, the server accepts the
solicitation, and the host later accepts the connection to the device.
[End of Document]
- 29 -
Service Class 2 Architecture - internal use only
SAMPLE INTERACTION 19 June 1984
CC:
alien::chapman
alien::pettengill
aurora::hallyb
aurora::lindenberg
bergil::lauck
bergil::perlman
bergil::oran
delphi::beck
delphi::mann
delphi::ywoskus
glivet::ofsevit
hydra::avery
mother::pitcher
phenix::strecker
rune::t_day
smaug::bailey
spags::martin
spags::sudama
spags::maiewski
star::gamache
star::rspitz
star::vannoy
star::robert
star::drayton
syzygy::duffy
ultra::lipner
ultra::miller
castor::j_covert
smaug::ferguson
elrond::forecast
gidney::gunn
star::halvorsen
wilbur::kawell
vax4::grok::koning
gidney::palmieri
exodus::lapelle
marvin::kzin::janus::palka
kl2102::platukis
elrond::schriesheim
orc::yang
- 30 -
[END OF LAT-INFO.MEMOS]