top - download
⟦8faf704fd⟧ Wang Wps File
Length: 42560 (0xa640)
Types: Wang Wps File
Notes: FIX/3232/PSP/0033
Names: »3195A «
Derivation
└─⟦507b19fd6⟧ Bits:30006135 8" Wang WCS floppy, CR 0282A
└─ ⟦this⟧ »3195A «
WangText
…1a……00……00……00……00…*…0a……00……00…*…0b…* *…07…)…0c…)…01…)…06…(…09…(…0d…(…00…(
(…07…'…0c…'…00…'
'…06…'…07…&…09…&…0f…&…02…&
&…07…%…0a…%…0d…%…0e…%…0f…%…00…%…01…%…02…%
% %…05…%…06…%…07…$…08…$…09…$…0a…$…0b…$…0c…$…0d…$…0e…$…0f…$…00…$…01…$…02…$
…0f……02…/FIX/3232/PSP/0033
…02…CAH/821005…02……02…#
LTUX-CRYPTO/RED & BLACK PRODUCT SPECIFICATION
…0f……02……02…FK 7809
TABLE OF CONTENTS Page
11 LXPROS .......................................…02…100
11.1 Input .....................................…02…100
11.2 Output ....................................…02…101
11.3 Processing ................................…02…103
11.4 Data Structures ...........................…02…107
12 X25RXMOD/X25TXMOD ............................…02…108
12.1 Input .....................................…02…108
12.2 Output ....................................…02…109
12.3 Processing ................................…02…109
12.4 Data Structures ...........................…02…114
12.5 Reding the memory dump ....................…02…116
13 X25SUB .......................................…02…120
14 X25PRE .......................................…02…149
14.1 Input .....................................…02…149
14.2 Output ....................................…02…149
14.3 Processing ................................…02…150
15 HDLCRED/SYNCBLACK/INTTAB/EXTIRS ..............…02…151
15.1 Input .....................................…02…152
15.2 Output ....................................…02…153
15.3 Processing ................................…02…154
15.4 V24 Interface Usage .......................…02…161
15.5 Data Structures ...........................…02…167
15.6 Timing ....................................…02…169
16 LXPROM .......................................…02…172
16.1 Input .....................................…02…172
16.2 Output ....................................…02…172
16.3 Processing ................................…02…173
17 TESTGEN. .....................................…02…174
17.1 Input .....................................…02…174
17.2 Output ....................................…02…175
17.3 Processing ................................…02…175
17.4 Data Structures ...........................…02…176
18 TSTXFER ......................................…02…177
18.1 Input .....................................…02…177
18.2 Output ....................................…02…177
18.3 Processing ................................…02…177
19 LTMDCS .......................................…02…178
20 KERNEL .......................................…02…178
21 NEWKERN ......................................…02…191
22 QUALITY ASSURANCE ............................…02…205
23 PREPARATION FOR CHANGE AND DELIVERY ..........…02…205
11. L̲X̲P̲R̲O̲S̲
The LTUX-protocol, slave, controls the transfer of
messages between the LTUX-CRYPTO/RED and the NSS.
A flow control function is implemented with the LXPROS
submodule issuing a 'non-busy' packet when ready to
receive more packets on a certain CRYPTO channel (identified
by corresponding TRUNK-ID). If a packet is received
from the TDX-bus with a bad completion code, the packet
is rejected. If a packet is returned from the TDX-transmitter
with a bad completion code, the packet is retransmitted
until successful completion. The packet sequence is
not changed.
11.1 I̲n̲p̲u̲t̲
Message packets are received from the NSS via the TDX-bus.
The completion code in the buffer header is inspected
and if 0 the packet is accepted. Else the packet is
returned to the empty queue. The buffer format is
shown below.
byte: 0 1 2 3 4 5 6
518
Spare byte
used by
X25RXM
TRUNK-ID
X25-header
0-512 message
bytes
From the X25RXM submodule message packets with a corresponding format are received.
The state of the CRYPTO channels are read from the position:
CRCHST +(CRYPTO channel No.).
From the submodule X25TXM empty buffers are received when a packet has been acknowledged
or discarded.
From the TDX-bus interface empty buffers are received, when transmitted on the TDX-bus.
11.2 O̲u̲t̲p̲u̲t̲
The TRUNK-ID of the messages received from the NSS is converted to a CRYPTO channel No. by
use of the message CRYPTO system conversion table. The message is forwarded to the X25TXM
by insertion in one of the queues ROPQ10-ROPQ17, the last digit identifying the CRYPTO channel
number. The corresponding CRYPTO channel is set busy in the state table, CRCHST +(CRYPTO
channel No.). The corresponding X25INH byte in the X25 control table is reset to ensure
processing by X25TXM (if stopped due to missing ACK's).
If an X25.3 restart packet (issued during open trunk command) the restart flag of the corresponding
CRYPTO channel is set.
The messages received in RIPQ1 are forwarded for transmission on the TDX-bus, one by one.
Only when a packet has been succesfully transmitted, the next packet is handed over for
transmission. This is controlled by the flag TDXIFST, 0 meaning free, 3 meaning busy. When
a channel has changed its state to non-busy (CRCHST) a non-busy packet is generated with
the format:
byte 0 1 2 3 5
TRUNK-ID #50 #00
The TRUNKD-ID corresponds to the CRYPTO channel number. The packet is inserted for transmission
in RIPQ1 (together with the message packets).
Empty buffers received in ROEQ0 are forwarded for the TDX-interface routines. To avoid buffers
in the waiting queue of the interface routine a maximum of 3 buffers are forwarded any time.
Empty buffers received from a succesful transmission on the TDX-bus are inserted in the RIEQ0
if buffer length is 529 bytes (message buffers), else buffers are inserted in RIEQ1 (non-busy
packets, length 16 bytes).
11.3 P̲R̲O̲C̲E̲S̲S̲I̲N̲G̲
The processing is split into 4 parts as shown below:
LXPROS: Init command received? RETURN
Receiver processing (packets received the NSS on subdevice 3)
Channel state processing (generates the necessary non-busy packets).
Empty buffer processing/retransmit packet with unsuccesful completion code after
TX , and distributes empty byffer to RIEQ0 and RIEQ1).
Transmitter processing (forwards the packets in RIPQ1 one by one for transmission
on TDX-bus, subdevice 3).
A more detailed flow-gram of the different parts are shown on fig. 11.3-1 thru 11.3-4.
Packet reeived from NSS? LXPR25
y
If empty buffer in ROEQ0 then deliver empty buffer to subdevice 3
Extract error code from buffer header
If error code 0 then
increment error count,
return buffer to ROEQ0
set all channels to non-busy
else
if byte count =6 then
get TRUNK-ID
convert TRUNK-ID to CRYPTO channel No.
insert packet in queue (ROPQ10-ROPQ17)
set corresponding channel busy
reset X25-inhibit flag of channel
if X25.3 restart packet then set
restart flag of actual channel
else
return buffer to ROEQ0
LXPR25:
Test if 3 empty buffers ready for incoming traffic on subdevice 3.
if less then 3 buffers then
if empty buffer in ROEQ0 then
delivery buffer for subdevice 3.
Channel state processing
fig. 11.3-1…01…LXPROS, receiver processing
Get No. of last CRYPTO channel served by X25 protocol.
Get state of said channel.
If state = non-busy not reported then
Generate non-busy packet by calling PRPCHD:KERNEL.
If packet succesfully generated then
Insert packet for TX in RIPQ1.
Update max. element count of RIPQ1 (stored in WAITCNT).
Reset channel state to non-busy, reported.
Empty buffer processing.
fig. 11.3-2…01…LXPROS, channel state processing
If empty buffer ready from subdevice 3 then
Extract status code from buffer header.
If transmission succesfully then
get buffer size.
If buffer size = 16 then
return buffer to RIEQ1
else
adjust off-set to 0
return buffer to RIEQ0
Set TDX-IF state to non-busy
else
retransmit buffer
increment error count (TXERR)
Transmitter processing
fig. 11.3-3
…01…LXPROS, empty buffer processing
If TDX-I/F state non-busy then
if packet ready in RIPQ1 then
forward packet for transmission on TDX-bus, subdevice 3
Set state of TDX-I/F to busy
RETURN
…01…fig. 11.3-4…01…LXPROS, transmitter processing
11.4 D̲a̲t̲a̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲s̲
CRCHST: 8 bytes displaying CRYPTO channel state of channel 0-7. The state of the actual
channels is pointed out by CRCHST +(CRYPTO channel No.). The following states
are defined:
0: non-busy, reported
1: busy
2: non-busy, not reported.
OUTBERR: No. of packets received from the TDX-bus with bad completion code.
INBERR: No. of packets returned from transmission with bad completion code.
IRF: Init ready flag: 0: if no init received from CR80, 1 if init completed.
X25CTAB: X25 control table, ref. section 12.4
TDXIFST: 0: TDX-I/F subdevice 3 free
1: TDX-I/F subdevice 3 transmitting.
WAITCNT: Maximum No. of elements in RIPQ1 since last CRYPTO garbling status request.
12. X̲2̲5̲R̲X̲M̲O̲D̲/̲X̲2̲5̲T̲X̲M̲O̲D̲
To support the NSS with a virtually error free transmission medium from node to node on X25
level 2 (HDLC) protocol has been implemented in the LTUX-CRYPTO/RED. One independent protocol
is running per CRYPTO channel. The protocol is operating with a window size of 2. Packets
are retransmitted twice in case of missing ACK. In case of 3 timeouts (each 15 sec.) an
automatic restart is performed, and the involved packet is discarded. The protocol is transparent
as seen from the NNS, i.e. start and restart is automatically activated.
12.1 I̲n̲p̲u̲t̲
From the LXPROS submodule packets are received in queues ROPQ10 thru ROPQ17. From the HDLCRED
submodule packets waiting for ACK are returned in queues ROPQ30 thru ROPQ37.
Empty buffers used for the generation of protocol frames (S/U-frames) are taken from the
queue ROEQ1.
Packets accepted by the X25PRE submodule are received in queues RIPQ10 thru RIPQ17. Both
I-frames (messages) and S/U-frames (protocol control) may occur in these queues.
The service of the different channels are controlled by the variable X25SERV, containing
the number of the next channel to serve.
12.2 O̲u̲t̲p̲u̲t̲
I-frames and S/U-frames are delivered in ROPQ20 thru ROPQ27 for transmission by the HDLCRED
submodule. Accepted I-frames are delivered in RIPQ1 for transmission on the TDX-bus by the
LXPROS submodule.
Empty message buffer are returned in ROEQ0 by X25TXM submodule (ACK'ed or discarded (timeout)
packets), and in RIEQ0 by X25RXM submodule (packets discarded due to bad numbering).
12.3 P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
The two submodules, X25RXM and X25TXM are programmed as fully reentrant programs with a 32-bytes
data area allocated to each active CRYPTO channel. A maximum of 8 channels are allowed
The actual channel number to serve are determined by X25SERV. This variable is updated by
the X25RXM.
The protocol is state/event controlled, the state/event diagrams are shown in fig. 12.3-3.
An outline of the processing is given in the flowgrams in fig. 12.3-1 thru 12.3-2.
Get channel No. last serviced.
Update No. modulus max. channel No. (MNCRCH).
Get address of actual control table.
Get state of channel
Case state of
X25RC0: Get RXEVENT.
Write event No. to DAYFILE of actual channel
Case event of:
ACR0 ̲00:
.
.
.
ACRO ̲12:
X25RC1: Get RXEVENT
Write event No. to DAYFILE of actual channel
Case event of:
ACR1 ̲00:
.
.
.
ACR1 ̲12:
RETURN.
fig. 12.3-1
X25RXM, processing overview
Get channel No. to service.
Get address of actual control table.
Get state of channel.
Case state of
X25TCB Get TXEVENT
if event No. 7 then
issue disconnect command
start timer N-1
TX-STATE: 5.
X25TC1 Get TXEVENT
case event of
ACT1 ̲00
.
.
.
ACT1 ̲10:
X25TC2 Get TXEVENT
case event of
.
.
.
X25TC5 Get TXEVENT
case event of
ACT5 ̲00
.
.
.
ACT5 ̲10:
RETURN
fig. 12.3-2…01…X25TXM, processing overview
FIG. 12.3-3
X25RXM
12.4 D̲a̲t̲a̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲s̲
To control the processing of the X25.2 protocol of each CRYPTO channel, a 32 bytes control
area is allocated to each channel. The layout is shown in fig. 12.4-1.
fig. 12.4-1…01…X25.2 control table
The positions named TST nnnn are only used for test purposes during module test. TSTIFR
and TSTSFR may be used to introduce "transmission errors" on information frames and control
frames. The positions TSTFNO, TSTNFNO and TSTECNT are used to test the correct sequencing
of packets, that no packets has disappeared and that no packets has been duplicated. The
soft failure flag is set whenever a retransmission has been performed.
The flag is reset when a transmission report is generated.
The positions named X25 nnnn are used to control the X25.2 protocol as shown in the state/event
diagrams. The position X25LSTA is used to ensure proper clean-up in case of CRYPTO restart
or switch-over (initiated by front panel switches). The position X25INH is used to stop
the actual channel. This is done if a restart has been tried 3 times without success. The
channel reactivated when a frame is received for the channel, either from the NSS (CR80)
or from the black LTUX.
The position X25REIN is used to cause a restart when a X25.3 restart packet is received from
the NSS.
In excess of the control table a 32-bytes "dayfile" area is defined per channel. This area
is used to store the last 31 receiver events of the actual channel.
12.5 R̲e̲a̲d̲i̲n̲g̲ ̲t̲h̲e̲ ̲m̲e̲m̲o̲r̲y̲ ̲d̲u̲m̲p̲
Using the front panel switches as described in section 3.3 (switching standby channel on
before switching active channel off) generates a dump of the dayfile and X25 control table
areas. The dump is printed in hexadecimal numbers on the logprinter connected to jack 1.
The layout of the dump is shown in fig. 12.5-1.
In the dayfile dump the value "FF" indicates in which position the next receiver event will
be logged. The dayfile area is used in a cyclic manner and only contains the last 31 events.
A proper functioning channel will show the events, 1, 4 and 5. A complete list of the possible
receiver events are shown in fig. 12.1-2.
FIG. 12.5-1
LTUX-CRYTO/RED & BLACK
Test printout
Memory Dump…86…W …02… …02… …02… …02… …02…
0: No event (dummy)
1: I-frame received and accepted
(actual frame No., N(S) equal to expected frame No., V(R)).
2: I-frame received and rejected
(frame already received, N(S) V(R)).
3: I-frame received and rejected
(missing frame, N(S) V(R)).
4: S-frame with acknowledge of last frame (ACK(N-1)).
5: S-frame with acknowledge of last but one frame (ACK(N-2)).
6: S-frame with negative acknowledge of last frame, and acknowledge of last but one
frame (NAK(N-1), ACK(N-2)).
7: S-frame with negative acknowledge of last and last but one frame (NAK(N-1), NAK(N-2)).
8: S-frame with "Set asynchronous balanced mode" command (activation command).
9: S-frame with unnumbered acknowledge (UA).
10. S-frame with disconnect command (deactivation command).
fig. 12.5-2…01…X25.2 receiver events
In the X25.2 control table the TX-state and RX-state positions are of special interest.
The positions are marked in fig. 12.5-1. The most common states are shown in fig. 12.5-3.
TX RX
00 00 : Channel not used.
05 00 : Channel activation transmitted, but no response received. This combination
indicates a bad channel.
02 01 : Channel active and properly working. No outstanding frames.
03 01 : Channel active and properly working. One frame is outstanding.
04 01 : Channel active and properly working. Two frames are outstanding.
fig. 12.5-3…01…Common TX/RX-states
13. X̲2̲5̲S̲U̲B̲
To support the X25.2 protocol a number of subroutines have been defined. The different subroutines
are described in the corresponding headers, telling about processing and register usage.
A register not mentioned in the header is "do not care" with respect to entry, and "destroyed"
with respect to exit. The interrupt register "I" is never changed and neither the alternative
register set. On the following pages the subroutines are described.
14. X̲2̲5̲P̲R̲E̲
This submodule receives the inbound packets from the HDLCRED submodule. The CRC-result is
controlled. In case of error the packet is rejected. Further the trunk-ID of the packet
is checked. If known (in message CRYPTO system conversion table) the packet is handed over
to the corresponding X25.2 protocol. If TRUNK-ID is not found, the packet is rejected.
The submodule allows for "loop-back" trunk-ID's, e.g. at node K the trunk-ID KL1 is accepted.
14.1 I̲n̲p̲u̲t̲
X25.2 frames from HDLCRED submodules. The buffers are received in the queue RIPQ0. Off-set
in the buffer header is 0.
14.2 O̲u̲t̲p̲u̲t̲
If the frame is accepted, the buffer is inserted in one of the queues RIPQ10-RIPQ17. The
actual queue is determined by the CRYPTO channel No. (the last digit in the queue name indicates
corresponding CRYPTO channel).
If, for some reason, the packet is rejected, the buffer is returned to RIEQ0. If the buffer
contains 0 bytes (this causes the buffer to be rejected) an "X" is printed on the log-printer.
If the buffer was an I-frame (message) and less than 2 empty buffers are left, the buffer
is returned to RIEQ0 and an "r" is printed on the log.
14.3 P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
Frame ready in RIPQ0?
Byte count 0? …0e…n…0f… print "x"
CRC-accepted? …0e…n…0f…
…0e…n…0f… X25.2 I-frame?
At least 2 empty buffers in RIEQ0? print "r"
Assume external frame
Trunk-ID found in MCSCT …0e…n…0f… assume loop
…0e…back frame…0f…
Trunk-ID found …0e…n…0f…
in MCSCT
Insert frame in queue of Insert buffer in
corresponding CRYPTO empty buffer
channel (RIPQ10-RIPQ17) queue RIEQ0
15. H̲D̲L̲C̲R̲E̲D̲/̲S̲Y̲N̲C̲B̲L̲A̲C̲K̲/̲I̲N̲T̲T̲A̲B̲/̲E̲X̲T̲I̲R̲S̲.
These submodules controle the frame transfer between the RED and the BLACK LTUX. Also the
submodules controle the channel multiplexing, allowing all trunks to use the same CRYPTO
device. The HDLCRED submodule is running in the RED LTUX, the SYNCBLACK submodule in the
BLACK LTUX.
Both the HDLCRED and the SYNCBLACK submodules uses the submodules INTTAB and EXTISR.
The multiplexing principle is shown in fig. 12-1.
15.1 I̲N̲P̲U̲T̲.̲
HDLCRED:
Outbound X25.2 frames (I & S/U - frames) are received from the ROPQ20 - ROPQ27, the last
digit indicating CRYPTO channel No.
Empty buffers for inbound traffic are taken from RIE20. Status and control information are
read from the corresponding SIO-control table (CTAB2A for jack 3 and CTAB2B for jack 4).
Input from V24 interface are shown in fig.
SYNCBLANK:
Empty buffers for outbound frames are taken from BOEQ0. Inbound frames for transmission to
the red LTUX are fetched from BIPQ1. Status and control information are read from the corresponding
SIO-control table (CTAB1A for rack 1 and CTAB2A for jack 3). Input from V24 interfaces are
shown in fig.
INTTAB & EXTISR:
Status and control information are read from the corresponding SIO-control table. Characters
for transmission are read one by one from the actual buffer data area. Input from V24 interfaces
are shown in fig.
15.2 O̲U̲T̲P̲U̲T̲.̲
HDLCRED:
Inbound X25.2 frames (I & S/U - frames) are delivered to the X25PRE submodule in the queue
RIPQ0. Empty buffers for outbound frames are delivered in ROE2Q if the buffer contained an
I-frame (518 bytes) and the offset in the buffer header is set to 1. If the buffer contained
a S/U-frame the buffer is returned to ROEQ1 and the offset in the buffer header is set to
0.
Status and control information are written to the corresponding SIO-control table. Output
to V24 interfaces are shown in fig.
SYNCBLACK:
Outbound X25.2 frames are delivered for transmission on the BLACK TDX-bus (subroutine ODEPA
called). The subdevice No. to use is determined by: subdevice: = CRYPTO channel No. +3. Empty
buffers for inbound frames are delivered to the TDX-system by calling the subroutine IDEPA.
The subdevice No. to use is read from the buffer header, byte 1 (ref. section 16, LXPROM).
The byte is reset before calling IDEPA. Status and control information are written to the
corresponding SIO-control table. Output to V24 interface are shown in fig.
INTTAB/EXTISR:
Status and control information are read from the corresponding SIO-control table. Characters
received from the SIO are written to the actual buffer data area one by one. The result of
the cyclic redundancy check (CRC) is written to byte 9 in the corresponding buffer header
(only the RED LTUX). Output to V24 interface are shown in fig.
15.3 P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲.̲
Both the HDLCRED and the SYNCBLACK are state/event controlled. The submodules are split into
a TX- and a RX-part, activated separately by the LXROPS/LXBOPS submodule.
Two independent incarnations are defined for both the HDLCRED and the SYNCBLACK. For the
HDLCRED one is used to control jack 3 and the other one to control jack 4. For the SYNCBLACK
one is used to control jack 1 and the other one to control jack 3.
The incarnations are controlled by independent SIO control tables. Only one incarnation of
HDLCRED and one of SYNCBLACK are active at the same time. This is controlled by the submodules
CRYPTOSR and CRYPTOSB, respectively. The detailed processing is shown in the state/event
diagrams fig. 15.3-1 and fig. 15.3-2.
The submodule INTTAB is used to define the necessary interrupt routines to support the HDLCRED
and SYNCBLACK submodules. 4 different interrupt routines are defined. The routines are defined
by use of assembler macros and one set (4) of routines are defined per pack.
The routines defined are described below. &X in the name indicates that the suffix is defined
during macro layout.
TXBE&X:
Transmit buffer empty. Called when the SIO is ready for the next character to transmit. The
routine transfers a character from memory to actual SIO. In the corresponding SIO control
table the memory pointer is incremented and the bytes left counter decremented. If actual
bytes left count = 0 nothing is done. Memory pointer (TXPOS) must be initiated to buffer
start address -1 before first character transfer. Bytes left count must be initiated to character
count +1.
RXCA&X:
The routine is able to read one charcters from the actual SIO part to a memory location.
In the corresponding SIO-control table the memory pointer is incremented and bytes left count
decremented. If bytes left = 0, the state changes to state 6. Memory pointer RXPOS must be
initated to buffer start address -1 before first character transfer. Bytes left count must
be initiated to buffer size +1.
SRXC&X:
This routine is activated by the "special receive condition" interrupt from the SIO. In the
HDLCRED submodule, this interrupt is used to detect the end of frame. In RX-state 4 the error
state and the residue is read from the SIO and stored in the current buffer header, byte
9. The state is changed to 5.
If RX-state is anything else but 4 an error reset command is issued and no action taken.
EXTS&X:
This routine is activated by "external status interrupt" from the SIO. This interrupt may
be caused by different events. These are described below together with the EXTISR submodule.
The EXTS&X routine saves the current registers, activates EXTISR submodule and restores the
registers.
The EXTISR submodule processes the external status interrupts from the SIO. The reason for
this is read from SIO read register 0. The following events may occur:
Break/abort: Transmission of frame suspended.
TX-underrum/EOP: Transmitter has run out of characters.
Syncbyte (#7E) are transmitted.
CTS-line: The V24-line CTS has changed it's state.
SYNC/HUNT: If bit is set byte synchronization has been achieved and reception af frame
information may start.
DCD-line: The V24-line DCD has changed it's state.
FIG. 15.3-1
LTUX CRYPTO/RED
HDLCRED Driver
Transmitter Part
State/Event Diagram…86…W …02… …02… …02… …02… …02…
FIG. 15.3-1:
LTUX CRYPTO/RED
HDLCRED Driver
Receiver Part
State/Event Diagram…86…W …02… …02… …02… …02… …02…
FIG. 15.3-2
LTUX-CRYTO/BLACK
SYNCBLACK Driver
Transmitter Part
State/Event Diagram…86…W …02… …02… …02… …02… …02…
FIG. 15.3-2:
LTUX CRYPTO/BLACK
SYNCBLACK Driver
Receiver Park
State/Event Diagram…86…W …02… …02… …02… …02… …02…
15.4 V̲2̲4̲ ̲i̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲u̲s̲a̲g̲e̲.̲
The V24-signals used to control CRYPTO activation, CRYPTO garbling detection, channel multiplexing
and data transfer are shown in fig. 15.4-1.
The actual signalling is shown in fig. 15.4-2.
To achieve the needed number of V24-signals the LTUX-CRYPTO/RED back panel need some modifications.
These are shown in fig. 15.4-3.
The LTUX-CRYPTO/BLACK uses a standard DCE back panel.
FIG. 15.4-1
LTUX-CRYPTO/RED & BLACK
V24 - Interface
Specification…86…W …02… …02… …02… …02… …02…
FIG. 15.4-2:
LTUX-CRYPTO/RED & BLACK
V24 Signalling, Idle Run
FIG. 15.4-2
LTUX-CRYTO/RED & BLACK
V24 Signalling, Data Transfer…86…W …02… …02… …02… …02… …02…
FIG. 15.4-3:
LTUX-CRYTO/RED
Back Panel…86…W …02… …02… …02… …02… …02…
15.5 D̲a̲t̲a̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲s̲
To control the operation of the HDLC/SYNC driver a SIO control table is defined. One table
exists per driver process. Tables are identified by suffix = actual SIO channel (1A, 1B,
2A, 2B).
The table is mainly addresed by use of index register Ix and an offset value, only if speed
and compactness is the main thing the direct entries are used.
When a packet is transferred to the X25DMM submodule the standard buffer header (shown below)
contains an error code in byte No. 9. The layout of the byte is shown below. If packet
was received without any error the byte will contain 86H.
15.6 T̲i̲m̲i̲n̲g̲.̲
When running at 32 kbps, half duplex, one character is received/transmitted every 250 sec
The interrupt routines for receiving and transmitting a character are running
for 50 sec from interrupt to return.
Some interface routines (M-CPU to M-FE) are running for 200 sec without enabling interrupts.
Therefore a timer interrupt routine has to be stopped to avoid transmitter underrun/receiver
overrun. The timer is not used when transmitting or receiving.
As shown at fig. 15.4-2 some delays has been introduced in the channel multiplexing scheme.
The purposes of these delays are:
* To allow BID1000 to "clean up" before changing data flow. The time needed is the transmission
time of 80 bits, corresponding to 2.5 msec at 32 kbps.
* To allow log printer to print channel or receiver state. The time needed is 33 msec.
* To avoid deadlock due to different processing time and during channel shift. The time
needed is approximately 6 msec (worst case loop around time in LTUX-CRYPTO/RED is about
3 msec).
If needed improved performance may be achieved by reducing above delay to about 14 msec per
channel. The performance increase will be approximately 64 %, ref. below. The disadvantage
is that the test printout on the log-printer is no longer reliable.
Average multiplexing delay, outbound traffic, 4.5 trunks, delay 46 msec/chan., special delay
at channel O.
6̲7̲ ̲+̲ ̲3̲,̲5̲ ̲.̲ ̲4̲6̲ . 4̲.̲5̲ = 114 msec.
4.5
Tx-time, 16 bytes: 65,7 msec(including mux.signalling)
Tx-time, 518 bytes: 207,6 msec(including mux.signalling)
Weighted average TX-time, outbound:
114 + 65,7…0e….…0f…0.55 + 207.6 …0e….…0f… 0.45 = 243.6 msec/packet
corresponding to 4̲,̲1̲ ̲p̲a̲c̲k̲e̲t̲s̲/̲s̲e̲c̲.̲
Average multiplexing delay outbound traffic, 4.5 trunks, delay 14 msec/chan. (no special
delay at channel O)
Weighted average TX-time, outbound:
31.5 + 33.7 …0f….…0f… 0.55 + 175.6 …0f….…0f… 0.45 =
129.1 msec/packet
corresponding to 7̲.̲8̲ ̲p̲a̲c̲k̲e̲t̲s̲/̲s̲e̲c̲.̲
Average multiplexing delay, inbound traffic (4.5 trunks) delay 46 msec/chan., special delay
at channel O.
6̲7̲ ̲+̲ ̲3̲.̲5̲ ̲…8e….̲…8f… ̲4̲6̲ …0f…msec = 25.3 msec.
4.5 2
TX-time, 16 bytes: 67,1 msec
TX-time, 518 bytes: 205,5 msec
Weighted average TX-time, inbound:
25.3 + 67.1 …0e….…0f… 0.55 + 205.5…0e….…0f…0.45 = 154.7 msec/packet
corresponding to 6̲.̲5̲ ̲p̲a̲c̲k̲e̲t̲s̲/̲s̲e̲c̲.̲
Average multiplexing delay, inbound traffic (4.5 trunks), delay 14 msec/chan., (no special
delay at channel O).
Weighted average TX-time, inbound:
7 + 35.1 …0f….…0f… 0.55 + 173.5 …0f….…0f… 0.45 =
104.4 msec/packet
corresponding to 9̲.̲6̲ ̲p̲a̲c̲k̲e̲t̲s̲/̲s̲e̲c̲.̲
Total performance gain:
16. L̲X̲P̲R̲O̲M̲
This submodule is situated on the LTUX-CRYPTO/BLACK and controls the buffer transfer to and
from the black TDX-bus.
16.1 I̲n̲p̲u̲t̲.̲
Empty buffers are received from the subdevices 3-10, when the content has been transmitted
on the TDX-bus.
Packet buffers are received from subdevice 3-10. The buffers contains data received by the
LTUX-TRUNK communicating with the actual subdevice.
16.2 O̲u̲t̲p̲u̲t̲.̲
Empty buffers are delivered to the SYNCBLACK submodule in the queue BIPQ1. In case of a bad
completion code, the packet buffer is returned as empty to the actual subdevice. If byte
count is less than 6, the buffer is returned too.
16.3 P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲.̲
The processing is described by use of "pseudo" code.
LXPROM:
for I: = 3 until (max. No. of channels + 3) do
while packet buffer ready at subdevice I
get buffer
if packet OK, then
save subdevice No. in buffer header
insert packet in BIPQ1
else
return buffer to empty queue
for I: = 3 until (max. No. of channels + 3) do
while empty buffer ready at subdevice I
get buffer
insert buffer in BOEQO
RETURN.
17 T̲E̲S̲T̲G̲E̲N̲.̲
This subroutine is only active when the LTUX is in TEST mode. The subroutine generates test
messages and inserts these in ingoing (outbound) packet queue of subdevice 3. Message are
generated for actual CRYPTO channel if not busy, else nothing is done. If no empty buffer
is available nothing is done.
The routine also removes packets, if any, from outgoing (inbound) packet queue (RIPQ2) and
insert these in outgoing (inbound) empty buffer queue (RIEQ2).
The messages generated are provided with a sequence number module 256. This is done to verify
that the
X 25.2 protocol does not mix, duplicate or discard any packet.
17.1 I̲n̲p̲u̲t̲.̲
Empty buffers for generation of test messages are taken from ROEQO. Packet buffers are moved
from RIPQ2 to RIEQ2, and from RBCPQ1 to RBCEQ1. This is done to simulate transmission on
the TDX bus, subdevice 3 and 2, respectively.
The channel No. is read from ACCRCH and channel state (busy/non-busy, frame No.) is read
from the corresponding X25 control table.
17.2 O̲u̲t̲p̲u̲t̲.̲
The generated test messages are delivered in ROPQO. Packet buffers are moved from RIPQ2 to
RIEQ2, and from RBCPQ1 to RBCEQ1.
The external frame count in the actual X25 control table are up-dated.
17.3 P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲.̲
TESTGEN:
if initprocedure finished then
get actual channel No.
if channel non busy then
generate test message
get external frame count
up-date external frame count
insert TRUNK-ID in message
insert external frame count in message
insert message in ROPQO
if buffer ready in RIPQ2 then
transfer buffer to RIEQ2
if buffer ready in RBCPQ1 then
transfer buffer to RBCEQ1.
17.4 D̲a̲t̲a̲ ̲s̲t̲r̲u̲c̲t̲u̲r̲e̲s̲.̲
The test message used is shown below.
The spaces in the beginning of the message are replaced by TRUNK-ID and external frame count,
see fig. 17.4-1.
fig. 17.4-1
Test message format.
18 T̲S̲T̲X̲F̲E̲R̲.̲
The routine is used to transfer a buffer from outbound I/F queue to inbound I/F queue. The
corresponding crypto channel is set non-busy and the old buffer is returned to the empty
buffer queue.
If no empty buffer available for inbound messages then the old buffer is reinserted in the
outbound packet queue and the channel remains busy.
If more elements in outbound packet queue, all are removed as long as empty buffers are available
for inbound packets.
18.1 I̲n̲p̲u̲t̲.̲
Outbound packet buffers are received in BOPQO. Empty buffers for inbound traffic are received
in BIEQO.
18.2 O̲u̲t̲p̲u̲t̲.̲
Empty buffers for outbound traffic are returned to BOEQO. Packet buffers with inbound data
are delivered to RIPQ2.
18.3 P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲.̲
If buffer ready in BOPQO then
if empty buffer ready in BIEQO then
copy packet to new buffer
return old buffer to BOEQO
deliver new buffer to RIPQ2.
19 L̲T̲M̲D̲C̲S̲.̲
The TDX Device Configuration Submodule is used in the LTUX-S and LTUX-M for opening and closing
subdevices. Further parameters for programming the V24 line interfaces can be loaded to the
LTUX via this submodule.
The log-lines which are connecting hosts with subdevice No. 0 in the LTUX's are reserved
for the TDX-Device Configuration Protocol.
The protocol includes 3 commands for opening, closing subdevices and for loading an SIO parameter
block.
For further details ref.
TDX device configuration product specification
FIX/3232/PSP/0034.
20 K̲E̲R̲N̲E̲L̲.̲
In this submodule a number of subroutines common to many submodules are assembled. The different
subroutines are described in the corresponding headers, telling about processing and register
usage. A register not mentioned in the header is "do not care" with respect to entry, and
"destroyed" with respect to exit.
The interrupt register "I" is never changed and neither the alternative register set. On
the following pages the subroutines are described, a list of the names is given below:
TITCN, CNTTI, PRPCHD, INITSIO, WRJCK1, WRJCK2, TSTDAT.
21. N̲E̲W̲K̲E̲R̲N̲.̲
In this submodule a number of subroutines common to many submodules are assembled.
The different subroutines are described in the corresponding headers, telling about processing
and register usage. A register not mentioned in the header is "do not care" with respect
to entry, and "destroyed" with respect to exit.
The interrupt register "I" is never changed and neither the alternative register set. On
the following pages the subroutines are described, a list of the names is given below:
SETCTC, CTC39R, CTC3TIM, SETTIM, LED-ON,LED-OFF, BLINK, CTCDMM, BEVALXN.
22. Q̲U̲A̲L̲I̲T̲Y̲ ̲A̲S̲S̲U̲R̲A̲N̲C̲E̲.̲
Ref: FIX/3232/TPR/0036: LTUX-CRYPTO/RED & BLACK
Test procedure
FIX/3232/TPR/0059: LTUX-CRYPTO/RED & BLACK
Test report.
23. P̲R̲E̲P̲A̲R̲A̲T̲I̲O̲N̲ ̲F̲O̲R̲ ̲C̲H̲A̲N̲G̲E̲ ̲A̲N̲D̲ ̲D̲E̲L̲I̲V̲E̲R̲Y̲.̲
Restore files on development system, for tape No's reference current firmware release.
Make the changes wanted.
Assemble changed modules.
Link modules (link RED or link BLACK).
Verify that memory configuration is consistent with hardware layout.
Test new release according to testprocedure (FIX/3232/TPR/0036).
Burn new master PROM's. Note! In the LTUX-CRYPTO/RED the PROM 2179 must be burned in 2 steps,
from PROM address 0000H through 07FFH system firmware are stored (from CR1962 ̲5).
The application F/W are stored from 0800H through OFFFH.
Make new back-up and fire copy on tape.
Issue DCN to firmware release document (FIX/3031/LOG/0007).
